My suggestion for this 10 April 2014 (long post)

[Demongornot 10]

Hello everyone !

First thing : I use the public and not the dev build, i have not test Mars Expedition One, i just know features from video and the forum.

I have new suggestions for Take On Mars !

Sorry if some of them was already stated by someone else.

_First, start with the new Expedition One.

-Have you heard about Bio Suit ?

Its a kind of space suit that use tight material rather than air pressure !

http://mvl.mit.edu/EVA/biosuit/ http://www.homeokinetics.org/spacesuit.htm http://en.wikipedia.org/wiki/Space_activity_suit

It have several advantages such as no air leak possible, hard to fit but when its wear it provide better movement liberty, its lighter, less place needed to carry, weight efficient etc etc

I suggest that for Mars Expedition One we can upgrade things such as suit variant and part of the suit.

It also work with another concept :

Resupply, make us able to launch cargo only capsule full of food, water, materials and upgrades for the suit, new lab equipment and things like this.

Technology for the suit itself and the rocket that will launch it was available i tech trees and give us possibility to carry more payload while reducing the cost and a launch failure possibility.

In short :

-Possibility to upgrade stuff in the suit, material for more resistant one, life support system (quantity and recycling efficiency), camera and tech slot, energy battery/cells and others equipment.

-Part of the suit and suit itself, like better boots, gloves, helmet, and new suit model, like : Martian standard space suit Mk1,2,3 (don't need visual change) and BioSuit for example.

-Resupply automated vehicle that can permit to the Expedition One's crew to get resupply, material for bigger habitation, new space suit, new object, possibility to upgrade cargo itself for reduce cost and risk, improve quantity, better greenhouse that can permit better efficiency which result it more available place in resupply vehicle cause less food supply will be needed from Earth, etc.

Also what about the possibility of several power source ? First we start with solar panels and when we have study aerodylamic physic for low pressure and low gravity environment, we can get vertical wind turbine and other air generator adapted to mars.

And of course this is ambitious, but what about terraforming possibility ?

Now about rover itself i have some new idea :

First thing :

A better indication on the mission page of what is the required vehicle, if we unlock medium rover before large lander but that we still want to launch a large lander (and call it Phoenix :D), its really bad to launch it in a landing site specialized for Rover where we need to move for analyse and do others stuff, its a waste of money and lander...Actually the only way its to look what is the game designed available vehicle for the mission...

In the tech tree, indication of what technology fit with which vehicle, i have manage to find it myself but even i have unlock some technology that don't fit with my actual rover, and its a waste of money cause i was forced to wait the next vehicle to use them.

So a good thing will be when we select a body type to be able to see what maximum technology fit with it, like showing a green dot next to this technology, or highlight in a specific color the items, so we can be able to unlock only what we need at first, and don't get a rover with missing things...

Technology upgrade, possibility to upgrade what variant of each technology we have, for example the APXS that was in the first rover such as Mars Pathfinder and Sojourner is a old version and probably have poor potential next to the one that was put in Curiosity, have possibility to get Mk1,2,3 and even more variant, which can unlock new mission objectives/better result that make us earn more money, it don't need any change in the 3D model (or at least at first), just on the values, and for install different variant you can use something like the "old" durability option.

URGENT/IMPORTANT needed update fix :

Actually, when we install the High-Gain Antenna on board of the rover (Medium one, i have not yet unlock the Large, i have restart several time the game) it take 3 slots, which is comprehensible do to the rotating aspect of this antenna, BUT two things should be able to be installed next to it, the RAD the the Solar Cell are both really low profile and should be able to be fit next to the High-Again Antenna without any issue/risk of collision, and it will permit to have both, better equipped rover and a back up solar cell/power source in case of issue.

Medium Rover should be able to fit on its top MAST, EAS, EMS, RAD, High-Gain Antenna and Solar Cell !

URGENT/IMPORTANT needed update fix 2 :

Small Rover need a Small Rover Arm to fit the APXS, which will permit to finally analyse sand with APXS, both real equivalent of the small rover, Pathfinder and Sojourner have up/down axis for the APXS.

You can see it in this video of the real one on MARS :

at 0:25 we can see the APXS slightly lowered, and at 0:38 we can also see it full lowered and analyzing sand.

It can fix issue of "hard to reach" rocks, "too flat/low" rock and sand analyse that stay unable, and it can extend missing variety by adding more sand analyse missing.

This video also show the need of make usable the MAST available on the Small Rover platform.

A small issue report :

The small/medium rover capsule with deflating bag should be slower to deflate those bag, they actually too fast and rather than slowly deflating it fall while deflating bags and sometime can break the rover.

Also this system, in real bounce way more than times the one in TKOM :

and the deflated bags should be visible (like the parachute) http://images.nationalgeographic.com/wpf/media-live/photos/000/010/cache/mars-spirit-landing_1076_990x742.jpg http://mes2cents.files.wordpress.com/2012/08/pathfinder_air_bags_-_gpn-2000-000484.jpg

For when delay simulation and real programming that will allow us to record what we want the rover to do itself will be available, possibility to get real rover speed will be nice for people who want, for example to feel like a real martian rover operator while programming its rover, lets him do what he want, and go to check its progress over a large period of time, cause real rover are SLOW, its top speed is about 5 centimeters per seconds, source : http://marsrover.nasa.gov/mission/spacecraft_rover_wheels.html demo :

Some people will like to programming its rover and lets it run for a long period of time and just connect to the game for check what the rover have done.

Small and Large Lander should not be able to take off again once the landing its completed, real Mars lander purge their tanks after landing.

Also the Large Lander actually experiencing a too low fuel consumption and difficulty to land, like of the thrusters are too much powerful it just hovering over the landing site and if we take manual control, it just can't goes down, even while pressing the "goes down" key it still goes up.

Future rover/lander between Curiosity (Large Rover) and Expedition One should be available, something like a Heavy Lander (who are able to take off and move on Mars using propulsion and mission's exploration point or user definite waypoint) and a Large Advanced Rover, more Missions for 0G Probes will be nice, but a new probe with more instruments and new missions set will be also a nice additions.

Cause need to launch a second 0g Probe ONLY for color picture its not really immersive...

Practicals options :

Possibility to disabled part of the rover and get them away from the control interface, or automated actions, like the solar panels, once deployed, their is no need to stow them, and even if we need, possibility with a simple button to deploy/stow them, same for light, when the game is laggy, its a pain to change instruments (since their is no key for this) but when we want to turn High Power Illumination on or off its a torture, available buttons in the interface for each high power illumination system, a available key slow for toggle instruments will be a nice addition.

Possibility to get more than 6 available camera, like a "next/previous" page that enable us to have more available camera on screen without issue of too much PIP running at once, possibility to reorganize them, its bad to see the Decent Camera on the slot 1, its should probably be put on the last slot since we only use it for the landing phase...

Possibility to have Primary, Secondary like actually + MAST with mouse, can be useful to get without toggle instruments every time, robot arm on Primary, robot head on secondary and mast on mouse, it will also prevent accidental arm move while moving the mouse.

For key options i have two request, first, an important one : possibility to clear key binding, cause when a key its already used somewhere else, we can't do that much except trying to remap the whole keyboard with keys that we don't use to lets key that we want to use free to be selected, its a pain...

Also actually the game have no support for the G13 gamepad's Joystick, i'm unable to map G13 axis and button to any actions, since i have a on/off switchable USB hub, all others joystick and device that have any kind of axis are disabled, the game just don't support the G13.

Also the actual roll left/right and up/down can be confusing, when its correctly mapped with roll left/right, the up and down options for the 0g Probe for example are inverted from what i want.

I not sure if the option : "Invert Aircraft Vertical Control" can help, but when i select "yes" and Back to Menu, it automatically back to "no" again, this will be nice to fix it.

Possibility to manage internal system, such as software, modes and others computer management, also disabled parts of the vehicle, or change things, if for the 0G probe for example one thruster get broken or damaged, possibility to disabled it and make the attitude control compensating from its absence when maneuvering the probe.

Or possibility to try to recover contact with a vehicle when a problem occur, sometime when time have too much affected the vehicle, it become unable to communicate with satellites again, we can fight to try to recover it, sometime it work, sometime it will be completely lost depending of the issue...

For those who don't have hard drive size limitation and like to have archives, can we please have an options to allow us to get more than 50 picture per vehicle ? after all we are at the 4To HDD era now, a lot of people have a bench of free/almost useless free space on their HDD !

Even my wallpaper folder have 730Mo of pictures (almost 1000 pictures)

Also my last suggestion/request its about a borderless windowed mode, since its more a game for relaxation that require a lot of time rather than a action game, it will be really nice to have this for those who want to do something else while playing or those who do others things while playing and having several screens.

Thanks for your time, i hope my suggestions/idea will be useful !

Edited April 10, 2014 by Demongornot

[Demongornot 10]

Hey, its me again, i have a new idea about the "rover programming"

I know that you plan to make in the future a high complexity rover programming system that allow us to do like NASA/JPL do.

But until this system become available/possible, i have an idea that can both help you to test a rover "pathfinding/waypoint" solution, simple, not unrealistic and can give to everyone the possibility to finally have a "automated" rover.

I have an experience in script and i use a lot software like Glovepie, so i know that my solution are 100% possible and not really hard to do.

A waypoint system based on a really simple concept.

First needed thing, allow in free flight camera to use it (to make like 3D software of the NASA/JPL and have good path making possibility)

Second, allow in Free Flight camera to see the pathfinding and the missions objectives such as "waypoints" objects like Rock, Sand and others area to explore.

Third needed thing is the possibility to set more than 20 command queue commands (after all today computer can easily record thousand of code line in a really soft file)

And the last thing for practical reason will be to be able to delete or edit a SINGLE command in the "command sequence", cause if we do a simple type error at the last line...Its a pain to write everything one more time.

Here is my solution :

When we unable the "waypoint mode" which will probably be the same system as the "point" system in the "command sequence" mode, it just need to be usable in free camera mode, and rather than just show a simple dot + a line, we see a dot + a large line on the ground, or in fact a tape more than a line, it can be 3 time larger than the distance between left and right middle wheels of the rover that we use.

We just can put several of them waypoint one after one, we can edit them (move them, delete one and create a new one between two of them).

The tape between waypoints will be useful for two things.

First, it will help the player to make a safe path between two place he want the rover to go for avoiding obstacle, he will have to check himself the patch to see if their is any rock or anything else that can block or damage the rover.

Second, it will be the solution for make the rover work.

When we put waypoint, well you probably already know the idea :

The game read the heading between the actual rover position and the next waypoint, it measure the distance and just create its own two commands : Left/right x deg and then forward x m, then the rover just do nothing else more complex than what the game can actually permit.

Except that the rover will never be able to go to the exact waypoint cause of wind and terrain angle that will make him go away from its path.

That the moment for the tape to be used, tape can use a system equivalent of the "analyse area circle", when any part of the rover (deployed arm, solar panels or wheels) go out of this area for, two seconds for example, the rover just check its position next to the tape, he just measure the distance between the closest part of the center of the tape and the rover and the heading, and then like if it was a waypoint, a turning command follow by a move command is set, when the rover its back on track he start again to measure waypoint itself (not the tape this time) and just start like if we just done create the waypoint.

This solution its simple, it don't require any kind of AI or pathfinding solution, it provide both for users possibility to make safe patch and for the game to run without crazy solution cause its one of the most simple that we can ever imagine, and its probably 100 working and not that hard to implement cause its simple scripting.

Note that this solution don't fix the "ToPoint" harm issue.

But this solution require during this mode to lets the player see ALL objectives of a mission, points for photo, area to analyse and point for waypoint.

The best will be the possibility to filter it per missions, and of course possibility to set a long queue for several missions one after one.

You can take profit of this to lets player choose what mission he want to assign to the rover in a simple list format (like the CTR tab that permit to choose and switch between vehicles) rather than just allow to select nearest.

Mission name (yellow/green = able, red = require instrument not found in this rover) - Mission reward in $K - percentage of completion.

For the ToPoint command, first, it can't work for a playerside if we don't state what instrument we want to put here.

"TOPT APXS1 ROBOARM1" will be better than just "TOPT ROBOARM1"

About that, since the TI-WIDE1 (for example) command can't be handle cause of the "-" symbol, rename it TIWIDEx or TIWx for the command side will be a good idea if their is difficulty to fox the "-" symbol issue.

For the Arms control, i have an idea.

First, the point that we can place should have a "green/red" state, why ? If we set a waypoint, and then a point for the arm/mast and them we want the arm to go here but that this is 10m away, the rover can't help us, so a simple "collision box (a sphere which correspond of the maximum rover's arm range based on the last waypoint before this command in the command sequence list, it need safe area of few centimeters to balance any rover unexpected movement like "wind slide")" which start at the arm attach point will simply make an area where we know that the rover's arm can reach.

If we put the point inside, it will be green, if its outside, its red and only usable with MAST.

Now that we are sure that the Arm can go to a specific point, their is tons of solution for make the arm go where we want.

Note that the player will also have to check himself if the rover is correctly oriented at this waypoint for lets the

For the player it can look like "TOPT 35 APXS1 ROBOARM1" (35 for example correspond to the number of this point, we can already place several point, i have check with the MAST and it really follow several point, but we need to be able to see them all and to have their ID number).

Then a simple solution for the game will be :

_Set the arm to unstow position

_Check point heading and rotate the rover arm to this yaw position.

_Use a "ghost" variant of the arm which is just represented by the path of the arm by a collision sphere which represent the head) that will just goes down and touch the point we want to touch.

