User talk:Paradox-01/Archive1

Contact

Only email or talk page. Got laptop back.

--paradox-01 (talk) 22:16, 4 March 2017 (CET)

Image categorization

I really appreciate you helping out with categorizing the images by class. I was hesitant to make a category for Konoko because she's in almost every image on the wiki, so it's a big task if we're going to be thorough. But I guess we can chip away at it. My main concern is that, if we only categorize *some* of each character's/class' images, then how do we ever know if we're done? That's why I was looking through all wiki images for each class that I categorized. That way I could know that I had truly found every image for that class, and cross it off the to-do list. Just something to think about in terms of how we keep track of our remaining work. Also, I wanted to mention that underscores don't matter in category (or any page) names. MediaWiki treats them as space characters, so we usually just use spaces instead. --Iritscen (talk) 22:06, 19 May 2017 (CEST)

---

Just a reminder to add categories to your images (in the Summary field) when uploading them. See my edits of today for examples of where things should go. Thanks. --Iritscen (talk) 21:48, 27 December 2017 (CET)

OniSplit source code

The source code can be retrieved by decompiling OniSplit.exe with "JustDecompile". After dragging and dropping the OniSplit into the decompiler you can already browse the code.

This should work with any version. This gives us the opportunity to compare them and fix bugs such as the recently discovered character dae export bug.

If you want to save the code as files, you go to Tools > Create Project.

After loading the project file into Microsoft Visual Studio Community 2015 Update 3 it looks all good at first sight. But in attempt to build a new exe quite a number of errors per file are shown. In total it's about 1100 whereby multiple errors are found in the same expression.

Oni.Func<Vector3, float> cSu0024u003cu003e9_CachedAnonymousMethodDelegate3 = RoomBuilder.CS$<>9__CachedAnonymousMethodDelegate3;

You can find the Main function in Program.cs --paradox-01 (talk) 16:47, 23 August 2016 (CEST)

Honestly, your time would be better spent just writing to Neo asking for a more recent release of the source. We've always known decompilation was a possibility, but then you lose comments and at least some symbol names, which makes the code unnecessarily difficult to work with. Neo has been holding out on releasing the source again until he reaches v1.0 or ports it to .NET Core, but he can probably be convinced to release it or at least fix bugs if you ask nicely. --Iritscen (talk) 18:55, 23 August 2016 (CEST)

What makes you think Neo will rewrite OniSplit for .Net Core (released 2016)? -- Anyway, I just found the decompiler by accident and thought it would be a nice addition to .. nothing. I don't have his email address anymore and he doesn't appear on yahoo. Our last chat dates back to 2015 September. Version 0.99 was and is the latest. He said he didn't changes the code for a long time. --paradox-01 (talk) 11:56, 24 August 2016 (CEST)

I said that he might rewrite OniSplit for .NET Core because he told me so :-) I think I have contact info for him, so I'll ask him about the state of OniSplit and a possible source release. --Iritscen (talk) 22:18, 24 August 2016 (CEST)

Sadly, since I have been unable to contact Neo, decompilation is looking like a more relevant option lately. I will write details about this in a more central location in the future, but I am thinking of porting OniSplit's features to C. The conversion code in OniSplit (-create/-extract) is what's really valuable -- the splitting part (-import/-export) should be trivial to re-create -- so for the really technical parts of Neo's code that none of us understand at the moment, we may need to start just dumping in functions composed of OniSplit's decompiled C#, ported to C or C++, and then make sense of those chunks of code in the future, pecking away at them over time. Initially, at least, we won't need to understand them as long as they produce the right results, and over time we can add comments and apply better symbol names if the originals get lost in the process. --Iritscen (talk) 17:00, 4 May 2017 (CEST)

Translations issues

• An English translation for RS related stuff was requested. Dunno if I really want to translate brainstorming stuff or if I distillate some parts and wreck the other.
• It has been suggested to put some stuff at Added value sections.
• Keeping track of quotes:

