Mission scripting: the old Sdvig

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,814
Reaction score
869
Points
203
Location
Earth
Website
orbides.org
Preferred Pronouns
she/her
Several years ago i made a scripting system for Orbiter - Sdvig.
It was designed to allow interactive events in Orbiter, like missions and advanced controls, with both capabilities demonstrated by "Orbiter: First Mission" rescue scenario and hover engine control modification script based on even older Intermod add-on.

The system was a fiasco, for many reasons i know, like a lack of documentation and enigmatic script code, and others i don't know.

Sdvig is based on an emerging pascal compiler i called Paser, the scripts look and work like pascal programs, a syntax, that is both versatile and had newbie teaching in design.
For example, the most of the script to change the default behavior of hover engine control keys looks like that (Lines starting with // are comments):
Code:
//Hover throttle

  //getkey(key) checks for the keypress of the "key", if key is pressed returns true, otherwise false.
  if not getkey(VK_CONTROL) then begin
   if getkey(VK_INSERT) then begin
    //If the ins wasn't pressed, save the current thrust level, assume it's pressed, and set full thrust
    if not othm then begin othl:=get_thrust_level(cvn,THGROUP_HOVER); othm:=true; end;
    set_thrust_level(cvn,THGROUP_HOVER,1);
   end;
   if not getkey(VK_INSERT) then begin
    //If the ins was pressed, restore the current thrust level, and assume it's not
    if othm then begin set_thrust_level(cvn,THGROUP_HOVER,othl); othm:=false; end;
   end;
   //Kill thrust
   if getkey(VK_DELETE) then set_thrust_level(cvn,THGROUP_HOVER,0);
  end;
  if getkey(VK_CONTROL) then begin
   //Increment thrust and save it as current
   if getkey(VK_INSERT) then begin set_thrust_level(cvn,THGROUP_HOVER,get_thrust_level(cvn,THGROUP_HOVER)+0.01); othl:=get_thrust_level(cvn,THGROUP_HOVER); end;
   //Decrement thrust and save it as current
   if getkey(VK_DELETE) then set_thrust_level(cvn,THGROUP_HOVER,get_thrust_level(cvn,THGROUP_HOVER)-0.01);
  end;

The scripts can be scenario-dependent, that is achieved by putting some lines into the scn file.
For example, Orbiter: First mission scn file definition:
Code:
BEGIN_Sdvig
 MFD_Mode=Screen
 Scenario_Script=missions\ofm
 # Event handlers - redundant
 ontimer=ontimer
 ondraw=ondraw
 onstateload=onstateload 
 onstatesave=onstatesave 
END

And that about finishes a general description.

The point of this thread, then, is to find out, does anyone want a system like that?
And that is not in terms of using the missions, which is obviously wanted (is it, btw?), but in terms of making the missions and scripts, since it will come with hardly anything included - a rescue mission and some demos.

Condensing it together, is it worth developing further? And if yes, what are to be expected from it? I'm open to ideas and opinions.

-------------------------------
The current relatively stable version you can try the system in action on could be found here:
http://orbides.1gb.ru/orbf/sdvig_0.7_alpha_080517.zip

The reference documentation is the "script\Sdvig-Reference.exe" file.

The scripts are in "script" directory, mission and demo script-enabled scenarios are in "Scenarios\script" directory.

Global scripts, like Intermod, are run in every scenario if active.
"Scripting config" Launchpad button allows to select active global scripts.

-Orbiter: First mission code is scripts\missions\ofm.pas
-Intermod code is script\intermod.pas
-Scripting demos are in script\demos

Well, and some screenshots:
Text and info displays:
sdsc1.jpg

Camera sequences (cut-scenes and pseudo-movies):
sdsc2.jpg

Mission timer:
sdsc3.jpg
 
Of course it would be worth developing but you might want to consider using the Lua scripting of the new ORBITER engine or at least use Lua as the language (although they are very similar).

Would you be able to spawn and delete vessels in the script. If then, there are many possibilities.

For example, one could imagine a scenario where a shuttle must deliver a module to the ISS. When a EVA to connect the module fails and the crewman drifts away from station, the Secondary mission would be to dock with crewman and return to station.

I enjoyed sdvig, it gave Orbiter a fresh feel. It also made the rescue mission seem to have a greater purpose than those commonly included with DanSteph's DGIV.

Your work has always surprosed me Artlav, they show your dedication and imagination.

BTW looking forward to any progress on OGLAClient
 
Wow, that's a great stuff, somehow I completely miss that. May be cause I discovered orbiter too late to see sdvig for the first time. And I would not say that it is poorly documented.

And heh.. And it looks like I'l never finish a thing - I was making a scripting system for my pet addon, but I have stopped working on it after I've seen news abput Lua scripting in orbiter 2008. Now I was considering to make a camera for cutscenes, until now :))))

