UPK Utils

[Zyxpsilon]

tracktwo,

When and *IF* you can spare some time, could you please have a look at this weird "flaw" for me since i'm somehow positive that one of my ReCLR project feature would be causing such stuff??

 

http://forums.nexusmods.com/index.php?/topic/2764974-beta-15c-bug-reports/page-23&do=findComment&comment=24542329

Edited May 25, 2015 by Zyxpsilon

[wghost81]

c and c++ do not allow // in strings either, they use escape characters instead, so it looks like this: \/\/. I should have used escape characters from the very start, but for some reason I decided not to. For the same reason pseudocode decompiler outputs strings as they are, sometimes resulting in bad code, which is impossible to apply.

 

As I said previously, I am working on GUI modding utility to include all the improved command line utilities and make Zyx's life better. :) Unfortunately, Witcher 3 is now out, so I'm torn between it and XCOM. :)

[tracktwo]

zyxpsilon That's really weird. Is it the scanner mod that you're referring to with the tacticalhud changes? Which pistol strings cause the bug?

 

And not to be too much of a pedant, but const char*x = "//"; is perfectly cromulent c++, but that isn't really important cause modfiles aren't c++ :) Regardless, I'm looking forward to the new features. I hadn't upgraded in a while and just got the new [@] () stuff and it's wonderful. Anything that makes computing jump offsets easier is a huge quality of life improvement, so thanks for that.

[wghost81]

Yeah, my bad, you're right. Just never had a need for it in any of my programs, so I never knew it is allowed. :)

[Zyxpsilon]

wGhost, i might need your help with a PatcherGUI error with one of my files;

PatchUPK
Can't open D:\XCom_EU\PatcherGUI71\Mods\(2D-)ReCLR-LW4_CustomStrategyHUD(UI_z).txt (file does not exist, or bad, or not ASCII)!

That's the only message i get... could it be the huge file size? 204,725!!

I've used too many comments // or + characters, etc -- maybe?

All the other regular files were saved in the same ways and they are working fine.

 

