[Ninety-Six]

Time to decrease my popularity again.



No crash log, as usual for this type. Scenario was normal play in DC E3L5. House of Representatives floor if that matters any.

eduke log attached.

 eduke32.log (3.97K)
Number of downloads: 178

[LeoD]

Ninety-Six, on 27 April 2020 - 09:11 PM, said:

again.png
No crash log, as usual for this type. Scenario was normal play in DC E3L5. House of Representatives floor if that matters any.

Actually, that's no hard crash but a graceful exit, refusing to continue after recognising an impossible state:

Spoiler

int32_t insertsprite(int16_t sectnum, int16_t statnum)
{
    // TODO: guard against bad sectnum?
    int32_t const newspritenum = insertspritestat(statnum);

    if (newspritenum >= 0)
    {
        Bassert((unsigned)sectnum < MAXSECTORS);

        do_insertsprite_at_headofsect(newspritenum, sectnum);
        Numsprites++;
    }

    return newspritenum;
}

I guess that one of your additional CON files tried to spawn a sprite in a non-existing sector.

[Danukem]

It's not uncommon for the player or actors to go into nullspace. If you use a noclip cheat then the player will do this frequently. Mods typically will not check to see what sector the current actor is in before using the spawn CON command or variants. In fact there are lots "spawn" commands in the original CONs and no way to even check sector in that old CON script. The spawned sprite will inherit the sector of the spawning sprite. So if the spawning sprite in nullspace, it would seem that the spawned sprite would have a "bad sectnum".

What I'm saying is that this phenomenon can happen quite innocently and it didn't used to cause a crash or "graceful exit". It's reasonable to expect the game to handle this with only a warning in the log. What secnum it should assign to the spawned sprite is a good question, though.

[Ninety-Six]

The only con files active are Darkus' fixes, which shouldn't be spawning anything anywhere (beyond respawn fixes, but as Dan pointed out, this is not something that has happened before), and gore, which only leaves gibs on the floor where they land (likewise. I've been using both for years and this is the first time this has ever happened). I was quite in the middle of the Representative assembly. There was no reason for the gibs to spawn outside the room.

[Danukem]

Ninety-Six, on 28 April 2020 - 04:37 PM, said:

The only con files active are Darkus' fixes, which shouldn't be spawning anything anywhere (beyond respawn fixes, but as Dan pointed out, this is not something that has happened before), and gore, which only leaves gibs on the floor where they land (likewise. I've been using both for years and this is the first time this has ever happened). I was quite in the middle of the Representative assembly. There was no reason for the gibs to spawn outside the room.

Like I was saying, the crash appears to happen from spawns that are ordinary and normally innocent. I did look at the Darkus fix code just now, and I didn't see any spawns that looked questionable. They were just ordinary things like monsters spawning bloodpools during gameplay which the vanilla code has always done and have never required any special checks.

I did see one thing that looked dangerous and that was setting .statnum directly instead of using changespritestat. I think if you set it directly then the sprite doesn't get entered into the status list for that statnum and if that's the case it could definitely lead to problems.

[Ninety-Six]

Trooper Dan, on 28 April 2020 - 06:12 PM, said:

I think if you set it directly then the sprite doesn't get entered into the status list for that statnum and if that's the case it could definitely lead to problems.

Would that cause any issue with this code? https://forums.duke4...929#entry309929

[Danukem]

Hmm, no. According to the wiki it's no longer necessary to use changespritestat. So we are back to the CON code being innocent of any crime.

[Ninety-Six]

Trooper Dan, on 28 April 2020 - 07:43 PM, said:

Hmm, no. According to the wiki it's no longer necessary to use changespritestat. So we are back to the CON code being innocent of any crime.

And those were the only non-vanilla things I was running, unless the widescreen weapon sprites were conspiring on the CON's behalf.

I kinda doubt it though.

[LeoD]

Ninety-Six, on 28 April 2020 - 04:37 PM, said:

The only con files active are Darkus' fixes, which shouldn't be spawning anything anywhere (beyond respawn fixes, but as Dan pointed out, this is not something that has happened before), and gore, which only leaves gibs on the floor where they land (likewise.

Your log kind of tells otherwise...or are those the gore stuff?

Application parameters: -addon 1 -jDC -mx mut_pigshoot.con -mx mut_drone_expl.con -mx mut_boss1_shprob.con 

Trooper Dan, on 28 April 2020 - 04:16 PM, said:

What I'm saying is that this phenomenon can happen quite innocently and it didn't used to cause a crash or "graceful exit". It's reasonable to expect the game to handle this with only a warning in the log. What secnum it should assign to the spawned sprite is a good question, though.

I'd side with the developers here for once. That's the 'price' you pay when using the 'picky' debug executable instead of the release version. It's my default, too, as long as performance is OK.
Of course the assertion messages imply that there's room for code improvements...

[TerminX]

LeoD, on 29 April 2020 - 03:29 AM, said:

Of course the assertion messages imply that there's room for code improvements...

It's actually not possible for spawning to ever fail in the Build Engine. All games utilizing the engine are programmed around this concept. So, yeah, there is room for code improvement here, but it's room for improvement to the CON code that is telling the engine to self-destruct.

In this case, the operation is probably failing because current versions of EDuke32 keep the sprite's sectnum updated during movement. This may be problematic for things that try to modify the built-in gib sprites to spawn extra stuff, as they normally literally just fall through the world with no collision or anything and delete themselves when they go out of bounds. If the CON code in question was doing something naive and incorrect like just spawning shit into the ether in EVENT_KILLIT, then yeah, it's going to blow up.

I don't have any further insight into it at the moment, but just as with every other programming/scripting language, sometimes upgrades to the compiler or backend will make buggy code fail to function, despite the fact that the stars previously aligned in a way that allowed a particular operation to "fail" "successfully."

I don't know if there's a good way to fix this without breaking something else. The best option would probably be fixing the CON files in question to not try spawning things into null space.

[Ninety-Six]

LeoD, on 29 April 2020 - 03:29 AM, said:

Your log kind of tells otherwise...or are those the gore stuff?

Application parameters: -addon 1 -jDC -mx mut_pigshoot.con -mx mut_drone_expl.con -mx mut_boss1_shprob.con 

Oh, those. Those are just the mutators Darkus recently released that modify his fixes to replicate certain elements of vanilla behavior (in order: pig hitstun, sentry drone delayed explosion, and battlelords being more resistant to the shrinker).

LeoD, on 29 April 2020 - 03:29 AM, said:

That's the 'price' you pay when using the 'picky' debug executable instead of the release version. It's my default, too, as long as performance is OK.

For me, even though I was playing casually it was hoping to catch more bugs.

That, and hoping I'm wrong about the weapon switch bug and that it will trigger so helpful data can finally be gathered (plus with that bug in place it kinda makes casual playing impossible since it's pretty much a game-ender).

TerminX, on 29 April 2020 - 10:07 AM, said:

-snip-

I admit, I'm still confused about how they could spawn in null space, at least in this instance. I was nowhere near any walls...

[Danukem]

Ninety-Six, on 29 April 2020 - 01:46 PM, said:

I admit, I'm still confused about how they could spawn in null space, at least in this instance. I was nowhere near any walls...

The takeaway is that there is a burden of proof that has to be met before it will be treated as a bug that needs to be fixed. If you could set up a situation where the crash happened using vanilla CONs and was reproduceable, that would definitely meet the standard. Short of that, with modified CONs it would have to be shown that it's happening without any improper code. Essentially, TX is saying that the burden of proof is on you because there is reasonable doubt given all the modified CONs you are using.