XCOM Modding: Need of a centralized source of information?

[anUser]

Hey, Ive got a few things to say, Ill try to be brief and dont miss any. Sry for bad writting, onscreen keyboard.

 

Manually placed links, i was thinking something like in the utorials page highlight the howto install mods, howto mod and howto write wiki artilcles, nothing else

 

Notes page, i vote for creating a raw, unprocessed data section or category for such files. Dont get me wrong, they are useful but ideally Id love to have the original function involved in each mod decompiled and hex code brokn down... and then from the oriinaal function link to that version or write the altered code in the same function plage... if it ever happens that 2 or more mods use the same function differently we just list their reespective code there. Again, the first time ill want to implement amineris mod ill follow the mod page, but the 2nd or 3rd ill want to jump to the function I know I have o edit... so I d hate having to navigate to get there. If by now, until all the data gets processed i have to im ok with that but i dont think thats gotta be some sort of basis to structure data in the wiki

 

Im ok with not listing every function in the main XCOM category, but Id limit to max 1 step to reach ANYTHING, 2 for very specific content... 3 it gets lost, imo

[dubiousintent]

 

anUser, on 13 May 2013 - 15:03, said:
Manually placed links, i was thinking something like in the utorials page highlight the howto install mods, howto mod and howto write wiki artilcles, nothing else

Wouldn't renaming those three articles to begin with '1_How to <subject>' better serve that purpose? That way their nature is clearer and they would appear first in the list of pages. Just listing them in a note doesn't make it easier to locate them. While most articles in the Tutorial category can be considered 'How To' articles, we could limit that usage to only the broadest tutorials, suitable to be in the 'Start here' cat as well.

Notes page, i vote for creating a raw, unprocessed data section or category for such files. Dont get me wrong, they are useful but ideally Id love to have the original function involved in each mod decompiled and hex code brokn down... and then from the oriinaal function link to that version or write the altered code in the same function plage... if it ever happens that 2 or more mods use the same function differently we just list their reespective code there. Again, the first time ill want to implement amineris mod ill follow the mod page, but the 2nd or 3rd ill want to jump to the function I know I have o edit... so I d hate having to navigate to get there. If by now, until all the data gets processed i have to im ok with that but i dont think thats gotta be some sort of basis to structure data in the wiki

Hmm. I could create a 'Code Breakdown' sub-category (s-cat) and then link all the "raw, unprocessed data" pages from mods to there. Then people can cross link to the 'Functionality' (Classes, ENum Values, Functions) s-cats as they work that out. That what you had in mind?

What do others think?

Im ok with not listing every function in the main XCOM category, but Id limit to max 1 step to reach ANYTHING, 2 for very specific content... 3 it gets lost, imo

"XCOM" to "Modding" to s-cats flat enough for you? That's only two levels if you consider that you always start from the top level anywhere. Or are you really suggesting moving everything in the s-cats up to the "Modding" cat?

@Others: I'd prefer to work on a consensus approach, but if I only get one opinion then it will rule. Please weigh in.

-Dubious-

[Amineri]

I use both the links and the search function. Stuff doesn't get lost that easily. But then, I have a weird memory and can remember all sorts of weird things.

 

To help stuff from getting totally lost, and for those people that want a "big list of everything", I think an "Index Category" is perfectly fine.

 

However, some of us don't mind or prefer navigating with more categories and steps. Can't we have both? Have every page with the index category, and a hierarchical category structure too?

 

That would give THREE ways to find things:

 

1) Hierarchical category system -- good for browsing when you don't know what you're looking for

2) Index -- "kitchen sink" list -- quick link to every single page

3) Search box -- it actually does work !

[dubiousintent]

Right now, the 'Index Category' is 'Category:XCOM'. That puts the typical hierarchical structure on it's head: the base of the pyramid is flipped on it's top by appearing on the very first category page you see with all the pages in the lower half of the category page. It's 'weird' to my way of thinking, but does make it possible to find anything. Just hope it's workable for everyone.

 

I'm not sure having a sub-category named 'Category:Index' would add anything, especially as it would basically just be a duplicate of 'Category:XCOM' though more clearly identified. Others, please weigh in?

 