tracktwo (nope... this isn't about your Scanner-Mod),

 

Well, here's the essential i guess -- it's an excerpt from a current PM conversation with Spazmo...

 

------------------------

Since i am using HTML fonts to color every Weapon-Names (straight from Localization INT files) for all instances of their strings (both in the Strategy (Inventory, GreyMarket, Build Items, etc) & Tactical (Ammo Panels) gameplay layers.), i needed to edit the WeaponContainer Class in gfxTacticalHUD for the following function;

-----------------------------------------
function SetWeaponName(str)
{
this.nameField.text = str;
this.nameField.autoSize = true;
this.nameField._y = this.startNameY - this.nameField.textHeight;
if(this.nameField.textWidth > this.bgBarNameMinWidth)
{
this.bgBar._width = this.nameField.textWidth - this.bgBarNameMinWidth + this.bgBarDefault;
}
else
{
this.bgBar._width = this.bgBarDefault;
}
}
------------------------------------

with this slight correction...

this.nameField.htmlText = str;

 

A simple byte change and everything was working as intended...

[bEFORE_HEX]
96 04 00 04 01 08 21 4E 96 04 00 08 4E 04 02 4F
[AFTER_HEX]
96 04 00 04 01 08 21 4E 96 04 00 08 4D 04 02 4F

 

Opinion, thoughts?

------------------------

Edited May 26, 2015 by Zyxpsilon

[wghost81]

Zyxpsilon, can I see the file in question?

 

Only ASCII characters (0 through 127) are allowed in file path/name and inside the mod file itself. Extended ASCII characters and Unicode characters are not allowed, even in comments. I know this can be inconvenient and artificial, but I have zero experience with code tables and things like that, so I decided to stick to the ASCII table, as it is the same for all locales, and return to this problem later. I will try to implement full Unicode support in upcoming GUI version of UPK Utils.

 

So, general advice is to keep your path and file names as simple as possible and to not use locale-specific characters in modfiles.

[tracktwo]

I'm really bad at reading the actionscript bytecode, but I'm guessing the 4E/4D change is a string table reference where 4E is "text" and 4D is "htmlText"? Seems reasonable to me if so. You say it's now working as intended or are there still bugs?

[Zyxpsilon]

wGhost -- AFAIC, there are no extra characters in the saved file... but i'll still eMail it to you. Remind me where though!

 

PS; Oooopppss... looks like there *WAS* indeed a silly character burried in a comment line. I also found another typo when PatcherGUI couldn't find a "code block"... two bytes were glued together! And then -- the magic words showed up; Patched successfully!

 

TrackTwo, yes, the 4E/4D trick is the HTML compatibility edit. It allows the "Font" coloring instructions to pass through via INT strings and straight into various other HUD areas. So this tiny correction happens to have collateral effects on other functions like the Hovering Antenna *BUT* only for the Pistol slot. In a similar way, when the Arc-Thrower (by ini edit) is used in that slot... it also will cause the flaw.

Edited May 26, 2015 by Zyxpsilon

[Zyxpsilon]

Okay... this stuff completely eludes my mind. It's as if the Patch code refuses to apply corrections at the proper OFFSET even when it's declared as 0.

 

The area i want to (still) customize is the Barracks List. I think that the newest feature (Spazmo's ShowXP in the status column) added by Beta15E4 is re-allocating multiple "copies" of the OBJECT (gfxSoldiersList) itself in a protected area.

 

My "regular" UICollection_Strategy_SF.UPK patcher file has something similar to the code below;

// BL1a) DefineShape4 (53) :: Main Frame (#BF0000 -- #CC1010)
//REL_OFFSET=12A9707 --- 6FA73A
REL_OFFSET=0
[BEFORE_HEX]
FF 14 51 0B 00 00 35 00 87 FC BA AC 4F F8 59 61 70 87 FC BA AC 4F F8 59 61 70 01 00 01 14 00 A0 02 00 03 67 E8 ED 99 01 26 0A 9A C1 F6 7E E0 01 B3 47 1A 5A 96 E5 8D FC 96 0B D2 C4 5F 25 4D E3 4E D3 BE 96 B9 7B 53 C5 C5 65 59 7A 52 BF CF FF E9 CE F2 BB 4E 54 D9 CD 06 20 CE 44 D9 E8 8D 57 D1 3B AF 23 E5 EE 00 1B EA 79 00 06 C6 37 C2 00 00 01 3C 00 A0 02 00 03 67 E8 ED FF 01 25 4D B7 7B E0 A4 FB 53 C5 C5 65 59 78 59 60 5E A1 20 09 07 04 FF C6 9D A7 78 26 F0 60 A5 D4 56 F9 C0 F5 F2 DD D0 60 A9 AE 0F 6F C3 32 71 A5 A9 6E 58 DF C1 36 02 F0 35 A9 DB 79 50 1F 34 18 83 38 1C 37 C2 00 06 00 67 E8 ED 11 00 67 E8 ED 16 00 67 E8 ED 02 00 67 E8 ED 07 00 67 E8 ED 0C 00 67 E8 ED 10 00
[AFTER_HEX]
FF 14 51 0B 00 00 35 00 87 FC BA AC 4F F8 59 61 70 87 FC BA AC 4F F8 59 61 70 01 00 01 14 00 A0 02 00 03 CC 10 10 99 01 26 0A 9A C1 F6 7E E0 01 B3 47 1A 5A 96 E5 8D FC 96 0B D2 C4 5F 25 4D E3 4E D3 BE 96 B9 7B 53 C5 C5 65 59 7A 52 BF CF FF E9 CE F2 BB 4E 54 D9 CD 06 20 CE 44 D9 E8 8D 57 D1 3B AF 23 E5 EE 00 1B EA 79 00 06 C6 37 C2 00 00 01 3C 00 A0 02 00 03 CC 10 10 FF 01 25 4D B7 7B E0 A4 FB 53 C5 C5 65 59 78 59 60 5E A1 20 09 07 04 FF C6 9D A7 78 26 F0 60 A5 D4 56 F9 C0 F5 F2 DD D0 60 A9 AE 0F 6F C3 32 71 A5 A9 6E 58 DF C1 36 02 F0 35 A9 DB 79 50 1F 34 18 83 38 1C 37 C2 00 06 00 CC 10 10 11 00 CC 10 10 16 00 CC 10 10 02 00 CC 10 10 07 00 CC 10 10 0C 00 CC 10 10 10 00

Along with many more sections that alter various shapes & text components.

I've noted the OFFSET(s) in the second comment line. These are simply "resetting" consistantly.

 

Any help?

[wghost81]

None before I can see the whole script and the error log. ;)

 

REL_OFFSET=0 in front of BEFORE_HEX is merely a temporal solution to force patcher to search for the BEFORE_HEX data from the beginning of the object. Actual offset value is set when BEFORE_HEX is found and AFTER_HEX is applied at that offset.

 

If you're using patcher to mod another patcher's mod, never use global search as the old code still exists inside upk and new one is appended to the end of the file. Use OBJECT key to find the proper part of the file and then search inside it to find the data you need.