dose206

We're looking at a beta tonight or tomorrow

Daemonjax and I, with several others as well, are working on a distribution program to help with passing around mods. It looks like we'll likely have a workable beta build sometime this weekend. The thread is over here.

Daemonjax mentioned to me that he's got an irc channel set up and that he's lonely in there..... but I'm enough a noob with irc that I don't know how to find it.

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

What programming language did you choose for the GUI? C#? Does dreadylein know C#? If not, this will be interesting. :D Yup, C#, although I'm not committed to it, I haven't gotten very far in yet. 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. Pretty sure you're right about C# XML libraries, and I agree that XML is a good format. I hadn't considered integrating hexeditor, notepad++ and ue explorer support, I was approaching it from a mod-user standpoint, but I agree that it makes more sense to view it the other way around. I don't have much experience integrating with existing software programs, do you have any suggestions on where to start looking at it? The mod manager will need its own configuration file that tracks (at least) where the XCOM installation root folder is as well as where to put/find the backups. This will theoretically be different on every user's machine, but shouldn't change through the life of use for individual users.

Okay, I've gotten a very rough shell of a GUI built, and at this point it doesn't have ANY overlapping functionality with anything else, so it could easily become just a GUI used to run .bat files. Since I wanted to learn about .bat files, I also started creating a .bat file to do the job, although I'm undecided if that's the way that I want to go. Anyhow, I've successfully managed to devote nearly all of my day to this, so I'm off to study a bit before bed. I'll get back to work tomorrow afternoon, most likely. Have a nice night (or good morning) everyone! Also, if anyone is bothered by the fact that my posts don't have much substance, just tell me to shut it and post when I have some real updates. I can take it, I promise.

God, I can't make up my mind. I can either work on the GUI right now, but I actually would do it in C# (I forgot how poorly Eclipse handles GUI design, VS is much easier), or I can do it command line style in Java, and worry about GUI later. I've seen the suggestion of having separate command line programs cobbled together with a GUI. What do you prefer? I don't see why not (famous last words)

Dear god, man. Start studying! What class is it for? It's just Financial Accounting, and I'm pretty comfortable with the material. On another note, I think I will start with GUI, since we will eventually need it and it is what I'm most comfortable with ATM. I'm thinking I'll start with a GUI for "settings" which will be stored in a config file. Stuff like "where is your xcom installation located". Do we have a preference in terms of language? I suppose I'll start with Java, but don't imagine I'll get far enough to make changing languages too much of a hassle.

Okay, Daemonjax, I've worked entirely through your gender tutorial without repacking anything. I understand now what we're talking about and what we're up against. I'll try and at least start on some code tonight and get it online (does google code support svn? I've never used them for storage). I can't promise anything because, as I mentioned earlier, I have an exam tomorrow and so far I've spent the entire day getting set up and running to mod XCom :). I should be able to get something online within a day or two. On the plus side, I ended up installing XCom on my laptop, which is far from being a gaming rig, and it runs great so far! Unexpected bonus!

Daemonjax is the salty captain and I'm the greenhorn with eyes as wide as saucers, for ease of identification. EDIT: Yes, dreadylein is here too. He's the one who's not the salty captain or the wide eyed greenhorn

Well, as much as I'd hate to slow everyone down by having to learn as I go... I love learning new things. Anyhow, we might be better served by getting the program working and running, and adding the GUI afterwards. In the end, I'm happy to follow your lead and happy to take directions... this is unfamiliar territory for me, after all.

I love tutorialized versions.

Fair enough :). I think my confusion stems from the fact that I haven't actually sat down and done any of this yet. I'm approaching it, so far, from a purely theoretical standpoint, and the doing will likely clear up most of the mist in my head. I am familiar, I have tortoise intstalled on my machine already, so I'm ready to roll there. However, I've never really worked on command line software before, I've only played with GUI stuff. However, I have full confidence that that won't be an issue. EDIT: If I'm following you correctly, modpatcher (along with some other things, like XSHAPE) is essentially modifying the structure that forces the game to read our modified files, while what we've been talking about here is how to automate and distribute the actual modified files (in such a way to avoid copyright issues, etc.) EDIT2: Nope, I think I got it now. I'm actually going through and doing and that makes a huge difference. Modpatcher is used if you want to fiddle around in the .inis. We're not doing that. After following along with your gender tutorial (almost finished with it) I can see that we're not messing with .inis at all. Gosh, I should have just jumped in with both feet in the first place. I'm a little slow some days, you'll have to forgive me ;)

