all I know is that I have never gotten a vga error until very recently
Not sure if completely, since some legacy symbols seem to be removed or forgotten to be included on the newer versions it seem.
I remember a software I tried once crashing left and right until I installed the 2005 version, I had the 2010 one (it was the latest one at the time).
I gave up on trying to understand M$ way of doing things, same for IMC LOL.
I guess most people lose their imagination capabilities as they grow old, good thing I still kept mine at my age LOL.
They do not even get a chance to install and error moving on with the way I install them. That is why I do that and use the discrete way of installing this stuff. Once you do that only Flash and Java need updating which one day will be on their way out like the older runtimes.
VM blocking has nothing to do with errors inside the lua wrapper. Prolly can be related to optimization or other things since January tho.
This is kinda true, plus some functions are really changed. As much I dislike Microsoft I understand that you canât keep blindly supporting old versions for 10+ years all the way.
If things needs to be changed for better performance or usage, sometimes you will need to do those big changes. Keeping endless backward compatibility can be really complicated, especially when one given application may use some specific set of functions or choses lower level functions (more likely to change/break) instead of using higher level ones.
If itâs related to optimization canât they just uncheck the âOptimization (Beta)â or force it to run on 1 core in task manager and completely avoid the VGA error?
I mean, thatâs what I would do if I got the VGA error.
Purely anecdotal, but I deleted every legacy version of VS C++ distro and reinstalled 2015 for 32 and 64 bit, and I did not VGA error for the whole day.
I will post my findings if I continue to VGA error afterwards. I do ET alot so that seems to be the biggest culprit.
They did ask users to disable âOptimization (Beta)â (tickets) to test if it solved the issue until they bring out a fix for the error. It doesnât completely solve the issue but might reduce the frequency you get the errors, maybe. At least reduced them for a friend but wonât completely solve it.
As well you donât simply kill all optimization progress because one thing that can be fixed. One could decide to temporary make Optimization disabled as default but the harm would be worse than trying to fix it, in my opinion. (Is it the majority or minority of players who have crash issues? I donât think it is the vast majority to justify breaking something to fix another.)
(As well VGA error isnât a âVGA errorâ.)
@fatedhour as well the game works solid for me here. Even on Wine/Linux. I canât even test to try to provide any data I could get :<
I actually have multiple partitions set up on my box, like windows 7, windows vista, and windows XP. If I had this particular VGA error I would be able to try it on 3 different OS [holding the hardware configration constant] to see if the OS itself had anything to do with it.
Well itâs rock solid for me though.
i like this one, short and sweets, thanks lunar for these information.
no more wall of text in the future~~
I can get consistent VGA errors when I am ingame with
CTRL + ALT + DELETE to start task manager. Is it due to desync?
My ctrl+alt+delete always used to work before this patch. Before patch, ctrl+alt+delete ==>and back to game screen would give me 1-2 seconds frozen screen delay but the client would not crash. After this delay ToS works again.
Maybe related to vga crash.
@STAFF_Yuri :
In this topic someone has a VGA error there is a log entry shown that seemingly shows a Lua error.
TOS ârecentlyâ got multithreading when IMC made this optimization update, correct? Do these multiple threads access the same Lua state? For example, if you have a rendering thread that needs info for the UI and a gameplay thread that needs info about skill mechanics, do they get their data from the same Lua state?
I ask because Lua states are not thread-safe/not multithreading-safe. If you have multiple threads accessing the same Lua state, even if itâs just reading data from the lua state, it can seriously mess up the Lua stack and cause crashes or wrong data.
It might not always crash/produce wrong data, depending on how often the different threads access lua, and sometimes you can be lucky and not see errors for a long time, but the possibility is always there.
If the problem came after you implemented multithreading then itâs definitely a thing you should check out.
This topic was automatically closed after 60 days. New replies are no longer allowed.