_At this point it know basically at which position of the arm the head will touch the surface, and then he rotate the head to make the instrument correspond between arms position and object's surface angle based on where of the virtual head collision sphere the "point" have touch.

_And then the arm will simply goes down to the point and slow down when he is close, at this point when the instrument is whiting the acceptable range for working (not too far, not too close) he stop.

And here we go, we just need the next command set by the player to be "USE APXS1" and then "UNSTOW ROBOARM1" to avoid it to be broken by the next maneuver, and its done.

Note that we need some things to accomplish that.

First, the possibility to set the speed of the rover for the waypoint will be nice, like :

MOVETOPOINT 35 (waypoint ID) 25 (speed in Cm/s and Ft/s for example), possibility to set negative value for the speed, like -5, to make the rover goes backward, nice thing after done analyzing a rock and before turn the rover around without risk it to broke wheels/solar panels with the big rock we just analyse.

The game should know where the Rover will be based on the last command while the next writing command, basic position without wind and terrain angle that can make the rover slide.

Possibility based on this to know what is the camera's angle at the "point" we want, for example if the game know based on the previous waypoint's end position + things like move forward 10m the actual position of the rover, he can also permit to get a line that correspond to the camera position and then in a T shape at the end of this line, another one that just show the camera angle, it will permit to take picture whiting a correct range and avoid to be too close or too far to take this picture, it can also permit to set the zoom level with a visual indication of what area we will be able to see for the picture.

