[Silvers]

Originally Posted by foxhound27 hello Silvers sorry to bother you but i have a request hehe could you add sm_hatclient <user> <hat> ? thank you!

Done.

PHP Code:

sm_hatclient   // Set a clients hat. Usage: sm_hatclient <#userid|name> [hat name or hat index: 0-128 (MAX_HATS)]. 


[foxhound27]

Originally Posted by Silvers Done. PHP Code: sm_hatclient   // Set a clients hat. Usage: sm_hatclient <#userid|name> [hat name or hat index: 0-128 (MAX_HATS)].

amazing, thank you so much

[Alex101192]

I encountered some problems after I upgraded to April 1 version.

I was loading survival mode on the server on dead center, and the loading was stuck 75%, similar how it was stuck in the coop markers plugin when loading passing. When I loaded survival a second time, the game loaded fine. But when trying again a third time it got already stuck in the loading while loading icon was still spinning (so server side issue).

I noticed players were still joining campaign and such, so the issue seems to be encountered on survival and may be on other gamemodes too. Downgrading to the previous version fixed the problem entirely.

[Silvers]

Originally Posted by Alex101192 I encountered some problems after I upgraded to April 1 version. I was loading survival mode on the server on dead center, and the loading was stuck 75%, similar how it was stuck in the coop markers plugin when loading passing. When I loaded survival a second time, the game loaded fine. But when trying again a third time it got already stuck in the loading while loading icon was still spinning (so server side issue). I noticed players were still joining campaign and such, so the issue seems to be encountered on survival and may be on other gamemodes too. Downgrading to the previous version fixed the problem entirely.

As I thought this plugins last update in no way could cause this. After testing over and over in linux and windows, various scenarios, I've now been informed this plugin is not causing the issue.

Humans are bad pattern recognition machines, I learnt this a long time ago. Too much lately and in the past my plugins have been blamed for various issues which are in no way related or possible. So now I'll ignoring issues unless it's clearly a possibility or there are multiple reports. I've wasted too much time over the years chasing shadows. /vent

[Alex101192]

Yeah hats was not the problem with that, I thought I had written a comment here saying it. hmm.

Anyway I have found some maps in which the plugin must not precache models, or otherwise cause a crash

l4d_hats_precache "c1m3_mall,l4d_zero01_south,l4d_zero02_complex,l4d_zero03_chasm,l4d_zero04_steppes,l4d_zero05_aerith,crashbandicootmap2,crashbandicootmap4,l4d2_stadium3_city1,l4d2_stadium4_city2,l4d2_stadium5_stadium"

Precaching the models on these maps causes graphical bugs and crashes. You can test them if you don't believe me. I suggest putting these as default disable on the cfg.

[Marttt]

Alex101192,

c1m3_mall usually crashes, unless you use the "l4d_hats_precache" cvar.

I use another solution, I remove some "trash" entities with stripper (mostly prop_physics entites).

Maybe I can publish a plugin with my stripper config, I do that for custom maps as well to "fix", but sometimes I actually break the map xDD

Note, cvar has a limit of 255 characters or something like that when read, so careful adding a lot of maps because you can reach its length limit, making the last maps from the cvar not work.

[Silvers]

Originally Posted by Marttt Note, cvar has a limit of 255 characters or something like that when read, so careful adding a lot of maps because you can reach its length limit, making the last maps from the cvar not work.

The plugin uses the value "char sCvar[256];" which is setting the current limit of 255 characters but by changing this you can get to 490 characters after that you receive a "WARNING: Command too long... ignoring!" error. This error comes from the engine enforcing the cvar and string are no more than 510 characters, that's the whole string counted like: "l4d_hats_precache "c1m3_mall,...".

This limit could probably be patched out (I might test doing that)... I have tested cvars with 15k+ characters in their name and they work, might have been value too I can't remember was a while back. The next limit you would probably hit is 8192 from Command Buffer plugin if you use that. There maybe other limiting factors somewhere, such as A2S query. Will update eventually and increase the plugins cvar string and add those maps recommended as default. Thanks.

[Alex101192]

Originally Posted by Marttt Alex101192, c1m3_mall usually crashes, unless you use the "l4d_hats_precache" cvar. I use another solution, I remove some "trash" entities with stripper (mostly prop_physics entites). Maybe I can publish a plugin with my stripper config, I do that for custom maps as well to "fix", but sometimes I actually break the map xDD Note, cvar has a limit of 255 characters or something like that when read, so careful adding a lot of maps because you can reach its length limit, making the last maps from the cvar not work.

That's too much work just for this. I'd rather just disable it. Hats aren't an essential part of the server.

[Slaven555]

Originally Posted by Marttt Alex101192, c1m3_mall usually crashes, unless you use the "l4d_hats_precache" cvar. I use another solution, I remove some "trash" entities with stripper (mostly prop_physics entites). Maybe I can publish a plugin with my stripper config, I do that for custom maps as well to "fix", but sometimes I actually break the map xDD

You can give an example for a stripper

[Marttt]

Sure, check the attachment. I didn't fully test if it affects something else, but runs fine in my server for plugins that don't have "precache" prevent maps, still may need some tweaks. I usually do that for custom maps that crash a lot.