Expanding function size in UPK

[Bertilsson]

Oh well, possibility to increase size any function up to 65k is really no small step in either case :)

[bokauk]

This is huge and will unlock so much potential for XCOM modding!

It's exactly what we need, well done! :D

[Drakous79]

Great job :thumbsup:

[johnnylump]

I will chime in with a "brilliant!" and ask whether this or some related development would also somehow allow us to expand enumerated types?

[wghost81]

Unfortunately, enumerated types are namelist table entries, so expanding these won't be easy. I haven't looked into enums object data so far, may be it will be possible to add new enums with some weird names from nametable, I don't know. :)

[Amineri]

I will chime in with a "brilliant!" and ask whether this or some related development would also somehow allow us to expand enumerated types?

 

 

Unfortunately, enumerated types are namelist table entries, so expanding these won't be easy. I haven't looked into enums object data so far, may be it will be possible to add new enums with some weird names from nametable, I don't know. :smile:

 

Also each element of an enumerated list requires an entry into the object list, plus one object for the enum container itself. Structure definitions work the same way. Enum and structure elements get their namestring by following the index to the name list from the object entry that implements them.

 

So an enum with 20 values requires 21 object list entries, and a structure with 20 types requires 21 object list entries. So adding additional enum types or structure members is exactly as difficult as adding a new function.

 

The hex format for the structure definition makes this very clear:

 

35 <reference to struct member> <reference to struct container> 00 00 <instance variable>

 

So to build m_aMyStruct.iStructElem, would be :

35 <reference to iStructElem> <reference to iStructElem's container struct> 00 00 01 <reference to m_aMyStruct>

 

These "references" are really just indices into the object (or import) list.

[Drakous79]

Can be a mod, that uses move and expand feature, uninstalled? I mean something like move back and shrink, that could avoid verifying integrity of game cache.

[wghost81]

Can be a mod, that uses move and expand feature, uninstalled? I mean something like move back and shrink, that could avoid verifying integrity of game cache.

Since verifying cache is a way to revert your game to vanilla, I haven't ever bothered with uninstallation. If you don't like this way of uninstalling mods, the easiest way to make an uninstaller will be to make backups, manually or automatically. Old function is still present in upk, although you have to know it's offset and size to restore original objectlist entry.

 

I'm working on GUI wrapper for PatchUPK now, which will automatically unpack UPKs and make backups before any change is made.

[Drakous79]

A copy of old function is appended to the end of upk file? What would happen if there are both old and expanded function in the upk and offset and size is set to the old one?

 

I like if there's convenient way to remove mods without need to reinstall everything because of one mod. Would be nice to have some installation protocol or log with info about original size and placement of old function, that could be used for reverse process. Or it can be part of the mod. If possible, it is better than backup, because backup fails in case more mods are installed afterwards. For example a mod altering XComGame and XComStrategyGame - bad things may happen, if only XComGame is restored from backup.

 

It's just an idea. I don't mind verifying cache. But I am worried about compatibility of mods. Well, it's something we don't care about much, mainly because of "ease" of modding we've been given.

[Bertilsson]

I would like an intelligent installer that accepts function name and auto-expand/relocate that function if there is not enough room to fit the mod data :)

 

If it also accepts local offsets it doesn't have to have any negative impact on mod compatibility as long as everyone starts using the same installer (or at least same logic in their installers).

 

The size of the resulting expansion data would be so small that I cannot dream of anyone seeing the wasted space as any issue, even if the same function was expanded repeatedly.

 

Something like this

[XComGame.XGUnit.LoadSquad:LocalOffset]

 

If it was also accepting local before and after hexes it would even be a step forward in mod compatibility as such before and after hexes could be very small and focused on only doing what is needed and wouldn't be affected by additional data added in that function as long as that part is not directly affected by previous mod.

 

But I guess I am getting a bit off topic now :)