Fixing CS 1.6 Model Flicker: ReHLDS & Gametime Guide

by Admin 53 views
Fixing CS 1.6 Model Flicker: ReHLDS & Gametime Guide

Hey there, fellow CS 1.6 server admins and players! Ever been in the heat of a classic map like awp_india_christmast or de_dust2_2x2_xmas, enjoying the festive decorations, only to notice that those awesome static models – like snowmen, trees, and presents – are flickering like crazy? Or perhaps your custom hostage models are disappearing and reappearing right before your eyes? Yeah, it's super annoying, and it totally breaks the immersion. This isn't just a minor visual glitch; it can seriously impact the quality and professionalism of your server, especially if you're aiming for a high-performance, competitive setup. We're talking about a phenomenon where these static studio models and even custom hostages seem to blink out of existence for a frame or two, particularly when you're moving around or turning your camera. It's frustrating, and it leaves players feeling like something is off with the server's stability. While players and weapon models usually stay put, the disappearing act of map decorations and key game entities like hostages creates a jarring experience. This issue primarily pops up when you're running a ReHLDS server on Linux, especially with high updaterates and a specific cvar enabled: sv_rehlds_local_gametime 1. Many server operators strive for the best possible tickrate and updaterate to provide a smooth, responsive gameplay experience, and encountering such a visual bug can be a real headache. Nobody wants their carefully chosen map decorations or unique custom hostages to look like they're having a seizure! In this comprehensive guide, we're going to dive deep into why this happens, what we've discovered through extensive testing, and most importantly, how you can fix it. So, if your CS 1.6 server is struggling with these annoying flickering models, stick around – we've got the answers you need to get your game looking crisp and stable again. Let's make sure your server provides the best possible experience for your players, free from any distracting visual glitches.

Understanding the Flicker: What's Really Happening?

Alright, so you've seen the flickering, but what's actually going on behind the scenes? When you're running your ReHLDS server, particularly on a Linux machine with sv_rehlds_local_gametime 1 enabled and rocking those high sys_ticrate and sv_maxupdaterate settings (think 1000 / 101), certain entities start acting up. Specifically, we're talking about static studio models – those cool map decorations that add so much character to your maps, like snowmen, Christmas trees, and presents on festive layouts. On top of that, any custom hostage models you've integrated into your server will also join the flickering party. It's like they're playing peek-a-boo with your clients! They'll briefly disappear from the client's view, only to pop back into existence almost immediately. This isn't just a visual nuisance; it indicates a deeper synchronization problem. Interestingly, this bug seems quite specific. We've observed that standard player models and weapon models usually remain perfectly stable, without any of this disappearing act. This tells us that the issue isn't a global rendering problem or a general network breakdown, but rather something affecting how certain types of entities are handled and transmitted to the client, or how the client interprets their state. When you peek at your net_graph 3, you'll likely notice a dense, almost snowy line of yellow and orange dots. What do these mean? They're your client screaming about frequent extrapolation. In simpler terms, extrapolation happens when your client doesn't receive an entity's update in time, so it tries to guess where the entity should be based on its last known position and velocity. When this happens constantly, especially for static objects that shouldn't be moving much, it results in the visible flicker. The client is basically losing track of these models for a split second and then rediscovering them. Now, here's the kicker: if you take the exact same setup – same maps, same models, same high rates – and run it on a vanilla HLDS server (the good old steam_legacy version) on the same Linux machine, or even on Windows, the flickering doesn't happen. Furthermore, if you simply disable sv_rehlds_local_gametime by setting it to 0 on your ReHLDS server, the problem also vanishes. This stark contrast is a huge clue, indicating that the sv_rehlds_local_gametime cvar, in combination with high updaterates on Linux, is the direct trigger for this peculiar behavior. It's a clear signal that something in ReHLDS's alternative timebase or how it interacts with entity updates at these specific rates on Linux environments is causing this desynchronization. Understanding this difference is crucial for identifying and implementing the correct fix, ensuring your server runs smoothly without compromising visual fidelity.

The Culprit: sv_rehlds_local_gametime 1 and High Rates

