Score detection

[Phytotron]

SELF-SPLIT from here.

Q: Is there a way to adjust the new score detection enemy influence settings to make score detection more like it used to be; i.e., more about whose wall one crashed into?

A: ENEMY_DEAD_PENALTY 0 and ENEMY_CURRENTTIME_INFLUENCE 0 should get you back to the actual crash being taken as most important. ENEMY_TEAMMATE_PENALTY 0 if you want to go all the way and count all crashes into teammates' walls as team kills.

Unfortunately, that's not quite up to it, either. I realise that a server-side recording would be best, but you don't have a regular server up that I've found. Just sumo and fortress stuff. And I dunno how to make a server-side recording myself—or if I even can, given my access to the server.

So, here are a few screenshots just giving one simplistic, quick-and-easily reproducible example (of many) of the "off-ness" I (and others) dislike about the new score detection. This is after changing the above settings to 0 in Shrunkland.

In the last example, turning right into red "Elm" would sometimes even award the score to green "Pine."

In these examples, I think the wall crashed into should be awarded the point.

...after all, what really killed you are the walls surrounding it.

This is what I'm saying! I really believe that the entirety of one's wall, and where and how it's placed, should be relevant to the game, not just what occurs in proximity (both in terms of time and space) to twitchy cycles. So, this is both a matter of functionality and "philosophy"—I have some objections to the latter, but sometimes it doesn't even get right what it's supposedly meant to do.

I mean, I have no idea how to explain situations like these:

- Two players are engaged in one way or another, one crashes. But some other guy on the other side of the arena, with both his cycle and the entirety of his wall waaay over there, somehow gets the point.

- Players A and B are engaged. Player C comes in and does something to take out one or both of them with his wall. Players A and B get each others' points.

- Player A boxes in player B. Player C goes in to get player B. Player A crashes. Player B crashes into player C's wall. Player A gets the point from B.

- Player A lays a wall down around the arena. Player B and C are battling. Player B goes inside the trash and Player C disengages. Player B drives around a bit and ultimately crashes into something player A had made. Player C gets the point.

- Players A and B are approaching each other perpendicularly, as in the start of a round, with B to the right of A. Player C approaches opposite A. A turns left, C turns left and cuts off B who crashes. A gets the point. (This similar to the screenshots above.)


I dunno, it's difficult to break down sometimes (especially off the top of my head while not playing) because of all the various scenarios and if-then's, but there are definitely a lot more instances now than there used to be when I see an objectionable score awarded.

[Phytotron]

Erm, just realised, looks like ENEMY_DEAD_PENALTY 0 and ENEMY_CURRENTTIME_INFLUENCE 0 are the defaults. Sooo...how would the current defaults get one "back" to the previous way? Am I missing something?

[Z-Man]

ENEMY_CURRENTTIME_INFLUENCE 1 is what I *wanted* to say
But that still doesn't resolve the problem. There is one bug in the wall built time calculation, I'll fix that, but that also still doesn't solve the problem. The problem is that before you crash into the wall, you're drawing acceleration from other walls. And those count as influences as well, and they are tied with the crash influence in terms of importance. Hmm. I guess I'll let the acceleration influence enter with lower importance, reduced by speed*distance.

Edit: done on all branches. About those other cases: well, sure, sometimes the new system picks the wrong killer. Dunno about the first case, I'd assert that can't ever happen unless there is a very strange bug in the sensor system (has happened before), which would need a serverside recording (or a clientside recording of it happening in a local or hosted game). But the others, sure, can happen. I'd say it's better than this one, general case:
- player A makes player B crash into player C's wall, which happens to be around randomly. Player C gets the points.
The new system and its default settings give player A at least a good chance of getting the point, he just has to actually throw a wall near enough to B.

[Phytotron]

OK, I'll try it as 1. That's just for_ CURRENTTIME_, and not _DEAD_PENALTY?

I didn't realise it was the wall accel that was factoring into the influence. That at least makes some scoring make more sense as to where it came from, even if it's still bonkers sometimes.

- player A makes player B crash into player C's wall, which happens to be around randomly. Player C gets the points.

Thing is, sometimes C deserves it. Think about a case where A and B are engaged, C comes up behind and in between them, then blocks the way back out, anticipating that he might get a point from whomever might turn back. Even if A gets around B and causes B to turn back and crash into C's wall, C still did have a deliberate role in that. And variations on that theme. I do stuff like that all the time and get gypped out of a point.

Obviously not every situation can be accounted for, I get that. Even human observers would argue some cases.

[Z-Man]

Just the CURRENTTIME one. Note that it's one of those floating points variables where all values between 0 and 1 make sense; your sweet spot may already exist somewhere there.

And yeah, it's very much debatable who deserves a point in any given situation, and it's pretty much impossible for a machine to figure out. It would need to determine which moves were done intentionally to kill an enemy and which were just random or evasive actions, and which of the intentional actions had what part in the death of a player, and even more so which potential actions of other players the victim was aware of. There could be cases where the mere strategic positioning of one player kills the other (like, threaten to close the exit of a tunnel, so the player in the tunnel tries to turn around and fails.)