Daemonjax

I don't use the UEE hex viewer at all. ;) I use HxD.

Turns out the .tfc files have the same header as compressed upk files. Gildor says they're actually uncompressed, so (if true) this would be the fringe case for compressed upk detection (though I could just make an exception for that file extension). ;) Nevermind, they are compressed.

If you were talking about meshes in particular, I haven't even considered them yet... I was just talking about textures. :D I don't know how meshes are handled in the Unreal Engine. EDIT: Oh, I read your post more carefully and you were being specific about meshes. Usually tampering with a mesh changes its filesize. That alone would make it a no-go at this point as far as I know. Sorry to get your hopes up. ;) Textures on the other hand... that's different. When you extract a mesh from a upk, can you find the bytes in that mesh file within that upk by searching via copy/paste with a decent hexeditor? Or does whatever program you use to extract it change the format? If that's a yes, then... If you then just load and save the mesh (in whatever program you'd use to edit these meshes), is it still the same exact file? If that's a yes, then there's no problem. :D If it's no to both, I think you're hosed. Again, I haven't looked into modding meshes in this game, so I dunno.

Yes, it will work. XCOM Mod Manager doesn't care if it's one byte or a million. It'll patch whatever file you want -- as long as you give it the original and modified data in files so. The file could be the entire upk. It doesn't care. I'm pretty sure you could do that right now (EDIT: You can but it's very cumbersome) with XCOM Mod Manager... although actually doing it would kinda suck. BUT, there's a better way which would make distributing texture mods so that they would all be compatible with one another. If what Gildor told us is true (that the tfc files are uncompressed), that better way is possible and relatively straightforward. We can swap as many bytes as we want... I wouldn't want to do that by hand, but I already wrote the program to automate that for us. Anyways, it's been a good day. :D I don't have the time to look into it much more right now, but I will soon.

Thanks for the info. :D I'll look into it when I have more time. It makes Normal difficulty unplayable for me.

I noticed that when I removed the +10 aim bonus from Classic/Impossible, the AI was just as easily exploitable by overwatching as on normal.

Ok, fair enough. Step by step tutorial is incoming shortly. The uncompressed_size files are automatically taken care of when you use the modinstaller.bat file. ;) Good idea, will do. You're right. The mod config file should have an extension. I personally like .xcom_mod_config. For me, the gui does the same thing (returns error code 1) even if I delete ModMaker.jar and ModInstaller.jar. But, dose has a new version for me to test... we'll see how it goes. It's in C#. I'm hopeful. If it doesn't work then we'll just switch to java and get the gui done this weekend. Java Swing is pretty decent nowadays, and their Nimbus look and feel looks and feels not at all like crap. UPDATE: OK, the GUI is available for download at the same link as on the first page. I can't get it to work correctly, but it works for him, so we need others to test it regardless. Keep in mind that the batch files have more features than the GUI at this point, but (in theory) you can more easily create and install mods using the GUI. I'm also working on another GUI in Java. I expect to have something good enough to share tomorrow. If you need help, I'm usually in IRC.

I still wouldn't bother actually repacking. Just keep your unpacked files unmolested. Edit a copy of the file and use it to make a .xcom_mod file. A GUI would streamline all of this, of course. Maybe the existing GUI that dose created works for everyone else but me (hint: need testers). :/

So, is anyone using this thing or what?

Exactly. It skipped it because the .uncompressed_file exists. One thing I could do is: IF (filename).uncompressed_file exists AND (filename) is uncompressed then yell_at_user() I don't think there's a fringe case where that would be a bad thing. At that point, I may as well have XSHAPE take care of the .uncompressed_file for you. ;) Consider it done in .20beta (since that would be an added feature, not a bugfix).

I see what you're saying, but I intended it that way for ease of use. The idea is that you don't need to muck around with the config file unless you're adding files to it. If at least one file listed doesn't have their .uncompressed_size, then it will continue without errors. With the -v option, you can see what it's actually checking, so I don't see a problem. Anyways, I think it's better than the alternative. We can agree to disagree. ;)

Here's the source code up to error code 5... if (args.length == 0) return 1; if (!configFile.canRead()) return 2; if (configFile.length() == 0) return 3; scan = new Scanner(configFile); while (scan.hasNextLine()) { String line = scan.nextLine().trim(); if (line.isEmpty()) { scan.close(); return 4; } if (!isCompressed(line)) ++count; } scan.close(); if (count == 0) return 5; Now here's the isCompressed function: final static String CFOLDER = "XComGame\\CookedPCConsole\\"; final static String COMPRESSED = ".uncompressed_size"; static boolean isCompressed(String s) { return new File(CFOLDER + s + COMPRESSED).exists(); } Note: The !'s mean NOT If I missed something, it's not on the if (!isCompressed(line)) ++count; line, since isCompressed(...) can only return true for one reason. You have to look at that while loop and think of a reason it would exit before incrementing the local count variable, but also a reason that would not return exit codes 1 through 4. I can't think of any reason other than the uncompressed.size files existing. Basically, the line: while (scan.hasNextLine()) would have to return false for a reasons other than: 1) bad arguments sent to XSHAPE.jar 2) config file can't be read 3) config file is empty 4) config file contains lines of whitespace The only thing that comes to mind is if you have a filename added to the config file (whatever.ext), and you have that same filename in your cooked folder with .uncompressed_size added on to it (whatever.ext.uncompressed_size). Did you add any files to the config file? Here's the full source code: http://code.google.com/p/xshape/source/browse/trunk/XShape.java All sanity checks except for 16 are in: static int runSanityChecks(...)

