BlackAlpha

Yah, I didn't mean an actual bug, though I guess it sort of is bug, where the new recruits come in with Easy HP (6) on all difficulty levels. I meant it bothered me that playing on classic, I was getting a 'bonus' I didn't actually want. Thanks again for the instructions, I was able to make it work :) Of course then I promptly got a bomb mission on a map I was not familiar with, and wound up facing 6 thin men without being able to deactivate enough nodes, so I charged in a bit, missed a couple shots, and they proceeded to wipe 4/6 including my major and captain. Oh well, sticking it out, even though my last mission was 5 rookies... The issue where new recruits get more HP than starting soldiers, that's actually a bug. :wink: I can confirm what PepprmintButler said, it works. I found that out a while ago and have been using it in Warspace.

What bug are you talking about exactly?

It's possible to mod the UPK files, it's just that you are limited to HEX editing for now. Which means you can't make any complex modifications. But as far as I know, most mods don't mod the UPK files. You just need to restore the original EXE file to restore your game to vanilla. And I just remembered, some mods do alter different files, like the ini files.

In the example from my post: Injured days total = (base days + random days) Gravely injured days total = (base days + random days) + ((base days + random days) * 2) In vanilla it's: Gravely injured days total = (base days + random days) + (base days + random days) This has a high chance not to make any difference whatsoever from normal injury days, which is why I changed it in my mod.

Well, I thought it would be more fun if it's a surprise. Do you really want to know? Don't forget that you'll unlock them all soon enough. Did you remove "Flush" entirely from the skill tree? Since I've incorporated the Reaction Fire Mod into yours, "Flush" was sort of a handy ability to have with the reaction fire mod. I moved the skills around. They are all still in there, somewhere.

I updated the first post with info on how to see the data this mod changes, so everyone knows how it's done. Well, I thought it would be more fun if it's a surprise. Do you really want to know? Don't forget that you'll unlock them all soon enough.

I noticed in the code that there are checks for the AI where they do or do not do certain things when there are player controlled units on overwatch. I guess it comes down to editing those lines if you want to fix this "bug". But I didn't see a way to do so with mere HEX editing. I forgot in what files it was. It's in XComGame.upk, in one of the files that has "AI" in its name.

Just want to mention that I just had my first user that made that mistake. So it's definitely a good feature for the next version! :biggrin:

=================== XComStrategyGame.upk: =================== ==== XGItemTree ==== >>>> GetItemBuildTime if(eItemCat != 3 || (IsShipWeapon(eItem))) { iEngineerDays = 0; } Changed to: goto J0x52; eItemCat != 3 || (IsShipWeapon(eItem)); iEngineerDays = 0; J0x52: This is accomplished by changing the second 07 (at location 45) to an 06, so it skips all the code. This makes it so the production times are re-enabled and everything takes time to build. See the INI file for the time settings. Note that this one someone else found. I'm just repeating it to let people know about it. Credits to Daemonjax and Tbkiah. ==== XGFacility_Barracks ==== >>>> function DetermineTimeOut kSoldier.m_iTurnsOut += 24 * iBaseTimeOut + Rand(iRandTimeOut); Changed to: kSoldier.m_iTurnsOut += 48 * iBaseTimeOut + Rand(iRandTimeOut); This makes it so gravely wounded soldiers (who end a mission with less than half of their own maximum HP) will get a higher recovery time penalty. In this case, their recovery time penalty is roughly 3 times longer compared to soldiers with normal injuries. In this function the recovery times are calculated. When a unit has less than half of their HP, it will be considered gravely injured and more recovery days will be added do it. Note the following HP numbers and when they will result in being gravely injured. HP 1/2 = Will result in being injured, NOT gravely injured. HP 2/4 = Will result in being injured, NOT gravely injured. HP 2/3 = Will result in being injured, NOT gravely injured. HP 5/9 = Will result in being injured, NOT gravely injured. HP 1/4 = Will result in being GRAVELY injured. HP 1/3 = Will result in being GRAVELY injured. HP 4/9 = Will result in being GRAVELY injured. Etc, etc. ==== XGAIBehavior ==== >>>> function float GetMoveOffenseScore Changed "if(iHitChance < 50)" to "if(iHitChance < 15)". This should make the AI move less and shoot more often when their hit chance is low. Should affect long range shooting the most. I'm not sure about this one, though. It did seem to make a small difference when I tested it, but it could've been simply the RNG system messing with the results. Check the following topic on how to mod the skill trees of all classes: http://forums.nexusmods.com/index.php?/topic/813563-probably-found-a-way-to-edit-ability-trees-of-your-troops-and-enemies/

