Jump to content

Forcecvar bug


Aciz

Recommended Posts

I found this little bug on my server today: If a map-specific config has a forcecvar value that is not specified on the default config, after playing the map and switching to new map, clients who play with ET:Legacy are not forced to change that cvar back to default value. Here is an example that we encountered on our server today:

 

 

On our server, radar.cfg has forcecvar r_wolffog "0" and r_drawfoliage "0". We played radar, and forcecvars worked normally. Then we switched to Baserace. For me, fog was automatically forced back to 1, like the default value in ET is. But my friend who played with ET:Legacy, still had it on 0 and could toggle it. Same bug happened on et_ufo after that. But when I modified default.cfg to have forcecvar r_wolffog "1" and r_drawfoliage "1" and changed map to battery, my friend with ET:Legacy was forced to have r_wolffog "0" and couldn't change it. I was able to reproduce the entire issue just few minutes ago, with the exception that I couldn't change  r_wolffog back to 1 after having forced it to 0 on radar.

 

My friend played on Linux with ET:L 2.71 RC3, and I tried this on Windows with ET:L 2.71 RC4. Server is running silEnT 0.8.2.

Link to comment
Share on other sites

  • Management

I don't know if I understand the report. The forcecvar forces a cvar and that forcing is supposed to last until another value is forced. The player can not change the value by hand. So ifI understand correctly, you have:

forcecvar r_wolffog "1"
forcecvar r_drawfoliage "1"

in the default.cfg.

 

You have:

forcecvar r_wolffog "0"
forcecvar r_drawfoliage "0"

in radar.cfg. This would be the correct way to force these cvars differently based on the maps.

 

This sounds like an ET:Legacy issue. You should take this to ET Legacy team at http://www.etlegacy.com/projects/etlegacy/boards. Technically, the cvar forcing is nothing but a pair of trap_Cvar_Register and trap_Cvar_Set calls to the engine.

Link to comment
Share on other sites

I don't know if I understand the report. The forcecvar forces a cvar and that forcing is supposed to last until another value is forced. The player can not change the value by hand. So ifI understand correctly, you have:

forcecvar r_wolffog "1"
forcecvar r_drawfoliage "1"

in the default.cfg.

 

You have:

forcecvar r_wolffog "0"
forcecvar r_drawfoliage "0"

in radar.cfg. This would be the correct way to force these cvars differently based on the maps.

 

This sounds like an ET:Legacy issue. You should take this to ET Legacy team at http://www.etlegacy.com/projects/etlegacy/boards. Technically, the cvar forcing is nothing but a pair of trap_Cvar_Register and trap_Cvar_Set calls to the engine.

 

Yes, those are the settings I currently have. But on normal ET client, the fog & foliage cvars were forced back to 1 on any other map than radar because they are cheat protected commands even if I didn't have them forced to 1 on defaul config. On ET:Legacy however, they were not.

Link to comment
Share on other sites

So it looks like the bug is in ET:L. Cvar forcing is not done by the mod.

 

Ah, so you would say that ET:L doesn't know how to handle forcecvar command from server?

 

Edit: nvm, I think I found out why it does that: in ET:L, r_wolffog isn't cheat protected cvar. That's why it doesn't reset back to 1.

Edited by Aciz
Link to comment
Share on other sites

  • Management

 

Ah, so you would say that ET:L doesn't know how to handle forcecvar command from server?

The forcecvar is not an engine command. The forcing is done by the client mod with trap_Cvar_Register and trap_Cvar_Set calls to the engine. The bug is in the ET Legacy in the way it handles these calls or in the way it handles cvars. Like I already posted above.

Link to comment
Share on other sites

The forcecvar is not an engine command. The forcing is done by the client mod with trap_Cvar_Register and trap_Cvar_Set calls to the engine. The bug is in the ET Legacy in the way it handles these calls or in the way it handles cvars. Like I already posted above.

 

Ah, I see. But as I said before, the "bug" happened because ET:L doesn't label r_wolffog as cheat protected command.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...