Try using XCOM Mod Manager to create differentials of the upk data you want to change. I made it with bytecode changes in mind, but the program doesn't care what the data actually is... as long as it's the same size as the original data (which reminds me of another sanity check I should put in ;)). I'll try and work with you to make it work if it doesn't work already. Textures are stored in the UPKs, right? EDIT: Ahh.. tfc files... but they're probably just upk by another name... checking them out. Looks like they're compressed with lzo (or unreal's implementation of lzo): Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 C1 83 2A 9E 00 00 02 Áƒ*ž... ... but I can't uncompress them... bummer. Even if we can't unpack them, I might be able to find a way if we could uncompress them at least. Maybe Gildor could help. EDIT: Found this thread here: http://www.gildor.org/smf/index.php/topic,1602.0.html It looks like they can be uncompressed, but I can't find any more information about this. I guess it's time for me to register on Gildor's site. Maybe the only way to do this is through a program like texmod.

As long as either the original data (with the upk filename), or the changes with offsets (and complete path to the original unpacked file) are somehow displayed and copy/pastable, then it won't be too difficult for me to add support for this. There's several ways to make it work, too many to list... i.e. you could also just treat ModMaker as a black box and just feed it the information that it wants without needing to understand how it works at all. Either way, I'm sure they'll play together one day. We'll see what happens. ;) Oh, heh, I was just thinking out loud about how I don't want to write my own GUI... they take time and effort and require so many changes and mockups to look great. The mere thought of doing one for free makes me die a little inside. I wasn't implying you should use java for yours. :D

You're right. Eliot can change it. I, being a mere mortal, however, have to be content with changing bytecode I actually understand. ;)

I've been wanting to know that myself for some time now. After about 6 hours I'd given up... Specifically on the same function you posted (function bool CanBeSold(int iItem)), and probably for the same reason. Forget it. It's magic. ;) I will check out everything Eliot has said on the subject, though, since he's the Unreal Engine guru. I think we're talking about two different things. EDIT: I stand corrected it seems. That's some crazy guru s*** to figure that out. Not a feat I can reproduce at all. There's nothing that distinguishes that red 00 from the others in my eyes. Maybe Eliot can explain to us how the jump byte actually works (I'm looking at you, function CanBeSold).

We can't change that (Actually, apparently Elliot can). However, we can change: XComGame\XComDamageType\CausesSurroundingAreaDamage\CausesSurroundingAreaDamage.Function static function bool CausesSurroundingAreaDamage(class<DamageType> inDamageType) { // End:0x32 Loop:False if(inDamageType == class'XComDamageType_AreaBurn' || (inDamageType == class'XComDamageType_Flame')) { return false; } return true; } Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 33 4A 00 00 32 55 00 00 00 00 00 00 21 4A 00 00 3J..2U......!J.. 00000010 00 00 00 00 00 00 00 00 23 4A 00 00 00 00 00 00 ........#J...... 00000020 19 00 00 00 26 03 00 00 3F 00 00 00 2B 00 00 00 ....&...?...+... 00000030 07 32 00 84 72 00 23 4A 00 00 20 51 4A 00 00 16 .2.„r.#J.. QJ... 00000040 18 15 00 72 00 23 4A 00 00 20 4D 4A 00 00 16 16 ...r.#J.. MJ.... 00000050 04 28 04 27 04 3A 22 4A 00 00 53 00 00 00 02 20 .(.'.:"J..S.... 00000060 02 00 B3 0F 00 00 00 00 00 00 ..³....... Change the 0x07 to 0x06 at offset 0x30 to skip the conditional, and see what happens. Hell, I'll make a distributable mod for it... 1 sec... FireDoesDamageMod -- for XCOM Mod Manager

Editing the unpacked files is the only sane way I was able to make the XCOM Mod Manager work in principle. Otherwise, yeah, I wouldn't bother unpacking at all.

When we have a working GUI for XCOM Mod Manager, I may be able to build support into the program to parse that and create a distributable mod. It depends, but we'll see. Or, you could build support for ModMaker (the java sub-program which actually generates the mod file) into your program. Instead of modifying the upk, you'd just have to modify the unpacked file. That sounds easier, but whatever. :D Whichever happens first, I guess. ;) EDIT: I noticed you used a browser as your gui. I considered doing that, also. But, java has decent a decent gui builder, and I wouldn't learn anything new doing another client-server app. I'd much rather someone else did the gui for me. /sigh

