NPCs change yaw more slowly when game is running at higher FPS

[SamVanheer]

When the game is running at a higher FPS NPC yaw speed is slower. This happens because yaw speed is multiplied by the engine's frametime, but the AI think logic only runs 10 times a second at most. As a result NPCs turn slower the higher the FPS is, and faster the lower it is.

To fix this the yaw change logic needs to track how much time has passed since the last yaw change time:

halflife/dlls/monsters.cpp

Lines 2529 to 2581 in c76dd53

	//=========================================================
	// Changeyaw - turns a monster towards its ideal_yaw
	//=========================================================
	float CBaseMonster::ChangeYaw ( int yawSpeed )
	{
	float ideal, current, move, speed;
	current = UTIL_AngleMod( pev->angles.y );
	ideal = pev->ideal_yaw;
	if (current != ideal)
	{
	speed = (float)yawSpeed * gpGlobals->frametime * 10;
	move = ideal - current;
	if (ideal > current)
	{
	if (move >= 180)
	move = move - 360;
	}
	else
	{
	if (move <= -180)
	move = move + 360;
	}
	if (move > 0)
	{// turning to the monster's left
	if (move > speed)
	move = speed;
	}
	else
	{// turning to the monster's right
	if (move < -speed)
	move = -speed;
	}
	pev->angles.y = UTIL_AngleMod (current + move);
	// turn head in desired direction only if they have a turnable head
	if (m_afCapability & bits_CAP_TURN_HEAD)
	{
	float yaw = pev->ideal_yaw - pev->angles.y;
	if (yaw > 180) yaw -= 360;
	if (yaw < -180) yaw += 360;
	// yaw *= 0.8;
	SetBoneController( 0, yaw );
	}
	}
	else
	move = 0;
	return move;
	}

This should be modified to work like this:

//speed = (float)yawSpeed * gpGlobals->frametime * 10;

float delta = gpGlobals->time - m_flLastYawTime;

//Clamp delta like the engine does with frametime
if( delta > 0.25 )
	delta = 0.25;

speed = ( float ) yawSpeed * delta * 10;

//More logic

else
	move = 0;

m_flLastYawTime = gpGlobals->time;

m_flLastYawTime is a float member of CBaseMonster and should be save/restored as a FIELD_TIME. This might break old save games however.

I've recorded 2 videos showing the broken and fixed behavior:
Broken: https://youtu.be/4yTzozi7Wrs
Fixed: https://youtu.be/WMiVSmMo3MI

You can see the FPS in the upper left corner.

[DrCola]

This might affect speedrunners but the big upside is the ability to play the game at a proper framerate without ruining the experience. It would also make the experience the same for everyone.

[BlackShadow]

This might affect speedrunners but the big upside is the ability to play the game at a proper framerate without ruining the experience. It would also make the experience the same for everyone.

Speedrunners aren't using Steam Version for speedrunning. They're either using old version or Steam ported WON version of the game

[BlackShadow]

And this fix will be much appricated!

[SamVanheer]

Note that not all NPCs use this method to change yaw since it's virtual, and pitch may need to be changed as well. A more general solution would be to track the last think time and then use a method that gets the delta time. Then all code that needs to use it can just call that.

In addition not all NPCs use the same AI think method so those NPCs will need to update the last think time variable on their own.

[SamVanheer]

Quoting some complaints that have been raised about fixing this:

hol' up

Issue? Bug? really? For HL:Source I can buy it, for others not so much.

does that mean HL1 was harder on our older computers because I can't remember lol.

be careful what you wish for. you're literally tinkering with a core part of the game that the better players are accustomed to and rely on. You're messing with the gameplay 20 years post launch. I don't think YOU are personally bothered by this or play the game that much. This is a bigger deal than you probably think it is.

Maybe make this an option controlled by cvar so the old behavior can be restored if people want it.

[BlackShadow]

This shouldn't be an complaint at all. This issue is really frustrating. Because of this people can't play Half-Life in higher fresh rates. This issue needs to be sorted. Like i said this won't effect pros or speedrunning community.

[DrCola]

This shouldn't be an complaint at all. This issue is really frustrating. Because of this people can't play Half-Life in higher fresh rates. This issue needs to be sorted. Like i said this won't effect pros or speedrunning community.

