Declined Suggestion for dodgeballserver #4 (1 Viewer)

Trial phase for autoslay

  • Yes

    Votes: 2 22.2%
  • No

    Votes: 7 77.8%

  • Total voters
    9
  • Poll closed .
Status
Not open for further replies.

mrbooooom

Member
Joined
Jun 29, 2014
Messages
96
Suggestion for the dodgeballserver #4



As far as I know it should be possible to auto-slay every stealer (with a plugin code similar to the one which is showing the name of a stealer) .

So it would clean up game play even if no admin is on.


The main reason not to do this (as admins told me) is mainly the concern that “walls” and helping RTD disabled players would not be possible anymore.



Considering that every hour at the server with no admins on you can see literally hundreds of steals but the above mentioned walls and helping players are rather rare events I like to suggest , just as a trial , to try this auto-slay on Server#4 for a while.

Just to see what happens. If the gameplay gets better or not.

Cheers

Booooom
 
I am against any idea that involves unreliable automatic punishment. Punishing innocent players is just plain terrible. Even if it's just a small portion of the cases.
 
Totally agreed: punishing innocent players would be not desirable.

But based on my observations during many hours of gameplay since the stealing-info plugin was added, I don't think that the stealing detection is unreliable. Havent seen a malfunction once.
 
I don't think that the stealing detection is unreliable. Havent seen a malfunction once.
That's debatable because in numerous instances I've noticed players "stealing" the enemy's rockets, or players "stealing" their own rockets.
 
That's debatable because in numerous instances I've noticed players "stealing" the enemy's rockets, or players "stealing" their own rockets.

That can happen when a rocket is reflected instantly after being reflected. One of the plugins (I suspect the db plugin) chokes on the event spam.

By unreliable I mean that the plugin cannot decide whether a steal was allowed or not. It would punish every steal, including the exceptions.
 
By unreliable I mean that the plugin cannot decide whether a steal was allowed or not. It would punish every steal, including the exceptions.
Yeah, I understand. I was simply adding on as to why the plugin would be unreliable if it was set to automatically slay players. Not only will it be punishing players who are allowed to steal at given situations, but it will also punish players who aren't stealing, but instead, simply cqc'ing.
 
pros:
reliable punishment in terms of round the clock effectiveness, especially in quiet hours or when no admin is present. just having hopped off #4 when it was infested with people stealing just about everything.
Very quickly deters further stealing of ANY kind. people will quickly learn to move out of the way. You've seen me play Klay, how often do I steal out of necessity? -never-
Takes a load off of slaying. In a lot of cases when multiple people are stealing it becomes hard(er) to slay everyone manually and keep track of which steal is an exception. Fast forward a few minutes and you've got people crying why that one other guy didn't get a slay. This solves that. When a rocket is reflected instantly? This is 9 out of 10 cases a stolen rocket or someone blocking and should result in a slay anyway.

cons: as mentioned by klay.
Plugin would likely need tweaking(?)
It would disallow some very specific (though often dangerously close to rule-breaking) playstyles.


This "unreliable" automatic punishment worked wonders on youknowwhere. I'm all for it and would love to see it.
Players would simply learn to avoid it altogether. Players who cannot read english properly and/or don't read the rules would also quickly find out what they're doing wrong.

NUMEROUS unhandled calls on Dodgeball (I am guilty of this too, woops) as mentioned a little while ago in a different post and I know the vast majority of them are for stealing. With this admins can put their focus elsewhere.

thats just my 2 cents on this
 
An alternative solution to this problem would be to remove the ability of deflecting when not targeted all together.
This would, however, still create the problem of not being able to save others who are, for instance, frozen using rtd.

Unfortunately, the rtd version installed on the server (by pheadxdll a.k.a. linux_lover) doesn't have any natives or forwards that would allow external plugins (like the dodgeball plugin) to check whether someone is currently rolling and create appropriate exceptions.

Still, I feel like removing the ability to steal is a better solution compared to punishing. (Even if you were to give a margin of like 3 steals before punishment.)
 
