Debug info to trace item group spawning

[RenechCDDA]

Summary

Interface "Debug info to trace item group spawning"

Purpose of change

It has often come up (e.g. #65450 ) that something mysteriously appears in a location which clearly shouldn't be there, but the provenance of the item is very difficult to trace. Normally the only way to do so is to check the mapgen for the tile it spawned on and go through every possibility. Item groups can contain other item groups which can contain others which... [etc] which means that you could be searching thousands of lines of json for one entry, jumping back and forth across files.

Describe the solution

Just (temporarily) store this information on the item.

When spawning a new group, pass the ID through the incredibly confusing item group spawning functions. Continue passing it through as it recurses, adding new context when new context is had. Then make the information available when debug mode is enabled.

Note that this information is not preserved across savegames, on purpose. Doing so would cause a lot of save bloat for no real gain. In cases where this is useful, debug functions can already be used to force suspects to spawn repeatedly until another incident is seen. This function just makes backtracking it much simpler.

Describe alternatives you've considered

🤷 some sort of outside-cdda interactive GUI tool which expands item groups and searches through them, and also optionally works by recursing? Outside my skillset, really

Testing

The formatting is truly awful and I have grown tired of figuring out where to put the spaces.

Clang will probably yell about not passing strings by reference, will see what I have to do about that

Additional context

[andrei8l]

Storing that trace as a mandatory string seems pretty heavy. That default string is 27 bytes (or extra 1Mb every ~37000 items) and the one from the screenshot is 154 bytes (or extra 1Mb every ~6500 items), compared to the base item class that's 528 bytes. That probably doesn't seem like much, but I still remember when Kevin refused to increase item by 8 bytes for a real gameplay need just a couple of years ago...

Consider storing item group IDs instead and reconstructing the string only when displaying item info.

Since you're not interested in (de)serializing that trace, another alternative is to print the spawn traces to the debug log when debug mode is turned on and not saving them anywhere.

[RenechCDDA]

Storing that trace as a mandatory string seems pretty heavy. [...]

Thanks, I actually forgot I was supposed to wrap this all in if statements - it should only be getting stored if debug mode is on. Although I'm not sure if empty string will still need to be allocated space. Maybe std::optional<std::string>?

Since you're not interested in (de)serializing that trace

I'm OK with the idea but I think it's a complete non-starter due to the issues mentioned.

another alternative is to print the spawn traces to the debug log when debug mode is turned on and not saving them anywhere.

This seems like a pretty decent idea too, thanks. I'll have plenty to check out.

[GuardianDll]

it should only be getting stored if debug mode is on

another alternative is to print the spawn traces to the debug log when debug mode is turned on and not saving them anywhere.

Wouldn't it cause the issue because no one really plays the game with debug mode permanently on? i suspect it would go something like "there is a weird item spawned in this place, but i can't trace it using this function because i turned it on only after i spot the bug, not before"