If anything, just slow the turn rate a bit. At most they feel a bit too fast in the video. It's perfect with that small adjustment.

[CS-PRO1]

Not just NPCs.. It seems we have other issues with high fps levels like jumping slowdown and surfing becoming impossible:
#2338

[RauliTop]

Quoting some complaints that have been raised about fixing this:

hol' up
Issue? Bug? really? For HL:Source I can buy it, for others not so much.
does that mean HL1 was harder on our older computers because I can't remember lol.
be careful what you wish for. you're literally tinkering with a core part of the game that the better players are accustomed to and rely on. You're messing with the gameplay 20 years post launch. I don't think YOU are personally bothered by this or play the game that much. This is a bigger deal than you probably think it is.

Maybe make this an option controlled by cvar so the old behavior can be restored if people want it.

What the hell? Who wants to play like that? YES, IT'S A BUG and the person who write that complaint it's a bit crazy.

Really a bug: https://youtu.be/4yTzozi7Wrs?t=22

If anything, just slow the turn rate a bit. At most they feel a bit too fast in the video. It's perfect with that small adjustment.

Well, yes. I'm agree with that.
The NPC turns around too fast: https://youtu.be/WMiVSmMo3MI?t=6

[SamVanheer]

Quoting some complaints that have been raised about fixing this:

hol' up
Issue? Bug? really? For HL:Source I can buy it, for others not so much.
does that mean HL1 was harder on our older computers because I can't remember lol.
be careful what you wish for. you're literally tinkering with a core part of the game that the better players are accustomed to and rely on. You're messing with the gameplay 20 years post launch. I don't think YOU are personally bothered by this or play the game that much. This is a bigger deal than you probably think it is.

Maybe make this an option controlled by cvar so the old behavior can be restored if people want it.

What the hell? Who wants to play like that? YES, IT'S A BUG and the person who write that complaint it's a bit crazy.

Really a bug: https://youtu.be/4yTzozi7Wrs?t=22

If anything, just slow the turn rate a bit. At most they feel a bit too fast in the video. It's perfect with that small adjustment.

Well, yes. I'm agree with that.
The NPC turns around too fast: https://youtu.be/WMiVSmMo3MI?t=6

The person who wrote that wasn't aware of how severe the issue is, he agrees that it should be fixed.

In order for yaw speed to work correctly we need to figure out which FPS the game was meant to be running at when it was released, when people would be experiencing it as the developers made it work.

I've been told that fps_max 30 fixes issues with scripts so making the speed work as it does at that frametime should result in the original behavior.

[mikela-valve]

Thanks @SamVanheer, I'll have this in the next beta update.

In lieu of adding this field to the save/restore data and likely breaking older saved games (and breaking newer saved games with older client versions) I'm just going to default the initial yaw delta to the frame time. I don't think it will be terribly noticeable if just that one frame is slightly off in speed but let me know if anything doesn't look right.

[SamVanheer]

Thanks @SamVanheer, I'll have this in the next beta update.

In lieu of adding this field to the save/restore data and likely breaking older saved games (and breaking newer saved games with older client versions) I'm just going to default the initial yaw delta to the frame time. I don't think it will be terribly noticeable if just that one frame is slightly off in speed but let me know if anything doesn't look right.

Thanks, i'll try to get as many people together to test this as i can and report back what they find.

This shouldn't be an complaint at all. This issue is really frustrating. Because of this people can't play Half-Life in higher fresh rates. This issue needs to be sorted. Like i said this won't effect pros or speedrunning community.

...Except for the community speedrunning Half-Life Blue Shift, who all use the Steam version.

That's not really relevant to this situation since this issue is preventing people from playing the game as intended.

If a glitch were found that inserts changelevel commands with arbitrary maps names determined by moving in a particular way, speedrunners would exploit it to get extremely low run times, but it would still be fixed on account of being a bug.

[agrastiOs]

Looks to be indeed fixed. https://youtu.be/bcziOHhAfQo

[Magic-Nipples]

