Increase Persistent Heap Size (Load PAL IfAll.usd in NTSC)

[UnclePunch]

$Increase Persistent Heap Size [UnclePunch]
*Slightly increases persistent heap size to the PAL value, so the PAL IfAll.usd can fit in memory
043ba39c 004f9000

If anyone tried to use PAL's IfAll.usd for the smaller stock icons and more transparent insignias, it would crash because the game did not have enough room for it in the persistent heap (PAL's is 2 kbs larger). This changes it to the value it is in PAL.

Still not sure what about this file causes the icons to be smaller and shifted, but the insignia's transparency is controlled by the value shown here,

 

[Punkline]

Wow, nice Kung Fu! That’s a handy trick.

Still not sure what about this file causes the icons to be smaller and shifted

I would bet that it’s very similar to the damage HUD digits, which also use IfAll.usd to store their assets via HSD objects.

In the case of the damage HUD it’s like any other HSD object; where a texture is assigned to a joint using the JObj -> DObj -> MObj -> TObj relationship, stretched across a polygon PObj, and then transformed by information in the JObj and TObj. If the joint isn’t animated, then it might be possible to transform through modifications to object descriptions in IfAll, or to the instances generated in RAM from the object descriptions.

I don't recall whether these icons are animated or not -- but for animated JObjs -- direct modifications to a JObj that change the scale/position of the resulting texture will be overwritten by transformations caused by AObj assignments. A JObj like this will need to either be transformed procedurally with code + calls to HSD_JObjSetMtxDirtySub, or have their animation’s FObj strings modified in the file that it resides in.

 

[UnclePunch]

Wow, nice Kung Fu! That’s a handy trick.


I would bet that it’s very similar to the damage HUD digits, which also use IfAll.usd to store their assets via HSD objects.

In the case of the damage HUD it’s like any other HSD object; where a texture is assigned to a joint using the JObj -> DObj -> MObj -> TObj relationship, stretched across a polygon PObj, and then transformed by information in the JObj and TObj. If the joint isn’t animated, then it might be possible to transform through modifications to object descriptions in IfAll, or to the instances generated in RAM from the object descriptions.

I don't recall whether these icons are animated or not -- but for animated JObjs -- direct modifications to a JObj that change the scale/position of the resulting texture will be overwritten by transformations caused by AObj assignments. A JObj like this will need to either be transformed procedurally with code + calls to HSD_JObjSetMtxDirtySub, or have their animation’s FObj strings modified in the file that it resides in.

whats the pointer chain for JObj -> DObj -> MObj ?

 

[Punkline]

Here’s a cheat sheet:

The squares on the left are object descriptions that would reside in IfAll.
The octagons on the right are instantiated objects in RAM.

So, JObj -> 0x18 -> 0x08 would get you to a live MObj.
JObjDesc -> 0x10 -> 0x08 would get you to an MObjDesc.


If you want to do research on IfAll, note that a live JObj will point to its JObjDesc in offset 0x84, and you can use this tool to convert loaded file RAM address into literal file data offsets. This can help you find where in a file a JObjDesc comes from, and any of its related object descriptions.

Edit - this will also work for the addresses of image headers, which are pointed to by live TObjs. You can search for image header data or image data easily with tools like memory engine, or cheat engine; which allow you to search for strings of bytes.