ThruBits

[Major Cooke]

Pull Request

By using bytes (1 << [0, 31]), allows actors to pass through others within the same 'byte'. An example is in the PR.

---

Pull Request

A simple in-between method that adds more control over what actors can pass through others.

This allows me to create artificial floors/ceilings/walls with actors that avoids needing to use +THRUACTORS, since I'm making a Minecraft-themed map with randomly generated terrain out of simple blocks used for collision. This will ensure compatibility is maximized for all mods and introduces another means of adjusting what an actor can collide with.

More details in the PR.

[Rachael]

I think I would prefer to see this as a bitfield mask instead of as "levels", i.e. if (actor1->thrubits & actor2->thrubits) { noCollision = true; }

[Major Cooke]

Oh? Can you expand more on that idea's explanation? I'm intrigued but I don't think I see the full picture.

[Rachael]

x->thrubits = 1
y->thrubits = 2
(x & y) == 0, so they collide

x->thrubits = 1
y->thrubits = 3
(x & y) == 1, so they do not collide.

[Graf Zahl]

That definitely makes a lot more sense than what's there currently. Then the entire check can be condensed to a single '&' check of these two flag words. Since both would be 0 by default, no special flag and no helper functions would be needed.

[Major Cooke]

While this solves my most immediate problem of ensuring blocks are always blocking, I need help testing some more advanced cases. Is it possible to create 'groups' in a way, and how would that be done? I get that 0 means its always blocking, but if I'm going to be using this, it'll help greatly to know how to handle this.

I'll create a PR in the mean time.

[Major Cooke]

Here it is.

[Rachael]

Is it possible to create 'groups' in a way, and how would that be done?

That's what the bitfield is for. Except - you as the modder get to assign the groups. i.e. bit 1 is one group, bit 2 is another, etc.

The basic idea is - you're never going to need 4 billion levels of ThruActor. However, if you instead use 32 different levels that can be switched on and off inside various actor definitions - it creates a system that is much more flexible and much less need of overrides in the future. It allows a granularity that simple numbers cannot define, and does it in a way that is a simple test for the CPU rather than a complex machination of if's and if else's that would inevitably be built upon in the future.

There are times when it is appropriate to design a mechanic from the top down instead of the bottom up, and I feel this is one of those instances.

Basically, I'm trying to avoid a repeat of God/God2/Buddha/Buddha2/NODAMAGE/NOPAIN/FOILINVUL/FORCEPAIN/etc with the clipping code.

[Major Cooke]

So if I have actor X with (byte4|byte5), it can pass through anyone else with either of those two groups. Alright, that works for me.

Should anyone else need more, well... I guess we can cross that line when we get there.

[Major Cooke]

I've tested everything and the PR is already merged into QZDoom. Works like a charm.

[Apeirogon]

Maybe its better to implement it in other direction? Instead of "actors with same bits can pass through each other, collide otherwise" do it like "actors with same bits can collide with each other, pass through otherwise".

Also "thrubits" is not too good name for such thing, "Bits? What bits? Woob Woob Woooob???".
ThruGroup, PassLayer, IgnoreGroup or CollisionGroup maybe?

[Major Cooke]

I already asked Graf if I could do ThruGroup, but he said no.

You do have a good point about inverting though. It could be done with an added actor boolean if no one opposes it. But I'll wait for Rachael/Graf to speak on that matter first.

[Rachael]

Either works for me. As I've said before - the thing that I want to avoid is an override of an override of an override of an override ... especially when it comes to the collision code.

Stuffing up the collision code with a complex if-else tree can have a massively negative impact on performance.

[Graf Zahl]

I already asked Graf if I could do ThruGroup, but he said no.

And it remains 'no'. This is time critical code - adding a single bit masking check is no big deal, but doing anything more complex there will affect everything that does not need the feature.

[Major Cooke]

To clarify I meant rename it to ThruGroup, nothing more. But yeah. It makes more sense as ThruBits now that I think about it because of what can go into it.