http://carnage.bungie.org/oniforum/oni.forum.pl?read=19468 (User:Paradox-01/quotes_chef_1)

http://forums.bungie.org/oni/archive.pl?read=15104

note about influences:

http://forums.bungie.org/oni/archive.pl?read=4618

search page (somehow defunct):

http://forums.bungie.org/oni/archive.pl?

two more pages (with undocumented sources, cannot find them again):

User:Paradox-01/quotes_clearfy

User:Paradox-01/quotes_old_questions

List of (now) unused sections

While translating I noticed two misplaced sections. "Where went all the details?" was actually part of "Griffin in a Syndicate helicopter?" but off-topic.

• Talk:Restless_Souls/Reconstruction/Gapfilling#Where went all the details.3F (contains Hardy's talk)
• Talk:Restless_Souls/Reconstruction/Gapfilling#Jamie (random thoughts)

Paradox, you do know about this page, right? -- [[Restless_Souls/Reconstruction/Summary_of_2032]]. It is orphaned, so I just wanted to make sure you didn't forget about it. --Iritscen 20:13, 28 February 2008 (CET)

^_^ Nah, it's not orphaned but part of [[Restless_Souls/Reconstruction/Story_factors]] as "{{:Restless_Souls/Reconstruction/Summary_of_2032}}"

I had split material bigger than 32kb and put it into separate pages.

But thanks for keeping an eye onto redlinks and such.

--Paradox-01 21:19, 28 February 2008 (CET)

Ah, good. Just checking. I never took the time to try to understand the structure of your Restless Souls pages. It's like you have your own little site as part of the wiki :) --Iritscen 21:54, 28 February 2008 (CET)

RS pages structure chart

Restless_Souls
|
+--> various links


Restless_Souls/Reconstruction
               | | |
               | | |
               | | +--> {{:Restless_Souls/Reconstruction/Gapfilling}}
               | +----> {{:Restless_Souls/Reconstruction/Global_development}}
               +------> {{:Restless_Souls/Reconstruction/Story_factors}}

XML Project

Question: "How should I *not* move pages?" Answer: "By using transclusion." :-P Normally you should use the Move tool, but since the OBD talk pages have had some actual "talk" on them, we probably want to selectively copy and paste the XML content to the new XML: pages. We can discuss this more later, I just wanted to let you know before you made any more "moves" :-) --Iritscen (talk) 02:48, 3 November 2012 (CET)

"Answer: By using transclusion"

By using {{:}}, like I did in XML:AISA ? When I switched off the PC I realized that it wasn't such a good idea (although there was no talk on that page).

XML:AISA doesn't appear in the search because there's no real content on it. So I agree with you to copy-paste the content. -- paradox-01 (talk) 11:15, 3 November 2012 (CET)

Solved. --paradox-01 (talk) 21:16, 6 November 2012 (CET)

Broken Links

Okay, I moved the pages that we agreed did not have notable history or extant discussion that needed to stay in the OBD namespace (sorry it took so long). Note that there are now red links on pages that referred to the moved pages. You could try going here and searching for "talk". Also, if you search there for "XML"... I assume those are just types that you haven't gotten to document yet? Just curious. --Iritscen (talk) 19:54, 6 November 2012 (CET)

"sorry it took so long" -- I don't mind. Thanks for your assistance. :)

Yes, there are two file types that still need documentation (and others for sake of completeness). Modding the combat behavior was never my favorite and SABD had not much attention so I used my time on different things. The others will be redirects, either because Oni don't use it (AITR) or because the XML for that instance simply exist as file type (AGQR, now part of AKEV).

There are one or two things I would like you to pick up: ONLV and maybe TRBS (see list for reason).

things that need care

XML:AITR replace with better link: redirect to TRGV (I was blindly following analogy to OBD template)

XML:AGQR replace with better link: redirect to ONLV (^)

XML:BINA/SABD todo: documentation

XML:BINA/OBJC/CMBT todo: documentation

XML:HPge todo: documentation (for sake of completeness)

