Script to eliminate pop-in
-
-
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.
