• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

KFAntiBlocker - Disables player-to-player collision during trader time

Can anyone explain what is happening here? I'm playing on the doom 2 map with "show collision" to show me blocking models and volumes, and I've set bBlockActors to false allowing me to pass through enemies, and I've also altered my jump height slightly to allow me to jump higher, yet I can't pass through this window?

[edit 2] I've just cycled through all the BlockingVolume actors checking which variables will allow me to pass through, and it seems I can only pass through if bWorldGeometry and bBlockActors are both set to false. So what does this mean in terms of this mutator?

attachment.php


[edit] Sorry, double post.
 

Attachments

  • blocking.jpg
    blocking.jpg
    75.7 KB · Views: 0
Last edited:
Upvote 0
Those BlockingVolumes may behave in that way but given the nature of it being a property of Actors it seems best to leave it alone.

ZSynthetic has a very good suggestion there however.

"Very small" is likely to cause issues though. I think based on no particular information we could safely shrink the radius of the collision cylinder to 1/4 its normal size without causing these kinds of problems, since its height will remain the same and there's not likely to be any tall thin (1/4 player width) gaps doing this would expose.

Also given the standard trader door is about 1.5 x the width of a player this method would allow people to pass by even two well coordinated griefers attempting to block the doorway (and if you have more than that your server's going to have problems no mutator can solve...)

Thus:

Code:
Pawn.SetCollisionSize(Pawn.Default.CollisionRadius * 0.25,Pawn.Default.CollisionHeight)
I will try this out on my server and see how it works in practice (my players are extremely adept at finding problems and exploits :rolleyes:).
 
Last edited:
Upvote 0
Can you actually demonstrate an instance where this mutator would allow you to pass through a wall though? If for this mutator to cause an additional exploit requires you to do something very very specific to a blocking volume that's not seen on any maps then it's a non-issue really. Also, the shrinking the collision radius on the X/Z axis sounds even worse, what if you walked into a wall and then the collision sizes were reverted to normal? You'd then be partially inside a wall and be able to freely pass through the wall right? Why not just give the mutator a go and if there is some serious flaw found(which there hasn't been, despite you making it sound like enabling this would basically be noclipping) then only enable it on specific maps. The positives far outweigh the negatives in this case, and you haven't even demonstrated the negatives exist in practice.
 
Last edited:
Upvote 0
Those BlockingVolumes may behave in that way but given the nature of it being a property of Actors it seems best to leave it alone.
I disagree - if a BlockingVolume is meant to block actors, it will have the bBlockActors attribute set to true, and this completely overrides the same attribute of other actors. In order for an actor to pass through an unmodified BlockingVolume, it'd have to either have collision completely disabled or messed up to begin with. So there's absolutely no problem.

I'm not sure why behaviour is like this, but it just is.
 
Upvote 0
It is not a matter of opinion on the matter (this is not Yahoo Answers!) but a simple binary case of what the engine source code does and does not in this instance, and nobody here besides Tripwire is qualified to contradict the official documentation from the Epic UDN of what the property in question does!

Since no-one party to this discussion has the engine source code in front of them, if we choose to believe something other than what is stated in the docs we are hypothesising incorrectly at our peril.

You're committing the logical fallacy of showing one example where this problem is not caused which is not sufficient to say it will not occur in all cases.

* deep breath ;) *

Besides the example you have given in Doom is a Static Mesh exhibiting a collision hash not a BlockingVolume and you are also confusing the function of blocking (bBlockActors) with collision (bCollideActors):
http://udn.epicgames.com/Two/StaticMeshCollisionReference.html#Variable%20Description%20for%20%3Cem%3Eb_WorldGeometry%3C/em%3E%20TRUE

I already gave the WestLondon gate exploit that I tested and found was made possible by this mutator as an example of a regression caused by whitelisting this mutator, showing that we're opening up the levelling exploits the very system is supposed to prevent.

Further it is sufficient to show that doing this WILL cause a regression. Here are 30 or so KF classes (plus all those that derive/inherit from them) whose behaviour will be unpredictable and would lead to exploit possibilities by disabling bBlockActors on players:

Engine/Classes/Actor.uc
Engine/Classes/BlockingVolume.uc
Engine/Classes/KActor.uc
Engine/Classes/KVehicle.uc
Engine/Classes/LadderVolume.uc
Engine/Classes/LadderVolume.uc
Engine/Classes/Mover.uc
Engine/Classes/Pawn.uc
Engine/Classes/Pickup.uc
Engine/Classes/Projectile.uc
Engine/Classes/StaticMeshActor.uc
Engine/Classes/SVehicle.uc
Engine/Classes/Trigger.uc
Engine/Classes/Vehicle.uc
KFMod/Classes/ChainedPound.uc
KFMod/Classes/Injection.uc
KFMod/Classes/KeyPad.uc
KFMod/Classes/KFAmmoPickup.uc
KFMod/Classes/KFBloatVomit.uc
KFMod/Classes/KFDeco.uc
KFMod/Classes/KFDECO_Smashable.uc
KFMod/Classes/KFGlassMover.uc
KFMod/Classes/WeaponLocker.uc
ROEngine/Classes/RODestroyableStaticMeshBase.uc
ROEngine/Classes/ROTankCannon.uc
ROEngine/Classes/VehicleWeaponPawn.uc
Old2k4/Classes/NewTracer.uc
zYnthetic posted an extremely good suggestion as a holdover until Tripwire implement some sort of bBlockOtherPlayers in their engine, of which I posted an implementation and am testing on my server as we speak.

