ZDoom

[quote="Matt"]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.[/quote]
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.

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.

Thanks for the example! Will take a look in the coming weeks...

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: 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]

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)));
}

[/code]

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?

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.

Just out of curiosity how does this intermingling break things?

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.

[quote="Graf Zahl"]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.[/quote]
What isn't safe about this? Linetrace is play scope.
I'm not sure what you mean wrt. collision detection, either - collision detection wasn't really mentioned anywhere in the OP.

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.

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.