[6a34092]CheckWeaponChange STILL aborts

[Major Cooke]

I discovered another way to make it bug out so this isn't fixed fully.

summon PainElementalRune and perform a secondary fire.

I use an ACS script to terminate the morph.

Code: Select all

TNT1 A -1 
{
	A_Explode(1000,768,XF_NOTMISSILE,0,512);
	A_SpawnItemEx("PainKamikazeExploFX",0,0,25,0,0,pitch,0,SXF_NOCHECKPOSITION);
	ACS_NamedExecuteWithResult('ForceUnmorph',0,0,0,0);
}

Code: Select all

Script "ForceUnmorph" (void)
{
	UnMorphActor(0,1);
}

Tried changing it to this, same effect:

Code: Select all

TNT1 A -1 
{
	A_Explode(1000,768,XF_NOTMISSILE,0,512);
	A_SpawnItemEx("PainKamikazeExploFX",0,0,25,0,0,pitch,0,SXF_NOCHECKPOSITION);
	let inv = PowerMorph(FindInventory("PowerMorph",true));
	if (inv)
	{
		A_SetInventory("DemonTimerToken",0);
		A_SetInventory("DemonTimerTotal",0);
		inv.EffectTics = 0;
		inv.EndEffect();
		return;
	}
}

This also was a non-issue until after the scriptification occurred.

[Major Cooke]

Also this might or might not happen when killing a bossbrain while morphed, since I designed it to destroy demon runes (including active ones) once killed.

[Major Cooke]

More testing reveals it's the EndEffect() part that triggers the abort. I have a hunch the UndoMorph function also does the same when used on the weapon.

[Rachael]

Can you please edit your posts instead of bumping them with one-liners?

It's not a big deal if you do it occasionally (we all do it every so often and I'd like to think we have reasonable reasons for doing so) but doing it THIS much isn't going to get the problem fixed any faster.

[Major Cooke]

I figured it was pretty relevant to keep things up to date as edits don't inform others. Just wanted to confirm some things to safe others time. (Okay my second post is clearly guilty, I'll admit but the third one reaffirms the situation.)

Sorry bout that.

[Rachael]

With all told those bumps were a total of 71 minutes apart. I understand it's a pretty big issue (VM crashes are almost as bad as GZDoom crashing, itself), but in that time Graf hasn't even had an opportunity to respond much less look into the issue. Those both could have been done just fine as edits.

Double-posting is fine when your issue starts to get a bit buried and you feel it has been ignored with already ample opportunity for it to have been looked into. We're all human and occasionally we need reminders to look into stuff like this. This isn't the first time you've done this, though, and unfortunately people aren't interested in seeing red highlights on bug reports every time you have something new to add without at least some sort of developer interaction on it, first.

[Graf Zahl]

This is utterly hopeless. I think I am going to refactor how morphing happens. It's insanity squared right now.

[Major Cooke]

So what's the plan then, on how morphing will work? I'm curious if there's anything I should watch out for or if I should change anything.

Will there be a new system added while the old system is left there for compatibility if it proves to be tangled up like SBARINFO was?

I for one am super curious if this means switchable weapons, or some form of input introduction for slot 0-9 keys without having to rely on network events.

[Graf Zahl]

I have no idea yet what to do here. The entire implementation is just horrible, and everybody adding to that just extended the horror instead of removing it. Getting rid of that without breaking it is not easy.

[Major Cooke]

Sounds like it'd have to go with a new system similar to what you did with SBARINFO to ZScript, thus deprecating the current one. I'd be down with that.

Depending on what you do, perhaps psprites (overlays) on non-monsters might even be beneficial here...

[Graf Zahl]

It's not "the system" that is broken. What is broken is that PowerMorph alters the player picking up the item. Which is so bad because it tends to happen in the middle of P_CheckPosition so it's almost a given that some function loses the connection to the actor it is checking.

On the other hand, now imagine some code that expects the player to be morphed at a given piece of code, but it no longer is because the morph gets queued for later. It's a nearly unsolvable dilemma.

[Major Cooke]

Putting it that way makes SBARINFO look like a saint when compared, even though that's far from the truth.

And I take it your version system can't be used to route different things like the morph behaviors?

[Graf Zahl]

No. The versioning system is part of the compiler and has no effect on the play code. You can also mix differently versioned scripts in the same mod if you compile them as separate translation units.