I would suggest lowering the value of the number after the delta from 10 to 2 or 2.5.
speed = (float)yawSpeed * delta * 2;
If you look at the video posted by agrasti0s or solokillers, you can see the npc's are turning incredibly fast. Even more so than if you play the game before this fix. I believe Valve made the number 10 since the npc where spinning too slow with their code.

[DrCola]

@SamVanheer The speed seems to be fast apparently. Perhaps it can be tuned a bit to not break?
As shown in this post by Marphy
https://forum.facepunch.com/f/p/34232655/

Linked his videos here:
https://www.youtube.com/watch?v=a0vPeVWdLcw <- How the scientist is supposed to rotate towards the light switch.

https://files.facepunch.com/forum/upload/109778/578e8b09-9dc7-44d1-b975-2239bffcec6f/hl1_turnspeed.webm <- How they are doing it now. As seen, it is too fast.

I just want to say I very much appreciate that this fps problem is being looked into and I think just some adjustments is needed and it will be perfect.

[BlackShadow]

Yes they're insanely fast. Reducing their speed a little bit and voila! And what's more about this fix is it's only applied to Half-Life. Other mods still suffering this issue. Is it possible to apply this fix to the engine itself?

[SamVanheer]

No.

[BlackShadow]

No.

I see. I believe Goldsrc cannot overwrite monster.cpp in other mods .dll's and apply this fix for every mod. Such a shame really.

[mikela-valve]

@SamVanheer Any comments on the notes from @Magic-Nipples and @DrCola? I presume you've probably tested a fair amount with the current scaling factor, so I'm inclined to go with that for now since turning a bit too quickly is better than turning slowly but I can run a few more changes through beta before releasing this if there's consensus that it should be tuned more.

[SamVanheer]

Yeah it should be slowed down more to match the original. Do you need me to figure out a good setting?

[mikela-valve]

That would definitely be helpful. I'll check 2/2.5 to see how that looks but if you find a better setting let me know and I'll switch over to it.

[SamVanheer]

I'll make a test mod with a cvar to try out various settings and let some people play with it to see what the general consensus is.

[DrCola]

@mikela-valve @SamVanheer do you know if Half Life was designed with 30 or 60 fps in mind? I figure you can try adjusting the value until it's closer to the way NPCs turn at 30/60fps rate.

[agrastiOs]

@DrCola Just try to have the turn speed as similar as possible to this: https://www.youtube.com/watch?v=a0vPeVWdLcw

[SamVanheer]

The fps_max cvar has a default value of 72 in my WON build. Looks like dedicated servers used to run at 30 FPS by default though, so i'd assume that's the expected setting.

[mikela-valve]

I played around with a number of scaling factors yesterday and ended up thinking that multiplying by 2 felt the closest to the WON build. Part of the problem of matching it exactly is that it looks like either handling of animations or just turning altogether is a bit different and that results in the scientist not turning smoothly, so I tried to match the average speed of the original turn.

@SamVanheer Let me know if you find anything different in your testing.

[mikela-valve]

I've updated the coefficient to 2 in the latest beta. Let me know if it still seems too far off from the WON build.

[agrastiOs]

@mikela-valve I tested, it is very close to the WON version now. I think it can be closed. Though maybe we need @SamVanheer to test it too.

Also, I assume you will be shipping the beta to the public build after this issue and #2581 gets closed? Really appreciate the work you did on the GoldSrc games, and I think the community does too. Wish we had a Valve dev working on the Source games like you do on the GoldSrc games.

[mikela-valve]

Great, thanks @agrastiOs! I do plan to update the public build soon, once I finish following up on a few more issues. Closing this one as fixed.

[SamVanheer]

I did some testing to see what multipliers different FPS values would have when converting from the frametime formula to the new framerate independent one.

Using this code:

if( m_flLastYawTime == 0 )
{
	m_flLastYawTime = gpGlobals->time - gpGlobals->frametime;
}

float delta = gpGlobals->time - m_flLastYawTime;

m_flLastYawTime = gpGlobals->time;

if( delta > 0.25 )
	delta = 0.25;

speed = yawSpeed * delta * 2;

const float originalSpeed = ( float ) yawSpeed * gpGlobals->frametime * 10;

const float multiplier = originalSpeed / ( yawSpeed * delta );