Against this for the reasons klay mentioned. As long as we allow walling etc. we can't really do this. As for a threshold, as far as I've seen, people will still steal within the treshold.
 
  • Agree
Reactions: Nitro4D
Thanks, Wolfgang for the support.
"just having hopped off #4 when it was infested with people stealing just about everything."
"Very quickly deters further stealing of ANY kind. people will quickly learn to move out of the way."

My sentiments exactly.

Especially IMO it can't hurt, to TRY it OUT.
Easy to call it off in case players are not happy or if it creates problems.

Maybe admins could activate/deactivate this when leaving/joining? So its only "on" when no admins are online?


Regarding RTD...in a way cute but not really necessary for the game. Beside this it does create lags (delays, changes of timing whatever)


A word regarding walls. It is certainly ok if the wall is in the back and if the players participating just steal from each other.
But if the wall is somewhere in the middle (as I observed several times) and rockets get stolen from other players behind it should not be tolerated.
 
I'll put up a poll. If it passes I'll modify the plugin to include an option to autoslay (it should be possible to detect wether the target can airblast or not but idk).

We'll wait idk 1-2 weeks?
 
With boom on this one, walling can eat a d*ck it is rarely ever done in a way that's tolerable and more often than not will also result in people asking questions i.e why is he allowed to steal and i'm not?

This whole no stealing w/ exceptions thing is silly imho. Either allow it or don't. a lot of 'effort' is going into explaining the exceptions, keeping the peace when things go awkward with stealing and more often than not calls simply go unhandled and people are stuck in frustration.

I see a very easy way to fix most of these glaring issues on the dodgeball servers but strongly feel like these points are overlooked by most you.

You, as admins, probably won't see these problems too much because you hop on the servers, slay the stealers and that's it- a job well done, everyone's happy. But that's not counting the many hours every single day where things just go to shit. Or leaving the server only for people to start stealing again-- I've played this cat & mouse game, it's stupid.

The only real counter argument given so far is....walling. and the occasional rare innocent person being slain. I'd say to hell with both of them in favor of a FAR MORE EFFICIENT system.




PS I feel like these polls are rather odd because the people that read/vote in them are usually tight-knit groups(admins). I don't feel like it reaches out to its target audience and therefore not get an accurate representation of the people's votes.

Surely you don't like change, but I like to be able to play my dodgeball without having to !call as soon as it gets off cooldown.
 
Last edited:
You, as admins, probably won't see these problems too much because you hop on the servers, slay the stealers and that's it- a job well done, everyone's happy. But that's not counting the many hours every single day where things just go to shit. Or leaving the server only for people to start stealing again.

Ask yourself how and why I (and most of us) became admin and you can see how that isn't true. I've seen people wall quite a bit and it's something that I enjoy doing every now and then. Also, not being allowed to steal to save yourself can be annoying too. I've witnessed people get others killed countless times on <server with similar plugin> by just constantly standing behind them or orbiting into them. Especially on a server with a maximum playercount this high (20 is well above average for dodgeball), I can see this becoming quite annoying fairly quickly.
 
  • Like
Reactions: Callum
Yes, you're right no doubt about that.

From my personal experience auto-slaying stealers has always worked more efficiently (though this may depend on personal preference, but even so)
And yes, it would be a huge trade-off. Certain styles would no longer be allowed.

Where standing behind people is concerned-- that's teamkilling. And that would be your new "steal call" so to speak, guaranteeing you'll get a lot less of those than we get about stealing.

For the little while I've had the pleasure of administrating panda DB I've more often than not just slayed every stealer automatically, regardless of whether it was allowed or not. Now this may not have been the best thing for me to do but (again, in my experience) this proved to be far more effective even...or especially, on a crowded server. People'd just stop altogether. To usually little to no protest.
 
But why bother with punishment?

You can easily just add the following line to OnPlayerRunCmd:
PHP:
public Action:OnPlayerRunCmd(iClient, &iButtons, &iImpulse, Float:fVelocity[3], Float:fAngles[3], &iWeapon)
{
    if (g_bEnabled == true) iButtons &= ~IN_ATTACK;
    if (g_bEnabled && !ClientDeflectAllowed(iClient)) iButtons &= ~IN_ATTACK2;  // Added by Evert (panda.tf)
   
    return Plugin_Continue;
}