I am going to put notice boxes on all the category pages to make the cat's purpose more visible and get people to read them.

 

What hierarchical structure exists is found in the sub-categories. But we seem to be moving towards simply having all sub-cats linked to all other sub-cats. I think that blurs the distinctions between them. However, the goal is to make it easier for modders to find what they are looking for, so the ease of access to desired content is apparently more important even at the cost of categorization clarity.

 

To that end, I am considering linking all the content in the Functionality sub-cats into the 'Modding' category as well. Adding a 'nebulous' sub-cat of 'Code Breakdowns' as one of the Functionality sub-cats as well as to the 'Modding' parent cat will give us a higher and broader level of access to mod specific articles that arise from mod development discoveries. That brings access to all those articles up at least two levels, and the Functionality sub-cats still let people browse for them by function. So you drill down sub-cats to narrow your pool of articles rather than expand it.

 

Edit: At this point my goal is no more than three levels of cats: XCOM -> Major Separations sub-cats (Help, Modding, Mods, Tutorials), and Specialization sub-cats under those (i.e. Functionality, specific Mods, etc). The sole exception to this rule is that specific mods have one more sub-cat for all files that are directly related to the mod. The addition of a 'Code Breakdowns' sub-cat will let applicable mod specific files be linked from the 'Modding' sub-cat and thus visible at a much higher level. However, at this point I am still not persuaded there would be any benefit to linking such context specific files in the top level 'Category:XCOM'. /edit

 

Other than trying to keep this 'upside-down' concept firmly in mind, I have no problem with that. What it comes down to is adding all the sub-cats to the templates and having an author simply remove the ones they feel don't apply or would mislead. (Already done.) If people like the idea of adding 'Code Breakdowns' to 'Modding' and the Functionality sub-cats, then I just have to update the templates cats list, and re-visit all the existing articles to update their cats list as well. That's alright, as I want to revisit them anyway to try to apply the templates structure where missing for some consistency or at least flag them for re-writes. But I would prefer to get the number and names of sub-cats settled first.

 