possibly one or two other types that aren't of much use --paradox-01 (talk) 21:16, 6 November 2012 (CET)

Okay, I moved ONLV, but what did you want me to do with TRBS? It looks like you already cut-and-pasted it to XML:. But let me know what else I can do to help. --Iritscen (talk) 23:08, 6 November 2012 (CET)

lol You are right, I guess my cold makes me dizzy. --paradox-01 (talk) 09:33, 7 November 2012 (CET)

Iritscen, when you see this please move another one: http://wiki.oni2.net/OBD_talk:TRGE --paradox-01 (talk) 19:57, 7 November 2012 (CET)

Category

You might want to consider using a category-macro template like Template:OBD instead of manually entering the category name on each XML page. You can then simply drop a little "{{XML}}" at the bottom of each page, and later on the whole category can be "renamed" if we change our minds. --Iritscen (talk) 14:36, 8 November 2012 (CET)

For the records: 'scen, that worked fine.

I don't longer remember what this is, can I delete it? paradox-01 (talk) 21:14, 2 July 2017 (CEST)

Overview

1. Do we have a main XML: page like OBD: has OBD:Oni Binary Data? Would it be "XML_basic_tutorial"?
2. Is SSG's overview anywhere on the wiki? --Iritscen (talk) 20:42, 7 November 2012 (CET)

