Daemonjax

[0027.91] DevHTTP: FHttpDownload resolve complete to: 65.118.245.165:80 It's a known fact that the game calls home to that IP address. You can see it in your log files.

I've already discussed this to death. I spent too many hours on this already. Maybe in the future we'll be able to balance this.

This isn't like the original game where the number of items you're building it multiplied by the time to build. It takes the same number of days to build 1000 medkits, or 1 medkit. Also, your engineers aren't tied up for the time it takes to build. I hope you see the problem, now. If not, whatever. We'll just agree to disagree. Honestly, I just thought I was pointing out the obvious. :D I think it would be cool to allow players the choice to sell items at a loss on the grey market. But, I don't think you should be able to get infinite cash. With the game mechanics the way they are, any profit is infinite profit. UPDATE: function bool CanBeSold(int iItem) { local TItem kItem; kItem = Item(iItem); // End:0x74 Loop:False if(iItem == 192 || (iItem == 135) || (iItem == 133) || (iItem == 134)) { return false; } // End:0xbf Loop:False if(iItem == 192 || (iItem == 135) || (iItem == 133) || (iItem == 134)) { return false; } return m_arrItems[iItem].iCash != -1; return ReturnValue; @NULL(131072) } I modified the bytecode to decompile to the above. Then, with just a few more modifications, we should be able to exclude 8 items of our choosing. Assuming it just doesn't crash the game when I load the modified upk... Hopefully it won't mind the extra return and null at the bottom. :D In theory, it shouldn't matter since return m_arrItems[iItem].iCash != -1; should make that junk at the bottom unreachable code. Wish me luck! ;) UPDATE: Crashes with "Bad export index 180549991/18702". Sucks. I didn't modify the function length, per se, but I used 0x0B (Nothing) to basically null extra bytes out. Something didn't work. Huh... I'll have to try something else.

Don't think that's correct... when I left this code in: if(iItem == 192 || (iItem == 135) || (iItem == 133) || (iItem == 134)) { return false; } I was unable to sell medkits or scopes on the gray market. If I get around to it, I'll change the false to true in that code, and we'll know for sure. I could be wrong. Also, it looks like the price to sell is simply the iCash value, while the price to make it goes down as your number of engineers goes up (I found the code to change the engineer cost-decrease formula, btw). We'd want to mod this so that you can never make a profit from selling items. We want there to always be a loss, because the game doesn't multiply the number of items you're building by the build time. i.e. even a $1 profit (after subtracting the opportunity cost of just selling the materials) from selling manufactured equipment on the gray market would effectively become infinite cash. So, selling items on the gray market should always be a loss for game balance reasons. The problem is for interceptors, and manufactured goods that don't require elerium or alloys. The simple fix: Replace one of the items 192, 133, 134, 135 with the interceptor item number, and either: 1) add alloy and/or elerium requirement to everyone buildable (scopes, etc.); or 2) change those problem items to cost -1 iCash (like medkits).

Sounds interesting. I'll check it out.

Where in the code is the function giveperk() called? Is there a way to have UE Explorer export all the decompiled scripts in a upk? Because finding this stuff is ridiculous without being able to use a tool like grep.

if its of any interest... you dont need to re-run xshape if you use resource hacker instead of modpatcher (no idea why not, you just dont!) :thumbsup: I asked dreadylein about that, and he replied that it just made more sense to him at the time when he wrote modpatcher to re-apply the ini settings to the original backup exe everytime you run it... not apply the changes to the current exe. So, everytime you run it, you get a new exe... which is why the xshape sha hash changes go poof, and you have to re-run xshape. It's still faster than using resource hacker. I still use modpatcher with a custom batch file which runs xshape after its done.

Modpatcher does a very specific thing. DefaultGameCore.ini isn't read by the game, instead it's cooked into the exe. Modpatcher copies all information from a copy of the ini file to that location in the exe. It does its job, and does it well... but it only does that one thing. AFAIK, there's no other ini files that are like that. Now everyone is focusing on editing uncompressed upk file bytecode, but even that has limits. What we want is a full blown XCOM Editor, allowing us to edit and recompile all the game's scripts. But, I doubt we'll ever see that. Maybe... maybe... we'll eventually see a map editor from Firaxis... after they've sold us all their DLCs. So, if you want to learn how to mod this game... grab your favorite hexeditor and start hacking away.

Good info, there... let's keep the bytecode mods/info flowing. :D On that note, I figured out how to entirely disable shooting while panicked through bytecode. I doubt anyone would be interested in that particularly, but a lot of the code that handles panic is in the XGUnit class in XComGame.upk. We can also change the maximum range at which the panicked unit checks for targets when they fire randomly. It's currently set to 256 (4 * 64) distance units. I don't think either are particularly worthwhile mods, but if someone's interested in more details then let me know.