Thank you for reminding us all about 'search'. Sometimes the obvious just gets overlooked. (Forest -> Trees -> What's with all this wood?) The only problem with search is that you need to have some idea of what a page is about. My biggest worry is to locate 'orphan' pages I don't even know were added without any category. But at least you have reminded me I can search on 'xcom' and see if any strange pages show up.

 

-Dubious-

Edited May 15, 2013 by dubiousintent

[dubiousintent]

There having been no objections, added 'Category:Code Breakdowns' to the Wiki (under the Modding' Category so it is on the same level as the other Functionality sub-cats), and believe I have linked all the relevant pages. Let me know if I missed any.

 

-Dubious-

[dubiousintent]

Just wanted to inform people that I have added links to the articles on the UPK files: XComGame, XComStrategyGame, Command1, and XComShell that contain lists of the "packages" (classes, functions, etc.) they each contain. The hope is that they will assist people looking for either something in particular or in narrowing down where it is located. At the moment they are simply lists of file/folder names of the "packages". Hopefully people will add some descriptions are they investigate.

 

It takes more time to create the Wiki pages than it does to create the lists, so feel free to ask for other UPK files' packages you would like to see added.

 

-Dubious-

[dubiousintent]

Added 'bsdiff/bspatch' to the 'Modding Tools' article. This BSD licensed tool enables creating and distributing hex patches to the game EXE. The tool binary can be freely distributed (along with the patches you create) as long as the license is included.

 

-Dubious-

Edited June 28, 2013 by dubiousintent

[Bertilsson]

I'd like to add that bsdiff/bspatch is insanely simple to use:

bsdiff.exe OldFile NewFile PatchFile (PatchFile will be created)

bspatch OldFile NewFile PatchFile (NewFile will be created)

 

I tested it on XComGame.exe original version and the LongWar 1.9 Beta 2 version.

It took ~30 seconds to generate the 10KB patchfile and it took <1 second to recreate the newfile using original XComGame.exe and patchfile.

Edited June 28, 2013 by Bertilsson

[Amineri]

Excellent find!

 

I went looking for something like this a month or ago and failed at Google-ing ~_~

[dubiousintent]

Okay, after doing some digging around the internet it seems pretty clear Unreal 3 games are definitely intended be "extensible", to include replacing someone elses work (packages) with your own. But you apparently (but maybe not; see last entry) need the "Unreal Development Kit" (UDK; free) to compile the packages. The UDK includes all the asset source files (except C++ source) of the base Unreal engine. Here's my evidence.

First of all we have to get our terminology straight. Primarily when modding we are dealing in altering "packages", primarily UPKs, which have been "decompressed". Once decompressed they are still a single 'packed' package file that can then (if desired) be 'extracted' into their separate component files: such as '.u' files. Rather than me trying to rephrase more expert explanations, I urge you to read the following:

Packages: [http://udn.epicgames.com/Three/UnrealPackages.html]. An overview of packages and asset representation in the Unreal Engine.

EpicGames on Packages: [http://hyper.dnsalias.net/infobase/archive/unrealtech/Packages.htm]. Includes:
"When the Unreal engine needs to load a package, it looks in the subdirectories listed in the [Core.System] section, in the Path#= list."
"Whenever you save a package file to disk, the file is internally stamped with a GUID ("Globally Unique Identifier"), which is a 128-bit number which is guaranteed to be unique. In single-player play, this GUID is never used and is irrelevent. However, when you connect to an Internet-based server, the server sends a list of packages that are required for gameplay there (for example, the level it uses, any texture packages it uses, any sound packages, etc). These packages are identified by name and GUID. If you don't have one of the packages required by the server, the package file is automatically downloaded to your \Unreal\Cache directory, and given a filename based on its GUID."

* Packages enable an open plug-in architecture for easy community and licensee extensibility.
* Packages make the Unreal engine expandable in content, UnrealScript code, and C++ code.
* Packages help to improve the modularity of the code and reduce interdependencies.
* Packages make it much easier for licensees to separarate the Unreal engine from the Unreal game.
* Packages simplify Web-style downloading of content in Internet play.

"How do I have my new package used in the editor and during gameplay?"
"If you create any intrinsic UnrealScript classes, or if you need to access any UnrealScript classes from C++ code, then you can have Unreal generate a C++ header file which mirrors the classes you've defined in UnrealScript."

Working with Packages (Importing and Creating Assets) [http://waylon-art.com/LearningUnreal/UE3-06-WorkingWithPackages.htm]. "If you want to create your own custom content (textures, meshes, etc) you can put them into a new package and distribute that along with your map or mod. You can even save assets into your map as if it were a package. We’ll look at how to do both of these in this tutorial."

Reply from thread [http://www.unrealadmin.org/forums/showthread.php?t=17360]:
"You might be better off creating a new package and linking the two together instead of decompiling/recompiling someone else's work and code.

To do this, when you recompile your new package, put the [<specific '.u' file> being modded] in the EditPackages= lines and it will find the classes you are extending."

Here is the possible alternative to the UDK: Unreal X-Editor [http://en.wikipedia.org/wiki/Unreal_X-Editor]

Unreal X-Editor [http://forums.epicgames.com/threads/883437-Unreal-X-Editor-v3-1-3-Available]:
"... editor for creating/editing Unreal Script files. Unreal X-Editor is packed with rich features that makes Unreal Scripting easier for both beginners and experts. Listed are the features of Unreal X-Editor.

Features:
Class Tree Viewer
QuickLoad
Code Explorer
Class Finder
Class Usage Finder
Class Reference Finder
Autocomplete
Autocomplete Editor
Declaration Autocomplete
Code Folding
C# Style Commenting
Syntax Highlighting
Line Numbers
Auto Indent
Embed Selection
Basic Preset Scripts
Run UDK Editor from Unreal X-Editor
Run UDK Game from Unreal X-Editor
Compile/Full Compile Scripts from Unreal X-Editor
Various Skins to change the Look And Feel of Unreal X-Editor
And more...
Unreal X-Editor is free for Commercial and Non-Commercial use."

So for some of the mods people have been requesting, they probably are possible but will require following this line of exploration into the UDK.

-Dubious-