[6a34092]CheckWeaponChange STILL aborts

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [6a34092]CheckWeaponChange STILL aborts

Re: [6a34092]CheckWeaponChange STILL aborts

by Graf Zahl » Tue May 16, 2017 3:05 pm

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.

Re: [6a34092]CheckWeaponChange STILL aborts

by Major Cooke » Tue May 16, 2017 2:58 pm

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?

Re: [6a34092]CheckWeaponChange STILL aborts

by Graf Zahl » Tue May 16, 2017 10:25 am

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.

Re: [6a34092]CheckWeaponChange STILL aborts

by Major Cooke » Tue May 16, 2017 9:57 am

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...

Re: [6a34092]CheckWeaponChange STILL aborts

by Graf Zahl » Tue May 16, 2017 9:43 am

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.

Re: [6a34092]CheckWeaponChange STILL aborts

by Major Cooke » Tue May 16, 2017 8:01 am

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.

Re: [6a34092]CheckWeaponChange STILL aborts

by Graf Zahl » Sun May 14, 2017 9:28 am

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

Re: [6a34092]CheckWeaponChange STILL aborts

by Rachael » Sun May 14, 2017 8:23 am

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.

Re: [6a34092]CheckWeaponChange STILL aborts

by Major Cooke » Sun May 14, 2017 8:13 am

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.

Re: [6a34092]CheckWeaponChange STILL aborts

by Rachael » Sun May 14, 2017 8:07 am

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.

Re: [6a34092]CheckWeaponChange STILL aborts

by Major Cooke » Sun May 14, 2017 7:24 am

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.

Re: [6a34092]CheckWeaponChange STILL aborts

by Major Cooke » Sun May 14, 2017 6:28 am

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.

[6a34092]CheckWeaponChange STILL aborts

by Major Cooke » Sun May 14, 2017 6:13 am

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.

Top