Why does this game crash so often?

[BurningBridges]

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.

[nialloftara]

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.

[BurningBridges]

It always locks up the game. When I hit Windos-D or CRTL-ALt-DEL I always see a messagebox with a LUA error.

[Leonardo9613]

Try playing the game in windowed mode, it is unstable in full screen mode at the moment.

To enable it, go to options on the launcher and select windowed mode or unselect fullscreen mode.

[BurningBridges]

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.

[Jakgoe]

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.

No, I'm pretty sure the engine can handle lots of input, as that tends to happen when playing multiplayer... It never crashes for me then.

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.

That's a very known bug, which will be resolved when the game migrates to UE4. In the mean time, would it kill you to play the game in windowed mode?

[BlastersPewPew]

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?

[TrackpadUser]

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.

[BurningBridges]

It wont help much to reinstall I just bought the full version yesterday

Here is an example does this look like graphics issue? I rather think something else is going on.



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.

[nialloftara]

There's been a lot of corrupted installs lately, try following these instructions first. http://automationgame.com/phpBB3/viewtopic.php?f=16&t=1271

[BurningBridges]

Thanks I will try that.

[Stewie140]

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.

[BurningBridges]

It got a bit better since I know where I have to click, when I was using the menus by try and error it was much worse.

[brockers]

Doesnt for me. Usually mess abuot with it 4 hours a day.

NEED v6.

[BurningBridges]

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.