PDA

View Full Version : Modified Weighting System



Phaedrus
30th January 2007, 16:12
Delete this thread.

Zabiela
30th January 2007, 20:17
I like this, I can only hope some server admin are too. Thanks.

butterқnife
30th January 2007, 22:47
Ohh I do like that. Most weighting would be fun to try out.

Another idea... keep the weighting as it is now, but only enter the 4 IRIS (assuming a full server) with the highest weighting into the lottery. As fun as it is to get hidden after dealing only 3 damage, conversely it is most annoying to blast a hidden down to no health just to see the guy that got in one pistol shot become hidden. I think the simplest way to do this would be to find the average weighting of that round and set that as the min required to be put into the selection lottery.

Paegus
31st January 2007, 06:39
i REALLY like the idea of having the weighting carry over.
i think it would play out very nicely if it built up with consecutive rounds and reset ONLY when you become hidden. good players who hit the hidden a lot will easily overtake less good players who don't. but those players will still get a chance in hell as their weighing climbs higher and higher with each round. instead of having to fight an uphill battle EVERY round only to have it all reset when you're playing with people who can spot the hidden at 200m hiding in a well shadowed corner and launch 6 303 pellets at him before he's even felt the first one hit... well it's just no fun at all...

nor is it particularly fun to see consistent 60~70% chances and not get the hidden round after round after round only to get it eventually on a 5% chance and have some prat moan to you about how he should have got it on his bloody 90%

the extreme lower end still suffers a bit though when facing a server-destroyer because the -20s can add up...

i'd still prefer random selection tbh as there's no desire to not work as a team, cheating is relatively pointless (aside from the points you get) since you can kill the hidden every round but you still get to play him no more or less than anyone else and there is, by default, a hidden round limit of 1 so no uber-server-emptying-ownage can occur and hidden players are just that much less likely to be driven to kill everyone in 30 seconds flat because then they don't get to be hidden as long.

starstriker1
31st January 2007, 15:53
You've probably got this covered, but does it ignore any weighting the hidden receives? The hidden will usually get an absurdly high weighting that's ignored by the weighting system, but I can forsee problems if it gets carried over from round to round, or extra health was given based on it!

starstriker1
31st January 2007, 16:24
Heh. Just making sure! :D

Paegus
31st January 2007, 16:37
:thumbsup:

what cvar does one look for to see what servers are using this particular script?

Paegus
31st January 2007, 17:07
meh.. west coast usa.

Zabiela
31st January 2007, 19:20
meh.. west coast usa.

200 wifi + 100 atlantic + 100 continental usa + 50 for fun = 450 ping woo!

Knigh7s
31st January 2007, 21:59
I'll test this out on my [Knigh7s] server. But before i do, i will have to check if it is compatable with my event scripts.

[EDIT]: It is currently Loaded! I will keep track of it and test it out later when I get a chance to hop on my gaming PC. But its up to the players whether it stays on the server or not.

Knigh7s
31st January 2007, 23:28
server updated. I think I had the beta1.3 running at one point but went back because of lag and disconnection issues, but we will see.

Knigh7s
1st February 2007, 00:28
off


Ok, I think there is a glitch in the highest weight selection method. I will be checking it out, but you may want to turn it off. To turn it off edit the script config block, setting mws_enable_highest to 0. Everything else seems to be working great. I'm going to add some more features and fix the glitch ASAP tomorrow.

Knigh7s
1st February 2007, 04:37
you might want to check into unloading or reseting the system every x number of rounds, and or make sure it completely unloads everything at a "map" change.

Check your "Block ***_weight" (restore,resets and/or save)

also, i noticed you have block unload, but the only command there is an echo. What is it actually unloading?

Zabiela
1st February 2007, 19:48
I'll test this out on my [Knigh7s] server.

The forum is full of good news today... score! Thanks angel.

Knigh7s
2nd February 2007, 00:45
Alright Server has been updated with 1.1 and is running the default settings.