ALERT( at_console, "Original speed: %f, new multiplier: %f\n", originalSpeed, multiplier );

The value of multiplier is:

• 30 FPS: ~3.2
• 45 FPS: ~2.1
• 60 FPS: ~1.6

So a value of 2 is roughly 49.5 FPS.

Beyond that i tried to compare it to videos from the early 2000's but i didn't find any that were useful. It seems there are no trailers showing the finished gameplay for Half-Life itself, and the Opposing Force and Blue Shift trailers are low resolution, make quick cuts and don't really show this exact behavior.

That said the current speed seems to be good, and i haven't heard any complaints about the current beta. If more information is needed i can set up WON Half-Life on my old Windows XP machine and run it there. I'll check the average FPS value and see how that works out to a multiplier value.

Given that the original FPS maximum was 72 according to reverse engineered WON code and the average machine capabilities of the era i think a multiplier of 2 should be a good compromise.

[StevenKal]

This new member (m_flLastYawTime) breaks addons's plugins compatibility... for all the bunch of derived classes from "CBaseMonster".
This kind of fix is welcomed, but I hope in the future adding such members in a base class close to "CBaseEntity" will be limited or just inexistant (try using workaround rather than new members), for the reason I've just written.
Adding new members in a last class (like at the end of "CBasePlayer") is not really a problem, but here it is.

[BlackShadow]

@StevenKal I don't know if i get it right. This fix broke few AMXX plugins? If so can you post few plugins became broken.

[StevenKal]

This fix (more the way it is in fact, due to the addition of a new member in "CBaseMonster"), broke all the plugins dealing with members offsets. All the members of all the child/derived/sub classes from "CBaseMonster" are concerned. Like "CBasePlayer", "CBaseTurret", "CEnvExplosion", "CGrenade", all the monsters, etc., etc., etc.

I'm surprised the "SamVanheer GoldSrc dictionnary" didn't think about that knowing he is frequently defending things that may be broken in engine/game behavior, from other people suggestions. I guess he forget the addons's plugins!

I'm the developer of AMX, not AMXX one, so I don't care about how many "AMXX plugins" are broken, but that I can told you is that a lot of them dealing with CBasePlayer's members for such games are broken.
I don't know which games exactly received the changes, I don't use beta builds in my client neither test them for now (for AMX support with upcoming release), mainly since those are changes that may be not definitive (someone just reported me this today), but I'm guessing games using NPC codes like HL, TFC are at least concerned.
At the end, for example, all CBasePlayer's members have now (if there is the new binary on the server) a value of +4 (in byte-addressable format), or +1 (word-addressable format).

[BlackShadow]

AMX? Lol, i haven't heard that in a long time. I'm pretty sure you're saying this for Counter-Strike, but Counter-Strike will not receive this fix, infact Counter-Strike doesn't need this. It doesn't have any activity regarding to AI. Hostages are kinda exception because they just follow player.
(if you call that AI) Only Half-Life received this fix so far. I doubt if other games will receive that. If they do probaly Blue-Shift and Opposing Force will receive it. And even if it's breaking stuff in Half-Life i'll doubt if it'll effect whole community because nobodys using AMX as far i know.

[StevenKal]

