DUST Search - WTF Reduced kill points!!!???

Nova Knife wrote:

For the record, I feel like I should say that the CPM was told of this quite some time before deployment. We strongly cautioned them that it should never affect legit players, and there were a couple of us (Not all agreed) that this is not a good way to go about it. Not only did we get what felt like a patronizing pat on the head saying "Trust us, it will only affect the bad guys" but we tried to offer possible alternatives which were shrugged off.

While yes, this was the most efficient -stopgap- solution until a more robust one can be implemented, it is not ideal.

The ideal solution(s) once time allow are as follows :

(1) Absolute limit on points for a single action. IE: If you have five guys in a squad scanning and one guy kills a scanned victim, only one scan assist is given to the squad leader and the scan points are divided among those who earned them, with a bonus to the base value to the total points to keep them from earning +1's. There is no endless stream of +X's with this method, as multiple people trying to 'get in on the action' becomes moot and more time actually playing is the incentive. To this end, having multiple logi repping the same dude in order to farm guardian points would be moot, but multiple logi repping multiple different dudes would still get them all points. It encourages people to spread the love and work more as a team, rather than just everyone rallying around the 1-2 guys they know will crush everything.

(2) Re-assessment of squad bonus mechanics. (Will go into this later)

(3) When it comes to revives, the entire system needs to be revamped. I'll write a bigger post on how this should work, but essentially there should be persistent "overkill" HP. For example, A person is "Incapacitated" after being brought to 0 armor. if someone has 100 overkill HP, you would have to do more than 100 damage past their armor to "Kill" them, and they would not be able to be revived. If killed and dealt 48 of that overkill HP, they could be revived and survive another 52 overkill damage before being fully "dead". Players' not "dead" and incapacitated should be clearly visible as such and easily finished off. Revives should only be happening if a teammate saves someone just after they go down by killing their killer or forcing them to flee. No one should be getting "Kill" or "Death" stats unless the victim is down for good.

(4) Uplinks and Nanohives : Point accrual from these is mostly fine. The problem is people bypassing the "Max active" limit by using the same type of equipment but a different variant. This is unintended, and the only fix needed to stop "spam" is to fix this loophole.


Author	Thread Statistics \| Show CCP posts - 13 post(s)