Knigh7s
2nd February 2007, 23:40
to streamline the speed of the script look into using es_xsetinfo instead of es_setinfo. "es_xsetinfo is a variation of this command that does not expand variables (which can be faster in some cases)" also check here (http://www.eventscripts.com/pages/Es). all the script gurus use the xsetinfo in their config variables.

Knigh7s
7th February 2007, 22:49
[Knigh7s] GamerLobby.net Server has been updated with 1.2!

Paegus
8th February 2007, 21:48
have you looked into preserving weights across map changes and reconnects at all?

say whenever the hidden is picked it dumps a file containing timestamp, steamid and weight so on a map change it'll pick up were it left off with the available players. if a slower player connects late then they re-enter the pool and carry on from there.

the timestamp is there so their weighting expires after however long.

i know it's not really that big of a deal but it's an exercise of the brain... assuming the eventscripts can even write files that is...

complaints about "but then the first high weighter gets stuck play vs 1 guy" can go jump in a bucket of hdn_jointim 30~45

Ging
8th February 2007, 22:31
Weighting certainly shouldn't carry over from map to map - having it across rounds is enough to throw the balance out.

Paegus
8th February 2007, 22:55
how exactly does it throw the balance out? as is it's just a glorified random mode minus the simple pleasure of those things players sometimes do that vaguely resemble cooperative team work...

Ging
9th February 2007, 00:45
You keep saying it throws off the balance, but it sounds like you haven't even tried it. So how do you know? Please explain.

I have tried it - I spent a while playing on knights with it during the week, I mentioned that elsewhere when I was discussing my view on these scripts.

The weighting works by providing a fair (disregarding individual player skill, which we just can't factor in without punishing people for being good) selection method from round to round - carrying weighting over (even in the form of extra health, which is a whole different world of crap) spoils the 'fairness' of the next round by providing players with an advantage from the off...

Continuing that advantage across map changes (which is when the majority of players that are going to leave, will leave - opening space for players without a prior weighting bonus to join in the interim) further spoils it - if only because a new map should be a new and clear playing field, without bits and pieces left over from the previous game.

Knigh7s
9th February 2007, 05:13
Continuing that advantage across map changes (which is when the majority of players that are going to leave, will leave - opening space for players without a prior weighting bonus to join in the interim) further spoils it - if only because a new map should be a new and clear playing field, without bits and pieces left over from the previous game.

Most understandable on that part, I think that is going to be fixed.


nor is it particularly fun to see consistent 60~70% chances and not get the hidden round after round after round only to get it eventually on a 5% chance and have some prat moan to you about how he should have got it on his bloody 90%

This is the main reason why i like this script! And that it announces in the chat area so I dont have to constantly hit the "~" at death. Call me lazy! hehe

[EDIT]: The almighty Ging played on my server! wait, which one? So many Gings!!! J/K

Ion67
10th February 2007, 06:20
It was a good idea initially, but I think it has gone to far. We do not need so many modes of selection. The newest "proximity meter" or whatever it is will not promote team play anymore, they will do the same thing as before, except now they may camp together.

Ging
10th February 2007, 10:53
Anyway, the idea is to reward teamplay. And of course it would be relative to the number of people alive, so when its down to 1 or 2 guys, they don't rack up tons of points. The amount of points would be configurable, but should probably only add up to a max of something like 25 points or so in a round. Anyway, your ideas are welcome on this, including scrapping the entire thing (Ging).

We actually discussed doing something similar to this when we first started talking about the weighting selection method - but we never implemented it as we weren't convinced by how much it would reward teamplay over a group of guys camping. (the difference is hard to figure out!)

Paegus
10th February 2007, 13:31
how about...

group classes:
4 = 1 IRIS player, 0% bonus rate
3 = 25% of IRIS players alive at round start, 25% bonus rate
2 = 50% of IRIS, 50% bonus rate
1 = 100% of IRIS, 100% bonus rate

ex:
if the round starts with 6 iris and they split up into 2 groups of 4 and 2 then you have 1 class 2 and 1 class 3 group. if they split up into 2 groups of 3 then you get 2 class 2 groups.

if there are less than 3 iris the just return 0 already and skip the whole thing because there's no point. any groups formed will contain all players so points will be awarded evenly to everyone rendering them useless.


poll each player's coords
see how far they are away from every other player
add one point to their highest qualifying group class hit count
loop through their previous positions (3 or 4 tops i'd say)
if their current_position is within camper_radius from their current_position-n then subtract 1/n points from their current group class hit count.

and at the end of the round...
player[i].weight = player[i].weight + ((player[i].class_1_group_count * class_1_rate) + (player[i].class_2_group_count * class_2_rate) + (player[i].class_3_group_count * class_3_rate) * (max_team_play_points / scans_per_round))

Ging
10th February 2007, 17:18
Like Paegus says, you can make sure they are moving.

I can assure you - we considered pretty much every aspect of it and just felt it wouldn't add enough to the weighting system to make it worth while.

Paegus
10th February 2007, 18:09
add one point to their highest qualifying group class hit count
only the highest group gets the point. sub groups, be they the player's intended group or not are of course ignored.

if group_class < 4 {
if group_class < 3 {
if group_class < 2 {
//it's a class 1 group
player[i].teamplaybonus++ = group_class_1_rate;
} else {
//it's a class 2 group
player[i].teamplaybonus++ = group_class_2_rate;
}
} else {
//it's a class 3 group
player[i].teamplaybonus++ = group_class_3_rate;
}

//class is higher than 4 so do group related activities
}

//class 4, nothing to do... do we really care if a loner camp?

i was looking at it thinking that the groups would be entirely virtual. each player is the centre of his own group of whatever class. the more players near him the higher his class gets. though there is a valid point to using actual groups in that if the whole group is camping but the members are changing positions.

personally i wouldn't bother over-thinking it at this point. the group radius would be just inside the radar range. you want it close enough to be useful and prevent as much 'passing by on the other side of the wall' as possible. but you don't want it too close because another term for "tight grouping" is "pipebomb magnet".

f a player is considered to be camping then based on his group class you can theorize what other players are doing. a class 0 grouped camper means that everyone else within group range of him probably is as well and if they are scan after scan then they will also be being penalized accordingly. if they're orbiting then their positions may leave their previous camp-zone but they'll be in it again soon enough (hence the history scan). and by orbiting they're placing themselves at a disadvantage in that they wont see the hidden as easily as a stationary person. you can have several camper ranges as well. high, medium and low. high effects the full penalty medium and low imply some movement so you can scale it back accordingly.

i'd actually thought briefly about just stacking all the coordinate data in a nice 5d array and do a lump job on it when the round ends so any lag spikes are harmless. but depending on the round time and scan frequency that could get kinda a tad heavy. if you have all that data though you can map the coordinates, define zones around each one and see how often which ones intersect and for how many scans. you could then do all the math and group function when the round ends instead of in dribs and drabs.

Ging
10th February 2007, 18:46
To avoid the factor of standing on the opposite side of the wall - we were going to just fire tracelines at each player within the radius and see if there was an object / wall that got in the way at head height (implying that you could see the player)...

I'm not sure how feasible a similar solution would be via event script however.

Paegus
10th February 2007, 18:58
i'm going on the assumption that no such tracing could be done script-side as it wasn't when i last messed with server scripting in cs 1.5~6. though it may well be possible now.


I was thinking the highest group a person is in is his group, but seperate groups still get points for their class. For example, a small flanking group shouldn't be ignored because they aren't the largest. Their group is serving a tactical purpose.

yeah that's the way i went. each player's bonus would be product of what group they're in in a given scan. if they are in the high class group then they're simultaneously in any number of lower-class groups so just assume they're in the highest class group available. their weight bonus is just the bonus rate points they've acquired times the points per scan. if your on the outskirts of the main group then you're still in a group with whoever is in range of you. you won't get the full point that scan but you won't get nothing...
the camp multiplier directly effects the overall fraction of a point you'd have receiving for that scan. if you're stationary you'll get some piddly wee bonus

Knigh7s
12th February 2007, 07:01
how about...

group classes:
4 = 1 IRIS player, 0% bonus rate
3 = 25% of IRIS players alive at round start, 25% bonus rate
2 = 50% of IRIS, 50% bonus rate
1 = 100% of IRIS, 100% bonus rate

ex:
if the round starts with 6 iris and they split up into 2 groups of 4 and 2 then you have 1 class 2 and 1 class 3 group. if they split up into 2 groups of 3 then you get 2 class 2 groups.

if there are less than 3 iris the just return 0 already and skip the whole thing because there's no point. any groups formed will contain all players so points will be awarded evenly to everyone rendering them useless.


poll each player's coords
see how far they are away from every other player
add one point to their highest qualifying group class hit count
loop through their previous positions (3 or 4 tops i'd say)
if their current_position is within camper_radius from their current_position-n then subtract 1/n points from their current group class hit count.

and at the end of the round...
player[i].weight = player[i].weight + ((player[i].class_1_group_count * class_1_rate) + (player[i].class_2_group_count * class_2_rate) + (player[i].class_3_group_count * class_3_rate) * (max_team_play_points / scans_per_round))

My brain just fried!!! LoL

Well I can see there has been alot of discussions going on here. Everything sounds pretty interesting :) can't wait for the update on your script so we can have a little test scrim again?!

Cheesey
15th March 2007, 11:16
Wow, I almost overslept the best inventions :)! thank you for that nice tool, I'll test it as soon as possible! I love the idea! :)

Cheesey
16th March 2007, 08:12
I've already vistied it! (It's in your sig ;) )

some sound nice, some just unnecessary... I'll take a look on them ;) Don't worry..