1. Bots camp frozen enemies. They stand there until ordered away, see an enemy to attack, or die of camping.
2. You freeze in place, but what you see on your screen is that your view appears to slide sideways.
Any help in fixing these or other issues welcomed.
All the code is visible in the package.
Ok 1# fixed, tested, and on the server - it was a bug in Freon_Trigger.
#2 I think may be a replication issue. I have no idea where to start or how to replicate it. It happens very rarely
Kops reported a problem with the balancer on the Freon server...if people leave and one team gets too few players the balancer moves players across to the smaller team...and they get a big points penalty
For Freon it's kindest to freeze them first with a shot to the head, and then to swap teams so they can be thawed.
The change I put in today is intended to prevent any loss of points when being chosen.
I might tweak it a bit more if needed.
Great work, mate.
there's a bug that's been in quite a while and I tried to fix but unclear how it happens exactly... it looks like a timing issue somehow,..
right click on freon when you're frozen should return the view back to your frozen body,. but it often doesn't do that but instead goes into 3rd person view on the player you're spec-ing,. (the 3rd person view really should only happen on TAM)
oh, btw, about bugs. i don't know how to explain it, but i try. if you killed someone, and that person is frozen, you can push him under a bit closer to a ceiling or torch, or something, whatever.. then, jump on his head and constantly jump on it. if the ceiling is low enough, then the frozen character dies, apparently from pushing under the textures. i killed Magorit like that many times on constructor, by accident.
Thanks. I'll have a look. Is that just since being able to stand on frozen players, or before?
before, when staying on frozen head wasn't avaiable, but if you can stand on them now, then I think it will be easier to do such kill
Hmmm... probably going to need to put some debug output in around the takedamage code and get you to do it and see what is causing that to happen.
It could be 'world damage' which results in death, or perhaps crush or something else
not a bug..,. noticed the thaw speed on serv seems v slow or slower than it was (seems too slow to me!) :)
It should only be slow if they killed themselves... see the other thread of hints and tips
I'm thinking of adding some other indicator so that you can tell.
Normal thaw is set to 5.5 secs / number of thawers. Self kill thaw is one third the speed currently
ah didn't know that,. people might kill themselves by accident and should kill themselves in overtime - either case not sure why slower thawing is a good thing ?
one thing (again not a bug) is on US freon servs HoC/SoL (not sure about eu/core) when ppl thaw they are given either a minimum health value or the health or the person(s) that thawed them or the average of their teams health if they self-thawed,. I think last I noticed on mia it puts their health back to the normal starting health?
Killing yourself in overtime and getting thawed in (5.5/number of thawers) seconds seems to me to be an exploit just as much as freezing yourself into lava for full health.
I've increased the thaw speed on the server in that circumstance to 60%, but that may not be enough of an incentive to gain health by cuddling instead (going close to a higher health teammate)
On the thaw health, I have a vague recollection that this is caused by the talking icon mut.... I've not noticed the thaw health. Necro gives the resd player 100/100 as intended. I've upped the points for doing that
We could try taking that off the mut list and see what happens
Ok so the testing confirmed that it Is this mutator that is somehow interacting in a rather wierd way resulting in the that health you see. It's not clear how or why that happens.
As you can see there are now voting options for having the mutator or not which will result in the two different thawing health outcomes
I've been thinking again about thawing rewards.
Currently, if you are thawing a player at the moment they thaw you get points, adrenaline, and ammo for the gun that you are holding.
You get those rewards regardless of your contribution
If you arrived 1 millisecond before the thaw you get the same rewards as the player who was thawing the whole time.
Conversely, the player who helped the thawee from 0 to 99% and then is fragged or has to run away and isn't thawing right at the moment of thaw gets no reward.
I'm thinking of changing the logic to reward based on actual thaw work done.
I have the outlines of (optional) code in test at the moment.
Thoughts?
none, except those, that, in just mine humble opinion you run ahead of the train. We have some issues with the equalizer, issues with suicides, issues with obstruction of flakery or rocket damage, but you fix some things, and make only those fixes that seems necessary to you, no offense, but somehow strange. fixes for fixes and wrap unnecessary whistlers
In case you don't know what i am talking about - Issues with EQ: yesterday, when we played with teams, people began to leave the winning team, and equalizer was pushed people with a high rate from losing team to winning team, making the game useless and hopeless, Justice[ReZq] was there, I pointed him on that, but i don't know if he said about it to you.
Issues with suicide: this situation is happening to me twice, after fixing mechanics of friendly fire and the ribbons. If i have low health, and shoot at the enemy, and at this very moment a fuckingly quick player flies into my sight - the following situation occurs: I am hitting the teammate, killing him, and get a penalty for teamkill, and a ribbon of a down - suicidal. But! Idiot was not me, that one, the quicky, who got into my scope. And killed teammate thawed normally, and i am stand and wait for the penalty time. Punished for nothing.
And the third one, in my opinion, bug from very beginning - Flak and Rockets sometimes do not hit. Just today, three rockets from alternate rocket fiering flew right in my face and yesterday, a couple of times twas flakery, but i get no damage at all. And it's kind of weird.
I understand that i have no any proof of that, exept equalizer, and i should demorec that things, but i never guess when it suppose to be happened.
No offense, no pretend, just a private opinion of what it would be worth fixing.
This is the sort of very useful information I'm looking for. Thank you.
Let's take each in turn.
1. The equaliser. This is something that isn't part of the game type, and wasn't written by me. It sits outside as an add on to keep the player numbers from being more than one person different. It swaps the latest player who joined the game from the bigger team to the team with 2 players fewer. The only change I've made to the code is to freeze the player who is moved rather than them just dying to 'dead'.
You are saying that this is a problem, and I'm listening. What functionality can you think of which is better if one team has 2 more players than the other?
2. The suicide. I agree with you, there are times when reverse friendly fire gets you...and it's annoying. There are two ways of addressing this.
The first is to change to the other RFF setting. With this on the damage is shared between the two teammates involved. If your teammates shoot you, you are damaged and so are they. This is a problem in a public server as there is always one teammate who spams rockets at you all map long. Actually I'm not sure how this helps!
The other option is to look at the code to see if/how RFF can be seen as not being a suicide.
Unfortunately doing that leaves the game open to abuse as not having a suicide penalty. You can just shoot teammates to get frozen, and they can thaw you in 5.5 seconds to full health.
Note: the current settings for suicide death is that thawing with one player takes 11 seconds, with two it's 5.5 seconds, with three it's 3.6 seconds...so not a massive problem...
3. Dud flak and rockets. This is netcode in the engine. There's nothing that can be done about this by any modding.
If you dont mind, I will not split my post into three.
1. The equalizer itself implies equalization, tuning, adjusting, and it sorts the players by rating or some other reason at the start of the game, so your sarcasm
Quote from: Piglet on January 31, 2019, 16:46You are saying that this is a problem, and I'm listening. What functionality can you think of which is better if one team has 2 more players than the other?
is inappropriate.
Perhaps the rating is bolted for a reason and the equalizer can use its data to make the teams equal?
2. Teamkill should be punished, yes. But, shooting in teammates? it's kinda odd. They get reduce hp, to help me get full? it's really weird. Suicide? Not by that much. Lava selfthaw is not cheating, it is a trick, a dangerous trick, on the verge of suicide and that can fail whole team. Selfkill by overtime if you almost last player is not cheating, this is a trick. You have issues with losing for a smart team, or trcky team? I just do not understand the goal, we are all here to have fun, and not for showing each other the length of our ... aim. Or do we?
3. As far as I know, on CORE, freon does not have a zero ping mutator, and, as far as I know, there are no problems with registering damage from flak or rockets. Can it be relative to this problem?
It wasn't sarcasm. You misunderstood.
The current equaliser is exactly as I specified. It moves the latest joining player from the team with 2 more players to the team with 2 fewer.
There is an option which we are not using 'Auto Balance When New Players Join' which would re-do the teams every time a player joins (and potentially when one leaves). This appears to be what you are suggesting.
Think what would happen... Each time someone joins the entire teams would be shuffled. You'd be moved from team to team ... Is that better than what we have at the moment? This isn't sarcasm, it's a question.
2. You have to remember that what you see on your screen is what your client game has calculated as having happened. The server takes all the input from each connected client machine and decides what actually happened. It can sometimes decide that what your client showed was wrong. This is why you see warping players as the server updates your client on the actual player position.
Where the 'New Net' (From utcomp I think) is switched on the calculations made to determine what happened are changed. I've not looked at the code, but I suspect that it biases the decision about what happened more towards what the high ping client machine calculated than using what the server calculated.
However the calculation is done there will always be times when the final decision about what happened isn't what you saw on your screen when taking information from any client at all. As soon as you give any credence to what happened on clients running 200+ later than the server then it's going to result in significantly noticeable updates.
Or as I put it before.. it's netcode problems. Unless you can get instantaneous communication between the client machines and the server then you have to predict on the client and correct all clients based on what the server decides.
the 3spn balancer option isn't that bad,. it rarely moves the players who are doing well - which keeps things fairly consistent, balance on join doesn't need to happen - people can move themselves if they joined the wrong team (so long as the teams are uneven players) - when someone leaves and that team goes two players down I think the 3spn balancer should be run at that point - moving the last player can make things more uneven
I'm thinking of changing the logic to reward based on actual thaw work done. - SoL did a version like that where they took into account thaw times,. it's on github but I didn't like the way they did it (and it broke the dual thaw distance code)
RFF - ok sure it's annoying when people jump in front but I'd count that as gameplay,. not pointing fingers but on other servers I see ppl complain about this and often they stand behind and in crowds of players shooting crap - so it's partly on them perhaps(!)
on netcode,. it's a fair chunk of work but when void added netcode to 3psn base code he pulling it from utcomp - lock stock and barrel,.. which is fine but the guy who wrote utcomp came back later and said hey I made tons of improvements to netcode in utcomp,.. the 3psn version of netcode is using the previous utcomp version,,
whether it's much better netcode is harder to prove but if you play on a never utcomp server across the pond it feels better than the netcode in 3spn - at least seems fairer
it's a distributed game and whet one player sees is not the same as another - it can't be perfect in a fps because there are network delays - unavoidable
there is a bug that doesn't happen often but it's in all versions of 3psn,.. sometimes you get killed instantly when someone res's you (permadeath) - it seems to be linked to whether you're holding down the fire button when frozen at the point you're res'd you die,.
bugs like that I'm not sure how easy to fix though(!)
btw - this happens on 3psn TAM servers as well so it's not freon specific but in the base code - and I wonder really if the cause is somewhere in the engine code,. but it probably could be coded round - like by adding a check if the player died within a second or two of being res'd (similar to how the timer works at the start of round to stop ppl from killing themselves at round start)
How much effort would it be to replace the netcode from the latest utcomp?
I've not seen the death on thaw
In the current version on the server I've added the option for counting 100 health units of thaw as a thaw, with a bigger reward every 50 and a slightly smaller one at each 100. It's not been tried out apart from on my test server - and it's not currently active on the Mia server. I might turn it on at some point over an evening to see how it goes. It counts all the partial thaws...
yeah - it only happens on a res,. think if you try holding down the fire button you might see it - most ppl don't do that - but if you die and are res'd quickly it does happen
utcomp netcode change probably 5-10 hours,. it's just copying the right parts of the utcomp across / over the top of the existing,. 3210cw and onwards the netcode is sort of inside 3spn but in separate files so it's mostly just copying those over the top (and perhaps slight tweaks!)
Any idea where to get hold of the latest utcomp code?
I'll email it you :)
Thanks. Got it.
I've fixed Kop's issue today. Code tested out ok, but hasn't got to the server yet.
1. If you can't use an adrenaline pickup, you can't pick it up. Before you could pick it up but it didn't help you. Health and Sheild pickups already worked this way, but adren was different.
2. Now you get a message when you can't pick up a pickup similar to the one you get when you do pickup.
"You can't pick up more health"
"You can't pick up more sheild"
"You can't pick up more adrenaline"
nicely done.
Well, I tried with the utcomp 1.7a code....and tried with a few helpers. It feels awful.
I may have completely messed up the port - but I don't think anything I did is likely to have made any problematic changes to the logic which weren't already there.
You can try from yourself (from the link in the next post)
I'll leave that server running for a few hours if anyone's interested in seeing how bad it feels!
OK - will leave it available for people to look at here. (https://miasma.org/images/3SPNvPigletTest_utcomp1.7a.zip)
I don't see it as being worth any more time invested in it.
Link fixed
you may be interested in this:
timecodes are 2:33 (https://www.youtube.com/watch?v=7GBoU8TNYvA&feature=youtu.be&t=153) and 3:42 (https://youtu.be/7GBoU8TNYvA?t=223)
there was some more. but i can't remember timeline.
Now it is easier to do this, before it was necessary to find a certain height, so that it was enough for a frozen body, and for a jump on the head, and also not enough, to fit in both. There is such a place in the constructor2006, in the rankin, under the bridge to the third level, and in many other maps.
fixed. not 4-42, 3-42
Hmmm. Interesting. Do you know what damage type is registered when that happens? I'd need to know how to differentiate that from other damage
i believe that works like telefrag. While it was impossible to stand on their frozen heads, I thought that what was happening an infiltration in their bodies by multiple jumps due to limited space.
Hmmm - can you try it again and let me know if you can still do it?
I've added some code and a little debug but can't test without willing people to do it.
[edit] that didn't work - will have to put more debug in[/edit]
Aha! By George I've got it.
Fix now on the server. Just in case there are any unexpected side effects to the fix it's admin configurable on/off.
This should also fix the occasional random telefrags...
Hey Pig. Have roxx been nerfed? Noticed over the last few games even 3 or 4 solid hits will not kill a full-health player.
No. No change. If you want I can add in the mutator that shows the damage caused if you want to do a test
Ah ok - must be my tired aiming then. No need for the damage mut, mate. Cheers.
quick one and perhaps it's just me (and I can live with it either way)
there's a lot of cool maps on the freon server,. and sure people want and enjoy playing the classics but I wonder could the map vote exclusion limit be higher,. I think it's set to 4 or 5 and the same maps keep getting picked,. could be higher and give more chance for less played maps? :)
Sure. Was 4, now 7. Is this too high or not high enough?
Are there good maps we're missing?
We have limited health thawing and the bug-caused full health thaw both voteable. I've seen both in use so not sure how much people care which they get
right most people don't care / notice the difference on how health is on thaws,. it's subtle and really only matters in overtime but also it comes into play if you're using Challenge Mode to help stop one team getting ahead too much (I think Challenge Mode is set on?)
thanks! 7 sounds good - will see :)
maps missing,. soo many... will mention three,. murk is a good thawing map and is good for more players,. moongames is a fun map 4v4,. shred is a good 2v2 / 3v3 map
actually there's a fair few decent maps that work for more players,. onion is good one for a fuller server
Hmmm repeat limit isn't sticking. Will sort it out next time I see the server empty
Linkies for maps? (I have the onion. Not sure which version to grab. Will load "DM-TheOnionLE" - not that I can see the difference)
cool - will load it up :)
have sent you a message w/ a mappack - I think that should have most of them in it(!)
Thanks. Will have a look later
Questions from h-duke, with answers from me for discussion:
One Thing is: no break or delay, when a round Ends
There are deliberately two different end of round delays. The first is after the last player dies but before damage is turned off. This is to allow any draw to be registered...for example where the bio of the last killed ends up killing the killer. It also allows for pushing frozen players into lava and them to thaw. This is deliberately left in the game.
The other delay is after the damage stops and allows you to kill frozen players... for the humiliation factor!
Lttle more time, Maybe 1 or 2 minutes when a new match starts.....
Hmmm I can increase the start time, but wouldn't want it too long. People don't want to sit about waiting... what problem do you see?
h-duke
Is it possible to Change a Setting? I like this info About dominating and owning someone 😊
I think there's a revenge mod. It is worth a try out.
And u know the Thing About the thawsettings 😉 (because i wanna know what s said if i thawed 50 guys. I know 40 is incinerator 😊)
All the code and sounds are in the download you get from the server. You can look if you like.
I've been planning to change the sounds and make thrm a little more configurable by the admin, as it's hard to get to 30 even when counting 100 health given as one whole thaw
Will put this in the Freon foru
one thing I do notice is the game start delay is shorter than most servers,. so the ready up time (or whatever it is) means when one map ends and the next map starts sometimes if I have to download a map the game has started before I join,. could that delay be a little longer (additional 20 seconds?) - ok I know I could turn the map cache to never empty but.... :)
Ok. I've upped the net start delay to 30. Let's see how that feels
cool, thanks! :)
Vendetta mod added today... without the icons. Let's see how it goes
At the start of a new game, if a balancing bot joins, the first round has started before the bot has a chance to join so it joins dead.
Quote from: Piglet on March 08, 2019, 10:49
Vendetta mod added today... without the icons. Let's see how it goes
Vendetta is nice.
I would vote for few zounds. Not a billion of them, but just the common and short ones: Hi / hello, some lols and byes
Even if some people dislike zounds, they can still disable them. but most of people love them.
let's give them a try. I can make some great and funny packs.
I absolutely hate zounds... hate hate hate...
If minimal then maybe, but...
What colour are the Vendetta messages from other people's events?
purple i think
I was trying to get rid of the yellow ones, but didn't get it right.
map exclusion list is 7 - perhaps it could be higher,. like a couple more and see,. I guess if you come in to play one or two games you want to play rankin or whatever but...
on the https://www.gametracker.com/server_info/31.186.250.19:5777/ shows every 10 games is rankin (it's probably more since there are 2 versions)., but a lot of cool maps never get voted :)
Maybe have to code in contrast every 4 :P
I'm in a really grumpy mood today. 2 bad night's sleeps - and every game I go into there's some unkillable pro against me and a team of wall-shooters
ya - as soon as there's 2 difficult to kill players on one side and none of the other it gets difficult,. thing is their ppr wasn't really going up quick enough,. can the balance thingy be set to take into account some of the 'game ppr' - I think you said it was currently on 100% average ppr but some game ppr in there might help (or might not) :)
I'm wondering whether thawing is giving too many points.
I'm 12.5ppr but can't hope to kill those top fraggers. They need to be kept separate somehow.
Any code/thoughts would be appreciated
the problem is balance,. if there's one A player on a side and none on the other it should balance,. two A players one side (and none on the other) and it is much harder,.
I didn't notice their ppr but they were on the same side and avg ppr doesn't move quick enough to offset that,. the amount of damage/kills should have pushed their game ppr up and then run the balancer it should put them on different sides
thaw's for 10 points used to be how it was set on SoL and HoC and it mostly balanced fine,. with partial thawing points I don't know how the points are allocated between time thawing and total thaw etc
SoLToolz is really a handy thing for admin to use,. it allows all kinds of handy things,. force rez and moving players between teams,. we could have offset those players by moving the C players to their side so you have more B players on the other,. it's point+click easy,. you look at the escape menu and you have buttons to switch players (and other stuff like whois type things)
it's really an edge case but the work 1/2 exists in 3spn
if you go to spec and rejoin you retain your points,. that is also the case in some situations if your connection drops and you reconnect to the server,. you keep your points
what isn't done,. you loose your adren in both cases,. ideally it should be re-applied the same way points are kept
ok,. it's the kind of thing most don't notice and no drama either way but will put here so it's listed at least :)
Do you need the latest code to look at fixing that?
Another thing that needs looking at is the balancer and what happens when a player joins mid round. If there is a bot playing they get kicked out..even though the new player is waiting to spawn at the start of the next round...or a res.
I've seen a round lost as the last player unfrozen is the bot that got kicked as it thawed
The code should be more aware of this and only kick the bot if the new player actually starts to play
Hello !
I don't think this is very important thing but... today I played vs bots only on freon, it was Check Maze_b2 map, bots were totally confused, they just stood all the time and did nothing until they saw me or my bot teammate. One round I was moving near spawn place and both bots' "tent colapsed" cuz they were camping all the time... it never happened on any other map I've played so maybe it was some disposable glitch.
Nice server btw, keep it up ;)
Thanks. Welcome to the forum. I hope to see you on the server one evening.
They will be doing that because the map can't be properly bot-pathed. I'm not a mapper - I can hack other people's a bit, but rely on others for that sort of thing
weird one just now,. playing there were like 4 frozen players our side and 1 live,. they tried to stand thaw a frozen bot - moved back and used res and the res picked the frozen bot,. that shouldn't happen (never seen that before - real players should always be picked unless there's only a bot froze) ?
I've always seen it pick a player rather than bot.
The code tries to pick only players which are not actively being thawed. Maybe the bot was the only team member not actively being thawed.
naa,. was only one player our side alive,. I don't think the froze players were even near each other (in case it's counting touching froze as thawing - unlikely)
Well I've checked the code, and it doesn't discriminate between human players and bot players.
It could!
It works through all the players (bot or not) that are dead or frozen
...checking which of the players being actively thawed was res'd most long ago
...checking which of the players not being actively thawed was res'd most long ago
at the end,
...if it found a dead/frozen player not being actively thawed that's the one to res (if time tied then it's a random one from the same time longest ago)
...if it didn't find a dead/frozen player not being actively thawed, then if it found one being actively thawed that's the one to res
..otherwise abort the res as nobody is dead or frozen.
that is weird,. I would have guessed it would have tried not to res a bot, preferring a real player,. though not looked at the code in a long time I guess I thought it 'must' do that as I don't recall seeing a bot get res'd before the other day,.
Probably because bots get added after players so all players have an earlier time of last res than any bot, if that starts initially as the join time the all the humans before it would consider a bot.
However, it wouldn't be a vast amount of work to make it work like this:
1. Human not being thawed
2. Human being thawed
3. Bot not being thawed
4. Bot being thawed
I did also wonder whether dead players should get priority over frozen ones
Bump
From hagis
yeah - dead before frozen,. possibly it should,. have to consider whether newly joined players are technically dead would end being brought into the game before the next round (realise that happens already by random chance)
I think they would.
I'll have to look at the code when I have a chance
server is getting busy at times which is cool but I think ppl are sitting in spec slots when they aren't ready to play
is possible to add a couple more spec slots and or kick people from spec on map change or something,. not sure but noticed people even when the server wasn't full were sat in spec through multiple map changes
Any idea what to add to the code to kick them? Is there an "about to change maps" event we can extend?
there's a game / map start section,.. it does things like set up the team colours and stuff,.. umm might be in team base I think
don't know if kicking specs every map change is a good idea,. but not sure what other way there is to stop people holding slots all the time (or through multiple maps w/o joining even when there is space)
I guess another way would be timer running for each spec slot,. if they held it for more than 20 mins or something just kick,. ok some games are longer than 20 mins but they can always rejoin if they actually specing
are you able to see in code if a player is watching a player or it's in free cam mode.
If yes, boot them when 3 min free cam mode.
or see clanmanager -> AFK-Detector
yeah - I don't know anything about that mutator but perhaps it might be useful?
ok,. perhaps it's just me that find it annoying,. u want to play a game,. server is full that's cool if ppl are playing but to it irks me that ppl hold spec slots just because and they aren't joining when there is space which stops others joining to spec who do wish to play
Just kick them with a message :)
I've been trying to extend Serverext slot manager as I've done in the past and I'm getting GPF's when compiling. No idea why
just to see I was in spec earlier and teamsay (spec) asking if people were there,. in the end I kicked 4 specs - only 1 rejoined after 10 mins or something
The code current running on the server is a first cut of allowing players more than 100 adrenaline.
The code isn't complete, but needed some people playing it to be able to test it.
Functionality changes:
1. Configurable adrenaline reward for resurrection in Freon. Currently set to zero.
2. Configurable max adrenaline, currently set to 120.
3. White message and small 'unlock' click at 100 adrenaline and after every (configurable) 5 changes in adrenaline resulting in you having over 100. It's a non-intrusive nag to use adrenaline. It's probably too subtle.
Bugs known:
If you are frozen the HUD shows 100 adren max. I'll fix that when I get a moment.
Bug fixed.
Tempted to use these as Adrenaline Nags (not really): https://www.soundboard.com/sb/DOIT
first reminder: YES U CAN
then: JUST DO IT
then: DO IT
then: NO wut are u w8ting for
https://www.youtube.com/watch?v=10DQeSk1LaY
Heh! Any sensible suggestions welcome.
I'd have the 'adreniline full' message trigger at 100, then repeat every 2 mins or so until used, regardless of whether it's at 100 or 120.
OK - I have something better working now. I'll pop it on the server when I see it less busy.
Hopefully a little more obvious, but not too intrusive. Nag time is configurable...
I don't know if I've imagined it - but I think I noticed the adrenaline icon / pill top right flashing when adren was a 0 - I think it only flashed before when full (possibly!) :)
I can't think of any reason for that. I've not changed the HUD code other than in how it computes the adrenaline number to show (CalculateEnergy()).
Then again....who has zero adren for long....? :P
Quote from: Piglet on September 06, 2019, 00:11
OK - I have something better working now. I'll pop it on the server when I see it less busy.
Hopefully a little more obvious, but not too intrusive. Nag time is configurable...
Seems to be working well. Not too intrusive...
Not intrusive enough for some players...
Pushing enemies in lava to try and kill them. It's getting out of hand on some maps with teams losing several rounds because a couple of eejits are unsuccessfully trying to rack up their ppr with extra kills rather than thawing. It's like having enemy agents on your own team!
On a side note, self-thawing speed seems 1.5x faster?
No changes in thaw speed (90 game seconds)...maybe we're just getting older.
For those who are interested, these are the current settings (there are a lot to choose from as I like making things configurable where I can):
(https://miasma.rocks/images/settings_3spn.jpg)
(https://miasma.rocks/images/settings_freon.jpg)
(https://miasma.rocks/images/settings_necro.jpg)
Can you remove the arenaline announcement or make it an option to toggle?
I have announcements turned off entirely in the game for streaming purposes.
As well it does not make use of the players chosen announcer.
What's the setting you use to do that?
It can't use chosen announcer as they don't all have that sound.
Ahh found it
I may add something to be really rude to players who never use adren though
I agree on it being annoying when people do not res. Especially when it are the few who always tend to neglect, but I don't see any reason to annoy the hell out of everybody neglecting their settings and preferations.
I that much prefer to have it disabled for myself that i would never play again if it stayed enabled.
From a tactical point of view you do not have to res either as some people are just that much better. Those people should boost for the benefit of the team. Dawkins used to show that over and over again getting over 60 ppr boosting and saving the team often.
it's been a long time since I looked at the code but to mention,. it's a little obscure
the idea of using some game PPR against historic PPR is a good idea but I've a feeling it's sort of broken,. so team is winning already then A player joins that team,. people type teams because the balance got worse,. except the new player hasn't played a round,. so their 'game PPR' is 0,. really people should wait at least a round perhaps but using any 'game PPR' only makes sense when that player has played more than one round
Hmm - so 100 in "Auto Balance Avg VS Current PPR Weight (Percent)" might work better?
well,. I think you want some game ppr,. players under or over perform some games and it's good to try and account for that,. how much I don't know,. at a guess 20 or 30% game ppr perhaps (who knows!) :)
well - it was 80....before you said that...
cool,. my eyesight,. I couldn't tell (thought it said 50) :)
Quote from: hagis on September 06, 2019, 16:45
I don't know if I've imagined it - but I think I noticed the adrenaline icon / pill top right flashing when adren was a 0 - I think it only flashed before when full (possibly!) :)
Ah yes...found it. Will upload a fix when the server is empty.
Fix added early this morning. Adrenaline should now flash from 100
Also added random map vote and a webadmin fix while the server was down
nice,. it's weird I don't often notice the flashing pill at 100 adren or whatever but I did notice it more when it was 0 - I guess before match starts you're not so focused on someone trying to kill you :)
It was a good spot, thanks. I'd simplified the logic, missing that one variable was used to trigger flashing when == max adren. I've changed the flashing now to happen when adren >= necro combo amount (100) instead
not a bug or an issue for most I suspect but I do notice the same 5-10 maps basically played in rotation,. that seems to happen more on mia freon than I noticed on other servers
options
increase the exclusion count - it's simple to change
have map lists,. SoL and HoC use maplists,. on SoL they have (or used to have) different map lists depending,. so 'prime time' when the server is busy has larger maps and less smaller maps,. HoC rotates map lists every 2-3 months (some popular maps are in every list like koden)
switch out the most played maps (e.g. campgrounds) for other version so at least it's different,. the campground on HoC is better suited to full server and plays nice
leave as it is,. I should play less :)
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";
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 :)
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
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)
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.
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)
Is there? I don't know that one...which is why we have the external balancer
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
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.
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 :D
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
That's fair enough :)
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.
A shorter round end delay might help this i would of thought, once that last kill is landed its round over in my brain. :)
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 :(
Not sure how lava thaw behavior is in code, but you could just add an internal counter for each lava thaw, give less hp for each consecutive thaw but reset on actual thaw.
It could also kill someone after 2 lava thaws
Quote from: Piglet on November 25, 2019, 15:31
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 :(
not making work for you (I'd just limit the maps that have lava on them!) but the self freeze into lava is already done,.
instead of working out if the push killed can check instead who pushed for the thaw into lava,. could basically check if enemy team does a lava thaw then deduct health from the player who did the push or something...
Want to have a look at the code?
I'm not sure the last update around auto team balance on join worked...
hey pigs,. you remember when people were joining in spec with and it was causing the balancer to be called,. I think that is happening now again,.
match was full slots and no one called teams but balancer got called and only thing I noticed was someone joined spec?
Heh. Can you see why? I thought I fixed that
LATEST PIGSPN
WHEN DEMOING I GET THE FOLLOWING EXCEPTION, DOES NOT HAPPEN INSTANTLY BUT ONLY AFTER A FEW MOMENTS OF DEMORECCING HAS BEEN DONE
General protection fault!
History: AActor::ProcessDemoRecFunction <- (Freon_Player/Function Engine.Controller.ClientSwitchToBestWeapon) <- AActor::ProcessRemoteFunction <- (Function Engine.Controller.ClientSwitchToBestWeapon) <- UObject::ProcessEvent <- (Freon_Player DM-PipeWorks][-Night.Freon_Player, Function Engine.Controller.ClientSwitchToBestWeapon) <- RemoteCall <- HandleStream <- UActorChannel::ReceivedBunch <- (Actor Freon_Player) <- UChannel::ReceivedSequencedBunch <- Direct <- UChannel::ReceivedRawBunch <- DispatchDataToChannel <- BunchData <- UNetConnection::ReceivedPacket <- UNetConnection::ReceivedRawPacket <- UTcpNetDriver::TickDispatch <- UpdatePreNet <- ULevel::Tick <- (NetMode=3) <- TickLevel <- UGameEngine::Tick <- Level DM-Pipeworks][-Night <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free
Please can you try running the prime95 torture test on your machine? That looks like a hardware memory problem to me.