I prefer the time travel analogy. No not Looper's time travel :D If you went back in time and did the same exact thing, would the outcome change? No, of course not.

You can also use tab for autocompetion. But, this isn't a thread for learning dos or using gildor's tools. So, let's stop now. :D EDIT: Just PM me with odd questions like this. I'll either ignore you, or answer... but at least this thread will stay mostly pure.

Copy the decompress.exe to some folder Copy the upk file(s) (compressed.upk for this example) you want to decompress to the same folder Open a command line prompt Go to that folder type: decompress -lzo -out=decompressed.upk compressed.upk decompressed.upk is a filename you choose. Too easy, amirite? ;) essential dos commands: http://www.lsi.upc.edu/~robert/teaching/foninf/doshelp.html c:, d:, e:, etc... will change drives, btw.

try: decompress from the command line... if you're just double clicking on it from windows explorer... then that could be your problem. ;) ... Kids these days. ;)

2 stock fighters can take down a medium 4 stock fighters can take down a large

It just tweaks some ini settings. Don't get your hopes so high up. ;) Someone should just make an ini tweak guide, explaining each and everyone ini setting.

Gildor's package decompressor: http://www.gildor.org/downloads

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. 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).

Isn't that what I said? :D I thought everyone knew at this point that there's an anti-savescumming feature built into the game. You can't reload and get different results for the same action. It's common knowledge at this point, especially in the mod talk forum. This isn't 2k's general discussion.

http://code.google.com/p/xcom-modmanager/ Project is up. Simply calling it XCOM Modmanager, or XM for short. I don't know how this will/could fit in with the Nexus Modmanager. I'm not thinking about that right now. Once we get to beta status, we can make a new thread. I PMed dreadylein, and he says he's in. @dose206 PM me your google email (gmail) address so I can add you as a contributor. What programming language did you choose for the GUI? C#? Does dreadylein know C#? If not, this will be interesting. :D I can learn C# or whatever as the case need be. I'll work on a sample mod folder... the stuff that a modder would have in a folder to be processed by the modmanager. UPDATE: It really just should be a folder (the name of the mod or something like that), containing: 1) the modified file (i.e. Executing.State for this mod here: http://forums.nexusmods.com/index.php?/topic/811009-the-next-step/page__view__findpost__p__6491427) 2) a configuration file (config.xml) generated by the modmanager which contains all the other information needed Modmanager then parses the files to create a mod file, which is what's shared. None of the information in the original file should be in this mod file. There's no reason this couldn't be integrated into nexus modmanager, but that's something for another day. Thoughts: 1) We'll have to work out the configuration file structure. We should use xml for it, so it stays human readable. 2) We can easily integrate hexeditor, notepad++, and ue explorer support into the GUI. 3) I'd like to tackle this from the mod-maker's perspective first. By the time we get to the mod-user functionality, the necessary gritty details will already be worked out. 4) C# has standard libraries for XML afaik, so you should be good for that. 5) We can use modpatcher, and xshape, gildor's decompresser, and one of the unpackers as-written (or close to it) for that functionality. 6) We don't need permission from any authors as long as we don't distribute their program with the modmanager. The user can just download them on his own. I'm sure we'll discuss things in further detail once I get your gmail email addresses.

New version up. The search algorithm is complete, albeit more simplified.

I keep looking, but I'm not finding anything that looks like function length within the function script itself. I believe that information is in the decompiled .class file or another file (.package, or .UPKpkginfo, etc.). But my money is on the .class file.

Actually, just put marathon to 1.99f instead and you can play just fine with everything ALMOST doubled... Genius. :D

I made this to help out: http://dl.dropbox.com/u/32777109/Games/XCOM%202012/output.txt Just hit F3 and do a search in your browser for bytecode or name.

Yeah, in the pinned thread above this one. Maybe it's time for glasses? ;)

A7 is the bytecode for Rand. 2C is the bytcode for intconst for the next byte, which is 03. 16 25 16 02... not sure. Don't forget it'll need bytecode equivalent for the unary comparison operation... but there is none for unary (afaik), so it'll look like something else in bytecode than what we see decompiled. I know the code doesn't end there, since 53 is end of function. I would not be surprised if the next 2 bytes were: 16 26... then it'd make sense. Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000170 00 00 45 9A A7 2C 03 16 25 16 02 00 2C 02 01 00 ..Eš§,..%...,... Ok, so it doesn't... :D 16 25 16 02 00 2C 02 01 0 2 1 2C followed by two bytes which are treated as ints from byte values... I seen that before in other code. The rest is stuff for the unary conditional. BTW, I tutorialized this mod in this thread here: http://forums.nexusmods.com/index.php?/topic/811009-the-next-step/page__st__40