[Feature] Names and/or tags for DEHACKED actors

[TheKins]

GZDoom version

GZDoom 4.13.0 onwards

Which game are you running with GZDoom?

Doom 2

What Operating System are you using?

Windows 10

If Other OS, please describe

Windows

Relevant hardware info

No response

Is your feature request related to a problem? Please describe.

My friends and I are interested in extending our gameplay mods to support Legacy of Rust, the new content of which is (currently?) implemented via a MBF21 DEHACKED lump. This means that all the new content has the generic placeholder names like Deh_Actor_154, which is confusing and can potentially cause false positives with other mapsets that use MBF21.

Describe the solution you'd like

Most modern mapsets that use DEHACKED extensions give their actors unique names in the file for level editors to interpret. (ex. Thing 155 (Vassago)). Would it be possible to rename the DEHACKED placeholder actors at load to incorporate these while keeping the "deh_" prefix? (For example, Deh_Rocket_In_Flight). Failing that, copying this unique name to the actor's Tag property will give modders directly working with the CheckReplacement event handler something to check.

Describe alternatives you've considered

I suppose one could load one of the plaintext files in the WAD via Zscript and parse it looking for enough specific lines that you can nod your head and go "yup, this sure is id1.wad". That's more than a little painful, though,

Add any other context or screenshots about the feature request here.

[coelckers]

Renaming these actors will cause other problems. Using the tag would be doable, but that still doesn't address the core problem here, i.e. that using Dehacked as a way to define official new content clashes badly with GZDoom's mode of operation.
Ideally we should redefine all these actors via ZScript and then block loading the Dehacked patch to have something clean to work from.

[TheKins]

My understanding is that they used the DEHACKED patch instead of the native-code versions due to deadline constraints. I think there are plans to update it to use the native code versions at some point once the ID24 spec is fully finalized, but I do not know if that's still the case and haven't had the opportunity to ask.

I believe @RicardoLuis0 has already done some work on porting the ID24 actors to ZScript based on the GPLed ID24 spec code, so if you want to go that route at least some of the work has already been done.