UPK Utils

[Zyxpsilon]

I've got the whole Hex-Code for the gfxSoldierList Class as extracted from the current (Beta15E4) UICollection_Strategy_SF.UPK file if that's what you mean by "script".

What i did for some testing purposes is split my biggy 200KBs+ patch file into more manageable small parts. While i was there, i simply integrated the Barracks items into a single file. Since mostly everything else (other OBJECTS such as Hiring, SoldierPromotion, SquadSelect, etc) is being installed correctly, it will be easy for me to just create a new log from a failed try and share it with you via eMail along with the above "script source".

 

BUT -- if you say pointing each of the previous REL_OFFSET=0 to the exact starting "area" of gfxSoldierList with the first detected relative code (for example REL_OFFSET=12A9707... instead of 6FA73A) -- it would mean a proper dispatch of anything into the right locations... then, i'll try that too. If i get another failure, i'll join the LOG in the eMail too.

 

Thanks for your time and help. ;)

[Zyxpsilon]

After repetitive attempts at various ways to represent the tricky REL_OFFSET=? Well, no luck!

 

This is the exact code beginning;

MOD_NAME=ReCLR-LW4_CustomStrategyHUD(UI_z--Part5_TEST)
AUTHOR=Zyxpsilon
DESCRIPTION=Various UI Elements

// Version #15E4 : Compatible with LongWar Beta15E4 and possibly later versions!

UPK_FILE=UICollection_Strategy_SF.UPK

//
//---------BARRACKS---------

// OBJECT=gfxSoldierList.SoldierList:AUTO

// BL2a) DefineShape4 (17) :: ButtonBG (#A0A0B0)
REL_OFFSET=0x012FEB58
[BEFORE_HEX]
FF 14 50 00 00 00 11 00 87 FF 9A 5F FF FF 98 22 A8 80 00 02 5F 90 00 00 22 40 01 00 01 14 00 80 02 67 E8 ED 7F 01
[AFTER_HEX]
FF 14 50 00 00 00 11 00 87 FF 9A 5F FF FF 98 22 A8 80 00 02 5F 90 00 00 22 40 01 00 01 14 00 80 02 A0 A0 B0 7F 01

And the LOG...

Writing backups to D:\XCom_EU\PatcherGUI71/backup/3112295724/1432794727
uicollection_strategy_sf.upk saved to backup directory
Backup completed successfully

Executing external PatchUPK program:
"D:\XCom_EU\PatcherGUI71/binaries/PatchUPK.exe" "D:\XCom_EU\PatcherGUI71\Mods\(2D-T)ReCLR-LW4_CustomStrategyHUD(UI_z--

Part5_TEST).txt" "G:\Steam\steamapps\common\XCom-Enemy-Unknown\XEW/xcomgame/cookedpcconsole"

PatchUPK
Installing mod: ReCLR-LW4_CustomStrategyHUD(UI_z--Part5_TEST)
by Zyxpsilon
Mod description:
Various UI Elements



Opening package ...
Package file: G:\Steam\steamapps\common\XCom-Enemy-Unknown\XEW/xcomgame/cookedpcconsole/uicollection_strategy_sf.upk
Package opened successfully!
Relative offset: 0x012FEB58 (19917656)
Invalid relative offset!
Execution stopped at #4 command named REL_OFFSET.
Restoring from backup: D:\XCom_EU\PatcherGUI71/backup/3112295724/1432794727
uicollection_strategy_sf.upk restored from backup
Restoring from backup completed successfully

What the --snip-- is going on with this silly friggin' stuff??!! :pinch: :sad: :sick:

Am i just crazy or blatantly stupid or what??

 

Btw, there were exactly *FOUR* different instances of that OBJECT in the file... and i was able to manually add the correct custom elements on the fourth "group" -- and, it works. Yet, PatcherGUI refuses to detect the right OFFSETS for that specific area.

My formatting must be invalid, indeed.

Edited May 28, 2015 by Zyxpsilon

[XMarksTheSpot]

Btw, there were exactly *FOUR* different instances of that OBJECT in the file... and i was able to manually add the correct custom elements on the fourth "group" -- and, it works. Yet, PatcherGUI refuses to detect the right OFFSETS for that specific area.

My formatting must be invalid, indeed.

You're still talking about Spazmo's Soldier List XP mod, right? That one's PatchUPK-based and contains multiple changes that include resize operations. As a result the target object in question gets cloned multiple times (each time for every resize) and appended to the UPK, explaining the additional instances.

 

I'm not a big fan of this 'clone-and-append' procedure as this makes my work (and apparently yours, too, Zyx) harder, but that's just how PatchUPK rolls :smile:

 

In any case, you should use the OBJECT=gfxSoldierList.SoldierList:AUTO line in your mod file instead of relative offsets to find the proper object, i.e. the most recent one that got added.

Edited May 28, 2015 by XMarksTheSpot

[Zyxpsilon]

