[ZScript] Actor Collision Exclusion

[Major Cooke]

I don't expect this to be looked at until after the first ZScript merge, honestly.

It'd be nice if actors could store names of actors whom they could pass through automatically. This would allow one actor to pass through another, but the other would also need to specify it can pass through that one. I'd have exceptional use of this ability, such as an alien that gets too close starts blocking another actor's movement while its free to move, alllowing the alien to devour its prey without chance of escape.

Code: Select all

class Alien : Actor
{
	Defaults
	{
		// Can 'stick' humans for eating.
		ThruActor "Victim";
		ThruSpecies "Human";
		ThruSpecies "Rodentia";
	}
}

class Victim : Actor
{
	Defaults
	{
		// Cannot move through aliens.
		ThruSpecies "Rodentia";
	}
}

[Fishytza]

It would also be nice if the inverse was possible. IE an actor that by default passes through everything except what it specifies. Perhaps something like:

Code: Select all

CollideWithActor "Piff";
CollideWithSpecies "Meh";

More specifically a way to emulate/deprecate the SPECTRAL flag.

Code: Select all

Class BlueGhost : Actor
{
    Default
    {
        ...
        CollideWithSpecies "IceProjectiles";
        ...
    }
}
Class RedGhost : Actor
{
    Default
    {
        ...
        CollideWithSpecies "FireProjectiles";
        ...
    }
}

[Major Cooke]

That too.

[Graf Zahl]

PIT_CheckThing will wholeheartedly thank you all for getting even more bloated...

[wildweasel]

I'm unsure I picked the best place to split the topic, but the split discussion is now here.

[Major Cooke]

http://forum.zdoom.org/viewtopic.php?f= ... 45#p948944 <--Right here would be the best. Everything to your post.

[wildweasel]

Done.

[Major Cooke]

I've given this some more thought... Perhaps this might be best if it worked like the following for runtime:

Code: Select all

target.ThruActor.Add("<name>");
target.ThruActor.Remove("<name>");
tracer.ThruSpecies.Add("<name>");
target.ThruSpecies.Remove("<name>");

Along with a boolean:

Code: Select all

target.Thru<Actor/Species>List(<bool>);

Which can enable and disable the whole list.

[ZzZombo]

But still, you can't have actor/class<->actor/class collision handling this way. Like make the Lost soul go though other monster, but not ones that are enemies to it (infighting or friendship shenanigans), or the already brought up tracer<->self<->master going through each other.

One way collision also would be nice, like missiles (or in general +NOBLOCKMAP), so one actor couldn't walk into some others by itself, except via external force, but those said actors would have no problems going thru the former just fine.

[Major Cooke]

I think you misunderstood my example. That was me having a target adding an actor class to their list of actors to pass through.

i.e. I have a cyberdemon with a tracer to a zombieman. The cyberdemon calls

Code: Select all

tracer.ThruActorList.Add("LostSoul");

Now the zombieman can go through lost souls.

If that's indeed what you were talking about, then yes, it actually can be done this way. It's a matter of how in the engine since my previous attempts were... poorly done. Graf and Randi both seem okay with the idea.

Ok, seriously people. My post was not 100% serious but we are talking about adding more checks to one of the most frequently called and most performance critical functions in the entire engine - one that already causes performance issues on maps like NUTS. I am very hesistant to add more here that isn't absolutely necessary.

[ZzZombo]

And I just said it only ever considers actor<->class interaction. Not actor<->actor or class<->actor, or class<->class. Dunno how to put it even more clearly.

[Major Cooke]

...I only was ever talking actors from the beginning.

[Graf Zahl]

Ideally the best way to deal with this would be a virtual function. But here's the problem: This is right in the middle of one of the most performance critical functions in the entire game (PIT_CheckThing) and repeatedly calling virtual scripted overrides from there is bound to have an adverse impact on the game. I'll definitely have to run some tests how this would impact a larger map with lots of movement.

[Major Cooke]

I had a thought about it... Why not have a special construct where it passes through each time PIT_CheckThing is called normally? The lists might have to be hard coded into the classes, yes, but at least they can still switch them around. This way there's no extra calls, it just checks to see if their names match up and/or species or whatever else, like flags even.

A conceptual piece of code would look like this:

Code: Select all

Class test : Actor
{
    CollideList exclude1
    {
        //AddActor (Class<Actor>, bool IsActorBlocking, bool AmIBlocking)
        // Both can pass through each other since both bools are false.
        AddActor("Cyberdemon", false, false);
        AddActor("SpiderMastermind", false, true);
        
        //AddSpecies(name, bool IsBlocking, bool AmIBlocking)
        AddSpecies("CowABungle",false, false);
    };
    
    CollideList  include1
    {
        Add("Zombieman", false, true);
        Add("DoomImp", false, true);
    };
    
    Default
    {
        CollisionList "exclude1";    
    }
    
    States
    {
    Spawn:
        TNT1 A 35
        TNT1 A 35
        {
            CollisionList = "include1";
        }
        
    }
} 

Or...
OR... Better perhaps!...
Maybe even functional comparisons.

Code: Select all

AddFunction (checker.health < 20 || checker.CheckClass("Cyberdemon"));

[Graf Zahl]

That's not going to work. I just ran a few tests of testing empty lists vs. empty virtual functions and the lists came back a distant second in performance. Calling a virtual function is not free, of course but ultimately for the default case of calling AActor's empty default it's negligible. But testing collision lists can be quite cumbersome, and they are way harder to implement.

So my proposal is to forget all this complexity and just add a new virtual function

bool CanCollide(Actor other, bool passive)

that can be overridden in each actor. Even when scripted that performs nearly as well as a native list because checks can be done far more directly - and in terms of maintenance overhead it is nearly free, except hooking up two script calls. It's also far more flexible because you can decide your checks based on actor state, not just class type.

Remember: We do have scripts now, there's really no point anymore to invent complex data structures for stuff that a one- or two-line function can do that's specially tailored to the use cases you want to solve.