Add a cooldown to workaround certain multicharacter scripts triggering events like `QBCore:Client:OnPlayerLoaded` more than once and duplicating targets when a player connected
Reworked `frameworkCache.lua` to the new layout
Fix possibility of invisible props/ peds/vehicles on spawn
Start adding very basic and unfinished support for RedM VorpCore
People were reporting issues with scripts claiming items didn't exist, I believe this was due to their servers having slot starts (eg. alot of clothes or vehicles being loaded)
I've rewritten it to fully delay loading until everything is correctly cached and let the scripts continue. Also hopefully reducing memory footprint for it too.
---
Also slipped in an `experimental` function that grabs inventory config files to check their set InventoryWeight and InventorySlots to automatically apply it for other functions
---
I've moved the framework caching to a new file `frameworkCache.lua`
This now caches the framework data once when `jim_bridge` starts
Then in `coreloader.lua` now, the information that is cached is now called from that script
This also includes better handling of ESX cached data and should stop errors
This greatly optimizes the loading of all my scripts and lowers server load to speed up server start times
I have been testing this for just under a week and 6 different test servers and it appears to work fine
This my attempt to aid ESX loading, essentially my scripts server side now need to be locked behind `onResourceStart()` because of ESX
Loading ESX into my scripts was delaying half of it and breaking the other half
This function forcibly waits until everythings loaded and then continues
This shouldn't affect other frameworks loading ability
My tests so far have been a success with it
I realised I was loading ESX the stupidest way
I think I was loading ESX object, then instantly clearing it and then used workarounds to try and reload it (thinking is hard ok)
It should now load correctly and faster
also I realised my custom `onPlayerLoaded()` function was loading too fast, so I've added a delay to it but removed the while loops for esx checks that could potentially break the script
This is still not in use for now, but it WILL be used in the future
I'm getting too many support tickets about the "Failed to load" warning in console about files they don't have/need
(if you don't run `ox_core` don't worry about `ox_core` not loading)
This system is intended to load it through the script instead of `fxmanifest.lua`
It is intended to check if the user has the required script and also warn them if it's not started (load order issue), or just load it as if it were told to in the fxmanifest