This is off topic, but after spending a few hours combing through some of the more prominent threads I have a question. Does anybody recommend a particular hex editor? I've never used one before and would prefer to start off with a decent one rather than jump my way through a few crappy ones until I figure out which features I like(need). Thanks in advance.

We'd have to use both methods, if we want to support mods on top of mods. If we were only looking at the hash values, and they had been modified previously, our program would have no way of knowing where to patch in the new code. I do love the idea of using hash values, either around the area to be modded, or as the "expected value" that you mentioned previously, but we would need to have the byte's offset as well. I was thinking it could be even more simple. Our modder creates a single file that contains, like you mentioned previously, the name of the file to be modified (filename.upk.original, and it could optionally check for filename.upk.modified, if the user knows this file has been modified previously). It would also contain the byte offset and perhaps the hash values, and then of course the new code to patch in. That's it, at least starting out. All our modder has to do to distribute his mod is send this one file out, and all our user has to do is run this file through our program. There could be some config settings for the user, such as where all the unmodified upks are, as well as the modified ones, but it seems to me that it doesn't have to be more complicated than that. Unless, of course, we want to support more heavily the mod makers as well. I guess it depends on exactly what the scope of this part of the program needs to be. EDIT: After reading your suggestion again, it sounds like we're suggesting essentially the same thing EDIT2: I reread through ALL the relevant threads in an effort to make sure I have all the proper software and understand the process properly. I haven't actually tried anything yet so pardon my ignorance, but aren't we talking about doing (essentially) what dreadylein's Modpatcher is already doing? If not, then I'm having trouble understanding what that program does.

Have you looked at copyright law lately? It is my (admittedly non-expert) understanding that generally ANY redistribution of copyrighted material is forboden, whether for monetary gain or not. Anyhow, if it can be (moderately) easily worked around, there's no reason to step on toes.

This seems like a good solution. However, I'm a little confused by the Else If in your pseudo code. Wouldn't it never be true that the upk would be compressed at that point, since it is uncompressed in step 2? I'm going to try and get my rig set up for modding tonight (downloading all the tools that are currently being used/ been made by others here). Hopefully I'll have time tomorrow to take one of the minor mods with well documented bytecode changes and write up a little java goodness that will automate it. However, with an exam early Monday morning, studying might get precedence... :)

Theoretically it doesn't seem that complicated. We're already talking about programmatically isolating lines of code, erasing them and replacing them with something else. In an effort to avoid copyright issues we want to avoid distributing complete .upks, which means we'll HAVE to selectively edit individual lines of code. If we read through an entire file, copy the entire contents, then parse out and edit the section we're aiming for, we shouldn't have issues with completely overwriting an earlier mod. The only tricky part would be determining if a given mod will overwrite lines already altered by an earlier mod, but that doesn't have to be our concern, rather an issue for mod developers to concern themselves with. However, your advice to keep KISS (keep it simple, stupid) in mind is, as this type of advice will always be, timely and certainly welcome in my eyes.

Yes. For those of us who are just cutting our teeth with modding (and even for those who are not, given the duct tape style mod "pipeline" we have now) this is great!

Okay, gotcha. So if I understand the pipeline correctly, it works as follows: 1. decompress .upks 2. patch in changes to .upk bytecode 3. update ..._filesize file to reflect that the new .upk is a different size 4. mod the .exe to reflect that the new upk has a different SHA hash (which essentially points the .exe to our modified file instead of using the original) I'd assume we want to allow Player A (from your earlier example) to be able to load the mod that Player B made AND the mod(s) that Players C, D, E, etc. have made as well, assuming that none of those mods directly overwrite each other. Assuming my basic understanding of the pipeline is correct, that means that when adding any new mod, we have to ensure that patching the bytecode ONLY patches the affected lines of that .upk. file, in order to avoid overwriting any earlier mods that made changes to other lines of that .upk It seems to me that in order to distribute any particular mod, all we'd need are 1. the new lines of code and 2. the .upk file and location within that file where the new lines should be patched. This points to, perhaps, a custom file format? If I make a mod, all I need to do is put my changes and instructions together in the right way and our program will be able to read it. Is this off base?

I'd be interested in pitching in, but with a caveat. I have two kids and am a full time uni student so my time is... limited. I'm pretty comfortable in Java, but also have some experience in some of the .NET languages. EDIT: Is this project related to your XSHAPE project? I'm still trying to sort out the current mod pipeline, but the goals stated in this thread seem to match what XSHAPE is doing to the untrained eye.