About 50 LUA errors / day. I now know that is not a question if Automation will crash, but only when.
Currently I got a crash every 15-20 minutes.
It often crashes on save model. If that has happened, it will crash every time I click sandbox until I manually delete the model file from Automation folder. Isnt it possible to add try catch around the loading menu so at least the game can not get permanently broken that way? Not everyone will be able to manage files manually and might give up in frustation.
Is that normal? Is it a problem with my computer and Automation runs fine on yours? Or has the game problems with its technology? I can hardly remember a program that crashed so often.
I’ve barely had any errors, you should post this in support next time. Are these errors the kind you can click past or does it close out the game? Have you installed mods? Is the car finished when you tried to save it, did it post stats in the trim tab? Also can you attatch your log.txt file.
Thanks I will try that. Although the LUA errors, null pointer exceptions, division by zero and such stuff do not sund like it has to with graphics.
Perhaps I am not playing the game “right” by clicking buttons in no particular order instead of just using the arrows?
My impression is that there is simply to much going on in the UI often for simple instructions (eg scaling an engine block from 4 to 6 cylinders) there is a lot of unnecessary sound / animation triggered in the background and they stack up and crash the system, especially if you dont wait and click several buttons in succession. The engine currently seems not able to handle a lot of user input.
Fullscreen implementation is another thing. I dont understand that it still cannot handle device lost, even such a simple thing as switching to desktop (to check an Excel sheet or something) will fail and lock up the program every time. That makes windowed mode probably unavoidable.
The ONLY crash I ever get is when I click PLAY and immediately change windows while the game loads, it will only crash then, I never get any other errors while playing the game on the current build. I also do not run fullscreen because of that “bug” I just made my window size slightly smaller than my screen size (due to start bar), no biggie IMO. Now one of the best things you can do is probably a fresh install, dont forget to delete the Automation folder in My Documents, also what are your system specs? Are you running on an integrated graphic chip by chance?
I sometimes have crashes when reloading a body repeatedly as I am doing small changes to my meshes, and I had the game crash a few times after letting it run in background doing nothing for a few hours, but I haven’t had any issues while tuning for challenges, and that involves a lot of clicking, adjusting and switching randomly through menus.
My suspicion is that I am not playing “right”. I often switch engines between chassis and jump between unrelated screens, change the layout of the engine etc. Love it when 20 sounds have to be played before the game responds again.
I also keep getting errors, and hopefully when the Steam update comes out they wil be able to fix it. I tried re-installing 5 times and still, I get calculation errors and stuff.
There are a lot of drawbacks to run windowed, and I don’t think the problems are even related to it.
I am a notoriously fast clicker and it’s Automation’s lack of responsiveness that is giving me problems. From my limited experience, it’s necessary to give the program more time to handle user input. For example, when I switch engines and then click “engine” I can hear approximately 15 sounds which are stacked up while the program “assembles” the engine. I now always wait until it finishes, before I add more clicks.
Tbh that’s weird design, lots of stuff is triggered before the program can respond again. I would suggest an optimization that makes sure sounds and animations are only played if the user really needs to see them. I am sure it would speed up the UI considerably and avoid other problems. This is a situation where programs should use suspended drawing. That means drawing to screen is suspended until all updates are finished. That way no work is going on the screen that the user doesnt want to see anyway.
To give a more concrete example, if a program wants to place the player at his current position in the level, you dont load the level and then move the player in real time through the whole level until he reaches the position, even though that might be straightforward to program. to mee it seems Automation does that in a way, and adds a lot of unnecessary workload. that is not good for responsiveness of the UI which in turn could be the cause for the mentioned hickups.
I know what he’s referring to, but I don’t think the game is playing the sounds for the sake of it. I believe its audio feed back that indicate the game is doing something (loading the engine in this case), rather than just sitting there.
It’s a bit like when you want the lowest from a stack of books.
You could take one at a time, put it down then proceed with the next, like peeling an onion. But if you can lift a whole stack you could do that all in one go.
The game seems to do the first approach which can take several seconds to complete.
I’m pretty sure its switching a lot of calculations and rendering processes behind the screens, same thing with block types. Its like loading a new map in other games walking in a building its got to switch gears, as it were, from trim to platform to engine and then from block to block and head type to head type. I’m not a programmer though so I’m not actually sure.