CCP Greyscale C C P C C P Alliance 51	Posted - 2013.10.30 04:24:00 - [1] - Quote Hi everyone. So. Right at the end of July we were sent a video of a semi-optimised farming setup which was allowing players to grind up, in one example we saw, 60,116WP over the course of 69 minutes. This is behavior we want to strongly discourage for several reasons (listed in ascending order of significance, ie most important last): It makes a mess of our progression curves It's not fair on players who're earning their progress normally It pushes well outside the boundaries of what we consider "normal", which opens the door to all kinds of potential issues, such as farming for Precision Strikes and then dropping a dozen at once People hiding off in the corner of a map farming tend to ruin matches Based on extensive experience with exploits in EVE, we considered and rejected trying to just patch out the particular behavior that was being used in this case. Why? Because players are smart and, typically, will find another way of accomplishing the same goal very quickly. Often the new exploit will be something that was only made possible by the fix for the last one; go research the history of the Lofty scam in EVE for a good example of this sort of thing. The bottom line is that trying to band-aid specific exploitative behaviors is a bad approach to this kind of problem. Instead we determined to do the smart long-term thing, and attack the root problem rather than the symptoms. In this case, the root problem is that we don't want people farming an excessive amount of WP, for any reason and using any trick. So, we started developing a design to limit WP gain directly. More specifically, we wanted to ensure that, at the end of a match, no player had scored more than a certain amount of WP per minute, as WP gain over time is the ultimate thing we want to target. The design we ended up with is fairly straightforward: We set two constants in our data: WP/minute ceiling and WP/minute limit Each player has a WP ceiling and a WP limit for each match These start at 0, and are incremented every second. This gives you two numbers that rise linearly over the course of the match If, any time you gain WP, your total WP score for the match would be above your current WP ceiling, we reduce the value of that WP payout proportional to how far between your current ceiling and your current limit it would take your score This has the following consequences: So long as your WP total stays below the WP ceiling, you will never see this system As your WP total moves above the ceiling, we trim your WP payout in a way that starts gentle but gets firmer as your WP/minute gets higher We can mathematically guarantee that you can never score more WP per minute than the limit value over the course of the match, so this system should be 100% exploit-proof and never need to be adjusted again Because we are tracking a moving ceiling over the course of the battle, rather than say tracking your income over the last minute or the last X WP scores or whatever, once you get past the first few minutes in-match your WP income can be very uneven and still not trigger the cap so long as your average over the course of the battle stays below the limit As a side-effect of the above, the system is more likely to start clipping scores if you score large amounts of WP in the first minute or two; this isn't optimal, but in the course of a normal battle (ie starting from the beginning rather than joining midway through) there's little opportunity to get big scores in your first minute or so, which should significantly reduce the impact of this factor. We're currently happy with the underlying design of this system: it's robust, it's failsafe, it's communicating its actions to players in a relatively clear way, and aside from first-minute concerns it has no inherent drawbacks that we've identified so far. However. The numbers are obviously wrong When we set this up, we did some data mining to determine what values we should use. We looked at some people who were obviously exploiting, and they were getting up into the 1000+WP/minute range. We also tried to determine what "normal" play looked like for high-scoring characters, and our research here fell short. We looked at a random sample of players, and we looked at the highest-scoring player on the server, and we were seeing that a little over 250 WP/minute was about the highest we were seeing. Obviously the ideal thing would be to calculate WP per minute per player per match for say a day, but the amount of data we'd need to crunch to do that was judged to be infeasible, and while all we really wanted to know was the top 10 WP/minute scores (which we would obviously validate against logs to check they weren't exploiting), we'd have to calculate the WP/minute for everyone to determine who those people were. We switched this feature on last week, with the values being 250 and 300 respectively. Pretty quickly we started seeing scattered feedback of players running into this "normally", so we started to dig into the metrics to try and see if we could tune this further. Thanks to some very astute data mining by one of our programmers, we managed to isolate the highest WP/minute scores by looking for incidences of players having their scores reduced by the cap, thus shortcutting the problem of having to analyze the entire playerbase to find these high-peaking players. What we're seeing in these data, somewhat unsurprisingly, is that it's possible to really spike your WP payouts and trip the cap in certain circumstances. For example, dropping a Precision Strike on a squad objective and killing what looks like five infantry and two full HAVs gets you a large number of points, which can swing you up considerably past 300/minute net if it happens relatively early in the battle, and the follow-up strikes you're getting from that flood of WP hardly help the matter over the course of the battle. Anyway, long story short, I spent most of yesterday looking at logs, and I'm in the process of preparing a hotfix to raise the values from 250 and 300 to 400 and 500. The highest legit net WP/minute I could find yesterday was 468, with a total pre-cap WP of 2142; under the current numbers on TQ this is cut down to around 1446 after the cap is applied, while with 400/500 it's only reduced to 2031. It's still not optimal that players are hitting the cap at all, but we're reluctant to push it too high as we need to keep it sufficiently close to "normal" play that people considering exploiting don't find it worth doing. I'm not sure yet exactly when this change will go out as I'm still tying off...


CCP Greyscale C C P C C P Alliance 51	Posted - 2013.10.30 04:31:00 - [2] - Quote OwnD07 wrote: Feedback time! ... The cap is currently way too strict. I hit it multiple times per night of playing. At least one game per night my kills don't even score me points. I understand wanting to keep people from exploiting the game, but come on. I'm hitting this cap /hard/ under normal gameplay circumstances. If it makes you feel any better, I can tell you that you were in the top five characters for "number of minutes in which WP scores were reduced"


CCP Greyscale C C P C C P Alliance 53	Posted - 2013.10.30 06:07:00 - [3] - Quote ratamaq doc wrote: CCP Greyscale wrote: ...Anyway, long story short, I spent most of yesterday looking at logs, and I'm in the process of preparing a hotfix to raise the values from 250 and 300 to 400 and 500. The highest legit net WP/minute I could find yesterday was 468, with a total pre-cap WP of 2142; under the current numbers on TQ this is cut down to around 1446 after the cap is applied, while with 400/500 it's only reduced to 2031. It's still not optimal that players are hitting the cap at all, but we're reluctant to push it too high as we need to keep it sufficiently close to "normal" play that people considering exploiting don't find it worth doing... Wait, so are you saying that 2142 or 2031 wp for a game is what you are seeing the top players earning? This cannot be the case. I assure I don't farm, and I'm no where near the top 10 in this game, but I break that somewhat regularly. This is a video of the end game stats of one of my all around best games to date. According to the timestamp of the recording, I did this on 04SEP2013 at 0116 -5 GMT if you want to check the logs. This was a skirmish I ran solo In a 'Sever' with an 'Exile'. I never once swapped my suite. So two links (templar) and two basic nano hives worth of equipment wp max, 22 kills, Scanner in the third slot and A LOT of hacks turning objectives. All legitimate activities. This was before we got WP for scanning. If I pulled 2600+ WP in that setup, I have to imagine that the 500 some odd players above me on all the leader boards are doing this regularly. A solo orbital is one of the things people work for in this game. It's easy to pull as a squad leader, but alone it's hard a fun challenge. Please tell me you are not taking this away. Sorry yeah, I should've said, that 2k WP was scored in six minutes If you're scoring 2k WP over 10 or 15 minutes you're unlikely to run into the cap unless you score a large number very early on. 2k evenly spread over 10 minutes is only 200 WP/minute, which isn't a problem even with current cap numbers.


