Jump to content

Mod Distribution/Automation Program


Daemonjax

Recommended Posts

Don't we run into an issue with 1) by distributing game assets? Are we abandoning the index position/hash value idea? If we don't distribute the modded files themselves, then the information on which file(s) are to be modded as well as where within the file(s) and change(s) to be made will need to be in the configuration file, but we would only need that one file.

 

No, and no... I was just describing the workflow of the modder, not what is included in the mod file.

 

The program parses the file and creates the mod, which does not contain parts of said file.

 

Any one of us can write the program to do that in any language we choose... preferably one with xml support.

 

I don't have much experience integrating with existing software programs, do you have any suggestions on where to start looking at it?

 

Perhaps I made it sound more daunting than it actually is. :D We'll discuss that later, once we decide on a better means of communication (I'm thinking we should create an irc channel).

Edited by Daemonjax
Link to comment
Share on other sites

  • Replies 108
  • Created
  • Last Reply

Top Posters In This Topic

Don't we run into an issue with 1) by distributing game assets? Are we abandoning the index position/hash value idea? If we don't distribute the modded files themselves, then the information on which file(s) are to be modded as well as where within the file(s) and change(s) to be made will need to be in the configuration file, but we would only need that one file.

 

No, and no... I was just describing the workflow of the modder, not what is included in the mod file.

 

The program parses the file and creates the mod, which does not contain parts of said file.

 

Gotcha, I thought you were describing the contents of the mod file.

 

EDIT: Okay, an irc channel sounds good to me, I don't want to unnecessarily clutter the forums

Edited by dose206
Link to comment
Share on other sites

I've been toying with some code to make it easier to combine multiple mods to the same cooked-in .ini files (i.e. DefaultGameCore) without having one mod overwrite the effects of another, as is the case now. Presumably we'll eventually want a single mod framework that can handle both .ini and .upk, so I thought I'd post here so we can coordinate a little.

 

I'm working in python so far because that's what I do at work so it's fresh in my mind, and I think I've sorted out how to read the Windows registry to find the .exe and how to pull out, inspect and then replace the .ini resource within the .exe file. My thought was that the .ini patcher would have to parse the existing .ini file and then apply any number of mod scripts to it, each of which only touches specific lines (or even parts of lines, like the aim bonus value for sectoids on classic difficulty). This way multiple mods could all apply their changes without interfering with eachother, and then the final result would be put back into the .exe just like the current modpatcher does.

 

So my question for you folks is, has there been much discussion about what kind of syntax most mod authors would be comfortable with in order to define mods that need to alter the same .ini file? My first thought was to mimic normal source code patch procedures and just use something like 'diff' to specify which particular lines of an .ini to change, without touching any of the others. However, that doesn't allow single values to be changed within a line, and it might have trouble with the idiosyncrasies of Firaxis' .ini format; for example, they're not just key=value pairs since some settings appear multiple times, and the order in which they appear is meaningful (like base funding, 4 of the same setting in a row which lines up with the 4 difficulty levels).

 

So at this point I'm imagining that a mod's patch file could look something like this:

 

SOLDIER_COST = 25
SOLDIER_COST_HARD = 50
BASE_FUNDING[2] = 100
BalanceMods_Easy[eType=eChar_Sectoid].iAim = 5

 

The first two changes are simple because they're not repeated, so the meaning is clear. The BASE_FUNDING option is trickier because it's used 4 times in the original file, so the array notation "[2]" would change the third occurrence (counting from 0) of the BASE_FUNDING option, which corresponds to Classic difficulty, to 100 without changing the value for any other difficulty. The last option is even trickier, since I'm not sure the order of the BalanceMods options matters given that each option specifies the unit it applies to. So, I have in mind this different kind of notation, which means find the BalanceMods_Easy line on which eType=eChar_Sectoid, and on that line, change the iAim value to 5 without touching any other value (like iHP, iCritHit, etc).

 

Thoughts so far? Does this syntax make sense, or does somebody have a simpler idea?

Link to comment
Share on other sites

The ini file that modpatcher uses is a line by line representation of what's currently cooked into the exe.

 

If I understand you correctly, you want to change it. Sounds like more work for little gain to me, but that's up to dreadylein... but he's said on occasion that he hates parsing strings. ;)

 

 

Anyways... progress on our Modmanager is coming along nicely, and I see no reason why we won't have a beta available for download sometime this weekend.

Edited by Daemonjax
Link to comment
Share on other sites

The ini file that modpatcher uses is a line by line representation of what's currently cooked into the exe.

 

Yes, and therein lies the problem: since every mod that uses modpatcher has to supply a complete, alternate copy of the file, you cannot use two mods at once since the second one will overwrite whatever the first one did. Ideally, mods would not have to re-define all of the settings they don't want to change; instead they would only list the particular values they do want to change, so that multiple mods can change different values without conflicting. Yes, that means string parsing, but it's not such a big deal; after just a few hours' work I have a working prototype already that parses the ini into a structured form and then re-renders it to plain text. All I need to do now is add the syntax for targeting and tweaking individual values of the structured data in between the parsing and rendering.

 

Anyways... progress on our Modmanager is coming along nicely, and I see no reason why we won't have a beta available for download sometime this weekend.

 

Does your modmanager do what dreadylein's modpatcher currently does, or is it only aimed at patching .upk data and not the .ini data?

 

edit: finally went back and read the whole thread closely instead of just skimming it; looks like right now you're planning on just plugging modpatcher in as an external binary, so with a little luck we can just tweak that component separately in order to support multiple mods changing DefaultGameCore

Edited by taleden
Link to comment
Share on other sites

Anyways... progress on our Modmanager is coming along nicely, and I see no reason why we won't have a beta available for download sometime this weekend.

 

Excellent news, I look forward to it. Keep up the great work :)

 

Anyone know if an IRC channel has been set up yet?

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...