But back to the topic: Scripting in orbiter is really what I wan't. And for that same reason - I wan't missions, interaction.
So yes, I want such a system. And I think it is very important for orbiter to have scripts.

And of course there is that Lua issue. I mean the language is nice (damn, I love it's tables), is more or less industrial standard for scripting, and have great modules (nothing extraordinare, just usefull stuff - sorting, math, pattern searches for strings, file io). I guess it would me more productive to integrate Lua in Orbiter.

But no matter what scripting language it is, I think there should be a good way for communication beetwen custom modules and script. And good tools for user/script io are important as well. Keyboard control is nice, text inputs are good as well, but *fast* GUI implemenatation could really make the difference. Well, may be script-created GUI is not nesessary, since it is hard to make such system. Complicated user interface could be made by custom module if needed. But then again - script/plugin interation is very important
 
I'm still trying to wrap my mind around what possibilities could come from such a project, but even where I'm at, I'd say it's an unequivocal "YES PLEASE!"

There are very attractive uses such scripting can bring, and I'm thinking like many complex projects, the possibilities will continue to pop up as it develops.

Excellent stuff, Artlav!
 
you might want to consider using the Lua scripting of the new ORBITER engine or at least use Lua as the language (although they are very similar).
And of course there is that Lua issue. I mean the language is nice (damn, I love it's tables), is more or less industrial standard for scripting, and have great modules (nothing extraordinare, just usefull stuff - sorting, math, pattern searches for strings, file io). I guess it would me more productive to integrate Lua in Orbiter.
I'm not going to use lua at lease because Orbiter beta engine's scripting already uses it, no use to reinvent the bicycle. The said scripting is also somewhat hardcore in syntax and concepts, which i think, defies one of the purposes of making it - simplicity of use.

Would you be able to spawn and delete vessels in the script. If then, there are many possibilities.
It certainly will be possible.

BTW looking forward to any progress on OGLAClient
Still waiting for Dr. Martin to give something to work on.

I think there should be a good way for communication beetwen custom modules and script. And good tools for user/script io are important as well. Keyboard control is nice, text inputs are good as well, but *fast* GUI implemenatation could really make the difference. Well, may be script-created GUI is not nesessary, since it is hard to make such system. Complicated user interface could be made by custom module if needed. But then again - script/plugin interation is very important
Interaction between user modules and scripts? Like ability to define a function call usable in the script, change variables, call script subroutines?
Fast GUI implementation - like a run-time script editor, console, script-controlled in-game windows?
 
Sounds interesting. People like good, logical and pretty languages. Remember that...

So... will this allow scripted auto-pilots? For example, if I was flying to a base on the Moon, where a Glider is parked, and I get within a k or so, would I be able to script in something that tells the parked Glider to preform a hover take-off, climb to 20 meters, engage the auto-hover and level auto-pilots, turn to heading xyz, and punch the throttles down? 'cause that could allow for some interesting "Chase Tony Mokbel around the Moon!" (just an example) sort of missions, especially with the camera sequences.

Just another thing: will it allow scripting in sounds and so on? And what about a sort of lock-out feature, so I just can't jump into good old Tony's DG and bring him to me?

Suggestions aside, this looks like a great idea. If it's finished before the end of term here in Vic, I might just include some scripted scenarios with my first add-on... But first I need to learn C++. Which will have to wait until the end of term as well...

EDIT:
May be cause I discovered orbiter too late to see sdvig for the first time.
We all discover Orbiter too late.
 
Interaction between user modules and scripts? Like ability to define a function call usable in the script, change variables, call script subroutines?
Fast GUI implementation - like a run-time script editor, console, script-controlled in-game windows?

About interaction - Suppose i'm making script for space shuttle mission. And I wan't script of shuttle's state: whether the payload doors are open, RMS status, etc.
And the other way around - I wan't script to be able to send messages to vessel.
I mean there should be library for that, so it could be included in plugin's code. It could be like this - when vessel opens payload bay it change slot1 value from 0 to 1. And any module (or script via it's function) could see that.


Oh and one more thing

Say, i'm making a linear mission, a checkopint race.
Using beta's script i could make it like this:

[bad pseudocode]
Wait till ship completes task1
Wait till ship completes task2
Wait till ship completes task3
Show congratulations and hiscore
[/bad pseudocode]

In sdvig i have to do it this way

[bad pseudocode]
At start:
Set current goal to task1

At every step:
if current goal is task1
then check if ship completes it
if it does Set current goal to task2

if current goal is task2
then check if ship completes it
if it does Set current goal to task3

if current goal is task3
then check if ship completes it
if it does show congrats and hiscore, set curren goal to task4
[/bad pseudocode]

Is it possible to change this situation?
 
People like good, logical and pretty languages. Remember that...
Paser is hopefully logical enough, but good and pretty are very subjective terms...

So... will this allow scripted auto-pilots? For example, if I was flying to a base on the Moon, where a Glider is parked, and I get within a k or so, would I be able to script in something that tells the parked Glider to preform a hover take-off, climb to 20 meters, engage the auto-hover and level auto-pilots, turn to heading xyz, and punch the throttles down? 'cause that could allow for some interesting "Chase Tony Mokbel around the Moon!" (just an example) sort of missions, especially with the camera sequences.
Hm. The Ascent demo does almost that, only triggered by key press rather than focused vessel distance.

I think some kind of framework is due to be developed to make autopilots simpler to define than the bare finite state automaton.
Any ideas or suggestions on how to do it "logical, good and pretty"?

Just another thing: will it allow scripting in sounds and so on? And what about a sort of lock-out feature, so I just can't jump into good old Tony's DG and bring him to me?
The sounds are already in (sample in Ascent demo), the lock-out is not entirely - the user controls and time wrap rate are overriden by script commands, but you can still change the focus or use non-script-controlled controls.
 
Say, i'm making a linear mission, a checkopint race.
Using beta's script i could make it like this:

[bad pseudocode]

In sdvig i have to do it this way

[bad pseudocode]

Is it possible to change this situation?
Depends on how you define change the situation.

Both approaches are logical, and you still need to define the tasks in the first example, while in the second they are provided along. The overall amount of code will be the same, and which approach is better is highly subjective.

I think things like proc.wait_simdt(3); could be done, but the whole multi-threaded parallel scripting is definitely beyond the add-on-space scope.
 
Will the scripting allow any networking capability?
Networking as in multiplayer/remote mission control?
Unlikely unless asked for.

I can include a networking module - something you can send/receive data over TCP/IP with, but the other side server or client had to be programmed independently. It could be another Orbiter running script, but i see little use of it without serious synchronization, ala OMP. A chat MFD could be made easily that way, tops.
 
I use Delphi so I think a pascal based scripting language would be great :)
 