1. Not name-wise. I don't wanted to create a new XML:??? page because that would have been pretty much XML_basic_tutorial as you already guessed. Should it be moved to - lets say - XML:basics ?
2. Afaik, ssg's overview isn't on this wiki yet. It would be nice to have a port of it. Maybe following style will be sufficient enough. (There are more overviews, just in case you didn't noticed: character files, message files, level 0 files.)

AAAA
 |
 +-- BBBB
 +-- CCCC
 |    |
 |    +-- DDDD
 |
 +-- EEEE

I changed my mind: colored table cells could show embedded instances of files, so ssg's style should be better.

Check this out: https://dl.dropbox.com/u/139715/temp/ssg_overviews_wikified.txt (dead link)

Now we've to find a good place for it. Any ideas? --paradox-01 (talk) 20:08, 11 November 2012 (CET)

Ooh, I like! The question of where to put it is a good one, as I would love to find a way to merge that hierarchical information with the acronym expansions given on the File types page, and, even better, to also have a small summary of each type ("AKEV (Akira Environment) is ___"). Short of using hover text, which I don't think is ideal, I don't have any ideas yet as to how to fit everything into one display. It just seems wasteful to use a whole page just for showing relationships, with no explanation of each type; also, the File types page is now somewhat wasteful of space too, since investigation of the file types is essentially done and we no longer need a page to track its progress with smileys. At least, that's my opinion; what do you think?

P.S.: One small tip -- I'm generally against the use of images external to the wiki. I would suggest uploading SSG's arrow pics to the wiki and then invoking them as shown below. The blank link field makes them non-clickable:

[[File:Wiki.png|link=]]

--Iritscen (talk) 21:02, 11 November 2012 (CET)

SSG's arrow pics: before we upload them let's be sure we will use them. (If it's going to be a html from an oni2 user account then we wouldn't upload them.)

Proposal of that new page (recycling OBD:file_types). (For Neo's sake, let's keep the ^_^ ? Or another symbol that makes them as done.)

• With a narrow table the content (types + hierarchy + explanation) should fit on one page.
• By default the hierarchy tables and explanations are hidden. Clicking a file type from the list at the left makes the corresponding table + explanation visible.

Problem

• If we can't pull this off we might consider writing a html page although a wiki page would be more appropriated.
• I don't know if we can show a table and at same time hide the previous table on click event. At least <div> demonstrates that some hiding/showing can be done on the wiki.

          

inspiration

Can you reuse the template source code at some point?

PS: User:Iritscen/vector.js - That's some customization but how do you store/call actual java script functions? --paradox-01 (talk) 15:56, 12 November 2012 (CET)

file types <a href="#AISA" id="table_1">AISA</a> <a href="#TXMP" id="table_2">TXMP</a> <a href="#ONCC" id="table_3">ONCC</a>

TxtC IGPA IGPG TSFF TSFL TSFT TSGA PSpc TXMP IGSA IGSt

explanation of clicked file type .......

Cool, I like the diagonal striping; I didn't even know that was possible. I also really like how you fit everything onto the page in three columns. I don't have the time this minute to do much work on this myself, but I can at least answer a couple of your questions.

"For Neo's sake, let's keep the ^_^ ?" -- If he still uses them, we should definitely keep them. I guess I was under the impression that Neo isn't really using those anymore. We should ask him.

"I don't know if we can show a table and at same time hide the previous table on click event [...] That's some customization but how do you store/call actual java script functions" -- I would direct your attention to MediaWiki:Common.js (also, note that all the JS pages are linked to on my user page). Towards the top of Common.js is code that imports additional scripts, such as MediaWiki:Common.js/edit.js, based on the type or name of the page. E.g., anyone performing an edit will have edit.js loaded for them, which does things like adding buttons to the toolbar (at least, it will when I fix it!). Does that help? --Iritscen (talk) 19:39, 12 November 2012 (CET)

Just a quick note, the repeating-linear-gradient property does not work for WebKit browsers. Chrome/Safari apparently need "-webkit-repeating-linear-gradient" instead. --Iritscen (talk) 03:31, 13 November 2012 (CET)

Another quick note, we would probably want to mimic the JS that enables the divhide template, as you already suggested and in line with this forum post, which means that we probably want to create a new table class (e.g. "click-table") that responds to 'onclick' events by modifying the text in a column in the table (e.g. "click-table-descrip"). But I can't figure out where the file type description text would come from. We don't really want all the description texts lodged inside the Javascript, but rather somewhere we can edit them freely. One possibility is to figure out how to copy/transclude text from a subpage, similar to the way Quotes/Consoles works, where each console quote is on a separate, editable page. --Iritscen (talk) 14:38, 13 November 2012 (CET)

I tried get myself more familiar with the different codes and their mixing, but I would just ending to make hundreds of edits just to learn how to do this or that. So I can't be a great help here. :/ paradox-01 (talk) 22:09, 13 November 2012 (CET)

That's okay, I have played around with JS before. I'll spend some time on this soon. --Iritscen (talk) 00:42, 14 November 2012 (CET)

Okay, I wrote some quick and dirty code and put it in Common.js. Go to my test space's file type table and you should get descriptions when you hover over each type. This could easily be adjusted to require a click instead of a hover but I liked the idea of a no-click interface. I'm going to step aside now and give you the chance to work with this table type as you see fit. I had to simplify the markup for testing purposes, and you might have some better ideas as to how to arrange the table.

As you'll see, the basic idea is that you attach the class "hovertable" to a wikitable, then you place multiple spans in one large cell of class "hovertable_descrip". Each span is "display:none" and contains the description for one type, which is given as that span's id. Then you declare other cells in the hovertable as class "hovercell" with ids that match the ones in the descrip cell. The JS I wrote attaches event handlers to all hovercells which display their corresponding span in the hovertable_descrip cell when the hovercell receives 'mouseover', and hide the span upon 'mouseout'. --Iritscen (talk) 20:22, 16 November 2012 (CET)

I checked your test space. It looks awesome, I didn't expected to see so fast results on this. However, there are 2 things I would like you to think about.

1) SSG's "Level files" table (https://dl.dropbox.com/u/139715/temp/ssg_overviews_wikified.txt, dead link) (ONLV) is too big for an absolute location of the explanation: if the user hovers the CRSA table cell he would see nothing because the explanation is out of view.

The solution to this problem might be to fix the explanation area to the screen. Here's an example made of CSS (https://dl.dropbox.com/u/139715/temp/explanation_fixed_to_screen.htm, dead link). (basically style="position: fixed; top: 50%; left: 50%;")