Alright, let's get straight to the point, guys: after extensive testing and ruling out pretty much everything else, we've pinpointed the primary suspect behind this annoying flickering: the sv_rehlds_local_gametime 1 cvar, especially when combined with high sys_ticrate and sv_maxupdaterate settings on your Linux ReHLDS server. This cvar, intended to improve server-side timing and stability, ironically introduces this visual bug under specific conditions. When your server is configured with sys_ticrate 1000 (meaning 1000 server frames per second) and sv_maxupdaterate 101 (allowing clients to receive up to 101 updates per second), and sv_rehlds_local_gametime 1 is enabled, that's when the static studio models and custom hostages start their dance of disappearance. The fundamental idea behind sv_rehlds_local_gametime is to provide a more accurate and stable timebase for server operations. However, in this specific scenario, it appears that this alternative time calculation introduces a subtle but critical jitter or phase offset between how the server is processing entity updates and how the client's interpolation window is trying to render them. Think of it like this: the server is sending updates, but because of this timing discrepancy, the client isn't always receiving those updates for static entities at the precise moment it expects them. Consequently, the client's engine falls back to extrapolation, guessing the entity's position, and when the real update eventually arrives, it causes the model to pop back into view, creating that noticeable flicker. This isn't a bug in the GoldSrc engine itself, as vanilla HLDS doesn't exhibit this issue with the same settings. It points directly to how ReHLDS, specifically with sv_rehlds_local_gametime 1, is handling its internal timing relative to entity state synchronization. We methodically tested various ReHLDS-specific cvars to isolate the problem. In our original server configuration, we had several ReHLDS cvars enabled, including sv_use_entity_file 2, sv_rehlds_hull_centering 1, sv_rehlds_attachedentities_playeranimationspeed_fix 1, and of course, sv_rehlds_local_gametime 1. To truly isolate the cause, we initially disabled all these ReHLDS cvars. Lo and behold, the flicker disappeared! This was a huge step in our troubleshooting process. Then, we meticulously re-enabled each cvar one by one, observing the server's behavior after each change. Our results were crystal clear:

  • Enabling sv_use_entity_file 2 by itself: no flicker.
  • Enabling sv_rehlds_hull_centering 1 by itself: no flicker.
  • Enabling sv_rehlds_attachedentities_playeranimationspeed_fix 1 by itself: no flicker.
  • But the moment we enabled sv_rehlds_local_gametime 1 again: the flicker returned immediately and consistently.

This definitively showed that sv_rehlds_local_gametime is the single cvar responsible for flipping the behavior between normal operation and the frustrating flicker. This specific interaction, mainly observed on Linux servers, suggests a nuanced problem in how the modified gametime logic in ReHLDS interfaces with the network update pipeline for certain non-player entities under high load conditions. It's a complex dance of server ticks, client updates, and interpolation, where a slight misstep can lead to visible glitches.

Setting Up for Success: Server & Client Config

To help you guys understand exactly what settings trigger this bug and what you can do about it, here are the configurations we used. Pay close attention to the rates and the crucial sv_rehlds_local_gametime cvar.

Server Configuration (Triggering the Flicker):

This is the minimal set of cvars that reliably triggers the flickering issue. If your server.cfg looks something like this, you're likely to experience the problem:

// Rates / tick
sys_ticrate "1000"
fps_max 500

sv_maxrate "100000"
sv_minrate "25000"
sv_maxupdaterate "101"
sv_minupdaterate "30"

sv_unlag "1"
sv_maxunlag "0.5"
sv_unlagsamples "1"
sv_unlagpush "0"
sv_timeout "60"

// ReHLDS-specific - THE KEY CVAR HERE!
sv_rehlds_force_dlmax 1
sv_rehlds_local_gametime 1   // <-- This one causes the flicker!

// Other rehlds cvars that do NOT seem to be the cause (but can be present)
sv_use_entity_file 2
sv_rehlds_hull_centering 1
sv_rehlds_attachedentities_playeranimationspeed_fix 1

Client Configuration (for Reproduction):

On the client side (your CS 1.6 game, protocol 48), these settings will make the flicker most noticeable:

rate 100000
cl_cmdrate 101
cl_updaterate 101
ex_interp 0       // Let the engine auto-set interp based on updaterate
fps_max 99+       // Ensure stable 100 FPS
net_graph 3       // Essential for seeing extrapolation (yellow/orange dots)

We also experimented with lower cl_updaterate values (like 80, 66, 60, 40, 30), and while they might reduce the intensity of the flicker, the most blatant reproduction happens when both server sv_maxupdaterate and client cl_updaterate are set to 101. It really highlights the problem when everything is pushed to the max.

Maps and Models Affected

While this issue can theoretically affect any map with static studio models, it's particularly noticeable on popular Christmas maps. Why? Because they're absolutely packed with custom static decorations that make the flicker obvious. For example, on awp_india_christmast, you'll see it clearly with models like:

  • models/awp_india_christmast/snow_tree.mdl
  • models/awp_india_christmast/c4-christmastree.mdl
  • models/awp_india_christmast/present1.mdl
  • models/awp_india_christmast/frost_man.mdl
  • models/awp_india_christmast/sneeuwman.mdl
  • models/awp_india_christmast/christmast_tree_bigger.mdl
  • sprites/tree_glow.spr