I'm busy finalizing my new mod version. I'm just using XSHAPE + Modpatcher for now. But I'm planning to use this for my next version. I quickly looked over the files but I couldn't find a step by step tutorial on how to create (not including the HEX editing, other topics can cover that) and install "your first mod", so to speak. I think adding that would make it easier for many people to figure out how to use this new mod manager.

Cool! :)

PM me the details. I can test it.

In my example, the V option doesn't show it checked the strategy.upk. I'm guessing it just skipped it entirely. But it's no big deal, anyway.

Yeah, I was talking about the "old way". Especially with the new mod manager, I guess it's less confusing and more orderly to just edit the unpacked files. It takes a while to unpack/repack the files but it's easier to keep track of modified content.

I see. The error was reported by another user. I'll chalk it up as user error and I'll tell him to triple check for the uncompressed_size file. On an unrelated note, I think I might have found a minor bug. This is how to reproduce it: Inside (game folder)\XComGame\CookedPCConsole\ 1. I remove "XComGame.upk.uncompressed_size". 2. I "forget" to remove "XComStrategyGame.upk.uncompressed_size". 3. I add a modified/uncompressed "XComGame.upk". 4. I add a modified/uncompressed "XComStrategyGame.upk". 5. I run XSHAPE and it shows 1 hash has been updated and it doesn't show any sort of error message about "XComStrategyGame.upk". The problem here is that I'm a tech savvy guy, so when I see only 1 hash has been changed, I know something is wrong. But "regular users" don't know that. I think XSHAPE should somehow detect this error and show an error message. For example, the program could assume all files added to XSHAPE.config need to be checked and when there's something wrong with one, it could show an error. The downside would be that the mod maker needs to edit XSHAPE.config to include all files that he has modified. And of course, it's more work for you. Pros are that when users screw up, they get an error message and they know what's up or they can ask for help and give us the error message. This is if you only use XSHAPE without the new mod manager. No idea if it's worthwhile adding an error for that in the new mod manager.

XCOM SHA Patcher for Executable (XSHAPE) v0.13b ERROR(5) USAGE: java -jar XSHAPE.jar -<verbose> <starting byte> More information: http://code.google.com/p/xshape I know this error code can show up when the ".uncompressed_size" files haven't been removed. Are there other situations that could result in this error code?

Some other users were able to fix the Java issue by going here: http://www.java.com/en/download/manual.jsp And then downloading the correct bit version for their OS. So if you got 64bit Windows, get the 64bit Java. Vice versa for 32bit. After that, Windows recognized Java correctly.

Nevermind that. The issue has been resolved.

Unpack method is a bit redundant. Easier and faster to just edit the UPK file, no? I only unpack to be able to open the functions with the HEX editor, so that I can look at the HEX code in the HEX editor.

I just noticed that editing "GetRandomTargetLocation" doesn't completely eliminate the chances of your soldiers shooting friendlies when in panic. It seems they still will try to shoot friendlies when there are no enemies in range of the unit who is in panic. I can't find the code responsible for that. I'm guessing it's somewhere in "XGAction_Fire" > "Setshot", not sure.

There's only 1 legit version and that's the Steam version. Other versions are not compatible with mods.

I'll look into the production times. When you start the game, does Steam say anything about "completing installation"? Meanwhile, try to restore your original EXE file and reinstall the mod.

I've seen the code that could make it possible. But you'll need to edit it. Which means we need official modding tools to make this happen. If you are wondering about the code, it's in: XComGame.upk > XGTacticalGameCore > function BuildCharacters

No, I don't know. But a possible fix so far is to manually install 64bit Java. I noticed Java tends to install the 32bit and maybe that's causing issues for 64bit systems?

I've got a possible issue. Today I've sent a test version of my new mod version to 4 people. This new mod version includes XSHAPE, which uses Java. Two of the testers reported back with the problem that Windows doesn't recognize Java: "Java is not recognized as an internal or external command, operable program or batch file." And hence XSHAPE doesn't work. Now I'm getting pretty paranoid. I know you can't really say so, but that's half of the people reporting that problem. Well, anyway, I can imagine that quite a few people might show up with similar problems. I'm wondering if there's an easy fix for this? Or can it somehow be avoided in the first place? If not in XSHAPE, what about the new tool? If it can be avoided in the new tool, then I'd rather hold off on releasing anything until the new tool is released. I don't want a repeat from what happened when Firaxis started using their new patching process, lots of people then showed up with problems.