Can we have a +NEVEREVERMOVE Flag?

[eharper256]

This is different from +DONTTHRUST or -PUSHABLE.

If an object is affected by A_ChangeVelocity from another object, both of these flags have no effect in preventing the forced movement. I have some projectiles that use that to throw enemies in specific directions (via +HITTRACER, and then using the Tracer as the target for A_Changevelocity, since this method is much more precise than utilising an A_Blast or similar).

Obviously, that's fine, but when the player accidently hits a tree or a prop etc., the tree goes flying and then re-roots itself in a new location (lol), sometimes even blocking progress as well as looking goofy.

Setting Mass to 0x7FFFFFFF, Gravity to 500, and Friction to 0.1 does help somewhat, though the movement does still take place as a short hop.

So, hence, I'd like to see a Flag that completely and utterly prevents that Class from moving from the spawn spot by even 1 pixel, as +NEVEREVERMOVE, or +TOTALLYSTATIC or whatever you want to call it. Even better if it can be set as default for all the standard iwad props, or if a keyword like "StaticDecor" could exist and added.

Thanks!!

[ZzZombo]

Filter out unwanted actors so they won't be pushed instead.

[eharper256]

Filter out unwanted actors so they won't be pushed instead.

That's a boatload of actors; at least 40+ from my own mod, plus all Doom, Heretic, and Hexen decorations, about 120 more?

[ZzZombo]

What do you mean? Surely you only want to push monsters and maybe players? Then filter out all non-monsters non-players.

[Rachael]

If using zscript is acceptable, a simple solution can be achieved by inserting the following tiny function into the actor's definition (outside of states or default block):

Code: Select all

class nevermoves : actor
{
    override void Tick()
    {
        vector3 oldpos = Pos;
        Super.Tick();
        SetOrigin(oldpos, false);
        vel = (0,0,0);
    }
}

Super.Tick() would handle the position changes and such, but SetOrigin will snap it back into place afterward. And the entire Tick() function is overrided to accomplish this.

If you want a truly static position, you can move the oldpos variable into the actor's scope, and set it in the PostBeginPlay() function instead, and then every tick it will snap back to its original position and will never be movable unless its oldpos is updated.

Code: Select all

class nevermoves : actor
{
    vector3 oldpos;
    override void PostBeginPlay()
    {
        Super.PostBeginPlay();
        oldpos = Pos;
    }
    override void Tick()
    {
        Super.Tick();
        SetOrigin(oldpos, false);
        vel = (0,0,0);
    }
}

[Professor Hastig]

I suggest to post your code. This entire suggestion sounds like "I want A, but if you implement B I will get A so please implement B!"

The only viable approach here should be to filter out any such actor when applying the velocity. If that is in your own code it should be no problem setting up the rules under which an actor is velocity applied to.

[eharper256]

I feel like everyone is misunderstanding here. I do not need this feature by any means, I just thought it would be a useful thing. Just as a run-down again:

1. Decorations and Trees and Gore exist. My mod can be used on Doom, Doom2, Heretic, and Hexen iwads, so my count is roughly 170-180 items. They are placed by mappers.
2. The player can accidently hit them with a projectile that has +HITTRACER, and which moves this hit object away with A_Changevelocity. Example:

Code: Select all

ACTOR ForceBlastL : FastProjectile	//Main forceblast
{					
	Damage ((9 * random(3, 4))+random(2,6))
	Radius 10	
	Height 10
	Speed 110
	DamageType "Force"
	+HITTRACER
	+ACTIVATEIMPACT
	+FORCEXYBILLBOARD
	+ROLLSPRITE
	+ROLLCENTER
	+INTERPOLATEANGLES
	+BLOODLESSIMPACT
	+NOTIMEFREEZE
	Projectile
	MissileType "ForceBlastRing"
	MissileHeight 8
	Alpha 0.16
	XScale 0.9
	YScale 0.95
	RenderStyle Add
	ProjectileKickBack 50
	States
	{
		Spawn:
			TNT1 A 1
			TNT1 A 2 A_Jump(256,"Spawn2","Spawn3")
			Goto Spawn2
		Spawn2:
			FORD C 1 Bright A_SetRoll(roll-44)
			Loop
		Spawn3:
			FORD C 1 Bright A_SetRoll(roll+44)
			Loop
		XDeath:
			FORD D 1 Bright 
			{
			A_RadiusThrust(275, 25, RTF_THRUSTZ, 15);
			A_ChangeVelocity (-5,-2,2,CVF_RELATIVE,AAPTR_TRACER);
			A_Fadeout(0.03);
			A_SetRoll(roll+44);
			}
			FORD D 1 Bright {A_Fadeout(0.03); A_SetRoll(roll+44);} 	
			FORD ABE 2 Bright {A_Fadeout(0.03); A_SetRoll(roll+44);}
			Stop
		Death:
			FORD D 1 Bright 
			{
			A_RadiusThrust(75, 25, RTF_THRUSTZ, 15);
			A_Fadeout(0.03);
			A_SetRoll(roll+44);
			}
			FORD D 1 Bright {A_Fadeout(0.03); A_SetRoll(roll+44);} 	
			FORD ABE 2 Bright {A_Fadeout(0.03); A_SetRoll(roll+44);}
			Stop
	}
}

