LineTrace flag: TRF_ACTIVATELINES
Moderator: GZDoom Developers
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
LineTrace flag: TRF_ACTIVATELINES
An option to have a LineTrace call activate the lines that the trace crosses.
I've got a use case where I'm calling LineTrace to get all sorts of information on the attack distance, direction, victim, etc. but I'm calling LineAttack again to deal with certain bullet-pass-through lines.
I've got a use case where I'm calling LineTrace to get all sorts of information on the attack distance, direction, victim, etc. but I'm calling LineAttack again to deal with certain bullet-pass-through lines.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: LineTrace flag: TRF_ACTIVATELINES
No. This simply isn't safe.
In the original code the collision detection for actors works exactly like you suggest and that's the single biggest problem in the entire engine.
In the original code the collision detection for actors works exactly like you suggest and that's the single biggest problem in the entire engine.
- phantombeta
- Posts: 2090
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: LineTrace flag: TRF_ACTIVATELINES
What isn't safe about this? Linetrace is play scope.Graf Zahl wrote:No. This simply isn't safe.
In the original code the collision detection for actors works exactly like you suggest and that's the single biggest problem in the entire engine.
I'm not sure what you mean wrt. collision detection, either - collision detection wasn't really mentioned anywhere in the OP.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: LineTrace flag: TRF_ACTIVATELINES
I mean safe from a gameplay mechanics point of view. Checking functions and evaluation functions should be separate and not be mixed together.
PIT_CheckThing and PIT_CheckLine made this mistake and it's something that's haunting us for all eternity. The code is fundamentally broken but cannot be fixed.
PIT_CheckThing and PIT_CheckLine made this mistake and it's something that's haunting us for all eternity. The code is fundamentally broken but cannot be fixed.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: LineTrace flag: TRF_ACTIVATELINES
Just out of curiosity how does this intermingling break things?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: LineTrace flag: TRF_ACTIVATELINES
In many nasty ways - the big problem is that any action can cause an actor to change state and thus to call an action function which in turn can trigger other actions that end up calling P_CheckPosition again, resulting in nasty recursions with unpredictable side effects.
One particular thing is that there are situations where triggering a teleporter simply does not work because after the teleport is complete, the recursion unwinds and only then finishes the move of the teleported actor, essentially resetting it to its old position.
Rest assured: You do not want side effects in checking functions - the actions should be taken after the result from the check has been evaluated, not while it collects its data.
One particular thing is that there are situations where triggering a teleporter simply does not work because after the teleport is complete, the recursion unwinds and only then finishes the move of the teleported actor, essentially resetting it to its old position.
Rest assured: You do not want side effects in checking functions - the actions should be taken after the result from the check has been evaluated, not while it collects its data.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: LineTrace flag: TRF_ACTIVATELINES
Got it, thanks.
Speaking of results after collecting data... is there any way to get from a LineTrace the linedefs that the trace has passed through?
Speaking of results after collecting data... is there any way to get from a LineTrace the linedefs that the trace has passed through?
Re: LineTrace flag: TRF_ACTIVATELINES
Matt: This is where you'll want to use the Linetracer class with it's more powerful Trace function rather than LineTrace. It can trace through the entire level and return everything if you set it up right. Here is an example of uses, a "railgun" function:
Code: Select all
Class SabotTracer : LineTracer
{
Actor owner;
array<actor> skips;
double maxdist;
override ETraceStatus TraceCallback()
{
if ( Results.HitType == TRACE_HitActor )
{
if ( (Results.HitActor == owner || skips.find(Results.Hitactor)!=skips.size())) return TRACE_Skip;
if ( Results.HitActor.bSHOOTABLE) return TRACE_Stop;
}
else if ( (Results.HitType == TRACE_HitWall) && (Results.Tier == TIER_Middle) )
{
if ( !Results.HitLine.sidedef[1] || (Results.HitLine.Flags&(Line.ML_BlockHitscan|Line.ML_BlockEverything)) )
return TRACE_Stop;
return TRACE_Skip;
}
return TRACE_Stop;
}
}
//[inside custom weapon attack function]
let t = sabotTracer(new("sabotTracer"));
t.owner = self;
t.maxdist = 9000.0;
vector3 dir = DSH_kMath.Vec3FromAngle(10,act.aimvector.x,act.aimvector.y).unit();
while(t.trace((self.pos.xy,player.viewz),cursector,dir,t.maxdist,0))
{
if( t.Results.HitType == TRACE_HitActor )
{
t.skips.push(t.Results.Hitactor);
t.Results.HitActor.DamageMobj(act,act,120,'bullet',0,0);
}
else
{
break;
}
}
double sparsity = 5;
for ( int i=0; i<t.Results.Distance; i+=sparsity )
{
Spawn("SabotSmoke",Vec3Offset(dir.x*i,dir.y*i,(player.viewz-self.pos.z-5)+(dir.z*i)));
}
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: LineTrace flag: TRF_ACTIVATELINES
Thanks for the example! Will take a look in the coming weeks...
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: LineTrace flag: TRF_ACTIVATELINES
TIL LineTracers can't activate lines. The flag for it is commented out and the TraceCallback function is data scope.
We still don't have a solution for this that doesn't involve calling a separate attack.
We still don't have a solution for this that doesn't involve calling a separate attack.
- phantombeta
- Posts: 2090
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: LineTrace flag: TRF_ACTIVATELINES
You put the lines in a dynamic array, then call the Activate function on them from outside TraceCallback. TraceCallback should only handle getting the info, not doing anything with said info.Matt wrote:TIL LineTracers can't activate lines. The flag for it is commented out and the TraceCallback function is data scope.
We still don't have a solution for this that doesn't involve calling a separate attack.