AMX & AMXX are addons that are basically some kind of API, by providing tools to coders, etc.
I told you I don't care about AMXX plugins beeing broken, but I've also said the fix concern "addons plugins" (I didn't say "AMX plugins only"), AMXX is concerned by that problem.
I'm defending compatibility of the addons with the new changes, even if the stuff I've coded regarding members could handle this kind of changes with ease (a way much better than AMXX), I'm still thinking this worth to complain regarding that because the way it is can be critical for addons & their modules/plugins.
And no, there are still a few servers using AMX, and this might change in the future when it will become something else than AMXX (despite it's already a bit due to that I'm doing on it & my special politic).
But well, don't go out of context, it's not the point of the subject.

[SamVanheer]

@Arkshine does AMXX have problems with this change? I see AMXX already has a solution for this problem: https://www.amxmodx.org/api/fakemeta/get_ent_data_float

So i think only legacy plugins should be affected by this.

@StevenKal your AMX fork is compromised and has a backdoor that you use to issue server commands to servers running your build. You even admitted to it here: https://forums.alliedmods.net/showpost.php?p=2371325&postcount=14

Nobody should be using your version of AMX, so there is no reason to consider any problems with it.

[rsKliPPy]

This doesn't concern AMXX since 1.8.3 at all. Gamedata API was introduced exactly because of this. If adding a new member to a class higher up in hierarchy is a good solution, then it should be done.

[Cianez]

I've just tested the beta. I think a coefficient of 1.6/1.7 would work better in my opinion @mikela-valve . The turning speed is a bit too fast at the moment. Testing is needed though.

[StevenKal]

@sam: Boost your "addons knownledge", AMXX is a fork of AMX, not the reverse thing. It's amazing the number of ignorants I see about that, who just think AMX is born from AMXX, because you start with AMXX. Look like people has more "respect" to the forked things than the original things forgotten a little too much. You really need some correction regarding that info.
At the same time (to you & others), get use to write "AMXX" instead of "AMX" when you talk about such addon, both are not the same, and that's not accurate, & if there is one to blame for "having the similar name", that's AMXX.
The "developer access" I have from years is for solid reasons (support, known plugins used, etc.), helpful for me and will never be removed. This is also a part of my politic I'll implement in an EULA file in the future (everything will be properly explained, as specified here: http://www.amxmod.net/forum/showthread.php?tid=1098&page=5&highlight=%22developer+access%22). And for the AMXX news, there are some distorted things, knowing I've also a serious argue with that arkshine from years, but if most of you prefer to believe him for 100% of the things for sure I can't really fight people addictions.

About the breaking part:
#1: This can break "old plugins" using old pdata natives with hardcoded members (but even new ones can use this, depends on programmers choices).
#2: This can break various modules like "HL Weapon Mod", where cfg files with members will need to be updated (users will not know that, as people here don't even know/think that this new member breaks plugins compatibility).
#3: AMXX last gamedata natives allow to easily update files, but the fact is, most of the people (especially users) do not just know this kind of stuff and the fact is, if they use a "beta version in the server" (like a new install with "-beta" on cmdline), data will be broken, unless AMXX developers update the official data matching to the beta, but there is also the fact a lot of people use old builds or non-beta builds... which have not that new member, that's why it's critical (and this kind of memeber addition should really be avoided). Some people may keep up AMXX version, by using the last, while they may not update their HLDS. And that I've just said worth for the #2 case too.

New member is recent, but you'll see when people will start having more frequent server crashes "due to HLDS updates", or claim their plugins "no longer work"...

[ghost]

@sam: Boost your "addons knownledge", AMXX is a fork of AMX, not the reverse thing. It's amazing the number of ignorants I see about that, who just think AMX is born from AMXX, etc...

There is no point in keeping broken server behavior broken to keep compatibility with server plugins. One of these is very much easier to update and fix than the other. This was a one time opportunity to fix a glaring issue that would only get worse as computers advance in speed, and I'm glad it has gone though.

[SamVanheer]

@StevenKal backdoors are never acceptable to have, and yours gives you unrestricted access to the server, and even has commands to query and change the RCON password. Until you update your AMXMod fork to have no backdoor access of any kind, i must assume you're acting in bad faith.

Note that this also includes providing up-to-date source code, as required by the AMXMod license. The source code on your website omits the backdoor code which is in violation of the license.

I have independently verified the contents of the AMXMod binaries on your website and i can confirm what the AMXModX team has reported, i am not taking their word for it.

In response to your problems:

1. The old API is deprecated, which is noted in the AMXModX 1.9 changelog
2. Server operators need to be informed of how to manage their servers in relation to official game updates
3. Server operators and players alike need to be informed of how the beta system works and when it's safe to use, this is something that's generally done by the developers when they release news updates so i'd encourage Valve to do so, but having the information spread by community members is a good thing

I've informed people not to use your AMXMod fork due to security issues and outdated/missing functionality, as well as best practices for beta usage and keeping servers updated: https://knockout.chat/thread/7/18#post-89649

And i've requested that the AMXModX API documentation be updated to discourage the use of the old pdata API: https://forums.alliedmods.net/showthread.php?p=2663943#post2663943

I know you'll take offense at my statements regarding your AMXMod fork but as i stated earlier in this post your continued use of a backdoor into servers forces me to assume you're acting in bad faith.

You've been well aware of this problem for nearly 4 years now, so i suggest you remove the backdoor.

But if you are insistent on continuing development of AMXMod it may be better to retire your fork and contribute to AMXModX instead, since it's the more popular and more active fork. That way we know we're all on the same page as far as features and compatibility goes.

[StevenKal]

Stop writing "AMX Mod fork", that's fucking non-sense ("fork" term), I confirm, you're ignorant about what is AMX Mod compared to AMX Mod X, choose your terms with more precision next time.
Yeah, go ahead, add info news about dev access, there are not enough people who were aware about that... nice.
I was a kind of impressed by your knownledge about GoldSrc (the fact you seem addicted at knowing how everything works, by the way, the "GoldSrc dictionnary" was in fact, a compliment), but I start discovering you're also kind of stupid by thinking like most of the others without looking for deeply why it's implemented (like "backdoor = evil nothing else"), also, again, one more "guy speaking French" who want to look for conflicts with me. You're gonna win your AuthID inside AMX to be restricted to join servers using it if you wish to spread that everywhere, while this could have been different between each other.
I suggest to read the link I previously gave you, in my forum where I explain a bit why this has been implemented, and try to understand rather than making your own opinion based of one word (backdoor).

On the website where you spread your things, you write:
"..showed up on the Github issue tracker to complain that his outdated fork isn't compatible with a change made in Half-Life's code"
I've didn't directly complained about the compability of my addon (I didn't even write "AMX" at the beginning), I was mainly talking for the both (AMX & AMXX), and I was complaning about the way the change is, but you still do not see how it's critical (new member in "CBaseMonster") for users using servers addons like AMX/AMXX, where most of them will have broken data & plugins, even by using new AMXX gamedata system via files.
By the way, I don't care about the compatibility of the current plugins I have on my website, neither care much about the v2010.1 compatibility with new changes in engine/games (I didn't updated it for a while), I'm focused at working on next release much more powerful, then after that I'll review the plugins in consequence of the massive changes, then also add an EULA as I said, at the same time, right now it's kind of dormant and I'm O.K. with that.
Additionnaly, the next release could handle this kind of changes (new members) without problems, whatever the C++ class where they have been implemented.

You can still dream about seeing me working on AMXX, this is a bit that arkshine tried to do (with various methods sometimes, irrespectful & unscrupulous), but this will never happen. AMXX is just not "how an addon should be" for my opinion/conception (the same way the Angelscript you promoted is not), due to how it is and the politic behind, and a lot of things which are just horrible and make global poor content split everywhere, even if there are various good things, plugins, devoted people, bunch of coders, etc., the global content is just not how I want it for AMX, but I'll explain everything later.

[kisak-valve]

Hello @StevenKal, from my perspective, @SamVanheer is directing feedback at your project, not you personally, and you're questioning his character before responding to the feedback.

Please keep in mind that insulting or demeaning anyone on this issue tracker is against the Code of Conduct, and if this discussion continues in that direction I'll need to step in as a moderator.

[StevenKal]

Yeah but continue spreading such infos to the people while this has already been done and seen by a ton of people, is kind of abusing, and kind of irrespectful regarding this last fact, the other fact it's a free project, and the other fact it's a lot of hours of work behind.
It's not perfect, and my politic is maybe something, but I doubt my project deserves so much "hate" like that, he is mainly just looking for an "enemy" rather than thinking of a different fix that won't touch members listing, the main purpose of the subject.
I could act like an ass if I wanted to look for problems with him too, on purpose, for example, by specifying he has been banned by Sven Co-op dev team due to X reasons (which are not my business in fact), while I could write some "evil" reasons just to justify a "ban action" the same way he is thinking I'm acting by "bad faith" while it's not the case.

Short morality is:
"It's not because you get banned that you did something very bad; it's not because I've a backdoor that I'm acting in bad faith; it's not because you have a gun in your house that you are a serial killer...".

[kisak-valve]

Regardless of intent, this issue report has derailed from the original issue, which has been resolved.