Always room for more... send me your gmail id, and I'll set you up as a contributor at first... Contribute with feedback on whatever you want, and creating/verifying issues on the project page, and we'll move you up to committer in no time. :D Plenty of stuff left to do. Right now I'm working on getting a lot of features working through batch files, since I haven't used batch files in forever... I'm rusty. ;) I'd actually REALLY like for someone else to try and see if the existing GUI (by dose206) works for them (download via svn checkout). Maybe I was doing it wrong. I know he put a decent amount of work into it, and it's a shame to have it sit there unused. UPDATE1: New version of the modinstaller batch file up. This one should make life easier for you guys since it includes support for automatic decompressing with backups, renaming of .compressed_size files, and automatically runs XSHAPE.bat when needed. Almost as good as a real gui now. I need to do stuff for the ModMaker batch file now (configuration file creation and unpacking). UPDATE2: Updated links. ModInstaller.bat is done until I implement mod uninstalls (or until I notice a problem).

You'll have to edit the config\config.xml file... look at the <XCOM> tag... change what's in the tag to point towards your xcom game folder. The default should be mostly correct... you may have to change only the drive letter from C to something else. For example, I need to have the following: <XCOM>E:\Program Files (x86)\Steam\steamapps\common\XCom-Enemy-Unknown</XCOM> Ordinarily, the GUI would make this more intuitive. Hope that helps. ;) My unpacked folder is similar: <Unpacked>E:\Program Files (x86)\Steam\steamapps\common\XCom-Enemy-Unknown\XComGame\CookedPCConsole\unpacked</Unpacked> I like to keep my unpacked folder within CookedPCConsole, but it could be anywhere... and you can change it at any time. Unpacking a UPK is different from just uncompressing it. You only need one XComGame.upk -- the one in your CookedPCConsole. If a mod you're installing wants to modify any upk, then it will have to be uncompressed first. I have a sanity check in place to catch this error if you forget. Also, before running XSHAPE, you'll need to rename/delete the accompanying .uncompressed_size file. XSHAPE will catch this error if you forget. As far as errorcode 5 goes, once you set the main game's folder within the <XCOM> tag, it will be able to find your CookedPCConsole folder, and all should be well. Let me know if this is confusing. :D NOTE: For installing mods, you don't have to worry about setting your <Unpacked> folder... not needed. For making mods, yes, you have to... it was the only sane way to do this. You may not need to set your <XCOM> folder when just making mods... I forget. Just make sure both are correct to be on the safe side. The GUI would make this process more streamlined. I realize that without a GUI doing this requires a certain level of understanding which may be beyond what the casual user is willing to acquire. While I essentially eliminated one hoop for mod users (hex-editing), there's still plenty others you're going to have to jump through at this time. When the GUI is working, it'll be all rainbows and unicorns. UPDATE1: I made a modification to ModInstaller.bat which adds automatic parsing of the .install.log file, which you can download from the first page via dropbox link. I recommend downloading it and overwriting the existing ModInstaller.bat file with it. UPDATE2: Fixed the updated ModInstaller.bat ;)

Well, all this does is patch the exe to load modified upk files. What you're talking about is a mod installation program, which I am currently working on here: http://forums.nexusmods.com/index.php?/topic/811448-mod-distributionautomation-program/ The installation of java 7 over 6 should automatically update your environment variables. If not, well, that's something you have to take up with Oracle. I know Sun's installer had issues with that, but Oracle installer of Java 7 has been smart enough for me. It's cool you found a fix, though. That output from XSHAPE looks correct. What were you expecting to see? The popup you're getting has nothing to do with XSHAPE, and I don't know what's doing it.

This thread has nothing to do with XSHAPE, but, yeah... just have java 7 installed. If they're getting: "Java is not recognized as an internal or external command, operable program or batch file." Then, they don't have java installed correctly, period, regardless of version. UPDATE1: Working on batch files now, so we won't have to wait for a working GUI. Should be done shortly. UPDATE2: Beta is up. http://code.google.com/p/xcom-modmanager/downloads/list Example mod and files included. It lacks a GUI (existing one is broken), so you'll have to do a lot of stuff manually (editing of xml files), but it's otherwise functional. Any feedback is appreciated, of course... but keep in mind that ModInstaller and ModMaker are intended to be back-ends to a GUI front-end. Please direct all GUI (or lack thereof) comments at dose206 ;)

Currently, dose is doing the GUI in C#, while I'm writing everything else in Java. If we need to restart with a new GUI, then it'll be in Java (since it would be easy for me to jump into it and make changes). If that happens, I'll do a beta release with no GUI first... Friday afternoon at the latest.

Lost power for a few days due to Sandy... I'm back up now. The ModInstaller and ModMaker parts of the program work fine. We're just having issues getting the GUI frontend to do what we want it to do. If this issue continues, I'll put together a command line interface.