CCP Greyscale C C P C C P Alliance 54	Posted - 2013.10.30 06:10:00 - [4] - Quote crazy space 1 wrote: Quote: Based on extensive experience with exploits in EVE, we considered and rejected trying to just patch out the particular behavior that was being used in this case. Why? Because players are smart and, typically, will find another way of accomplishing the same goal very quickly. Often the new exploit will be something that was only made possible by the fix for the last one; go research the history of the Lofty scam in EVE for a good example of this sort of thing. The bottom line is that trying to band-aid specific exploitative behaviors is a bad approach to this kind of problem. Instead we determined to do the smart long-term thing, and attack the root problem rather than the symptoms. wait... so... you don't mind if I go look it up and use it? sweet free sp here I come, thanks CCP, great mindset The Lofty scam? Sure, you can try I'm pretty sure I fixed it for good in 2008, though, so let me know if you manage to get it to work!


CCP Greyscale C C P C C P Alliance 59	Posted - 2013.10.30 07:32:00 - [5] - Quote Rasatsu wrote: Why isn't orbital strike events used as an input to the WP capping algorithm, raising the ceiling for that player? This seems a much better solution than increasing the cap so much as to make it profitable to do a bit of exploitation near the end of matches. The more complexity and special-casing you add into the system, the more loopholes you end up with, so we really want to avoid adding any additional rules like this if we can possibly avoid it. The overall goal of the cap is for it to be just low enough that players actively farming WP find that it's not worth the boredom of doing it when they could be making nearly as much and having more fun playing normally.


CCP Greyscale C C P C C P Alliance 60	Posted - 2013.10.30 09:54:00 - [6] - Quote SirManBoy wrote: CCP Greyscale wrote: Rasatsu wrote: Why isn't orbital strike events used as an input to the WP capping algorithm, raising the ceiling for that player? This seems a much better solution than increasing the cap so much as to make it profitable to do a bit of exploitation near the end of matches. The more complexity and special-casing you add into the system, the more loopholes you end up with, so we really want to avoid adding any additional rules like this if we can possibly avoid it. The overall goal of the cap is for it to be just low enough that players actively farming WP find that it's not worth the boredom of doing it when they could be making nearly as much and having more fun playing normally. Have you seen the kind of WP logis gain when their teams get struck by an orbital and now 8+ people spawn immediately from uplinks? Add this to the fact that in some matches the ebb and flow is such that logis continue to accrue all match long via a constant flow of uplink spawns, resupply points through hives, triage, and so on. As someone who routinely scores 3000-4000 WP a game (much of it coming in large spurts), performing legitimate support activities that help my team, I worry that I'm going to be affected here. I like my play style the way it is and I don't want to be punished for it. If your 4000 point game is taking longer than nine minutes, and you're not scoring more than 1000 points in the first two minutes or so of the battle, you'll not be affected by this feature once we get the new numbers onto TQ.


CCP Greyscale C C P C C P Alliance 78	Posted - 2013.10.31 02:43:00 - [7] - Quote Sana Rayya wrote: Thanks Greyscale, for explaining the rationale and math behind the warpoint limiter. The only thing I don't like is that the ceiling is scaled per minute from the very beginning of the match. In ambushes specifically, sometimes you spawn in within 50 meters of the reds, so you might end up scoring kills that are subsequently penalized within less than a minute of the start of the battle. Maybe you should build incrementally from another fixed WP value other than zero - say 500 WP limit right at the beginning, then 400 WP per minute after that? Yeah, this is probably the next tweak in the line if we find it's still an issue after we raise the cap. Brush Master wrote: I am fine as long as this does not effect normal gameplay but when you say it clear that it is happening, are you giving the player any feedback when it is happening? This goes back to the reduced WP gain on rep tools. It looks like a bug because no feedback is given, just reduced number. How about some red letters or something beside the WP to let them know that WP is reduced that way we know that is not a bug or can clearly see this is happening. Also, as others have said, this is the wrong way to implement something, you just did it and then asked for feedback, this is backwards and now we wait 1-2 weeks for a fix. These kinds of code pushes are what cause your player base to get mad and leave. Clear as in we're actually showing you the reduced payout numbers, rather than doing something behind the scenes and not telling you at all. I agree that it could be clearer still, but if this is tuned properly (#1 priority right now) the only people seeing it should be people deliberately farming, and a) they should be able to put 2 and 2 together themselves and b) we don't want to spend any significant amount of effort making a better UI just for them Aeon Amadi wrote: Flashbacks of dealing with Crimewatch, Greyscale? I'd characterise it as "lessons learned" rather than "flashbacks" but yeah, that's informing this decision-making