2) We talked about merging those hierarchies and the general file type overview. In my last draft the types were vertical listed but I think it will look less odd if they are horizontal (because the tables differ in their number of rows).

At the moment the chasing explanation makes a strange impression but that's due to the other content here. With nothing else then the content under the gray line should look ... not "super" ... but good enough. Or we make a step back and use H template?

2a) If we agree on the merging then the file types should be click-able: if user clicks TxtC type then of course the TxtC table should appear.

I think you can reuse the mechanism here you just created. Not sure about IGPG: it appears in TxtC but also in others (DPge, WPge, Opge, ...)

2b) Facing this problem we might choose an easier path than hiding all tables by default.

If we put all table under each other we could create "AAAA-using types" sections at the end of all tables: If the user clicked IGPG then the browser jumps to that section and there the user reads IGPG being used by this, this and that type. From there he can jump again (by clicking [[#ABCD|ABCD]]) and reaches his final choice (TxtC/DPge/WPge/... table).

---

ABNA

AGQC

AGQG

AGQR

AISA

AKAA

AKBA

AKBP

AKEV

AKOT

AKVA

BINA

CBPI

CBPM

CONS

CRSA

DOOR

DPge

ENVP

FILM

HPge

IDXA

IGHH

IGPA

IGPG

IGSA

IGSt

Impt

IPge

KeyI

M3GA

M3GM

Mtrl

OBAN

OBOA

OFGA

ONCC

ONCP

ONCV

ONGS

ONIA

ONLD

ONLV

ONOA

ONSK

ONVL

ONWC

OPge

OSBD

OTIT

OTLF

PLEA

PNTA

PSpc

PSpL

PSUI

QTNA

SNDD

SUBT

TRAC

TRAM

TRAS

TRBS

TRCM

TRGA

TRGE

TRIA

TRIG

TRMA

TRSC

TRTA

TSFF

TSFL

TSFT

TSGA

TURR

TXAN

TXCA

TXMA

TXMB

TXMP

TxtC

VCRA

WMCL

WMDD

WMM

WMMB

WPge

Based on OBD:file_types. Maybe we should list BINA subtypes too (object collections like CHAR, CONS, DOOR, ...) ?

TxtC

TxtC IGPA IGPG TSFF TSFL TSFT TSGA PSpc TXMP IGSA IGSt

TxtC: This is console text. IGPA: In-Game User Interface Page Array. IGPG: In-Game User Interface Page. TSFF: A font family. TSFL: A font language. TSFT: Actual font bitmaps. TSGA: A glyph array linking 256 possible symbols to their bitmaps (TSFTs). PSpc: Part Specification (coordinates for finding a UI symbol in a bitmap collection of UI elements. TXMP: A texture map! IGSA: In-Game user interface String Array. IGSt: In-Game user interface STring.

[ other tables ]

IGPG-using types

• TxtC
• OPge
• IPge
• WPge

---

Ah, the fixed-position box is interesting, that could be the answer. I think we will need to have a chat before I can fully understand what we are trying to document, though, in terms of what/how hierarchies are to be shown. I'll look for you online this weekend. --Iritscen (talk) 03:41, 17 November 2012 (CET)

Just a note on where I left off -- I fixed the classes so that the cells are being styled correctly. However, I seem to have accidentally changed the stripe style; I didn't mean to create a stripe with a gradient in it; I just want to make the blue and background colors evenly spaced at 10px or 15px. Also, the "position:fixed" on the descrip cell was somehow shifting the location of the next cell (TxtC), so for now I have removed that property. --Iritscen (talk) 23:56, 17 November 2012 (CET)

If you look closely there are 3 px value in the gradient code: for clean stripes let the last value be the sum of the others.

background-image: -webkit-repeating-linear-gradient(-45deg, transparent, transparent 10px, rgba(0, 0, 255, 0.2) 10px, rgba(0, 0, 255, 0.2) 20px); --paradox-01 (talk) 11:29, 18 November 2012 (CET)

The table in your test space will look okay if you enable the position fixed in Common.css again. That code piece rips the cell out of the table. I added some columns to fix it. --13:12, 18 November 2012 (CET)

Sorry, 'dox, I didn't think it would take very long, but after I had written some of the JavaScript, I could see how complicated it would be. Then I got sidetracked by real life for a while. Normally I would just keep at it until it's done, but seeing as I am trying to get back to my main Oni project ASAP, I'm afraid I have to cut short my work on this. Maybe it's more complicated than it needs to be. If you want to "retreat" back to a simpler solution, then let me know how I can help with that. Otherwise I might have time to finish this at a later date. I just don't want to spend hours on it when it's keeping me from my other work. --Iritscen (talk) 20:57, 17 December 2012 (CET)

New overview

Just wanted to say, I still feel this is an important thing to add to the wiki. But I made it too complex the first time around. Rather than a dynamically generated table, we should probably stick to something that is set up manually. Although my more complex code was never finished, we do still have the hovertable class available, as used above (and I can easily change it to display info on a click instead of a mouse-hover if that's better). Let me know if you have any new ideas on how to present the info, or if you want to stick with the format we had before.

The fact is, looking at this with a fresh perspective, I'm not 100% convinced that the arrow-based table is the best use of space or the easiest thing to read, or that we need fancy JS either. What about the simple text-based approach I suggested here, combined with your anchor-based TOC serving as an alphabetical index at the beginning? --Iritscen (talk) 00:03, 18 April 2013 (CEST)

About that thing at Current_events. Sounds like you want a simple page with sections and links. So if you don't want to hierarchal information then you could take XML:File_types and extend it. In that case I wouldn't use === but {{Anchor|some_anchor_name}}. This prevents the page to be ripped in sections. By that the user can follow links and the page will still look nice. --paradox-01 (talk) 12:56, 18 April 2013 (CEST)

Basically, yes. I like that "File types" page, I just would like the descriptions to be a bit longer and to list what types they have under them, or what types can contain them, and maybe group them by type. I think I'll make a separate WIP table in my userspace so I don't mess up yours, because I'm not 100% clear on what I want it to look like. --Iritscen (talk) 13:59, 18 April 2013 (CEST)

Okay, it can use some nicer formatting, but if you look at my TestSpace, you'll see what I had in mind. It's similar to your XML File types page, just organized by category, and with "parent" and "child" anchor links to the related types on the same page. Probably it can also contain your colored documentation dots and the types can link to their XML: pages instead of OBD:, at least if this replaces your File types page. Any suggestions? --Iritscen (talk) 22:07, 19 April 2013 (CEST)

Caution, the header template on pages like XML:BINA/OBJC/CHAR link to "other BINA" and "other OBJC" (XML:File_types) in analogy to OBD:BINA/OBJC and OBD:BINA.

I like how you structure the descriptions, I'm just a bit unhappy with the index thing because of the mentioned template header. As a compromise perhaps make 3 type indices so that the template can still link to those.

Type index: BINA

• [...]

Type index: CJBO

• [...]

Type index: other files

• [...]

Add color dots and links and I totally agree with replacing current file types page with this second version. :) --paradox-01 (talk) 22:43, 19 April 2013 (CEST)

Sorry, I don't understand the point you're making. I'm not 100% fluent in where all Oni's data is stored (particularly what is in .sep vs. .raw), but my idea was that this wasn't an important distinction to make for the beginner who just wants to know what these kinds of data do. After all, we no longer have to know which file to look in with a hex editor to mod something, we just ask OniSplit to export the data :-) But please let me know what you meant if there's a reason the reader has to think in terms of BINA vs. CBJO vs. everything else. --Iritscen (talk) 23:17, 19 April 2013 (CEST)

I just want the user to be aware of what types belong to object collections (for instance so he does chose the door collection and not the door class) and that searches can be easily be done by BINA*/BINAOBJC*. --paradox-01 (talk) 14:19, 20 April 2013 (CEST)