command sequence

[dahunn 10]

So how does this work? is there a tutorial of some sort? or is it still buged.

So send a probe to a mission area. but it was still dark on mars. selected the wait command for 5 hours or so, and i wanted the probe to take a photo after the 5 hour wait. Could not get it to work.

and are the photo's then saves some where? to view in game?

[dram 14]

Hi dahunn,

Vehicles are simulated only when you are in the actual location (controlling a vehicle or free fly cam), so after that wait it should have taken the photo.

You can view the photos in the mission control room by selecting the vehicle on the map and then clicking on PHOTOS. You can even share them on steam from there :)

[dahunn 10]

Hi dahunn,

Vehicles are simulated only when you are in the actual location (controlling a vehicle or free fly cam), so after that wait it should have taken the photo.

You can view the photos in the mission control room by selecting the vehicle on the map and then clicking on PHOTOS. You can even share them on steam from there :)

but tje problem is that i can get in the command line the waiting period programed. But how does the command line look for taking a picture then?

i got something like this: wait 5h this is ok. as i can see a green ok text or something like that, ad i can add this line to the command sequence.

With the photo command it doesn't work that way or i can not get it to work. i write something like "photo (the desired camera)" but the command line gives a error message and i can not add the line in the command que.

could you give me an example of how a command structure is supposed to look?

[dram 14]

Ahhh, now I understand, sorry. Yeah there is COMMAND LIST button there that will display a list of possible commands for that vehicle. You'll note it should be PHOTO CYC-WIDE1.

Wait a minute... just looked and I see the problem, it seems it parses the line incorrectly, thinking that the dash in CYC-WIDE1 is another command.

I just went and fixed this now. It will be in the next build. :)

[dahunn 10]

Ahhh, now I understand, sorry. Yeah there is COMMAND LIST button there that will display a list of possible commands for that vehicle. You'll note it should be PHOTO CYC-WIDE1.

Wait a minute... just looked and I see the problem, it seems it parses the line incorrectly, thinking that the dash in CYC-WIDE1 is another command.

I just went and fixed this now. It will be in the next build. :)

Ok thx for the update.

[dahunn 10]

one more question: it would be nice if there was an option that the controlling of a probe or rover was only done using this script method. Now you can switch between them. maneuvering manually feels like cheating to me :)

[Trase 10]

Ahhh, now I understand, sorry. Yeah there is COMMAND LIST button there that will display a list of possible commands for that vehicle. You'll note it should be PHOTO CYC-WIDE1.

Wait a minute... just looked and I see the problem, it seems it parses the line incorrectly, thinking that the dash in CYC-WIDE1 is another command.

I just went and fixed this now. It will be in the next build. :)

This thread had created a question I never had before: Will we be able to leave the rover operating in the background in the future? I understand this is a hard task, since you need to load the map and it's physics to simulate. But since realistic rover programming is assured at this point (I hope), I wonder if you will take it one step beyond.

one more question: it would be nice if there was an option that the controlling of a probe or rover was only done using this script method. Now you can switch between them. maneuvering manually feels like cheating to me :)

Developers confirmed that they are still working on programming, with the intent to add a bit of artificial intelligence to the rover (Like real ones have, for example, navigating past the easiest obstacles. Curiosity can even create a 3d grid of his surroundings) and removing the need for manual controlling if you prefer that. I really hope that's still in the works. I'm fully aware that this game is not fully centered around what I want, though.

Edited August 5, 2014 by Trase

[dahunn 10]

seems to be fixed now.

however, still can not ad multiple commands.

example:

wait 2h

photo cyc-wide1

wait 2h

photo cyc-wide1

when i send these commands to a probe. it only takes one picture.

and i have to connect to the probe first in order to get the command working.

And it would be nice that i didn't have to connect to the probe to see the picture. in the map mode, For example i issue the orders of taking 2 pictures 2hours apart. so when i log in the game after 5 hours. I expect to find 2 pictures taken in the map mode where i can see the pictures.

Now when i want to see the pictures i can not see any pictures taken. I have to be connected to the probe in order to make the first picture. And then i only get one picture instead of the 2 that i programed in...

so it works but still buggy....

[Demongornot 10]

