Ok, so in-game changelog is updated in the same batch as the game data on Steam ? That's good enough for now I guess. Eventually it would be great to be able to check if Steam really updated game and changelog fits to what I can see.

Of course I did that long before, otherwise I would not be able to use 0.8.0172 which is development version. But Steam seems kinda sleepy in updating or I am not sure how it works. Is there some way how to force check for updates ?

Nothing works. Restarted steam and launched TKOM and still 0.8.0172 there. Updates tab doesn't help in any way.

I would like to here a word from devs, how exactly is it setup. If all changes they do are immediately pushed to steam, or it's going in batches. And if each batch has it's version number.

Does anybody here has another version than I stated ?

Have you checked the LOG tab for error messages ?

Ok you are partly right, but it's much more simple.

It can be fixed temporarily by switching gui style while in vehicle, but some change has to happen. Meaning if there is arcade selected, I have to select normal first, go back to game and than again to the menu, switch to arcade and it magically works.

However it seems there is some issue with loading game and checking this setting. Once the game is saved (while in the vehicle) with arcade style and than loaded (even without quitting game), it reverts back to normal gui style.

That doesn't work either. I even tried restarting as I said before. Still getting only "classic".

I have also noticed these lines in filesystem.log if that means anything...

18:14:57:0943 R 1000625 :gui/layouts/hud_freeflycam.layout
18:14:57:0955 R 100061b :gui/layouts/ffcam_menu.layout
18:14:57:0989 R 1000630 :gui/layouts/hud_rover_sim.layout
18:14:58:0000 R 100062c :gui/layouts/hud_radialmenu_sim.layout
18:14:58:0001 R 1000622 :gui/layouts/hud_cameramode.layout
18:14:58:0002 R 1000626 :gui/layouts/hud_instrumentmode.layout
18:14:58:0003 R 1000634 :gui/layouts/hud_tabs_sim.layout

I think, this is more likely bug, as it should not thrust back to 450. Usual landing is quite straighforward except when some error happens. I recommend you to watch Log tab during landing.

Skipping whole landing would be nice, I have to agree on that too. However it goes with errors during landing as it was mentioned elsewhere. So with skipping it would mean even more randomized output of landing procedure or simply without any problems all the time.

Ok thanks. Just Steam seems kinda sleepy in updating. I had to force it by turning off betas and when it finished, switching back. Than I finally got 0.8.0172. That's why I got confused in first place and thought that dev build has the same version.

Running with admin rights seems to be working. This bug didn't happened again after couple of hours of playing. Tomorrow I will try again without admin rights and see if it's really an issue.

It's rather random and I am not sure how to reproduce it. I can trying running TKOM with admin right and let you know if it happens again.

I have found this rather annoying too, although broken wheel is not that big issue. Damaging some analyzer and finding about it when it should be used, that would be much worst.

Anyway, in my case wheel is usually damaged when driving off the landing platform. Even if landing goes without any error, I do a slow move and instantly there is error in log about breaking the wheel.

It seems to me, that it happens during unpacking procedure. When it lands with the rover on the bottom and than due to the weight of middle station it makes the part with rover to come up for a which is rather hard move and rover jumps into the air little bit. Usually when this "jumping" doesn't happen, there is no wheel break.

Also I am using all low grade components, so it's probably root of all evil there.

• Czech description as my english suck :) ---

Prostě když se to rozbaluje a přístalo to s roverem na spodku, tak váha té stanice uprostřed způsobí, že část s roverem se zvedne do vzduchu poměrně rychle a jakoby trochu nadskočí.

I can confirm this. With version 0.8.0170 it crashed even before "entering fullscreen", it froze immediately with game machine still displayed. With version 0.8.0172 it goes further, but still freezes upon turning whole screen black.

Not very helpful crash report...

------------------------------------

BALTHAZAR, 06.08 2013 15:25:57
Unhandled exception

Program: ...\!steam\steamapps\common\Take On Mars\TKOM.exe
Reason: Access violation. Illegal read by 0 at 0

SymGetSymFromAddr:126, addr:0x00000000
SymGetSymFromAddr:126, addr:0x00000000

I cannot imagine any kind of time acceleration as there are rocks in the way and other obstacles. Having super smart autopilot would amazing, but what would be purpose of the game afterwards ? Just taking photos/samples and rest will be done automatically ?

Well, there already is such thing :) No sure if intentional, but if you use click on control for forward/backward move on the HUD instead of keyboard, it will keep going :)

Well thing is, that if lander missed the target, there is a chance you wont be even able do most of the scanning tasks and possibly to take some photos.

Sure by achieving explore task you could send out another lander to finish remaining mission tasks, but at this point I am loading the game and trying to land again. Lets see what future updates will bring in.

I know it's too early, but it's the purpose of this tracker to collect ideas, isn't it ?

Sure, in real case scientist can draw chart, where is the rock, where is the rover and make calculation. Than they input commands to drive rover precisely on required spot. However neither of these thing can be do in the game.

I am not trying persuade anybody to put camera to the front, that doesn't solve a thing because than apxs need to be in back and it's same situation. However to have good immersion from the game without peeking through outside camera, there could be more tools to drive rover more accurately without need to actually bump into the rock several times.

Right, but for the full immersion I like driving by looking only in the camera. Outside view seems like cheating :)

Well don't tell me, that in real case if they want to do some apxs scanning, they are driving blindly just by looking in back. I bet there is more sensors that help them navigate on front side...What kind of science would that be, using just people mind to imagine distance and angle.

I guess this was too soon to report. I had found I can switch that camera to the front in the lab, which is great, but it should be definitely said so before launching first rover.

I believe that once popup windows will contain some valuable information, it would be great to have them there. So I am against removing them, but mouse I agree with the original suggestion.

Well it depends...I kinda like to have immediate feedback on my actions. I don't want to just drive around, analyze stuff and than after everything go to mission control and review results.

You are not in that rover physically anyway, it's view from the HQ and I am sure that popups are quite usual there as are other controls.

I think there should be possibility to add emergency parachute (does that even work on Mars ?) for some extra money spent. So expensive equipment can be retrieved later.

And what some version for advanced players and let them program the landing procedure by themselves ? :) There is plenty space for calculation errors. But surely it has to be optional.

@Accolyte: It seems, that "READY" is not enough, because as I had said, sometimes it just scans some other rock or whatever else. There should be visual confirmation about what rock you are really scanning.

Also rover controls in contrary are not very sensitive. There is slight delay when it starts moving and before you release it makes bigger move than intended. Never watched NASA video, but I would bet, they have this easier and it's not about angle of the rock.

It definitely needs more visual cues to make this type of scanning easier. I don't see any fun in scanning same rock 3 times from different angles. Compared to other scanning systems, this is slowpoke.

Yeah, it seems that APXS is very sensitive and sometimes it's scanning some other nearby rock rather than the one you require. There should be some visual confirmation what rock you are scanning instead of waiting till it is finished.

APXS can scan every rock, but only those highlighted are valid for mission. You have to be sure, that you are facing rover with correct side where APXS instrument is installed.

Yeah, watch for your distance indicator, it works only when there is exactly 0 distance. Having 0.1 doesn't work. Usually it means you really have to ram into that rock.

Scanners surely have some range to be able to work. Other thing is if you need to grab some sample physically. That should be solved with some arm, that can reach there.