[GZDooM 3.4.1] Buged flags

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: [GZDooM 3.4.1] Buged flags

Re: [GZDooM 3.4.1] Buged flags

by Graf Zahl » Thu Jul 12, 2018 2:44 pm

Here's the culprit:

Code: Select all

   TNT1 A 0 A_ChangeFlag("FRIENDLY",Random(0,1))
That's a crystal-clear case of "Don't do that!" if applied to a player. Same with the call in the BecomeEnemy state.

Re: [GZDooM 3.4.1] Buged flags

by Arch-vile90 » Thu Jul 12, 2018 2:30 pm

ok i find the real thing that generate the bad situation.
THIS ONE ( you can find it into the NeutronMine+Teleporter.dec from the Part 3 of the mod) :

Code: Select all

ACTOR NeutronExplosion
{Scale 0.4 Damage 0
+GHOST +FRIENDLY 
+MTHRUSPECIES +NOGRAVITY
+FORCERADIUSDMG
+NODAMAGETHRUST
+DONTTHRUST
+THRUSPECIES
+NOGRAVITY
DamageType "BlackHole"
States{
Spawn:
	TNT1 A 0
	TNT1 A 0 A_PlaySound("NBomb/Explosion",14)
NeutronLoop:
	TNT1 A 0 A_PlaySound("BHBall2/Explode",15)
	TNT1 A 0 A_JumpIfInventory("StrikerBallTimer",30,"Death")
	TNT1 AAAAAA 1 bright Light("NeutronExplosionLight") { //A_Explode(1,128,1);
A_SpawnItemEx("HellsingLightningFog",random(96,-96),random(96,-96),Random(96,-96),0,0,0,Random(-20,20),128); 
A_SpawnItemEx("NeutronSmoke",random(64,-64),random(64,-64),random(66,-66),0.00001*random(100000,-100000),0.00001*random(100000,-100000),0.00001*random(100000,-100000),random(0,359),128,0);
A_RadiusGive("NeutronPower",128,RGF_MONSTERS|RGF_CORPSES|RGF_NOMASTER,1);
A_RadiusGive("NeutronConvulsionEffect",180,RGF_GIVESELF|RGF_PLAYERS,1); }
	TNT1 A 0 A_GiveInventory("StrikerBallTimer",1)
Loop
Death:
	TNT1 A 0 A_ChangeFlag("NoGravity",0)
	TNT1 A 0 A_PlaySound("Volcabus/Cannon",7)
	TNT1 AAAAA 0 A_SpawnItemEx("ObeliskTrailSpark",random(19,-19),random(19,-19),random(19,-19),0,0,0,0,128,0)
	TNT1 A 0 A_SpawnItemEx("ObeliskExplode",0,0,48,0,0,0,0,128,0)
Stop
}}

Actor NeutronTimer : Inventory { Inventory.MaxAmount 1 }
Actor NeutronPower : CustomInventory
{ Inventory.MaxAmount 0
+Inventory.AutoActivate
States{
Spawn:
	TNT1 A 1
Fail
Use: // ------------------- THE MAGIC NIGHTMARE 
	TNT1 A 0 A_JumpIfHealthLower(1,"NeutronEnd")
	TNT1 A 0 A_JumpIfInventory("NeutronTimer",1,"BecomeEnemy")
	TNT1 A 0 A_ChangeFlag("FRIENDLY",Random(0,1))  
	TNT1 A 0 ACS_NamedExecute("NeutronGiver")
	TNT1 A 0 A_GiveInventory("NeutronTimer",1)
Stop
NeutronEnd:
	TNT1 A 0 A_Die
Stop
BecomeEnemy:
	TNT1 A 0 A_ChangeFlag("FRIENDLY",0)
	TNT1 A 0 A_TakeInventory("NeutronTimer",1)
Stop
}}

ACTOR NeutronConvulsionEffect : CustomInventory
{radius 160
Inventory.PickupMessage ""
Inventory.PickupSound "BHBall2/Explode"
-INVENTORY.ALWAYSPICKUP
+INVENTORY.AUTOACTIVATE
States{
Spawn:
    TNT1 A 2
stop
Pickup:
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
	TNT1 A 35
	TNT1 A 1 A_SetBlend("Black",0.9,150)
Stop
}}
This is the script "ACS_NamedExecute("NeutronGiver")", and it is really simple:

#library "NeutronExplosionEffect"
#include "zcommon.acs"

// ------------ Neutron Grenade
script "NeutronGiver" (void)
{
	delay(random(random(32,16),random(64,96)));
	GiveInventory("NeutronPower",1);
}
Tested just now, same situation. Not throwing the bomb no problem. Throwing him the nightmare begins.

The idea is like a missile from Russian Overkill, the Berta bomb which causes the monsters to beat themselves and then generate flames.
My is a bomb that effect plus a dangerous dark smoke area that damages and confuses the monsters, so as to be able to transform them, in rare cases, into friends.

If i remove this line "A_RadiusGive("NeutronPower",128,RGF_MONSTERS|RGF_CORPSES|RGF_NOMASTER,1); all will work fine but the idea of the bomb become useless.
And now the real problem: how to fix it?

Re: [GZDooM 3.4.1] Buged flags

by Graf Zahl » Thu Jul 12, 2018 2:12 pm

Good to hear. I think anyway that this can be filed away as a "scripting error".

Re: [GZDooM 3.4.1] Buged flags

by Arch-vile90 » Thu Jul 12, 2018 1:36 pm

Those actor were given via script for the weapon weel system ( it was a convoluted system, yes ) but that script has been removed days ago, that decorate was just the last piece of cancer ( i think ).
I've done some run on those maps where the bug mostly showed up and for now is all working fine. Maybe it generated some kind of strange conflict.