Then... i'm going to have to remove the // in front of that "OBJECT=" comment (for that specific Barracks stuff only) and then, put // on all the current REL_OFFSET lines. Which means it will be better to use a single Patcher file for that one only.

This "scope" search of relative locations gives us headaches for sure but Spazmo probably isn't really responsible for that messy situation... it's more like *HOW* the code processes custom editing (by enforcing Orphaned sections) within UPK files.

 

As an example, i couldn't even install his EnhancedTacticalInfo mod as it is picking the exact default color values (#67E8ED) for the stats while my previous corrections (via another Patch) simply and already had changed any of those. Thus, ETI can't find the right "BEFORE" items and as a result -- automatically fails! That gfxGermanMode is the target OBJECT for his alternative settings but (this is strange), Oakeman's version can be installed without troubles. He's patching everything to XComGame.UPK though when ETI applies its secondary "HUD'ding" stuff via UICollection_Tactical_SF exclusively! Sooooooo weird, man.

 

Ideally though, maybe wGhost could find an alternate Patching (still within the current Utils toolset she has made) method for us in order to address that special gimmicky problem. :wink:

 

Thanks to you too.

Edited May 28, 2015 by Zyxpsilon

[tracktwo]

IIRC there is a technical reason for orphaning the original object and adding a new modified version at the end of the file. Not all objects are relocatable in a upk, any objects of type SoundNodeWave and I believe textures (?) as well cannot be moved unless they are updated too, because they contain hardcoded offsets within the upk file inside them. So by resizing an object in place all other objects after it in the file would be shifted and would require fixups to reflect the new position in the file. With the current approach everything else stays exactly where it is, only the resized object moves and hopefully its not of a type that requires offset fixups.

[Zyxpsilon]

If it all *must* be handled that way... then, i actually don't mind much.

 

It's simply a real pain to deal with in certain situations like what just happened to me. Now that i know what it's all about (and since XMTS gave me some workaround solution), i'll just have to wish for a new PatchUPK "code" that could somehow help us -- if ever. ;)

[wghost81]

2Zyxpsilon

You can't use REL_OFFSET without specifying global offset first. Use OFFSET if you want to avoid object oriented patching. But note that in this case you will be struggling with the very essence of the Patcher: it is built to be object oriented. It does support offset based patching, but doesn't guarantee compatibility in this case.

[LiQuiD911]

I am struggling with simple patching :\

 

I'd like to swap a virtual function with an instance variable in XGUnit.ApplyHPStatPenalties() :

 

GetUnitMaxHP with m_iLowestHP in " fPct = float(m_GetUnitHP()) / float(GetUnitMaxHP());"
, the virtual function's hex code is slightly bigger than the variable's so i shift "/ float(GetUnitMaxHP())" to the left and then fill the extra hexes with NO-OP

 

UPK_FILE=XComGame.upk
OBJECT = XGUnit.ApplyHPStatPenalties : AUTO

FIND_HEX=1B 01 3C 00 00 00 00 00 00 16 38 3F 1B 04 3C 00 00 00 00 00 00 16 16
MODDED_HEX=01 f4 c4 00 00 38 3f 1b 04 3c 00 00 00 00 00 00 16 16 0b 0b 0b 0b 0b

 

the resulting code in UE Explorer seems fine "fPct = float(m_iLowestHP) / float(GetUnitMaxHP());" but the game crashes :sad: What am I getting wrong?

Edited June 18, 2015 by LiQuiD911

[SpazmoJones]

I am struggling with simple patching :\

 

I'd like to swap a virtual function with an instance variable in XGUnit.ApplyHPStatPenalties() :

 

GetUnitMaxHP with m_iLowestHP in " fPct = float(m_GetUnitHP()) / float(GetUnitMaxHP());"

, the virtual function's hex code is slightly bigger than the variable's so i shift "/ float(GetUnitMaxHP())" to the left and then fill the extra hexes with NO-OP

 

UPK_FILE=XComGame.upk

OBJECT = XGUnit.ApplyHPStatPenalties : AUTO

 

FIND_HEX=1B 01 3C 00 00 00 00 00 00 16 38 3F 1B 04 3C 00 00 00 00 00 00 16 16

MODDED_HEX=01 f4 c4 00 00 38 3f 1b 04 3c 00 00 00 00 00 00 16 16 0b 0b 0b 0b 0b

 

the resulting code in UE Explorer seems fine "fPct = float(m_iLowestHP) / float(GetUnitMaxHP());" but the game crashes :sad: What am I getting wrong?

 

Try patching the entire line (not just the variable reference) and put the nops at the end of that instead.

[wghost81]

LiQuiD911, function call has 10/10 memory/file size and you've replaced it with variable (9/5) and nops (5/5), which resulted it 14/10 memory/file size and messed up all the subsequent code and the whole script, as header still holds old values. Resizing this part of the code with before/after patching should help, but you need to use pseudo-code for memory calculations to work correctly.