The thing that afraid me is that devs have "promises" that TOM will have a fully modeled programming system as the NASA have, including 3D system to look reprogramming things such as trajectory or rover arm position, and that it will be in combination with possibility to have real time delay between order, execution and reception of the answer on Earth from Mars...

But since they are a small team and they now focus on multiplayer...I'm afraid that WAY BETTER rover programming (even a simple working arm prog) won't be done before the release, same for the extremely important missing key binding options, we can't simply map my keyboard, idk why, i have already explain it...But in fact i simply don't play the game even if i like to help in development on games in general, i cannot map anything for the manned expedition for example...And while i NEVER use default controls in any games...

The rover should already have a working arm and waypoint path system on programming + possibility to edit commands and not to have to rewrite them all just cause we make a single typo error...AND a way longer authorized list of commands (the command queue itself and new commands).

I have in fact write a wall of text that explain a simple but nice (in my point of view) method to do it 5 month ago : http://forums.bistudio.com/showthread.php?175972-My-suggestion-for-this-10-April-2014-(long-post)&p=2665485&viewfull=1#post2665485

I'm sad that it don't seam to have interest devs...

Anyway i'm start learning to code in Assembly language (MASM and NASM) and i'll after learn machine language learn C and C++ which is probably the language this game is coded in, since we have access to source code i might be able to help in 2 or 3 month (i've no job i have all my time to work on it so it will be fast since i already find the MASM and the preview of the C++ i get easy).

But if a dev can confirm me please in which language the game is coded in C ? C+ ? C++ ?

ps :

For those who want a "preview" of the possibility of the rover programming, i've make this video :

[dahunn 10]

reading the road map. I've read nothing about the real time signal delay for the rovers or any change on the missions for the rovers. Is this abandoned? it is all about multilayer now.

[dram 14]

reading the road map. I've read nothing about the real time signal delay for the rovers or any change on the missions for the rovers. Is this abandoned? it is all about multilayer now.

The missions of the rovers will not be changing, we've already entirely overhauled the campaign once, resulting in 4 months of work. The generated missions will be improved, and the programming of rovers is still part of the plan. As for the one/two way light time delay, I cannot say for certain whether it will be added or not, but I would dare not promise, so I am inclined towards no. We did an assessment of what is needed for this, and it is no simple task. Giving a vehicle a whole series of commands means it must physically perform them in some way or other, according to how long it would take. This may sound simple but remember that you can break off individual wheels, instruments, all affecting how the vehicle moves.

Adding in a realistic delay which requires the game to be running in order to perform the action is easily possible, but is not exactly what is desired.

[Demongornot 10]

But if you can create a really advanced and complete vehicle programming, i see some few tricks to help having vehicles running in background and signal delay, or in fact giving the illusion to do it !

You agree that when we use the programming system for a rover, if we could hide the rover the game could run every physic simulation he want about that rover since it is the focused vehicle, well the idea will be that the rover already do everything in the same time as the player input commands (but in this state damage are simulated but not activated until we finish the program sequence, if we do a bad move but don't send the signal it will make no senses to get the rover broken), if we ask the rover to travel a long distance, he can, only during the programming sequence "time warp (not jump to)" to this location, a little like we have in some games with time acceleration in real time, Kerbal in one example, but DCS World is a way better example based one how fast we can accelerate without getting strange physic.

Anyway during the sequence programming we don't need any visual render for what the rover actually do in background since he is not supposed to do it, the game can focus at 100% on physic simulation (but with accelerated time if/when needed) and on rendering visual only for the "programming software" which can be visually simplified.

The game record while we programming what happen to the rover, as a playback file for example, since programming even trough simple script sequence can be long, the rover will get all the time he need to simulate this, and then if we switch to another vessel or to a human or what ever else, when we comeback to this rover, the game just load and render the playback based on the time, if we do a programming for the rover that is supposed to last 3h and we comeback 2h latter to see how he is doing, we will get the playback rendering for 2h after his sequence start Minus the signal delay, for the player it won't make any difference between this and having it in real time running in background.

But a lot of things can be done with this trick, including the possibility to see a fake 3D software for the program sequence which is in fact the real rover that we manipulate.

While travelling on flat terrain, the rover won't care about simulate it while we programming it, but he will simulate encounter with objects, and an error message can be show in case of damage as a collision prevention by the programming software for example which is in fact the rover simulating the encounter and the game interpreting damage without rendering them, the idea can also be to make the game re-rendering (but without time warp this time) physical encounter while the basic simulation is finish, in short, the game could simply pre-computed the physical simulation first during the programming from the player, and then, if the rover finish this and the player have not finish, well the game will take his time to finishing and polishing the physic simulation for the "playback", it will be a multipass physic simulation rendering.

The idea is, while the player input command for travel, stop at a location and use robot arm, the game will simply during this make a simplified simulation of what the command sequence make the rover doing, and the time the player finish the command sequence, the rover can make another physic simulation pass where he have strong interaction with the terrain, the idea is if the rover loose a wheels that the simulation know it soon as possible to avoid the need to rerendering a third time the physic for everything else with a broken wheels this time based on if you prefer the player to be or not informed in case of damages on the trip.

Two physic rover will be great, one for simulating terrain moving which is invisible, a travel one that will run even while the other also run, and the to simulate robot arm and/or sensors/mast etc (mainly robot arm) which can render arm in the fake programming software to having a NASA/JPL like programming capability, like this :

with all the tools such as where the robot arm have to go and at which angle and stuff like this.

And the rendering (trough this second rover) could be something like this http://www.jpl.nasa.gov/video/details.php?id=1171

Another trick for getting a little more time for finishing this should be a fake transmission display, a progression bar with a "Please wait, sending command data to the rover"

And finally if the player is really quick, the game can simply finish the rendering just after the loading, it will be a little longer to load but the result will still be at least here !

I hope my idea have help you !

Edited January 29, 2015 by Demongornot

[dahunn 10]

Great idea Demongornot, When i first bought this game it was al about the rovers. Now it seems the game is all about multiplay. It saddens me a bit. I hope they will look in to the rovers more.

[dram 14]

Very nicely said Demongornot, in fact, something similar is what we hoped to do. But I realized it cannot be done ahead of time, it must be done on request. The issue is that how long should you simulate it for? You can skip a year for example and that should affect it. There are many issues involved, which is why it was not done immediately.

[Demongornot 10]

Thanks Dahun and thanks Dram !

And nice to hear !

For those issues the way my idea work solve the issue itself, since rovers are not autonomous and only do what sequence we program them, the time we skip is not a problem, my idea consist of simulating what the rover will do (including the weather at the time he will do it of course) while the player do the rover programming sequence, which mean, longer will be the sequence, longer the player will need to do it and longer the game can meanwhile simulate with accuracy what the rover will do when the player will send the sequence to the rover !

As i state it should work like a replay files, which mean, don't matter how many time the player will skip, if he skip a single hours in a sequence that will need 3 hours to be accomplish, the rover will appear as it already simulate he have to be one hours latter !

And if the player skip 4 hours, well the rover will be on its final state as he have simulate he will be 3 hours after the program sequence start !

I think no one will ever make a 1 year sequence ! But with my idea, even if he does, since the rover simulate what will happen while the player program the sequence, well, it will still be okay, at worst the player will have a big file which is the rover "replay" !

So if we skip 1 year anyway, even with a 2 or 3 days long program sequence which is already really long and will probably took a while to do for the player, the rover will stay where he is for 1 year minus 3 days without doing anything, like the actual game where rovers are not simulated in background, after he finish his sequence, the rover will stay inactive and since my idea don't consisting of simulating what the rover do in real time, there is no issue with both signal delay and time skipping !

For the signal delay, the sort of "replay files" like that the game could use for this can simply be relative to the time of reception, if for example Mars is 9 minutes light speed away in its actual position, the sequence will be relative to the hours of the transmission + the signal delay, and it can also give the to player the possibility to start the sequence at a given time !

The only relation the rover will have compare to the game time will be when in the sort of "replay track" the rover will be if the player decide to load the rover before he have completed his sequence or stop it in the middle of his task (stop will be actual time + time delay), if the player look at the rover after loading it, the rover will simply execute in real time the sequence, and if he send a stop order, the rover will keep perform the task until he receive the signal !

The only possible issue will be if the player is too fast to do the sequence and the game don't have the time to simulate it enough, that's why i have in first place talk about first pass of simulation which is simplified, at worst he will not have a 100% realistic sequence but still have it !

Unfinished sequence simulation could also keep ruining on control center !

[dram 14]

No worries. Yeah like I mentioned this issue is simulating the physics and everything. Unfortuantely it is not as easy as recording it to a file, the issue is what ajnd how to record it, but even more important, how to simulate it to record it :) Plenty of things to take into account, such as sun position (for solar panels) weather, impacts on wheels, etc.

[Demongornot 10]

I think i have not correctly explain, as i said the best is that the rover that the player actually perform the sequence writing for, actually do what the player write meanwhile, he just don't see it cause its not rendered, which will take less resources than actually render it in real time, when i said simulate i mean just doing it, exactly as the game will do in real time if the player control it, but its just in accelerated when needed, because with less resources taken thanks to the non rendering, it can permit with those supplementary resource to handle the scene the player see plus possibility to speed up the rover in case of the player put a waypoint 1Km away, the "background" running situation will speed up to quickly check any perturbation on the rover from the trip, and every others things like power drain, light sources and stuff like this are also calculated but not rendered, the player only see the same scene, in fact based on NASA and JPL tools, it better have to be static, but meanwhile the game calculate the exact copy of the rover and can even fake a light source based on where the sun will be at this time, the game don't need to render it for taking it into account, so the player keep only looking at the same scene static, frozen in the same time as it would in real life with a Nasa/JPL tool, but actually the game really do the inputs the players write for the rover sequence !

Since the rover actually really do it, its only not visible for the player, i won't be more difficult to "simulate" than actually doing it manually because except that the player only see a single static scene, where he can only move camera and place a low polygon count rover (as we see on the real NASA/JPL tools) while the "real" game just do what he write, after all on the 3D tools of the JPL the scene don't include visual representation of weather and sun when they input rover arm position.

For the "replay like recording system", the goal is only if the player decide to connect to the rover while the rover actually perform the task, that the player can see what the rover actually doing, so this kind of replay file is only to put the rover in a certain condition, exactly like save files will do, but this is is based on the time, it will state what the rover do at this particular time, so the player will, once its loaded, have the game loading what the rover do at T minus signal delay which will just put the rover in a different time state, this can also permit to have both real time if we see rover from manned expedition and with delay from mission control !

After all we only need to know what possible effect the rover can have (arm/wheel broken, electricity level, stuck, course deviation even if i don't know how the real one react in this condition) previously encounter and where he is when we loading, and yes of course the science, all this data are gathered while the player input commands of what the rover will do since the game could perform it in the same time, its just a matter of recording those data relative to the time without creating a too big file that state the condition every microseconds and happen to have 100+Mb size for some minutes of rover moving straight.

That's why i was talking about replay like system which are know to be light in size compare to what it will be to record the condition every given time, the car game Dirt and DCS World are good example if this kind if things that include persistent states/damages, the goal its only to know what will be the condition of the rover at the time the player will load it if he was doing something else meanwhile, but the game have already "simulate" it and already know the exact time he have perform every actions, its just a matter when/if the player load the scene while the rover perform his sequence to have him at the correct place at the correct attitude/speed/animation/state/movement/power level and others conditions based on the game time, and what the player get can simply be delayed based on the signal delay time, the game will load the state of the rover at game time minus time delay !

If the player simply put a waypoint, the game will move the invisible rover along this waypoint, the player will have no possibility to know that the game do it meanwhile, and it will be realistic, the player only have at his screen a static scene and a low polygon and physicless representation of the rover that will just teleport to this waypoint, so he could see based on the data of the terrain at this position, what the rover will be able to do, taking picture of objectives, using tools etc etc !

The goal is only to know what the rover will do and providing a useful and functional rover programming tool for the player !

My idea permit to have complex/advanced rover programming, possibility for the player to have (fake) rover activity on background from mission control/another rover, signal delay applied to this, rover programming tool that can show message of possible collision/path occlusion/rover damage/too angled slope and all at once !

[slimisjim 10]

My mod sense is tingling....