Feature: list/export classnames with corresponding CRC_ids

[Polly44]

I'm a tablemaker @fearlessRev, and use - for my AC titles - information that can be identified by its corresponding CRC_value. In particular classnames (such as EconomicSytemSettings) can/could be identified "quite easily". Since AC Valhalla (and beyond) this info is not (directly) present anymore. However: your tool indicates that you can/could produce this info nonetheless...
=> to give some examples:

1. you can produce a (full) list of inventory_item records; which are uniquely identified by their hex_Ids in the 1st column (the 3rd column is the actual classname ~ or so i assume). That name 'InventoryItemSettings' can also be identified by a uniqueId (which is what I am after primarily)
2. if even possible, allow listing of properties per class (see Inspector)
   ('EconomicSystemSettings' is a good/related example here)

ps: I'm obviously interested to know how this info is obtained, although I doubt it can be produced while game is running (and thus less practical from my point of view)

[forge-master]

@Polly44 is this a question about class layout in memory? I'm not super knowledgeable about how that. I assume it could be somewhat inferred in some way, but my knowledge is mostly about the layout of the data on disk.
Or are you asking for the list of class/properties hashes?

Technically, all this info (most?) is present in the .schema files that ships with ACViewer. I just never clearly opened the format because it's still in flux.

[Polly44]

"format because it's still in flux": can't place this remark, but no probs.
Just 2 examples:

1. AC Mirage: [ https://ibb.co/HYdQLhP ].
   as you can see, the hex_ID in the 1st column is also used in my table(s) to identify thàt particular item. Iow if i can easily export that particular view, I'll have all InventoryItems identified (incl the ones managed internally)
2. AC 1: [ https://ibb.co/cDnrCSt ]
   again, one can easily "match" most of the information between "disk_struct" and "memory_datastruct".
   'DesynchronisationSettings' is a classs (1st offset refers to VFT table.
   ps: while most values can easily be linked, in this particular case the 'CivilianKillEnable' bool I could identify evt by Trial&Error (~ highlighted entry)
   => hence my 2nd req obviously. It would be amazing to get the offset_descriptives filled accordingly

Bottomline: pt 1. is by far the most important one. I can give you more info on that part, but it is (kinda) confidential. If you do not mind contacting me at FearlessRev, we could pm directly without giving out each others personal info.
(check ac mirage table by Paul44)

ps: whether or not you could do something on my end, you can always ask me "anything" related to AC titles and I'll do my best to help out...

[forge-master]

I'm sorry, I have a very hard time understanding what you're trying to ask for. Maybe because I never looked much into CheatEngine and stuff like that.

""format because it's still in flux": can't place this remark, but no probs." ACViewer is released with a bunch of .schema files. Those contains the information on how to load the forge files (for the most part). Those files are generated by me, and follow my own format. This format is not necessarily final and could change in future revisions.

1. Not sure what you are asking for here. The matching between the type identifier and the type name? It's a just a crc32 of the type name. A list of all the objects of that specific type? I just have a hard time following.

2. I think you're asking about how to automatically know where each property is loaded in the class memory layout. If that is the case, there isn't too much I can do. The offset isn't present in the property descriptor. I assume most of the time they are in the same order as on disk, but that's not always guaranteed. I definitively know the bitfields for instance are not stored the same way as on disk. That said, I have ways to remove the guesswork, but that's on a per-type basis. I also have the internal properties types (the ones not stored on disk).

I don't know where you want me to contact you, but it'd be easier if you pinged me on the ACViewer discord, and go from there.

[Polly44]

yep, we "live" in 2 different worlds, so it'll take some time on our respective ends to pick_up/relate with both worlds.

Sorry, but not active on Discord... at all. I'm pretty much limiting/dedicating my time to [Fearless Revolution] these days. That said: let's only concentrate on pt1 for the moment (and info already present in your tool)...

What i show in that picture, is what I've collected - using CheatEngine - to present that particular info in my table. in your Inspector, you show the EXACT same info (indeed "linked" to its crc32 hexval in that (over)view ~ which makes it a unique identifier).

My request: basically a (menu)option to export (delimited) thàt very same view to a textfile. That is doable (even to my standards :)) (you have an 'export' option, but this is only for Terrain)

ps: i obtain this kind of info - item_descriptives - via opcode research, and this can take some considerable time. Plus: i can only collect what is - visually - accessed; iow shown on screen (most of the time)...
ps2: i have recently looked into another tool, called 'AnvilToolkit'. This tool allows me - among other things - to export structures in xml-format. I've recently been able to export [0_-_LocalizationPackage_English], which contains all english descriptives; including those for them InventoryItems. Still need to look into this how this is linked to the actual datastructs I collect though...
ps3: I'll prepare some more info later (this week).

[Polly44]

as promised:

1. Collecting MapIcon info: [ https://www.dropbox.com/scl/fi/uzzdww23dpz710k5jew0t/AC4_Collect-MapIcon-info_v1.pdf?rlkey=fqh8n3qj71rrvg91ktwnxit12&st=qbnrnlim&dl=0 ]
   another example of the type of info I collect/offer in my tables..

2. Collect Localization Info: [ https://www.dropbox.com/scl/fi/ukn15f8ozzm28yiwn3o49/AC4_CollectLocalInfo_v1.pdf?rlkey=w5x90ukirbjzkgbcet0btld98&st=6ssn5nt3&dl=0 ]
   I've spent considerable time this week on figuring out how to "link" localized info. Found it as explained in this doc.
   Note: while not explicitly mentioned in this document, you'll find the 'localization_IDs' as well via the Inspector.
   (i'm 99% sure you use that info on your end as well ~ if not, my bad...)