Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
printz

S_NULL no longer supported?

Recommended Posts

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?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×