I'm not sure why I came here even after knowing this will inevitably lead into toxicity because it seems to me that Hunting is only looking for an answer which satisfies him and his theory, and not ready to admit the otherwise. I won't be shocked if someone starts bringing up things which are a Lockheed U2 apart from this topic.
Though I tried to talk sense talking about all this, he only targeted me when I was talking from a general perspective. But I'll still try to explain stuff to the best of my knowledge because this is important.
Our team discussed with NewK on these issues and I believe he patched it out once we showed him what was up. But let's say RTV is using DecUI as a base to design their GUI, if it was on the earlier versions, then they are probably subject to this problem we noticed. If that timer GUI is all the GUI RTV has and its causing so much sync issues then I suspect there lies the problem.
Nope, RTV is neither using DecUI nor SetTexture. It has more than just the timer but I can assure you it has been scripted in the most efficient way possible, with the help of some of my utilities that I have thoroughly tested. There is only 1 high resolution sprite and total size of all sprites combined is under 1MB. The desync Hunting is referring to is completely out of his assumptions.
There's no reason to believe that GUI has any direct affect on sync. Yeah obviously if you overuse GUI it will definitely harm performance but isn't that obvious about overusing virtually anything?
Elements don't seem to cause any dramatic impact (apart from 3D ones) once they have been created. The major drop is either when creating elements or trying to manipulate them (using ScriptProcess), whatever drop a element has to cause, it causes it during the load event (hence the pause effect when your player is created in the server).
The ideal approach is to draw the GUI when script loads and show or hide it whenever it needs to be instead of creating it right before it needs to be shown. This way it wont interfere with memory or processing later on.
Talking about ScriptProcess, not everything will lead to high CPU consumption, if you're fading in or out a bunch of elements even PER FRAME, it would barely consume a percent. However, try resizing a label and you're instantly looking at the definition of a chaos.
So technically, you are good to go with any sort of UI
unless you:
- create stuff when it needs to be shown up,
- use a humungous amount of stuff (especially 3D),
- try to achieve complex results using ScriptProcess.
If you need a bad example to learn from, RTV v3's source code might still be lying around somewhere. It perfectly explains how NOT to do things. In general, asking yourself "is this necessary?" would do the job.
Knowing about how a low-end PC will react to the use of ScriptProcess, there exists what I call a KillSwitch for all the fading animations in RTV's GUI since long. The switch is automatically triggered if the player is facing even the smallest of drops.
Here is some stuff I tested in RTV with and without the GUI.
Before you go looking at those, please note the following:
- The server was restarted, GUI was NOT loaded at all while testing for without it. Anything that uses ScriptProcess wasn't loaded either.
- While testing the with GUI case, the KillSwitch was prevented from being triggered so the results are more realistic.
- I would assume the PC I tested on is an ideal ground for testing because opening anything in the background would lead to FPS drops, if there are any considerable performance issues caused by the GUI, they would unequivocally surface on the overlay.
- Screen was captured at a point where the GUI is in fade-in animation or just has completed fading so the effect of ScriptProcess is also captured.
Looking at the base from above, still:without GUIwith GUI (1)with GUI (2)shooting at a wall:without GUIwith GUI (1)with GUI (2)getting in the vehicle:without GUIwith GUI (1)with GUI (2)Even though my CPU temperature had risen up to 84 celc by end of all this, there was no significant difference. And I'm running the game on an integrated GPU with a f**ked up cooling system.
About those videos, the first one is a rare bug where you shoot the player out of his FOV and the shots never register. You can also reproduce this on LAN in a blank server.
Second video and third video, that is another story already explained on VCMP forum.
At the end I'm only gonna say this,
do not kill your creativity by thinking that the stuff you create will ultimately cause lag or performance drop of some kind. VCMP might have some limitations but the GUI is certainly not anywhere near the top of the list. It's your perfect sandbox. This is the most important part because I've learnt a lot from this game and it may as well have contributed to my creative skills apart from a lot other.
If you use it how its supposed to be, the impact will always be infinitely less than a molotov being thrown at you. The sync itself is what needs to be reworked, GUI fits perfectly at its place.
Regards
