Actor collision rules

[Monsterovich]

This feature is a replacement for +GHOST +THRUGHOST in situations that are complex and need more than +GHOST and +THRUGHOST, but where actors don't change their collision rules over time.

CollisionType <string> - actor that goes through actors with group <string>, an actor has only one collision type (set CollisionType "None" to disable)
CollisionGroup <string> - actor that allows other actors with type <string> to go through itself, an actor can have multiple collision groups (use ClearCollisionGroups to clear them)

Examples:

Code: Select all

Actor MegaRocket : Rocket replaces Rocket // MegaRocket goes through MegaDoomImp and MegaHellknight
{
	CollisionType "SuperMissile"
}

Actor MegaDoomImp : DoomImp replaces DoomImp
{
	CollisionGroup "SuperMissile"
}

Actor MegaHellknight : Hellknight replaces Hellknight
{
	CollisionGroup "SuperMissile"
}

Actor NotMegaHellKnight : MegaHellknight // MegaRocket can't go through this monster
{
	ClearCollisionGroups
}

Actor NotMegaRocket : MegaRocket // this actor can't go through anyone
{
	CollisionType "None"
}

// Tip: Projectiles have -SOLID by default, everything can go through rockets.

Fell the difference between:

Code: Select all

// OmegaDoomImp can't go through MegaDoomImp, but MegaDoomImp goes through OmegaDoomImp
Actor OmegaDoomImp : DoomImp
{
	CollisionGroup "Imps"
}

Actor MegaDoomImp : DoomImp
{
	CollisionType "Imps"
}

// ==================================

// OmegaDoomImp goes through MegaDoomImp, but MegaDoomImp can't go through OmegaDoomImp
Actor OmegaDoomImp : DoomImp
{
	CollisionType "Imps"
}

Actor MegaDoomImp : DoomImp
{
	CollisionGroup "Imps"
}

Unlike flags, collision variables can't be changed in states, but you can use many collision types and groups in the same actor type.

This feature will be very useful in situations like this:

Code: Select all

Actor RedTeamStructure : Structure
{
CollisionGroup "RedTeam"
}

Actor BlueTeamStructure : Structure
{
CollisionGroup "BlueTeam"
}

Actor BlueTeamClass1 : PlayerPawn
{
CollisionType "BlueTeam"
}

Actor BlueTeamClass2 : PlayerPawn
{
CollisionType "BlueTeam"
}

Actor RedTeamClass1 : PlayerPawn
{
CollisionType "RedTeam"
}

Actor RedTeamClass2 : PlayerPawn
{
CollisionType "RedTeam"
}

https://github.com/rheit/zdoom/pull/469

[Major Cooke]

Suggestions:

1. Allow it to be modified so the actor can choose to pass through others at any given point, and to change off whenever. This could spare us the problem of needing to deploy secondary actors just to perform for the first and using a lot of hacks. Similar to this. I'll want an actor, for example, to suddenly become 'transparent' some of the time and to go through certain actors, for a limited time, but ONLY certain actors. (Not having to spawn child actors to perform precisely for their parents would be a sweet relief!)
2. A flag to enable and disable the collisions entirely would help. +THRUGROUP and THRUTYPE would especially be useful here.
3. (Only if the first option is not viable) Allow groups to be declared like damagetypes, for convenience. The groups should have 'AllowInheritance' word so, when specified, groups can also include children except for those with the ClearCollisionGroups flag.

But yes, I've been dying to see something like this implemented for a while.

If you act upon any of them and need help, I can certainly lend a hand.

[Monsterovich]

An efficient alternative to this system that would allow to change collision types and groups of every actor during the game would be to store two bitfields in every actor:

int CollisionTypes;
int CollisionGroups;

And use a->CollisionTypes & b->CollisionGroups to check whether these two actors may go through each other.

This would limit the maximum amount of different collision types in the game to 32 (or more than that if more bits are added to each bitfield).

In such a system, every collision type is internally identified not by a string, but by a bit offset, but Decorate could still present collision types as strings, reserving a bit for every collision type used in the game, and aborting if there are more than 32 different collision types.

[Major Cooke]

Actually I've had a second thought over what I suggested.

What I suggest you do is give the actor:

Code: Select all

const PClass CollisionName; //see TeleFogSourceType
FName CollisionGroup; //see Species

If you check out how they're retroactively modified, you'll see both of my references have code pointer functions defined.

Then you just make two functions, A_SetCollisionName(<name>, <ptr>) and A_SetCollisionGroup(groupname, ptr), and that's basically this feature suggestion made modular in a nutshell. (Keeping the permanent ones wouldn't be a bad idea IMO (the devs may disagree), just rename those to PermCollisionGroup/Type and add a new property specifically for the temporary ones.)

Yes, I suggest actor pointer <ptr> properties for the sake of more complex actors. Come to think about it, this means relationships should also have functions for this too...

[Graf Zahl]

Hm. I thought I had commented on this before, but here it goes:

A generalization of the ghost stuff is definitely something I wouldn't mind.

But let's get to the problems with this submission:

- This seems to lack any inheritance support, which is not acceptable. A fully inheritable system must not only copy everything when a derived class is created, it also requires facilities to unset these properties selectively (i.e. not just clean everything.)
- it's static per class. The ghost stuff is actor-specific, i.e. an actor can change these properties at will.
- After thinking about the whole matter, some bitmask system might be better to implement this: Have one DWORD the type mask and another one the exclusion mask. Granted, that'd limit the system to 32 collision types (or 64 if we use a QWORD) but how many do we actually need?

But the biggest roadblock is that all of this will have to be completely refactored with the scripting branch. In clear English: The entire content of this submission accesses data that will soon go away. Therefore there is no point keeping this around.

[Major Cooke]

Has it been refactored by now? Thinking of doing this over now that the scripting branch is up.

When I see this, I honestly see a repeat of Species. But to be fair, this would at least allow some better flexibility and it's far better than my no(block/clip)mask attempt, should we go that kind of route akin to Species. I'll explain more about it in a new thread.

Granted, that'd limit the system to 32 collision types (or 64 if we use a QWORD) but how many do we actually need?

For bigger projects, more than 32 for sure...

[camaxide]

This might be an off-branch to the original question, but I guess it's related.
I have items like glasses, bottles etc. which shatter when shot - but it's a bit silly when a rocket hitting a wine-glass explodes in your face..
Is there a way to make it kill the 1hp glass and pass through without exploding (like a ripping rocket) I'd like this to happen with the normal Doom-rocket/plasma etc.

I guess something like

---

EXPLOCOUNT
A missile with this flag that should normally explode only does so if its increased special2 field is greater than its special1 field.

might also be used, though not entirely sure how it works - and it would likely still mean I'd have to replace all standard Doom-missiles in order for it to actually work.

I'm hoping for a flag I can give actors which should allow missiles to pass through, and still a kill to happen on the hit actor.

[Major Cooke]

This has nothing to do with actor collision. You'll want to make a new thread in the feature suggestions for that.

[D2JK]

I'll explain more about it in a new thread.

This would be an interesting feature to have. Where is this new thread?

[Major Cooke]

Check the code submissions subforum.