Check for DeHackEd-modified actors

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON
Topic review
   

Expand view Topic review: Check for DeHackEd-modified actors

Re: Check for DeHackEd-modified actors

by Player701 » Tue Jan 21, 2020 1:42 am

It is possible to implement this in user code, at least to a certain extent. The latest version of my project has some basic DeHackEd detection built in. It parses DEHACKED lumps and checks for mentions of things and frames with matching numbers. This information is then used to initialize the actor replacement table.

You can find the relevant bits of code here (the main DeHackEd detection code) and here (among other things, this class manages replacements by leveraging the data provided to it by the DeHackEd detector).

I admit this solution is not perfect because: 1) we cannot access DeHackEd code that is loaded via the "-deh" parameter, and 2) we only check if an actor is mentioned in DeHackEd code, and we cannot tell if the modification in question would actually interfere with our own code. The latter issue is particularly difficult to address, but it would still be somewhat easier if we didn't have to do all the parsing manually. Therefore, I do agree that some sort of engine-side DeHackEd API for ZScript would be nice to have.

Check for DeHackEd-modified actors

by Guest » Mon Jan 20, 2020 5:30 pm

Currently, there is no straight-forward means of identifying if an actor has been altered by DeHackEd. This is largely due to the various subtleties that have to be accounted for:
*The actor's Properties and Flags can be altered
*The starting frames of the actor's States can be changed (e.g. the Spawn state may be altered to start on a different frame compared to the 'vanilla' actor)
*Each frame the actor calls is subject to being altered in a number of ways (duration, action pointer, and perhaps the trickiest: the next frame/state)

There are maybe even other conditions I'm forgetting. But, in short, DeHackEd can do quite a lot of things to drastically alter an actor with even a small tweak.

My use case is to be able to selectively replace or ignore an actor via EventHandler, by checking if DeHackEd is modifying said actor. I could determine if an actor is "safe" to replace, and then could safely autoload a file that replaces vanilla actors (projects such as Smooth Doom may come to mind), without worry about DeHackEd replacements getting messed up.

Top