feat: T5 and T6 destructible def dumper#886
Conversation
0b40580 to
1242916
Compare
| if (context.m_gdt) | ||
| { | ||
| const auto infoString = CreateDestructiblePieceInfoString(piece, asset); | ||
| GdtEntry gdtEntry(asset.m_name + "::piece_" + std::to_string(i), GDF_FILENAME_DESTRUCTIBLE_PIECE); |
There was a problem hiding this comment.
I checked the official modtools and there were two destructible pieces in a gdt in total:
vehicle_american_jeep_base_piece and vehicle_american_jeep_piece (at least for supported games, BO3 has a bunch more).
But none were using a name with :: and i don't know how compatible that is exactly 😅
So i'd suggest to maybe
- Use a name without special characters
- Use the same name for the gdt entry and the file produces when it is raw
I'd suggest the following: {}_piece{:02}
Maybe add a new method in the DestructibleDefCommon for that creates a name for the destrucible piece and one that creates a filename so the filename method can just call the "name for destructible piece" method.
Also small nit: use std::format when possible 😛
There was a problem hiding this comment.
Yeah the :: naming is just a guess from me, alot of this code is mostly from my Xbox 360 variant of the dumper I worked on last year, so some of it might be wrong like the fields and names, this is also why std::format isn't used.
I was gonna work on it some more but completely forgot about it until I got an email 😅
|
|
||
| std::string GetFileNameForDestructiblePiece(const std::string& assetName, const int pieceIndex) | ||
| { | ||
| return std::format("destructiblepiece/{}_{}", assetName, pieceIndex); |
There was a problem hiding this comment.
See previous comment about naming the destructible piece gdt entry
| {"numPieces", offsetof(DestructibleDef, numPieces), CSPFT_INT }, | ||
| {"pieces", offsetof(DestructibleDef, pieces), CSPFT_INT }, | ||
| {"clientOnly", offsetof(DestructibleDef, clientOnly), CSPFT_INT }, | ||
| }; |
There was a problem hiding this comment.
I'm a bit confused on where these cspField_t definitions come from?
They are not from the game, the game does some weird weird stuff with 453 destructible def fields (instead of the 6 here) that overwrite parts of the destructiblepiece values.
Also 70 destructible piece fields (instead of the 55 here).
Don't understand me wrong, what the vanilla game does is absolutely horrible (adding 448 specific field types 🙃). I'm sure this could be solved better by creating a helper struct.
So i'd have nothing against solving this in a better way.
But as it is currently, this is omitting a lot of properties from the destructible def asset.
There was a problem hiding this comment.
I'm sure I've seen these in the game, perhaps I'm remembering wrong. Well I'll get some time later and go back and change whats wrong
There was a problem hiding this comment.
Yeah turns out I was wrong, I'm not sure what went wrong there
| |----------------------|-----------------|-----------------|------------------------------------------------------------------------------| | ||
| | PhysPreset | ❌ | ❌ | | | ||
| | PhysConstraints | ❌ | ❌ | | | ||
| | DestructibleDef | ❌ | ❌ | | |
There was a problem hiding this comment.
Any reason for omitting the T4 variant? Not that you have to do that here, just curious if there was a specific specialty on it that makes it different from the other two games. As you included T4 in the last PR for example.
There was a problem hiding this comment.
No reason, just never got around to working on the T4 one. This was worked on before I did any T4 work so that's kinda on me for not putting in the effort to also support T4 for this one
1242916 to
a87850d
Compare
…/OpenAssetTools into destructible-def-dumping
2 participants
Adds dumping support to T5 and T6 for the
DestructibleDefasset