No luck getting this to work so far. Initial attempt: forward & reverse keys did nothing, and vehicle was still attempting to reverse in response to some random axis's input. After trying to rebind W & S via the game UI, I managed to get the vehicle moving, but the handbrake was stuck on and could not be released, so movement is limited to a series of short jerks.

It looks like the answer is "Create New", and just accept the default path, because you can just ignore the 'project' after than and work on the Profile settings.

Hmm. When I open ArmA Reforger Tools I am presented with the Enfusion Workbench Launcher, and a blank list of projects, with options to "Create New" or "Add Existing". Which do I need to do in this case, and what path should I enter?

Thank you -dead-! I hadn't explored the Reforger tools and did not realise it had the ability to modify these things! I will try your excellent workaround!

Same problem here. Unplugging all my 4 x HOTAS devices just to play Reforger isn't really a viable option - it can easily screw up the configuration of other games that use them!

Indeed, there are still occasional oddities: http://i.imgur.com/4n1LodS.mp4

Well spotted! I have Saitek joystick, throttle and rudder pedals, and leave the rudder pedals plugged in even when not in use, as they are inconvenient to unplug. Unplugging them as you suggested does indeed fix the problem - I can get into the Mission Control screen and interact with it normally.

My preference would be for the program to ignore joystick inputs unless I specifically configure it to use them, or otherwise to have settings in the Options that allow such control. I have had similar problems in the past with programs that automatically use the inputs from the rudder pedals, and have no way to disable them.

It is curious that the main menu and options menu don't suffer from any problem - only the Mission Control screen (so far). Perhaps whatever logic they use could be applied to Mission Control?

In any case; thanks again for identifying the problem so readily! I'm looking forward to seeing how Take On Mars develops!

Agree with Bosgek - everyone can be made happy if "No Landing Failures" was made a tickbox option in a "Difficulties" setting screen.

In real life it would be impossible to land the probe by hand due to the communication delay times! :-) It could be done if it were controlled form a manned orbiter, though.

Now that would be cool - the ability to fund and launch a manned orbiter, and then have the "Mission Control" screen change to display the inside of the orbiter's command center!

I am encountering this same problem, running on a Matrox Triplehead in 3840 x 1024 mode. Switching to windows 1024x768 in the same game session makes the problems go away.

I also noticed some other odd behaviour in vehicles while remote-controlling an AI unit as Zeus. Possibly related? These include:

• When entering the Mi-290 co-pilot position (RH) it always auto-kicked me into the LH seat after a moment.
• Getting randomly ejected from vehicles from time to time.

I haven't thoroughly investigated these secondary issues - but they may be associated with the same underlying cause of the main issue.

This sounds similar to my experience. Started the campaign, and reached the point where we headed back to our starting camp on foot, and encountered our first enemy patrol. I don't know if Adams took any hits in that fight, but I stopped to loot bodies; I think Adams headed off to the next waypoint. When I got there, Adams did nothing, and I seemed to now be in charge of our fireteam (the two of us). I was able to proceed through the rest of the chapter by repeatedly telling Adams "proceed to next waypoint" and then following him.

The point is to make it easy for novice editor-users. A simply GUI option with four choices, for example. Having to change scripts is not really much different to how it is now.

This is related to reports #0000847, #0004675, #003254

Hmm; should probably have marked it "Feature" rather than "Major". If I can figure out how to edit the report, I'll change that.

Surely armapirx's suggestion is implementable? The system already has logic that detects that the player has crawled onto an 'unacceptable' surface, and changes them to an upright stance. Couldn't that same logic instead move the player back to the position they occupied on the previous frame - i.e. where they just moved from. The effect would be that their movement would be blocked (similar to how bushes and trees currently block your movement), until they raised their stance.

I can't count how many times I have been killed in a firefight because I bumped a stone wall!