S_NULL no longer supported?

[printz]

I excitedly downloaded r1289 to see what has been newly done to stuff like the portal code, but I can no longer run my mod because at startup it says:

E_ThingFrame: thing 'BruiserDemon': invalid raisestate 's_null'

. Understandably, I created that monster who has a nullified raise state (no raise). Is it a bug that dummy sprite name "S_NULL" is not accepted?

[Gez]

printz said:

I excitedly downloaded r1289 to see what has been newly done to stuff like the portal code

Sorry to disappoint you, but the portal code changes are at the moment still in the portal-clip branch. Which means they are not in the trunk. Which means they are not in the SVN builds hosted by DRD Team.

[Quasar]

printz said:

I excitedly downloaded r1289 to see what has been newly done to stuff like the portal code, but I can no longer run my mod because at startup it says:

E_ThingFrame: thing 'BruiserDemon': invalid raisestate 's_null'

. Understandably, I created that monster who has a nullified raise state (no raise). Is it a bug that dummy sprite name "S_NULL" is not accepted?

I need to see your EDF to determine what is actually going on here.

[Mordeth]

Instead of defining the raise-state, just leave the raise-state out of your new definition of BruiserDemon..? Not providing a raise-state will result in your monster not being able to be raised. In your case it can still be raised, but attempting to do so will result in it trying to revive a monster while the sprite is being removed.

[Quasar]

Mordeth said:

Instead of defining the raise-state, just leave the raise-state out of your new definition of BruiserDemon..? Not providing a raise-state will result in your monster not being able to be raised. In your case it can still be raised, but attempting to do so will result in it trying to revive a monster while the sprite is being removed.

Regardless, S_NULL should not cause an error. It's the first state defined and should be known by name. Please note that S_NULL is not a *sprite* name however, it's a frame mnemonic.

[printz]

In my case, the BruiserDemon inherits properties from another custom monster within the wad, the WarlordOfHell, who can be resurrected. As I remember (another computer), this S_NULL is the first occurence in the custom EDF.

[Quasar]

printz said:

In my case, the BruiserDemon inherits properties from another custom monster within the wad, the WarlordOfHell, who can be resurrected. As I remember (another computer), this S_NULL is the first occurence in the custom EDF.

Please pastebin the entire EDF with an expiration of 1 month or longer.

Also, before we go any further please be sure you are doing the obvious:

stdinclude("root.edf")

This is *required* now, because "Default Fallback" processing had to be removed to enable the new single-parsing-pass EDF architecture created in edf-branch to support DECORATE states, unless you intend to redefine everything in root.edf yourself, which for forward compatibility reasons, is *not* recommended.

[printz]

Relax, I can just send it to you thru PM when I'm back. Understandably I'm NOT going to post the whole EDF here.

[Quasar]

printz said:

Relax, I can just send it to you thru PM when I'm back. Understandably I'm NOT going to post the whole EDF here.

That's why I asked you to use pastebin.com :P

[printz]

I'm sending it right now.

Actually, I've changed my mind, because now it works, but it breaks an EDF rule: it's case sensitive. I changed this line from

  raisestate             s_null

to

  raisestate             S_NULL

and it stopped giving the error.

[Quasar]

printz said:

I'm sending it right now.

Actually, I've changed my mind, because now it works, but it breaks an EDF rule: it's case sensitive. I changed this line from

  raisestate             s_null

to

  raisestate             S_NULL

and it stopped giving the error.

Well, you're right, EDF is *not* supposed to be case-sensitive. So this shouldn't be happening >_> Maybe I made a slipup somewhere; I will go look for it right now.

EDIT: Fixed in r1292. I used the wrong ehash_t specialization, which resulted in use of strcmp/D_HashTableKeyCase rather than the appropriate strcasecmp/D_HashTableKey routines. Never caught it during edf-branch testing because all my stock EDFs happen to refer to states using same-case names.