Re: [GZDooM 3.4.1] Buged flags

by Rachael » Thu Jul 12, 2018 4:13 am

Graf Zahl wrote:It was the only one I found which alters its owner's flags. If it isn't this, something similar must be buried elsewhere.
I'm almost positive that it's something else.

I have searched those same files for instances of those two items being given, and could not find any.

Re: [GZDooM 3.4.1] Buged flags

by Graf Zahl » Thu Jul 12, 2018 3:30 am

It was the only one I found which alters its owner's flags. If it isn't this, something similar must be buried elsewhere.

Re: [GZDooM 3.4.1] Buged flags

by Arch-vile90 » Thu Jul 12, 2018 3:28 am

Graf Zahl wrote:Most of the flag switching looks harmless - but these two are another matter:

Code: Select all

// FRIENDLY
actor _CF_FRIENDLY_0 : CustomInventory
{
	states
	{
	Pickup:
		TNT1 A 0 A_ChangeFlag("FRIENDLY", false)
		stop
	}
}

actor _CF_FRIENDLY_1 : CustomInventory
{
	states
	{
	Pickup:
		TNT1 A 0 A_ChangeFlag("FRIENDLY", true)
		stop
	}
}
If those are given to a player, bad things will happen.
HUGH!
I was convinced that I had removed that old decorate but it is still present.
This was an old decorate it belonged to an old weapon wheel system ( now replaced with PYWeaonWeel ).


So you think THIS is the real problem?
This bug showed up before I started creating this twisted decorate. :?:
For now i try to do a run to check if it still alive.

Re: [GZDooM 3.4.1] Buged flags

by Graf Zahl » Thu Jul 12, 2018 3:09 am

Most of the flag switching looks harmless - but these two are another matter:

Code: Select all

// FRIENDLY
actor _CF_FRIENDLY_0 : CustomInventory
{
	states
	{
	Pickup:
		TNT1 A 0 A_ChangeFlag("FRIENDLY", false)
		stop
	}
}

actor _CF_FRIENDLY_1 : CustomInventory
{
	states
	{
	Pickup:
		TNT1 A 0 A_ChangeFlag("FRIENDLY", true)
		stop
	}
}
If those are given to a player, bad things will happen.

Re: [GZDooM 3.4.1] Buged flags

by Rachael » Thu Jul 12, 2018 3:07 am

Graf does allow it. Please send him a copy.

Re: [GZDooM 3.4.1] Buged flags

by Arch-vile90 » Thu Jul 12, 2018 2:00 am

For the question about istances, most of them are projectiles and missiles that damage the player if the flag is not specified but 588 is a bit strange, yes.

For now i send, if you allow to do it, to Graf the mod link in private.
If the problem is to check into all decorate i have no problem to do that; i have a lot of patience.

Re: [GZDooM 3.4.1] Buged flags

by Graf Zahl » Thu Jul 12, 2018 12:27 am

He didn't send me the mod. But from what you describe, "Don't do that!" pretty much nails it. The FRIENDLY flag is one of the most behavior-critical flags in the entire game and messing with it is bound to cause problems.

And concerning a compatibility flag: Those are meant to address common mapping habits that no longer apply due to some change. This sounds more like broken code, but I'd need to have a look first.

Re: [GZDooM 3.4.1] Buged flags

by Rachael » Wed Jul 11, 2018 6:36 pm

So from what I can see, this mod makes extremely extensive use of the FRIENDLY flag, and I really can't understand why.

Code: Select all

C:\GZDoom\testing\dec>grep -ri "friendly" "*"|wc
    588    2683   31488

C:\GZDoom\testing\dec>
That's at least 588 instances, and that's just from the files I extracted, that I managed to find containing DECORATE information.

The only real solution I can think of for this issue is implementing a compatflag, but until we have file-loaded specific checks rather than map-specific checks we simply cannot implement a check for when this particular file is loaded.

That being said, what little I saw of the use of the +FRIENDLY flag, its use is pretty redundant and hacky, and in many cases simply unnecessary, but in other cases can be done with an inventory check rather than using an actor flag. I think I am going to wait to see what Graf wants to do before I do anything. (Maybe this would be a good candidate for an "opt-out only" compatflag? Where the old behavior once again becomes default, and players/modders must specify a flag in order to activate the new behavior)

I can leave you with the wisdom of "DON'T DO THAT!" - but of course, 588 instances is too late for that now, and it is unreasonable to expect you to manually check through all of them and fix them, so either this mod is stuck on an old version of GZDoom, or it will depend very heavily on a compatibility flag, and there will need to be a way for this mod to set for itself that flag to be in use for all maps.

I can tell you this: When actual friendly monsters came into play, this mod definitely would've been broken, anyway, even in older versions of GZDoom. When they saw a lack of +FRIENDLY on the player, they would have outright attacked, even then.

Re: [GZDooM 3.4.1] Buged flags

by Rachael » Wed Jul 11, 2018 3:10 pm

If you must do it privately, please CC me in the message, as I am the one who developed that feature.

Re: [GZDooM 3.4.1] Buged flags

by Graf Zahl » Wed Jul 11, 2018 2:54 pm

Yes, we defnitely need the mod, something in there clears the FRIENDLY flag, from the looks of it.

Re: [GZDooM 3.4.1] Buged flags

by Zhs2 » Wed Jul 11, 2018 2:20 pm

GZDoom 3.2.0 release wrote:Unfriendly players - when a PlayerPawn object has -FRIENDLY set, they become a playable monster and interact with the game world as one. Additionally, they become deathmatch opponents, capable of dealing and taking damage from other players.

Top