Maps like de_dust2_2x2_xmas and other seasonal variants with dense static decorations will also show the issue prominently. Furthermore, if you're using custom hostage models (like through AMXX plugins such as hostages_models.amxx), those will also exhibit the same flickering behavior. It's crucial to remember that these exact same maps and models look perfectly fine, without any flicker, under these conditions:

  • On a vanilla HLDS (steam_legacy) server running on Linux.
  • On a vanilla HLDS server running on Windows.
  • On a ReHLDS server running on Linux, as long as sv_rehlds_local_gametime is set to 0.

This reinforces that the problem lies specifically within the sv_rehlds_local_gametime 1 setting in a ReHLDS Linux environment at high update rates.

Testing and Ruling Out: Our Investigation Process

Guys, we didn't just stumble upon this by accident; we went through a pretty rigorous testing process to make sure we truly understood the root cause. When you're dealing with server-side bugs, it's all about isolating variables, and that's exactly what we did. Our goal was to meticulously rule out any other potential culprits and definitively prove that sv_rehlds_local_gametime 1 was the key factor. First off, we performed a pure HLDS versus ReHLDS comparison. We started with a clean installation of HLDS (steam_legacy) on a Linux machine. We configured it with those high rates (1000 sys_ticrate, 101 sv_maxupdaterate) and observed absolutely no flickering. Everything was smooth as butter. Then, we took that exact same install and simply overlaid the official ReHLDS binaries (version 3.14.0.x), replacing engine_i486.so as per the ReHLDS README. Bingo! The flicker immediately appeared. This initial test was a huge indicator that the issue was indeed ReHLDS-specific. As an additional control, we even tested the same content and rates on a vanilla HLDS server running on Windows, and again, no flicker. This confirmed that it wasn't a general network or client issue, but something tied to ReHLDS on Linux. Next, we wanted to eliminate any possibility of plugin conflicts or issues with ReGameDLL. Many server owners run a whole suite of plugins, and sometimes, unexpected interactions can cause problems. So, we disabled Metamod and AMXX completely, stripping the server down to its bare essentials – just ReHLDS. Guess what? The issue still reproduced. This was a critical finding, telling us that AMXX plugins, Metamod-r, or any of their specific functionalities were not the cause. We even went a step further and swapped ReGameDLL for the original mp.dll, just to be absolutely sure that ReGameDLL's logic wasn't interfering. Again, the flickering persisted. So, we could confidently rule out AMXX plugins, Metamod-r, and ReGameDLL as the source of the problem. This significantly narrowed our focus to ReHLDS itself. The most crucial part of our investigation involved systematically testing ReHLDS cvars. Our initial server configuration had several ReHLDS-specific cvars enabled: sv_use_entity_file 2, sv_rehlds_hull_centering 1, sv_rehlds_attachedentities_playeranimationspeed_fix 1, and the problematic sv_rehlds_local_gametime 1. To figure out which one was causing the trouble, we first set all of these cvars to 0 and restarted the server. Presto! The flicker disappeared. This confirmed that one or more of these ReHLDS cvars was indeed the trigger. From there, it was a methodical process: we re-enabled each cvar one by one, restarting the server and testing after each change. Our results were crystal clear:

  • Enabling sv_use_entity_file 2 by itself: no flicker.
  • Enabling sv_rehlds_hull_centering 1 by itself: no flicker.
  • Enabling sv_rehlds_attachedentities_playeranimationspeed_fix 1 by itself: no flicker.
  • But the moment we enabled sv_rehlds_local_gametime 1 again: the flicker returned immediately and consistently.

This definitively showed that sv_rehlds_local_gametime is the single cvar responsible for flipping the behavior between normal operation and the frustrating flicker. Finally, we looked into rates themselves. While reducing sv_maxupdaterate (and client cl_updaterate) down to more moderate values like 30-60 could somewhat mitigate or hide the flicker even with sv_rehlds_local_gametime 1 enabled, this is more of a workaround that compromises gameplay fluidity rather than a true fix. The fact that with sv_rehlds_local_gametime 0, we could run at sv_maxupdaterate 101 and cl_updaterate 101 on the same Linux server without any visible flicker solidified our conclusion. Our comprehensive testing ruled out everything except for the specific interaction of sv_rehlds_local_gametime 1 with high rates on a Linux-based ReHLDS server, making it clear where the fix needs to be applied.

The Workaround: How to Fix It Right Now

Alright, guys, let's talk about the solution that will immediately stop that annoying flickering on your ReHLDS server. While we've delved into the technicalities of why sv_rehlds_local_gametime 1 causes this issue, the good news is that there's a straightforward workaround that you can implement right now to restore stability to your static studio models and custom hostages. The only reliable and immediate workaround we've found is to simply disable sv_rehlds_local_gametime. That's right, just set it to 0 in your server.cfg file. Here's how you do it:

// In your server.cfg file, find this line:
sv_rehlds_local_gametime 1

// And change it to:
sv_rehlds_local_gametime 0

