ZDoom

by **Graf Zahl** » Mon Dec 05, 2016 3:56 am

Absolutely. Die doesn't even clear the flag. Normally A_NoBlocking does that so skipping that call would keep the corpse solid - and allow overriding its CanCollideWith function to do what is desired.

by **Rachael** » Sun Dec 04, 2016 8:16 pm

Maybe I am missing something here, but can't you simply set +SOLID on your corpses if you want them executing your block function?

I found this handy little line in p_interaction.cpp in AActor::Die (line 637):

Code: Select all

		flags &= ~MF_SOLID;

Anything in the Death state is obviously after said function - so - ...?

by **Graf Zahl** » Sun Dec 04, 2016 7:10 pm

The thing is, the feature is not designed to make something non-solid blocking. It's designed to avoid a collision that's about to happen. The other way around is, as I said, far too costly.

by **Major Cooke** » Sun Dec 04, 2016 6:23 pm

We'll just have to use work-arounds in this case. If we want blocking corpses, we simply will have to spawn an actor in the exact same location as the corpses which block this particular actor from being able to go around them. It'll remain unsolid to everything else using this feature.

Thankfully it's not difficult to make.

by **Graf Zahl** » Sun Dec 04, 2016 6:20 pm

In this case I have to weigh between performance and flexibility, and here performance wins - every call that can be avoided is a plus. This is not a place where you can play loose with features. Like I said, PIT_CheckThing is one of the most performance critical and most called functions in the entire game, slowing this one down for some minor convenience will have widespread impact.

by **ZzZombo** » Sun Dec 04, 2016 6:15 pm

But the point was to enable modders to optionally override this, so they could in fact, enable corpses and whatnot also call back this function.

by **Graf Zahl** » Sun Dec 04, 2016 9:05 am

The logic already excludes everything that can be trivially classified as a non-collision. It only calls these functions to check if a registered collision is supposed to happen, but never to check if a non-collision should be ignored.

If you do not want these checks, do not override the virtual function, the default is a quick jump to an empty function that does almost nothing. This doesn't cost any significant performance compared to the rest of the function. But if only one actor overrides it, the checks need to be done to ensure proper behavior.

by **ZzZombo** » Sun Dec 04, 2016 8:55 am

I suppose a better way would be to mark a certain kind of actors as excluded from this kind of processing with a flag similar to +NOINTERACTION, maybe even reuse the existing THRUACTORS for this since it makes no sense to have with flag applied and custom actor collision logic at the same time. If it is set, the game will always treat them as non-solid for other actors, w/o this mechanism being applied; this has lots of benefits and marginally is the same like the current way, so no much extra work is needed.

by **Graf Zahl** » Sun Dec 04, 2016 7:24 am

The main problem here is performance. That stuff you suppose is really costly here. Imagine an actor with a relatively complex collision exclusion logic wading through a field of corpses. That can easily end up in hundreds of script calls if all corpses need to be checked. I tried to keep this simple: The purpose of this is merely to query if a collision or interaction should be allowed, because that's straightforward and quick to check. This is absolutely not the place to toy around with power options that require more complex checks because they always need to be done, even if none of the actors really needs them.

by **Major Cooke** » Sun Dec 04, 2016 6:58 am

Aaah, this makes it all clear now. Thanks!

However, I still think this could include two power options, one to not abort whenever one of them returns false and one to allow manual detection of everything like corpses. It may not make much sense, yet if I could wip up a recording of it to showcase some interesting things, I'd do it in a heartbeat.

Otherwise I have to make corpses spawn a blocking actor which allows passing through of everything else BUT that one actor (faking non-solid). And that's just more processing power being sapped.

Trust me when I say this, people WILL wind up using this kind of hacky stuff to achieve those things.

by **Graf Zahl** » Sun Dec 04, 2016 6:33 am

'self' is the checking actor, and 'other' the one it collides with. The function gets called twice in the process, from both actors taking part in the collision. First with the one whose move is being checked as 'self' and 'passive set to false, then again with the actor it collided with as 'self' and 'passive' set to true, so that both get a chance at deciding if the collision is supposed to happen.

by **Major Cooke** » Sun Dec 04, 2016 6:25 am

Graf Zahl wrote:I wouldn't use CheckClass.

Either use 'GetClass() ==' if you want to check a single class or 'mobj is "classname"' if you want to check for a group of actors, you can of course also do 'GetSpecies() == 'speciesname', or check friendliness or check if one actor has a specific damage type or whatever else you like to have tested. Calling the super method is not needed, AActor' just returns true and does nothing.

...Oooooh, wait a second! The actor parameter is automatically filled in if the passive boolean is set, to the actor its checking?

If that's the case, NOW it all makes sense.

Graf Zahl wrote:I added the virtual call at a place where the obvious non-collisions had already been processed and only do it for cases that might result in an actual collision, it will not get called if something intersects with a non-solid object that has no special properties.

The point is simply to allow the scripted functions to be more complex, the more often it gets called the more constrained you are.

I wonder though, could something to toggle off obvious collision exclusions be included? For the power user.

by **Graf Zahl** » Sun Dec 04, 2016 5:33 am

Major Cooke wrote:...Okay, better question. Graf, how did you test this to ensure the multi-actor thing works?

All I did was verify that the function gets called twice with the proper parameter setup. What you do inside the function is not limited in anyway. Look out for the correct parameter signature, though, it's "override bool CanCollideWith(Actor other, bool passive)".

by **Graf Zahl** » Sun Dec 04, 2016 5:32 am

Major Cooke wrote:

Code: Select all

override bool CanCollideWith()
{
    if (mobj.CheckClass("actor1"))
        return false;

    if (mobj.CheckClass("actor2"))
        return true;

    super.CanCollideWith();
}

I wouldn't use CheckClass.

Either use 'GetClass() ==' if you want to check a single class or 'mobj is "classname"' if you want to check for a group of actors, you can of course also do 'GetSpecies() == 'speciesname', or check friendliness or check if one actor has a specific damage type or whatever else you like to have tested. Calling the super method is not needed, AActor' just returns true and does nothing.

by **Major Cooke** » Sun Dec 04, 2016 5:06 am

...Okay, better question. Graf, how did you test this to ensure the multi-actor thing works?

ZDoom

[ZScript] Actor Collision Exclusion

Post a reply

Expand view Topic review: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Re: [ZScript] Actor Collision Exclusion

Post a reply

Expand view Topic review: [ZScript] Actor Collision Exclusion

Login • Register