It’s not start exec permissions.cfg it’s exec permissions.cfg
@KeyWest so was it the “stance” resource? if so, can you link that resource so I can take a look to see if it has any conflicts.
Yeah i know, but i must restart server? And where i put permissions.cfg file, because i use zap hosting service. Server.cfg folder name are server-data. What is correct folder?
Just keep it in the vMenu config folder, and make sure you add exec resources/vMenu/config/permissions.cfg and then start vMenu in the server.cfg.
Okey, thanks. I try
Up until the new update I didn’t have this issue. Could it be something with the Infinite Fuel option? We don’t have FRFuel installed we have LegacyFuel.
Unlikely, vMenu doesn’t set any decorators unless they already exist.
What scripts are you using that have decorators set?
can you give me an example of a decorator?
for example any of those natives being used.
Probably not, although we have a LOT of scripts. I wont be able to be 100% sure until I get home
well that fuel script of yours probably does, unless it uses events to sync everything which is quite a waste of resources tbh.
Can you provide a full list of all your resources? Or would that literally be impossible for me to check (> 25 scripts running)? I guess disable all of them one by one or a couple at a time and see if it’s still an issue.
@Chemical and @KeyWest I’ve done some tests, and the only way I was able to reproduce this exact error, is by creating a test script, that creates 1.5k different decorators, and then start vMenu after that.
Since vMenu only has 1 decorator, and not 1.5k different ones, it can’t be caused by vMenu. vMenu is just the one that crashes, because another script already registered too many decorators. This is giving you the “Global Error” because the pool size is too small.
Here’s proof that it crashes because 1500 decorators have been registered:
that’s the only reason it could crash if that pool is full, which is exactly the error you two are getting.
Is that in a gameconfig.xml?
Yes, however increasing that won’t help, you should instead find the script that’s spamming new (unique) decorators.
can you send a full client log file so I can possibly find out what script is causing this?
How would I search for it?
It’s the CitizenFX.log file inside your FiveM installation folder, I need the one that contains those errors that you sent with that screenshot.
@Chemical and @KeyWest you can temporarily use this:
https://ci.appveyor.com/api/buildjobs/wuiqd3a2h3p4d2ow/artifacts/vMenu-beta.zip
it will spam 4 error messages every second, instead of 4 errors every frame. This should lower the FPS loss, but you still NEED to fix the other script. This is just so you can debug this without lagging out because of the errors. It will still NOT allow vMenu to run correctly with that version, because it’s up to you to solve the other scripts.
Hello Vespura!
I’ve got a quick question. On an ESX server that I installed vMenu on, the players started having the issue where they go to the clothingshop, change clothes without issue but when they log out and back in, they have been reverted to the clothing they were wearing prior to the change.
I’ve been looking through the permissions file and I see the restore appearance and spawn as default mp character and I’m wondering if there’s any chance that these or other vMenu option might be conflicting with the system.
Is there a vMenu option that could behave in the manner that I’m describing(reverting a player to previously equipped clothing)?
Thanks for your time!
You can disable this with a convar, so if you disable that it shouldn’t conflict in case people enabled this in their menu settings.