[HL] netcode & fps bug

[izOzi]

Please fix HL Netcode, update vac and remove the Speed diffrence with diffrent FPS this example will cause a intern and Legal SPEEDHACK in half-life, 125 should be the Max (for smoothness)

developer 1 fps_max 200 - 250 - 333.3333 (much faster weapon shoot + movement, if you only use 199 or 249 fps its like slowmotion) fps_modem 0

Time of shooting a full MP5 clip (lowline is fast, numbers is FPS & speed) http://www39.zippyshare.com/v/65613607/file.html

AdrenalineGamer (HLDM for Teams) There is still a worldwide community for this 15years old game we have 4 leagues and diffrent tournements in 2013 Players from africa, south america, turkyie and russia get steam for AG/HLDM they buy good pcs to be competive with us and with good pcs they buy new valve games Please give us a update or the tools to make it ourself!

Please only serious comments

[AnAkkk]

fps_modem no longer exists and developer is no longer needed to get over 100 FPS. I wouldn't call changing FPS a "speedhack". Yes, all physics depend on the FPS, and the times to shoot, move, jump, etc will be slightly different depending on your FPS. Maybe it could be changed to be non FPS dependant, but I guess all the shooting times/spread etc would need to be recalculated, as the default ones are probably calculated for the old default fps_max of 72. If this was to be fixed, people would probably feel that the game is different as they're used to play with fps_max 100.

[dagla]

Well this is probably some weird kink of the old engine, but if it gives unfair advantages to players who know some magic numbers where it works differently then something needs to be done, it should not be FPS dependant. Altough at this pont changes like this would probably cause those players who are used to their favourite values to quit the game. I googled that picture and found this page detailing the issue in Russian http://aghl.ru/wiki/index.php?title=%D0%97%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D1%8C_%D1%84%D0%B8%D0%B7%D0%B8%D0%BA%D0%B8_%D0%B2_HL_%D0%BE%D1%82_FPS

[izOzi]

the problem about this fps bug is that some players become unhitable and completly diffrent movement physics its not about to change the old HL just to make it fun to play again and not to make unregistered hits etc

[AnAkkk]

Here's the more detailed report about the problem, in English: http://www.fortress-forever.com/fpsreport/

[LevShisterov]

AnAkIn1 is right about that timings where set for 72fps and game will change if it will be fixed from fps dependence. But most of good players plays on 100 fps at least. I.e. this is a thing you should know if you wish to play well. So may be it will not be so bad to do this game fps independent.

It is easy to remove most noticeable fps dependence about slowing down at "peak fps + 1": [proposed code change] In CL_Move when you fill msec field of usercmd structure you did it so: int msec = (int)(host_frametime * 1000); usercmd->msec = msec;

To avoid fps dependence you should keep the remainder: static double frametime_remider = 0; double dmsec = host_frametime * 1000; int msec = (int)dmsec; frametime_reminder += dmsec - msec; if (frametime_reminder > 1.0) { msec++; frametime_reminder--; } usercmd->msec = msec; [/proposed code change]

About graphs for MP5 shooting - this is a bug in game.dll. It require more code changes then for physics dependence. Bug happen because next shooting time is calculated from current processing gametime and not from the time when shoot actually should happen.

[AnAkkk]

@LevShisterov, do these code changes only fixes the movement speed problem, and wouldn't make any other difference? If it does I guess that would be quite easy to implement.

[LevShisterov]

To be honest I didn't conduct thorough investigation of that change, because in HLDM we all know that we should play on "peak" FPS. That code change fixes movement speed and could slightly change shooting timings. But that will be small compared to how these timings scatter with FPS change. I did small test in HLDM with gauss spin-up. It is has most noticeable change in consuming ammo with FPS change. I.e. on 72 FPS is was designed to eat up 10 uranium ammo. On 250 FPS is eats 11 ammo (I will not describe dependence of this on FPS to be not too complicated in my words). I remember it could be even 12 ammo on some FPS. So gauss spin-up ammo consuming is FPS dependent. I tested gauss spin-up with proposed code change and it still eats 10 ammo on 72 FPS, while movement speed is completely fixed. So there will be no need to adjust timings or something more. By the way if anyone wish to assure that there is FPS dependence in movement - it is easy: install AMXX speedometer plugin and just run forward (W), on standard 72 FPS you will not reach sv_maxspeed, on 71.4285 you will run with sv_maxspeed.

[LevShisterov]

Oh, sorry, you will need not usual speedometer plugin that shows desired speed, but that one that calculates actual speed based on time and moved distance.

[r3n4m3]

izOzi, what are u asking for?

[AnAkkk]

Can be closed I guess, the movement speed has been fixed. There's an other one about crouching here https://github.com/ValveSoftware/halflife/issues/26 and jumping here https://github.com/ValveSoftware/steam-for-linux/issues/1779

[execut4ble]

By the way, not only SMG or movement is affected. The HEV and Health rechargers charge faster too..