3. If 2 is applied to 1, we get things like the light on a stick from Doom flying off a pedestal and blocking a small corridor, or the trees from Hexen that appears to uproot itself. This is pretty minor, but it is relatively bizarre looking when it happens.
4. Even if I inherit all 170+ decor items and add Mass and Gravity to them (or indeed, make a base "HeavyDecoration" Class and inherit all decorations from this), they do still move slightly if hit by these projectiles. It's also a boat load of bloat code to fix a quirk in the engine. I'll do it if that's what I need to do, but...

Basically, it doesn't make too much sense to me that static map decorations can move at all; they're placed by the mapper, and are never meant to move, but various code makes this possible. Ideally, it would be nice for there to be a +NEVEREVERMOVE flag, and a base decoration class that has it, and make all the decorations, tree, and gore inherit it. Just for simplicity.

If that's not something we want to add to the code, fine, Graf can say that and move on. That's honestly what I was expecting. But I figured I could propose it anyways as it makes sense to me.

[ZzZombo]

No, it's you who is misunderstanding. You apply the thrust indiscriminately right now. I suggested that you do not do that and filter out unwanted things, yet you dismissed the suggestion w/o even really considering it, because even after I told you there is no need to check each individual actor in existence, you haven't heeded it.

[eharper256]

No, it's you who is misunderstanding. You apply the thrust indiscriminately right now. I suggested that you do not do that and filter out unwanted things, yet you dismissed the suggestion w/o even really considering it, because even after I told you there is no need to check each individual actor in existence, you haven't heeded it.

No need to be quite so snippy.

You tell me 'filter it!' without any context here and then tell me off. I have no grounding in coding, so I'm mostly just confused. In my head, "filtering" is just lump filtering which is not relevant. I'm honestly not aware of how I could apply a filter to A_Changevelocity, I was under the assumption it would have to use a pointer, therefore I thought you must be referring to adding something like +MTHRUSPECIES and +THRUSPECIES to everything I don't want to affect. Or doing a inheritance on all the decorations as mentioned above. Or adding Rachel's idea for ZScript on each item. Which means I have to include all the basic decorations in my mod to alter them. Is there a way to prevent it selecting decorations as tracers?

In any case, like I say, I'm not worried, I literally just thought "here's an idea". I'm not asking for modding help, or saying "this must be here!". If it's infeasible or thought to be a waste of time, that's fine, someone can close the topic.

[Rachael]

Semantics aside, on paper the flag seems to be a good idea, and that's the biggest reason why I haven't closed the topic outright. I didn't know that there was no pressing need to fill with this, most topics are a direct "I need this without hacky workarounds" request.

The problem is when you get into the weeds of this, you're modifying actor behaviour in ways that make actor movement a little ambiguous or possibly even unpredictable with this flag active.

So, if I were to implement this, I'd at most look at the "pos+=vel" statement and add an "if (flag)" to that, but beyond that I don't think I'd touch any of the other movement code, certainly not anything in the AI routines which inevitably will force movement under the right conditions anyhow. And probably call said flag +DONOTAPPLYVELOCITY.

[Graf Zahl]

I'm not too thrilled about the flag because it simply addresses the wrong thing. Actor velocity should not be conditional on other state.
@OP: Your blanket refusal to implement this correctly is not a valid reason to add yet another flag that may cause problems later.

[eharper256]

(shrug) Never mind then, you can go ahead and close the topic.