After making this change, make sure to restart your server or change the map to apply the new setting. Once you do this, you should immediately notice that the flickering of your map decorations and custom hostages has completely disappeared. Your server will behave much like a vanilla HLDS server in terms of visual stability for these entities, even at high sys_ticrate and sv_maxupdaterate settings. This is a crucial fix for anyone looking to maintain a visually consistent and professional server environment. It ensures that the player experience isn't marred by distracting glitches, allowing them to focus on the game itself. While this workaround is effective, it's important to acknowledge that it might not be the ideal long-term solution, especially if sv_rehlds_local_gametime 1 is intended to provide specific performance or timing benefits that we're now bypassing. For a competitive-style setup where every millisecond of timing accuracy matters, disabling a cvar designed for improved timing might feel like a compromise. However, in the context of addressing a highly visible and disruptive bug, it's an absolutely necessary step. There's also a secondary, less ideal workaround: reducing your sv_maxupdaterate and client cl_updaterate. If you drop these rates down to something lower, like 30 or 60, the flicker often becomes less noticeable or even disappears. However, this comes at the cost of responsiveness and the overall "crispness" of gameplay that high updaterates provide. Most competitive servers aim for 101 updaterate to give players the smoothest and most reactive experience possible, so throttling back on rates isn't really a viable option for many server owners. It's a trade-off that most would rather avoid, making sv_rehlds_local_gametime 0 the preferred method to maintain high performance and visual stability simultaneously. By implementing this simple change, you can ensure your players have a seamless and immersive experience, free from those irritating disappearing models, and keep your server running at its intended high performance levels. This workaround is robust and has been thoroughly tested, giving you peace of mind that your server's visual fidelity is restored while further investigations into the root cause can be pursued by the ReHLDS development team.

Meta-Information and Future Steps

For those of you who are more technically inclined or developers looking into this specific issue, here's a quick rundown of the environment where this bug was reproduced. This information is crucial for understanding the context and potentially helping with a permanent fix.

Our server environment details are:

  • Operating System: Ubuntu 22.04.4 LTS (x86_64), running on bare metal (no virtualization).
  • ReHLDS Version: 3.14.0.857-dev, build date 19:52:21 Mar 27 2025.
  • ReGameDLL Version: 5.28.0.756-dev, build date 19:19:31 Mar 27 2025.
  • Metamod-r Version: v1.3.0.149, build date 11:31:17 Apr 23 2024.
  • AMX Mod X Version: 1.10.0.5467.

All these components were installed using official binaries, ensuring no third-party modifications. We also had several plugins loaded (Reunion, Revoice, ReAuthCheck, Rechecker, AMX Mod X, YaPB, NetBufExtender, ReSemiclip, WHBlocker, Fun, Engine, GeoIP, CStrike, CSX, Ham Sandwich, ReAPI, ReAimDetector, FakeMeta), but as detailed in the testing section, none of these were found to be the cause. We believe this detailed context will be valuable for the ReHLDS development team. If there's a need for further investigation, we're totally ready to provide more data! This includes demo files recorded in both flickering (sv_rehlds_local_gametime 1) and stable (sv_rehlds_local_gametime 0) modes, the exact map and model packs we used, or testing any experimental builds or additional cvars the developers might suggest. Our aim is to assist in finding a permanent resolution so that sv_rehlds_local_gametime 1 can be used as intended without any visual drawbacks.

Conclusion: Smooth Gameplay is Just a Setting Away!

So there you have it, folks! Dealing with flickering static studio models and custom hostages on your CS 1.6 ReHLDS server, especially when running at high updaterates on Linux, can be a real pain. It detracts from the overall player experience and can make your server feel unstable. We've thoroughly investigated this issue, from initial observations and net_graph indications of frequent extrapolation to systematic testing that ruled out plugins, other ReHLDS cvars, and even the base GoldSrc engine itself. Our findings consistently point to one key culprit: the sv_rehlds_local_gametime 1 cvar. While this cvar is intended to enhance server timing, its interaction with high rates in a Linux ReHLDS environment seems to create a timing desynchronization that causes these specific entity types to flicker. The good news is that the solution is simple and highly effective: by setting sv_rehlds_local_gametime 0 in your server.cfg, you can immediately resolve the flickering issue without sacrificing your desired high sys_ticrate and sv_maxupdaterate settings. This allows you to maintain optimal server performance and provide a visually stable, immersive gameplay environment for all your players. We highly recommend implementing this workaround on your servers if you're experiencing this problem. Keep an eye on ReHLDS updates, as the development team might release a permanent fix for this specific interaction in the future, allowing the full benefits of sv_rehlds_local_gametime 1 to be realized without any visual drawbacks. In the meantime, enjoy your flicker-free CS 1.6 experience, and keep those servers running smoothly!