Freon bugs and issues to look at....

[Piglet]

The repeat limit is currently 7.

The map vote code here is custom - so we can change it however makes most sense.

I think the code has logic in it to modify the maplist depending on the number of players. Do you know how to set that up to prevent small/very large maps getting voted at the wrong time? class MapLimits3SPNCW

ahh - it's config - e.g.

MapLimits(0)="DM-Rankin?0?999";

[hagis]

to be fair - it it's rare to see very small maps get voted when there's lots of players,. it's more would be nice to see more variety in the played maps,. how to make that happen I don't know,.

I don't know (or think) this is even possible,. but as an idea,.

say there's a map that should get played more,.  whether that map could be automatically voted (providing it hasn't been played recently) so it was in the voted list with say 4 votes,. that way it doesn't have to be picked but it would get a 'push'

well I'm sure that's not a perfect solution and perhaps not even possible but there must be ways to get people out of  their comfort zone picking same maps

[Piglet]

If you're interested in pursuing something like that it can always be added into the code - either into the local vote code here or in the base freon

I'm still wondering whether to add the team balancer code into the Freon package so it can be entirely native and not running as a separate thing

[hagis]

freon already has balancer code,. I'm not sure what the separate process does extra tbh,.  I see it kick in when someone leaves the team with the least players but I think that's not needed

in the sense normal situation the server will anyway move a player from the team with extra (I know it doesn't happen like that on core but I don't know why - it happens fine on other servers so I'm not sure what's different)

[Piglet]

The extra is the bit that balances the team numbers

I added optional automatic balance whenever any player over a configurable PPR joins or leaves.

[hagis]

yep - the part that balances team numbers - I think there's a server setting or other setting that makes that happen anyway (at least I've only seen the problem happen on core)

[Piglet]

Is there? I don't know that one...which is why we have the external balancer

[hagis]

I think the autobalancer is not quite right,. at least I think this is happening

so logic is player over 'n' ppr joins and the autobalance gets called - that's fine

however the definition of 'join' - it seems to be taking into account the players joining in spec - so even on a full server when specs join it calls the balancer - even though the in game players is the same

[Piglet]

Ah - yes. I didn't think of that. Can you spot where to make the check better than where it is now?

misc_player.uc

I'll copy the test from function LoadPlayerDataStats() to function BecomeActivePlayer() - and then add in "if( !PlayerReplicationInfo.bOnlySpectator && ..." to the test in the LoadPlayerDataStats()

That should not trigger in the first place if stats arrive when spectating, and trigger if player moves to player from spec.

[THOR`]

Would it be possible to shorten the end of round delay and increase the start of round delay to compensate? seems difficult to determine when the last player is killed and the round is over as the end of round announcement takes a while and with the player count being so high it's not always obvious that the last player is dead.

It's a small thing but I find I end up running around for longer than I should at the end of the round which leaves less time relaxing my poor old hands

[Piglet]

Hi Thor, the end of round delay is configured deliberately - in case of draw or thaw in lava or picking up adrenaline pickups, or just making piles of enemy icicles, but I've not thought much about starting time. I'll have a ponder

[THOR`]

That's fair enough

[kops]

Is there any way to stop lava thawing after the last enemy player has been killed? It just takes one member of the team, once a round has been won, to play silly buggers and push a couple of enemy into the lava. All of a sudden a round you thought was over is now revived again, just because of someone trying to boost their ppr.

[THOR`]

A shorter round end delay might help this i would of thought, once that last kill is landed its round over in my brain.

[Piglet]

Me too - but this gives time for the killed player to fall into lava and thaw.

I did try and write something to stop it - but it didn't work in testing so I removed it all. A change to understand whether the last push was the killing one or not would require careful coding. I don't currently have much time