Long loading of chat resource
Filcatalao opened this issue · 8 comments
After some debugging i've found that the more resources you load, the slower will be the ui to be ready (and chat)
So this clientside code:
`
AddEventHandler('onClientResourceStart', function(resName)
Wait(500)
refreshCommands()
refreshThemes()
end)
`
will call that 2 functions each time a resource is loaded and so it will send NUIs data to update each suggestion and theme for every resource that is loaded and the UI hung for a few seconds after player loads the char and suddenly, all notifications and the chat, appers. On older PCs may take up to 30seconds after the player loaded to 'enable' the UI
The problem is that the previous version, before v2, does the same thing but doesn't hang the UI so it can process a lot faste the incoming messages. What is wrong or different since you've changed to v2? Is the compile method?
I would have to agree with this post, especially for Qb-Core Multicharacter... enabling chat significantly increases load times by at least 15 seconds making you think the game has frozen.
One fix that i've done and helped a lot was:
creating a
local playerLoaded = false
then
onClientResourceStart and onClientResourceStop, the refreshCommands() and refreshThemes() i put it inside a if playedLoaded
then added
RegisterNetEvent('esx:playerLoaded')
AddEventHandler('esx:playerLoaded', function(xPlayer)
playerLoaded = true
end)
and on
RegisterNUICallback('loaded', function(data, cb)
TriggerServerEvent('chat:init')
while not playerLoaded do Wait(500) end
refreshCommands()
refreshThemes()
chatLoaded = true
cb('ok')
end)
And solved. What does it do? Well, only when the player is loaded if will update commands and themes, just once.
And maintaint the functionality that on a resource stop or start it updates the commands and themes like before.
Maybe there's a more efficient solution to stop the loop between all sending commands and themes as much as the number of resources loaded, but it works and works well
How would you do this for qb-core ?
This is not really an issue. It just concerns servers with a bunch of inefficient resources, slow computing power and enough load to cause this.
Sure there is a workaround for this but it is a case by case scenario. Nothing is going to be done to address this as multiple other servers run this resource without issues (you know servers with owners that actually know how to code shit on their own)
So maybe post your workarounds in the forum and close this issue.
Yes sure, but this script is not efficient. If you have 200 scripts loading, you will repeat a loop that will iterate from 200 scripts, check what scripts are started and send nui's for each command registed.
It's simple, just put a print before the NUI call inside refreshCommands() function and see the huge inefficency by itself, repeating and repeating same stuff over N resources loaded, instead of doind that only 1 time, after player is loaded and all resources loaded.
This is not a workaround this is a solution to prevent overhead of repetitive NUIs doing the same thing over and over for every script that is loading.
In Discord of CFX we can see a lot of people telling that chat have a slow loading. (who uses this V2, because most people uses the previous version that doesn't have that problem)
Do you have any repro steps for this? This seems more like a weird issue induced or worsened by some script as the report mentions a lot of resource-specific concepts:
Qb-Core Multicharacter... enabling chat
after player loads the char
'esx:playerLoaded'
this V2
... or if you don't speak English (which you don't seem to), if someone who does can say what exactly is being reported here?
Why are you guys attacking this guy? From what I can see, Fcatalao does speak and understands English. What he's saying (if you don't understand or read english) is that, the code is in a constant loop until it has searched all the scripts whether they're loaded or not for commands, and he saying to fix this issue, why not wait until the player has fully loaded and wait until all the scripts are loaded to run it once. This is not rocket science and makes sense to me.
Hopefully this is clear enough.
I'm having the same issue but within QB-Core. I had this chat script which bypassed the cfx chat called OKOKChat which a lot of people use. Now, he has updated the script to a newer version to use cfx chat which slowed down the multicharacter script by about 10 -15 seconds. So for now, I reverted back to the v1 okokchat which has its own chat system and now my multicharacter selection screen is instantaneous.
If we're going to turn this thread into some mudslinging contest and implying anyone is being 'attacked', I'm closing this thread. Nobody is attacking anyone, I'm merely trying to understand what is being reported here, and asking if the author (not some random third party) can find someone who doesn't speak broken English to explain their issue.
Resource start events don't 'all trigger for every resource', these are supposed to only trigger when a resource gets started or stopped while already joined, which is exactly what that code is for: to handle resources that get stopped/started while the server is running, removing that functionality wouldn't make any sense, and 'player has fully loaded' here seems to be a concept made up by a specific resource (in this case, 'esx'), and this has no parallel in the platform itself.
Finally, if the community seems to imply the chat resource needs to be 'bypassed' for anything, I don't think this discussion can be saved at all, as it just builds on top of a repetitive lack of constructive feedback. It also seems apparently this 'v1' and 'v2' thing isn't even referring to this repository, but is rather referring to something named an 'okokokokchat'..?!
Again, if you're not intending to provide any means to a solution - or any repro steps - and instead are just trying to place blame on everyone for just about anything, don't post here at all.