A bump of hope.
That one is still worked on.

The vessel module-script interactions, better user/developer interface, autopilot controls basics and fuller function set is along the current work list.

Any better/new ideas are still accepted.
 
For me, module-script interaction is very important (and I'm glad you have mentioned it), so I'm stiill interested in SDVIG.

Hope someone else can find scriptiong engine usefull too
 
I'm not familiar with this particular type of code, but then again the code I worked with was for use in a military game. :beach:

I would encourage you to further develop this.
 
Lack of documentation?
What about the tutorial I sent you, Artlav?
The last one i got was from december 2007, and that time you said that you will wait till the interfaces are fixed as to not to redo the work.
 
I'm not sure if anyone is still watching this thread, but I really like the possibilities that his has. Well done so far, but I was wondering if it's possible to code in events for a vessel that doesn't exist when the scenario starts. IE. a UMmu that exits a ship.

If development on this has stopped, does anyone know when the new Orbiter with LUA will be out?


[EDIT]

I was wondering if it's possible to code in events for a vessel that doesn't exist when the scenario starts. IE. a UMmu that exits a ship.

Just for anyone else who was wondering that, I found a way that works:

Code:
program tst_init;
target script;

var b:integer;

procedure ontimer(simt:double);
begin
if get_vessel_id_by_name('UMmu_Sec-Captn_Dave')<>b    then
if object_distance('Gl-01','UMmu_Sec-Captn_Dave')>20 then set_screen_text(2,'Good!')
else set_screen_text(2,' ');

end;

begin
b:=get_vessel_id_by_name('Nobody_will_name_a_ship_this')

end.
 
Back
Top