Script to eliminate pop-in
-
I have this here GSC script that Resxt helped me out with for Black Ops 2 and I'm trying to get it working in WAW after he said it should work with the decompiled gsc. However, while the script does load when starting up the private server I run for faffing around it doesn't seem to be setting the lodbiasskinned and lodbiasrigid to -1000 to eliminate pop-in. What would I need to change to get this to work?
init() { level thread onPlayerConnect(); } onPlayerConnect() { level endon("end_game"); for(;;) { level waittill("connected", player); player setclientdvar("r_lodBiasRigid", -1000); player setclientdvar("r_lodBiasSkinned", -1000); } } -
r_lodBiasRigid and r_lodBiasSkinned are both saved in the players config and there for can't be modified by gsc. The reason it works on T6 is because of the fact the two dvars you are trying to modify are not in the players config.
-
FragsAreUs Well shit. Anything I can do then? it is getting tedious having to change the values everytime
-
Katcher12 Lower your fov to reduce pop-in. The higher the fov. The worst it gets due to distance. When Treyarch ported WaW & Bo2 to pc. They didn't consider adapting to high fov. Since console was forced to use 65 fov due to hardware limits. They even made the fog just to help hide pop-ins for zombies.
-
RedxSkull The fov is at the default 65 and I still notice LOD pop-in
-
Katcher12 you can always have a bind to set them like
bind f5 "r_lodbiasrigid -1000; r_lodBiasSkinned -1000"
but if its cheat protected you will need sv_cheats set to 1
-
FragsAreUs Well that's certainly better than nothing. Thank you. Where would I set these binds?
-
Katcher12 in the console or bootstrapper
-
-
Katcher12 the cmd that opens when you open the game is called the bootstrapper.
Entering commands there or in the in-game console is the same thing -
-
Katcher12 you could bind the dvars to the same key you use to walk forward so that you never have to think of it but
- I'm unsure if setting dvars all the time can cause lag/issues, in my experience no
- I'm unsure if it works properly on WAW
Would be
bind W "r_lodbiasrigid -1000; r_lodBiasSkinned -1000; +forward"
Where W is the key you use to walk forward. You might have to unbind/rebind it in the controls first idk -
Resxt Say I have F5 bound to set the lod biases to -1000. Would creating a script that, on connection, would automatically initiate that input be possible therefore automatically setting the values of lodbiasskined and lodbiasrigid to -1000 every time I load into a map?
-
-
Resxt Well a maybe is better than a no.
-
No this is easily possible in gsc it shouldn't matter if they're saved in player config you can still modify them.
You don't want to use "level waittill("connected", player);" nothing notifies that here, it won't work just use " flag_wait( "all_players_connected" ); "
The onPlayerConnect() function in zombiemode normally waits for a "connecting" flag not "connected," also you probably don't want to name it the same thing as a stock function
I just scripted in both dvars in my onplayerspawned() and onplayerconnect_clientdvars() functions in zombiemode.gsc because I'm actually modding a lot of stuff but if you want to do it in an external script that's still possible. These 2 functions ensure the LOD setting will change both when you restart and when you load the game like normal. Or, you could use a loop but that's not really necessary unless you want to be able to toggle the LOD settings (which is a good idea incase something goes wrong-you probably don't want to set these both to -1000. There is a vertex limit and game will have errors, models can turn invisible. Maybe test it out and try a few different values)
for example this is me modifying stock zombiemode, "lod_bias_enable" is a new fake dvar I made which there's a few more steps if you want to do something like that
if( isdefined( self.initialized ) ) { if( self.initialized == false ) { self.initialized = true; // self maps\_zombiemode_score::create_player_score_hud(); // set the initial score on the hud self maps\_zombiemode_score::set_player_score_hud( true ); self thread player_zombie_breadcrumb(); self thread player_reload(); self SetClientDvars( "aim_automelee_range", "96", "aim_automelee_lerp", "50", "aim_automelee_region_height", "240", "aim_automelee_region_width", "320", "player_meleechargefriction", "2500" ); if( getDvar( "lod_bias_enable" ) == "1" ) { self setclientdvar("r_lodBiasRigid", -1000); self setclientdvar("r_lodBiasSkinned", -1000); } } }
-
John_Banana Isn't that the T4m console? Because Plutonium changed how setclientdvar() dvar works so it can no longer be abused by server owners. You can't set saved dvars with setclientdvar() on Plutonium which was what OP was trying to do.
-
JezuzLizard Sounds like questionable dev choice, didn't see anyone mention that as the reason in this thread they just said 'can't be modified in gsc'. How were server owners abusing client dvars? I think if people wanna have their own shit servers where they do stupid things to client dvars then let them, people can always quit.
-
John_Banana said in Script to eliminate pop-in:
people can always quit.
Tell that to the people who don't know how to disconnect through the console that got stuck on a server that spammed the command to close menus...
-
John_Banana It's a client quality thing. If a server owner sets a client's fov in a loop for some reason its likely that client will come on to the forums and discord and complain about an fov bug not realizing it is the server doing it. This would hurt our reputation because now people think our game doesn't let you set fov when we claim to allow it.
Have you actually looked at what the saved dvars entail? They are stored in a file in %localappdata%/Plutonium/storage/t4/players/plutonium.cfg or plutonium_mp.cfg. When these dvars' values are set they save to these configs even if set by setclientdvar(). So a malicious server owner could set any of those dvars and then they save to that player's config file if we didn't patch setclientdvar() to respect the config file.
There really isn't much reason for you to write to dvars saved to the config file. Like r_fullscreen, r_mode, r_monitor, r_vsync, snaps, cl_voice, vid_xpos, and vid_ypos are examples of what is a saved dvar. It doesn't make any sense for a server owner to be able to modify these on a remote client.
