req: RandomJump

[Mordeth]

Apparantly RandomJump can only work with actual dehacked frame numbers in the 'Unknown1' field and not a frame mnemonic, ie. '477' and not 'S_SARG_RUN1'. Can this be changed? Otherwise introducing lots of jumps will mean butchering an original monster for available framenumbers.

[WNivek]

Mordeth said:

Apparantly RandomJump can only work with actual dehacked frame numbers in the 'Unknown1' field and not a frame mnemonic, ie. '477' and not 'S_SARG_RUN1'. Can this be changed? Otherwise introducing lots of jumps will mean butchering an original monster for available framenumbers.

try prefixing it with 'frame:'

example from something I was messing around with:
frame S_DeadMarine1 { cmp = "TNT1|*|*|0|randomjump|S_DeadMarine21|*|frame:S_DeadMarine22|128" }

[Mordeth]

WNivek said:
try prefixing it with 'frame:'

Just tried this. Does not work? It falls through to NULL. It only works if I replace the mnemonic with an actual Dehacked frame number. My line:

frame M_FIND_B7 { cmp = "FIND|H|*|2|RandomJump|M_FIND_B0|*|frame:M_FIND_S0|25" }

[EDIT] Apparantly this is intended :/ From the manual: "Translated to the DeHackEd number of the indicated frame. If the indicated frame has no unique DeHackEd number, the S_NULL state will be stored and a warning will be issued to the verbose EDF log." And I'm using custom frames.

[WNivek]

Oh? *double checks his own work* Oh, heh, right. I forgot about that. sorry. ^^;

[Quasar]

Give the frame a DeHackEd number. Frames cannot store strings inside of their misc fields; I cannot magically make them be able to do this. This is why misc and args fields MUST translate all extended values into numeric indices. For things, sounds, and frames, this numeric index is called the DeHackEd number.

ALWAYS use DeHackEd numbers starting at 10000. All DeHackEd numbers less than 10000 are reserved for engine use.

Example:

frame S_FOO { dehackednum = 10000 }

[Mordeth]

Ah, I can just make up a number? Allrighty then :)

[Quasar]

Mordeth: I'm quite shocked that you were able to do much of anything complicated with EDF without ever assigning custom DeHackEd numbers to your entities. Do I need to clarify the docs further on this issue?

[Mordeth]

Quasar said:
Mordeth: I'm quite shocked that you were able to do much of anything complicated with EDF without ever assigning custom DeHackEd numbers to your entities. Do I need to clarify the docs further on this issue?

Yes :)

I did use them for custom things (for spawning stuff and things like that), but I didn't realise the same thing applied for RandomJump as well. Sometimes I can be a bit dense :)

[Quasar]

Ohhh, I see ^_^

But yeah, the DeHackEd nums requested by all parameterized codepointers are the same ones you define via EDF. Before EDF, the DeHackEd numbers were determined solely by the order of the static definitions inside the EXE. Now that they're in EDF, the entities store their DEH number, and DEH numbers are looked up in a hash table and thus have nothing to do with order.

The fact the original entities as used by DOOM are in the same order as their DeHackEd numbers is just a consequence of the way I converted info.c into the various EDF modules using a program. They could be rearranged by hand into any order and would still work ;)

Keeping this in mind, you see that you can assign your own stuff any arbitrary DEH number. You don't have to use them in order or anything else special. The only reason you have to use ones greater than 10000 is that I have to reserve some space for the source port to use for new stuff I add -- if EDF patches used DEH nums less than 10000 and then I decided to use one myself, the patches would become unusable due to DeHackEd number conflicts ;)

Basically, think of the thingtype mnemonic and DeHackEd num as being two separate ids for the thingtype, both on equal footing. Sort of like how people call you by your name, and computers call you by an id number (ex: Social Security number). Things in the game engine (including parameterized codepointers) that must call things by a number for one reason or another (typically compatibility concerns or data storage limitations) always use the DeHackEd number.

Things with a -1 DEH num simply are never added to the hash table used to lookup things/frames/sounds by number. This is why such objects simply cannot be used with those features.

One other note: The number space for DeHackEd numbers is separate for frames, things, and sounds. You probably knew that already, though, since there's a frame #1, sound #1, and thing #1, but it bears stating I suppose. You can have a frame 10000 and a thing 10000, for example.

[WNivek]

This would probably be more trouble than it's worth, but would it perhaps be a good idea to code some sort of automatic or dynamic DeHackEd Number allcation thing?

Like, if someone tries to randomjump to frame:foo, but frame foo doesn't have a DHE num, have Eternity assign it a number that's not already assigned elsewhere.

I know it would be a pain to program this functionality into Eternity, but it would make things simpler for people trying to make their own EDFs, and would also help allow people to develop freely-exchangible EDF patches which you could just Include in your own mod's edfs without fear of DEH number conflicts

[Quasar]

Well I had considered this earlier and thought that it was too difficult of a problem. However, it might be possible to reserve a certain range of DeHackEd numbers for automatic allocation -- say, a range above 32768. I'll look into it as a feature for EE 3.33.03 -- 3.33.02 will be shipping out in a few days; I'm just waiting on myself to quit being lazy ;)