[PROJECT] Reconsider StructResolver approach due to incompatibility with reccmp

[TheRedDaemon]

Sadly, there is no real way around it: We either have to define the precise template object for every element instance, or we have to change the approach.

• ❌ I already tested an instance based approach. However, the definition is complicated, and it can not create filled structs. There is also the downside that certain structures that were already broken using the game ptr now are even more broken.
• ❓It might be possible to create a function based approach again. This should have consequences for the creation, will add artifacts to the init process, and the risk of double creation rises. It has also some of the same shortcomings as the instance based approach, since this only can help with creation of the instance, not with referencing.
• ❓Switch to a macro based approach. Unsure how that would look, but instead of templates, the entire system is switched.
• ❓We could talk to the reccmp people more, but I am not sure what to request. Our approach is just so different.

[gynt]

We either have to define the precise template object for every element instance

What would that look like? Do you have an example?

[TheRedDaemon]

With the current state it would need to be the definition of the instance:
StructResolver::Instance<"complete-type-path","game-address-as-decimal">::instance
Example:
StructResolver::Instance<OpenSHC::Audio::SoundEffectsHelperData1,14628848>::instance

It also annoys me because it is an "interna" (since still public, but hidden by macro).

[TheRedDaemon]

Attempted to encode some information in the types or PDB to possibly present the reccmp people.
No success. Even when accepting complicated workarounds it caused issues.
Even if I find something that "works", I would doubt that the reccmp people are interested in something that takes part in the compilation process...

Follow up on this: In our unique case, we would actually be able to theoretically provide enough information:

template <int original, void* replacement> struct RECCMP_GLOBAL_STRONGHOLDCRUSADER {};

#define MACRO_STRUCT_INSTANCE(GAME_ADDRESS, GAME_ADDRESS_NUMBER)                                                       \
    template <typename T> struct StructResolver::Instance<T, GAME_ADDRESS> {                                           \
        typedef int RECCMP_GLOBAL_STRONGHOLDCRUSADER_##GAME_ADDRESS_NUMBER;                                            \
        static T instance;                                                                                             \
        typedef RECCMP_GLOBAL_STRONGHOLDCRUSADER<GAME_ADDRESS, &instance> reccmp;                                      \
    };

resulting in the following type data (to note that the structs are instantiated):

0x1412 : Length = 150, Leaf = 0x1505 LF_STRUCTURE
	# members = 0,  field list type 0x0000, FORWARD REF, 
	Derivation list type 0x0000, VT shape type 0x0000
	Size = 0, class name = RECCMP_GLOBAL_STRONGHOLDCRUSADER<14628848,&StructResolver::Instance<OpenSHC::Audio::SoundEffectsHelperData1,14628848>::instance>

0x1413 : Length = 90, Leaf = 0x1203 LF_FIELDLIST
	list[0] = LF_NESTTYPE, type = T_INT4(0074), RECCMP_GLOBAL_STRONGHOLDCRUSADER_0x00DF37F0
	list[1] = LF_STATICMEMBER, public, type = 0x1411		member name = 'instance'
	list[2] = LF_NESTTYPE, type = 0x1412, reccmp

However, the reality is, that we have a very special case where our structure knows the address.
I see no particular way to make this in any way generic to get a benefit. At most, you could encode that this template produces classes that are interesting for Reccmp, but outside of getting this list, you would still need to "match" these, which removes the benefit.

---

Other comment regarding the instance approach:

• I would have to test for behaviour again in this case. The current approach garantuees init during start and even if no one uses the type. I am not sure this will work with the direct instance.

[TheRedDaemon]

Current state looks like the "internal" structure needs to be fixed and comments for them to be created.
While I mananged to make the "instance" version kinda work, it is a bit of a mess:

• Constructor creation is more complicated
• Start Up behaviour would need to be tested.
• The game ptr actually messes the opcode structure even more up if non supported structures like a direct add is involved. While the current approach already produces differences, this one makes the method unrecognisable if the game pointer is used.

Regardless, I will save the non-static approach in an experimental branch: LINK