UPK Utils

[wghost81]

Doesn't adding name references suffer the same multi-mod install issues as adding import/export entries? If two different mods both add to the namelist, then the references to each would be different depending on install order. This would require mods to always use the string-based name reference to be converted to the numeric name reference at mod-install time, wouldn't it?

Yes. Any Name/Import/Export entry does.

If the tool you're using to update the tables just pre-scanned for that entry, couldn't you just abort the insert and assume it was covered if the contents were the same? Especially for the name table. For the import/export table, I guess it would depend on if the signatures were equivalent.

If you'll add two copies of the same name to name table, game will probably crash, as all the entries in that table should be unique. Anyway, PatchUPK checks for existing names/objects and outputs a warning, so adding two identical names/objects is not possible. Edited June 30, 2014 by wghost81

[projectmercy]

Well, if anyone cares, here's how I'm using my logging.

 

Example mod that removes the max stat bonus from RollStat and logs the result:

 

 

 

 

MOD_NAME=DevOnlineMsg Logging Example
AUTHOR=ProjectMercy
DESCRIPTION=Example of my debug mod logging technique

Install via PatcherGUI / UPKUtils, Only tested in Enemy Within.
Version: 1.0


UPK_FILE=XComStrategyGame.upk

[ADD_NAME_ENTRY]
<%u 13>
<%t "DevOnlineMsg">
<%u 0x00000000>
<%u 0x00070010>

ALIAS=DebugLog:19 2E <XComGame.XComOnlineEventMgr> 19 2E <Engine.GameEngine> 12 20 <Engine.Engine> 0A 00 <Engine.Engine.GetEngine.ReturnValue> 00 1C <Engine.Engine.GetEngine> 16 09 00 <Engine.GameEngine.OnlineEventManager> 00 01 <Engine.GameEngine.OnlineEventManager> FF 00 <NullRef> 00 1B <DevOnlineMsg>

OBJECT=XGFacility_Barracks.RollStat:AUTO
[REPLACEMENT_CODE]
// iSpread = iHigh + iMultiple;
0F 00 <.iSpread>
92
00 <.iHigh>
00 <.iMultiple>
16
// iNewStat = (iLow - iHigh) + Rand(iSpread + 1);
0F 00 <.iNewStat>
92
93 00 <.iLow> 00 <.iHigh> 16
A7 92 00 <.iSpread> 26 16 16
16

// !DebugLog("Rolled Stat: " $ string(iNewStat));
<!DebugLog> 70 1F <%t "Rolled Stat: "> 38 53 00 <.iNewStat> 16 16

// return iNewStat;
04 00 <.iNewStat>
//EOS
53

 

 

 

Output looks like this:

 

 

 

[0015.29] DevOnline: Rolled Stat: 72
[0015.29] DevOnline: Rolled Stat: 42
[0015.29] DevOnline: Rolled Stat: 55

 

 

 

The one oddity, if you pick apart the code, would be in the ALIAS, you'll see at the end "FF 00 <NullRef>" the FF 00 is the virtual size of the DevOnlineMsg call (I believe, given Amineri's doco on it) but since I'm using string constants for this, the virtual size is based on the string length, which would mean you would think you have to separate the alias out into multiple parts and compute the virtual size on every log call. Oddly enough though, it doesn't appear to actually effect anything irrespective of whats in there. So I just set it to 0xFF. I haven't run into any issues with that so far. Since I'm not using it in a release mod, I'm not super concerned about it.

Edited June 30, 2014 by projectmercy

[wghost81]

Yes, we've noticed it too about virtual size. Sometimes it doesn't seem to affect anything and sometimes it causes the game to crash.

[Amineri]

From what I've seen, the relative size in such a situation only matters when there is a ReturnValue. The construction :

FF 00 <NullRef> 00 1B <DevOnlineMsg>

has FF 00 as the relative size of the referenced object. In this case the referenced object is DevOnlineMsg(), which has the hex structure 1B ## ## ## ## 00 00 00 00 16, so the memory size is 0A. Technically speaking the FF should be changed to 0A for correctness, but since the ReturnValue is <NullRef> (hex 00 00 00 00), it seems that the run-time Unreal Engine interpretter doesn't utilize the relative offset value.

[wghost81]

DevOnlineMsg("Message text"), actually. Isn't virtual size of an object include all function parameters?

[projectmercy]

DevOnlineMsg("Message text"), actually. Isn't virtual size of an object include all function parameters?

 

It does (Or at least UE Editor computes it that way). I checked all the examples in XComGame, and it changes based on the string const length. I think the important part of her post was strenghtening my theory that it only matters as regards a function call that results in a return. Maybe it has to do with stack allocation or something? No idea.

Edited June 30, 2014 by projectmercy

[projectmercy]

So, using text psuedo code is problematic. In the documentation:

 

<%t "text">
<%t "text with spaces "and inner quotes"">

 

It seems that the result is, the second > character ends the text section. So you can't have the value <%t "Where number > 5"> because it will assume the 5"> is another token. I assume this is a result of attempting to allow quotes in there and not escaping the quotes, but I think it would be easier if you required escaping the quotes. Either that, or there would ideally be a way to escape the greater than. For now I'm just switching to splitting the text section into multiple parts with the > hex in between.

[wghost81]

Yes, '<' and '>' characters are used to find pseudo-code tokens and you can't put those inside text tokens. But XCOM uses html tags for markup, like <br>. I didn't know that before, so I hadn't accounted for it. Escape characters are definitely on my To-Do list. :smile: Edited July 1, 2014 by wghost81

[projectmercy]

Yes, '<' and '>' characters are used to find pseudo-code tokens and you can't put those inside text tokens. But XCOM uses html tags for markup, like <br>. I didn't know that before, so I hadn't accounted for it. Escape characters are definitely on my To-Do list. :smile:

 

Nice, I learned two things in one post. Excellent.

 

I'll await the escape characters with bated breath then.

Edited July 1, 2014 by projectmercy

[wghost81]

I have an idea which will help preserve existing mods compatibility. What if for string tokens not the lone symbol '>', but the combination of two subsequent symbols '">' (with any possible whitespaces in between) will be considered an end of token? This combination seems rare enough.