And define a function bool ClientDeflectAllowed(int iClient) where you check if the player would be allowed to deflect or not.
For instance, the following code would allow targets of rockets AND players who are standing close enough to targets, to deflect.
PHP:
// Added by Evert (panda.tf)
private bool:ClientDeflectAllowed(int iClient)
{
    new Float:fClientPosition[3], Float:fTargetPosition[3];
    GetEntPropVector(iClient, Prop_Send, "m_vecOrigin", fClientPosition);
   
    new iRocket = -1;
    while(iRocket = FindNextValidRocket(iRocket) != -1)
    {
        new iTarget = EntRefToEntIndex(g_iRocketTarget[iRocket]);
        if (!IsValidClient(iTarget)) return false;
        if (iClient == iTarget) return true; // Rocket targets are always allowed to deflect
       
        GetEntPropVector(iTarget, Prop_Send, "m_vecOrigin", fTargetPosition);
        if(GetVectorDistance(fClientPosition, fTargetPosition, true) <= PLAYER_DISTANCE_THRESHOLD) // Client is within threshold distance (squared) of rocket target
            return true;  
    }
    return false;
}


I honestly don't see why you would bother with punishing for something that can be prevented altogether.
 
  • Informative
Reactions: Wolfgang
Because that would most likely cause a ton of odd bug reports that somone couldn't deflect a rocket.
 
Because that would most likely cause a ton of odd bug reports that somone couldn't deflect a rocket.

As opposed to how many calls on stealing?

And in all fairness, how many players on dodgeball would take time to write a bug report over something so obvious and perhaps trivial? A quick change in the 'general reminder' bind should help clear out most of the confusion. And to those it doesn't, it's no different from players unable to comprehend the rules Now. But at least then you wouldn't be required to hop ingame to deal with them at the press of a button.


"General reminder that stealing is forbidden and will instantly result in death." That might come off a bit strong but you get the point.


and just to be clear its not that i think you guys arent doing a good enough job cuz ily and the work you do tbot but that's all the more reason i would like to see something like this in place, i legitimately feel safer playing with an admin present knowing stealers are dealt with. that's saying something isn't it?
 
And in all fairness, how many players on dodgeball would take time to write a bug report over something so obvious and perhaps trivial? A quick change in the 'general reminder' bind should help clear out most of the confusion. And to those it doesn't, it's no different from players unable to comprehend the rules Now. But at least then you wouldn't be required to hop ingame to deal with them at the press of a button.

It is less than obvious not to be able to reflect a rocket. It is even less obvious to not be able to reflect a rocket in certain situations but to be able to in others. Slaying is IMO a way better way of dealing with it. In addition to that, we only get notified of the reflect (steal or not) after it has happened. We would have to modify the Dodgeball plugin such as to not create a race condition. That means we'd have to deploy a new version of the Dodgeball plugin. Slaying is simpler to implement and imo more understandable.

There are both technical and ux reasons to slay a player rather than prevent them from reflecting.

Also Wolf, I think we're talking past eachother right now? I was referring to the post above, not to auto-slay on stealing.
 
I should probably mention that I am aware of both technical and other reasons that makes this nigh impossible to implement and I am mostly speaking about a scenario that has a plugin capable of auto slaying smart enough to distinguish this from that and keep innocent casualties to a minimum. Think a little more in the direction of whatsitsname where it worked (mostly) beautifully. I believe that Evert's suggestion above although in the right direction, is a little too...much.

edit; and yeah, i misunderstood your post
 
I have to mention, that deploying a new version of dodgeball is unavoidable as stray rockets would cause a big issue (unavoidable death for the unsuspecting). We already have a fix for this, we are only waiting for @Kevin to have some free time and check it out. I am also not sure how the race condition is affecting the plugin, so that's probably worth fixing too.
 
  • Agree
Reactions: TBotV63
Status
Not open for further replies.

Users who are viewing this thread