That's it for my "programmable rover" idea.

I have another idea about the arm.

Actually it can only goes up/down and left/right, but what about a extension command, (based on primary/secondary up/down and roll right/roll left key).

Cause i'm sure that nothing prevent the arm to fully expend like in this drawn

http://www.automationworld.com/sites/default/files/styles/lightbox/public/field/image/news_rover_futek1.jpg?itok=gGT4IoXU

Of course at first i understand that you can't use this complex method with the "topoint" arm system.

But at least using my idea will be possible while having a longitudinal axis.

It will process like this :

_Arm set to Unstow position by the game

_Check heading and process to arm heading set.

_Check the point distance from the arm attachment point and put the correct longitudinal attitude to the arm even if he still point up.

_At the longitudinal distance set before, create a ghost arm's head hit box that will come down simulate the arm decent (without speed limit) until something is hit

_Based on that, orient the head to make sure the instrument will be at the good position when the arm will be here based on the position where the object have touch the virtual arm head's hit box

_Make the rover's arm come down and when it come close enough, slow down and finally stop when based on what instrument we want to be here, stop the arm at the correct operational distance, and its done.

Note that the virtual head's collision box will give a better result if the size of the box is based on the instrument the arm try to put in the position and not in a "onmisize" one.

Also note that for the waypoint, the rover will better have to, when he is at the expected point, turn itself at the desired heading (based on the heading between the previous position before the command's launch and the waypoint position itself) to avoid badly oriented rover that just have "fix" his position cause he was go out of the track.

Sorry for the wall of text but i think this idea wort it.

I hope you will find my idea useful, i know you are busy, but it can be a simple solution to make it working without any potential big issue, and based on what the "command sequence" options can actually accomplish, it can with just some scripting permit to make a fully working programming system for rover actions !

I hope to see my idea in your nice game !