CCP Greyscale C C P C C P Alliance 86	Posted - 2013.10.31 07:53:00 - [8] - Quote Nova Knife wrote: For the record, I feel like I should say that the CPM was told of this quite some time before deployment. We strongly cautioned them that it should never affect legit players, and there were a couple of us (Not all agreed) that this is not a good way to go about it. Not only did we get what felt like a patronizing pat on the head saying "Trust us, it will only affect the bad guys" but we tried to offer possible alternatives which were shrugged off. While yes, this was the most efficient -stopgap- solution until a more robust one can be implemented, it is not ideal. The ideal solution(s) once time allow are as follows : (1) Absolute limit on points for a single action. IE: If you have five guys in a squad scanning and one guy kills a scanned victim, only one scan assist is given to the squad leader and the scan points are divided among those who earned them, with a bonus to the base value to the total points to keep them from earning +1's. There is no endless stream of +X's with this method, as multiple people trying to 'get in on the action' becomes moot and more time actually playing is the incentive. To this end, having multiple logi repping the same dude in order to farm guardian points would be moot, but multiple logi repping multiple different dudes would still get them all points. It encourages people to spread the love and work more as a team, rather than just everyone rallying around the 1-2 guys they know will crush everything. (2) Re-assessment of squad bonus mechanics. (Will go into this later) (3) When it comes to revives, the entire system needs to be revamped. I'll write a bigger post on how this should work, but essentially there should be persistent "overkill" HP. For example, A person is "Incapacitated" after being brought to 0 armor. if someone has 100 overkill HP, you would have to do more than 100 damage past their armor to "Kill" them, and they would not be able to be revived. If killed and dealt 48 of that overkill HP, they could be revived and survive another 52 overkill damage before being fully "dead". Players' not "dead" and incapacitated should be clearly visible as such and easily finished off. Revives should only be happening if a teammate saves someone just after they go down by killing their killer or forcing them to flee. No one should be getting "Kill" or "Death" stats unless the victim is down for good. (4) Uplinks and Nanohives : Point accrual from these is mostly fine. The problem is people bypassing the "Max active" limit by using the same type of equipment but a different variant. This is unintended, and the only fix needed to stop "spam" is to fix this loophole. The general approach you're advocating here - addressing specific issues on a case-by-case basis - is, in my experience, not an efficient or effective way of dealing with exploits. If we identify specific cases where, in the course of normal play, we're handing out too many WP, we should and will alter the way payouts are awarded, as and when doing so becomes a priority, so that they're paying in a more balanced manner. This is a balancing concern, though. As far as exploits, farming and the like go, you attack the root not the leaves.


CCP Greyscale C C P C C P Alliance 100	Posted - 2013.11.04 02:33:00 - [9] - Quote Crash Monster wrote: 2) Alternately, you could implement a small "overheat" style buffer which shrinks as you approach the total cap -- where going above the limit is absorbed to a small but tunable degree -- allowing you to slow down later and not violate the ultimate limit. Not as simple as #1 but could make the cap effect less visible. Not totally sure what you're suggesting here, can you explain further?


CCP Greyscale C C P C C P Alliance 102	Posted - 2013.11.05 11:26:00 - [10] - Quote OK, cap ought to have been lifted from 250/300 to 450/500 today. If you're still running into it regularly after today's patch, please post here so I can look into what you're doing that's breaking our assumptions



CCP Greyscale C C P C C P Alliance 102	Posted - 2013.11.05 11:40:00 - [11] - Quote Absolute Idiom II wrote: Is there a reason that you couldn't simply add a max(1000,[your formula]) statement to ensure that you don't start off the battle with a cap of 0, but with a reasonable cap of 1000? Then only after 2.x minutes would your cap begin to climb higher than 1000. It opens the door to yo-yoing in and out of battles to game the cap. We might do something along those lines if people are still having issues, but I'd much rather not and keep everything nice and tight. (Yes, you can then try and track battles and persist the cap per-user per-battle, but at that point it stops being a simple fix and you're heading down the complexity rabbithole again.)