So I don't see where the ambiguity has come from. The situation is: It would be brilliant if the original solution works without causing other problems but it doesn't. I am not trying to rain on your parade for the sake of it.
 
Last edited:
Upvote 0
It is not a matter of opinion on the matter (this is not Yahoo Answers!) but a simple binary case of what the engine source code does and does not in this instance, and nobody here besides Tripwire is qualified to contradict the official documentation from the Epic UDN of what the property in question does!
And as we can see in this instance, the engine works just fine with this mutator and doesn't open any floodgates to exploits as you'd like to have us believe.
You're committing the logical fallacy of showing one example where this problem is not caused which is not sufficient to say it will not occur in all cases.
He didn't say this so this is a straw man argument.
I already gave the WestLondon gate exploit that I tested and found was made possible by this mutator as an example of a regression caused by whitelisting this mutator, showing that we're opening up the levelling exploits the very system is supposed to prevent.
I call bull**** on this. I just tried this in both solo and multiplayer with another user and he nor I were able to get on the gate on London, we tried for a good 2 minutes and there was no difference between jump heights or anything, with both the collision disabled or enabled between us. So again, demonstrate an instance on a map where there is such a difference.
Further it is sufficient to show that doing this WILL cause a regression. Here are 30 or so KF classes (plus all those that derive/inherit from them) whose behaviour will be unpredictable and would lead to exploit possibilities by disabling bBlockActors on players:
Slippery slope fallacy? If this were the case then the issues added by this mutator should be plentiful and beyond easy to demonstrate, right?
 
Upvote 0
Sorry rallfo, but since you haven't yet presented a concrete example of a problem (other than incorrectly claiming that the mutator allows you to use the gate glitch on WestLondon, which I know it doesn't as I've tested it myself!), I'm not sure whether to trust your knowledge. Especially considering the TWI senior programmer didn't mention any possible problems with it, and I'm sure being a professional developer he knows a lot more about the engine than you do.

Further it is sufficient to show that doing this WILL cause a regression. Here are 30 or so KF classes (plus all those that derive/inherit from them) whose behaviour will be unpredictable and would lead to exploit possibilities by disabling bBlockActors on players:
Proof? Just saying something doesn't prove it, and despite you claiming it will open up all sorts of exploits you haven't actually given any concrete examples. If you can, why haven't you already? It would have saved us both a lot of trouble.

Considering the game consists of a map (which contains blocking volumes and such), enemies, players, and pickups, which in this case requires blocking? Everything related to the map, right. But everything related to the map has bWorldGeometry set on it, which overrides another actor's bBlockActors attribute.

Here's a nice screenshot of me standing on top of the gate's BlockingVolume with my character's bBlockActors set to false. Oh, and I got up there by drastically altering my jump height, not by taking advantage of some supposed exploit possible with my mutator.
 

Attachments

  • blocking2.jpg
    blocking2.jpg
    92.4 KB · Views: 0
Upvote 0
As a server admin of course I want to just roll out this mutator too, that is why I am posting here in the first place, and playing Devil's advocate is not a reason to petulantly start attacking my credibility.

If you and the troll carry on like this I simply won't bother trying to help in future and other people whose advice you seek may think twice too.

For the record you assume incorrectly; my day job _is_ software development and my caution over this whole matter stems from bitter experience of regressive bugs. Besides I have been modding for this engine since UT99 as a hobby.

On your point about TWI not picking this one up, being a professional does not mean one can instantly spot all possible issues surrounding a piece of code merely by looking at it, the reality is it generally means you have far less time to put towards testing than you would like because of external pressures/deadlines.

Anyway to the matter in hand:
The version of westlondon on my server was an earlier fixed version from a 3rd party and instead of a BlockingVolume replaced the door with an InterpActor, which incidentally is an example of a dynamic actor that relys on bBlockActors to block players among other things.

Dynamic actors are normally things like moving platforms etcetera, which custom KF maps do use. With bBlockActors off Pawns will simply fall through them. Also ladders rely on dynamically altering bBlockActors to mount/dismount them (look at the code...).
 
Upvote 0
The version of westlondon on my server was an earlier fixed version from a 3rd party and instead of a BlockingVolume replaced the door with an InterpActor, which incidentally is an example of a dynamic actor that relys on bBlockActors to block players among other things.
Well then as long as people don't hack fixes into maps and set things up there should be no problem. I have no problem with the lift in the doom2 map, or the skateboards in Shopping-Center. :)
 
Upvote 0
I'm glad to see it in use. It's refreshing to go on a server and be easily able to walk in and out of the trader without having to worry about accidentally blocking someone or being blocked (accidentally or otherwise).

In fact I have already had one poor traderblocker have quite the WT* moment.
When he decided to "block" and demand money before he would let peeps in.
He was not happy when 5 players just ran through him
:D
 
Upvote 0