OHM Space Network Plugin

[4throck]

Seems very interesting.

I like the idea of command uploads.

You are only missing the most important one: take a picture! :thumbup:
OK we don't need actual image files to be saved, just moving the default camera to the target spacecraft's location for a few seconds will do.

 

[fred18]

You are only missing the most important one: take a picture! :thumbup:

It's there and working!!! you can send pictures from any vessel, or request picture from ground and you'll receive the picture from within the chosen vessel itself!

here's a sample, focus on the ISS, received one picture from a landed DG and one picture from the lunar space station in moon orbit, (moon is a bit dark but it's there in the upper part of the picture)

OK we don't need actual image files to be saved, just moving the default camera to the target spacecraft's location for a few seconds will do.

and it saves the files automatically!

[EDIT]
I have to add the send picture command also to the default commands that can be sent over radio, I forgot that

 

[4throck]

Great! I haven't tested the MFD yet, busy with the Multistage Titans

 

[fred18]

Map Screen of the MFD is in progress, what you see is not the default map mfd, but the space network one!

here's some screens together: dialog, links screen in external mfd, and two views of the map screen:

 

[Ripley]

I remember the original MAP Mfd had a huge impact on fps in the default dxd7 engine.
Does yours have it too?

 

[fred18]

I remember the original MAP Mfd had a huge impact on fps in the default dxd7 engine.
Does yours have it too?

That's a question that I've been asking myself too, since I have to say that to display the map and everything it's quite computing intensive. But to be honest (don't hate me) it is really difficult for me to guess because I'm running orbiter on my new pc which is quite powerful. I noticed a drop in FPS from 1500 to 1400 but I can't say if on low end machines the impact will be bigger, only testing from users once released will say it.

The good part is that the map screen is just one out of the three screens, which gives just a graphic reference, so even if it does have impact on FPS the user will be able to use easily the links screen and the messages screen of the MFD without any impact, and will have availbale all the functionalities.

Moreover: the dialog map tab instead (upper right part of the picture) does not have any impact because the map image is a graphic file and not "drawn" line by line as it is in the mfd, so even if the mfd's map screen impacts, the user can simply use the dialog map.

:tiphat:

 

[4throck]

Perhaps you can force the map to update manually, or very slowly. Even with low orbits 1 second should be enough.

Please remember that many people run Orbiter on older computers.
Mine is 10 years old... Other have powerful machines but run it on low spec laptops.
So smooth performance is always a good thing.

 

[fred18]

Perhaps you can force the map to update manually, or very slowly. Even with low orbits 1 second should be enough.

Please remember that many people run Orbiter on older computers.
Mine is 10 years old... Other have powerful machines but run it on low spec laptops.
So smooth performance is always a good thing.

I agree with you. as far as I know with the MFD there is no way to modify the update frequency from the MFD itself, so there's not much I can do about it.

The suggestion you make is instead massively used in the dialog: everything is updated either on request or on a time frame like 1 second or 1 decimal of second depending on the function. This really reduces the FPS impact to minimum (I couldn't notice any impact with the dialog and with most of the mfd functions).

Just as a remark the core of the plugin is within the dialog, which includes all the possible functions and possibilities of the Space Network plugin, the MFD is just a useful repeater for some of the functions, so since the dialog does not impact at all on performance the usage of the plugin is not threatened by performance loss.

 

[4throck]

The MFD update frequency can be set by the user. But you can call a function once a second (for example) even if the MFD runs faster.

Pseudo code:

IF current_time_in_seconds == even number THEN run my function

Integer divisions are useful for this kind of stuff.
I'm using this to animate blinking lights once a second in LUA.

 

[fred18]

The MFD update frequency can be set by the user. But you can call a function once a second (for example) even if the MFD runs faster.

Pseudo code:

IF current_time_in_seconds == even number THEN run my function

Integer divisions are useful for this kind of stuff.
I'm using this to animate blinking lights once a second in LUA.

I use a timer variable (initialized to 0 of course) which I keep updating
pseudo code:

timer += oapiGetSimStep();
if(timer> defined_interval){
timer = 0;
//do your stuff
}

anyway with the MFD the computing intensive stuff is not the calculalus, but the drawing itself: the earth coastlines are made up of nearly 10.000 points, and if you don't keep the drawing updated you'll get a black mfd screen.

Anyway I spent a lot of time to optimize the code in order to minimize fps impact, so I'm very confident that users with old pc won't experience any remarkable loss of performance. I'm quite sure that with the dialog (which includes a big and nice map) and with the other two screens of the MFD they won't experience any loss of performance at all. I'm confident that also with the map screen this will happen as well. We'll see shortly, since I think that I'm not far from the release of the plugin.

 

[Urwumpe]

If you keep the remainder of the time (time -= interval or time = fmod(time,interval) ) instead of resetting it to zero, you have a more constant update and reduce the jitter a bit.

 

[4throck]

Fred18, all this is just constructive discussion
I'm sure it will work and perform very well!

 

[fred18]

Fred18, all this is just constructive discussion
I'm sure it will work and perform very well!

Sure it is! I hope my words aren't taken in the wrong way, I'm just trying to explain various aspects, but criticism and suggestions are super very welcome! :thumbup:

---------- Post added at 23:20 ---------- Previous post was at 10:58 ----------

In the meantime the work is almost complete. MFD is basically finished, dialog already works fine.

I implemented the proper key conversion so now if a user wants to send a keypress to the vessel the command will be :

cmd: initial_mjd duration sendkey shift_parameter alt_parameter ctrl_parameter key
with: 
initial_mjd = mjd of keypress
duration = superflous but has to be there for consistency with the other commands, any number >0 is fine, a single key press will be sent anyway
sendkey = command, has to be written like this (or with capital letters, doesn't matter)
shift_parameter = if set to 1 a shift press will be simulated, 0 if not wanted
alt_paramter = equals to above with alt key
ctrl_paramter = equals to above ctrl key
key = the letter you want to send, letters, numbers, and numpad keys are allowed

examples:

cmd: 51989.2247 1 sendkey 0 0 0 numpad5

will engage the killrot (note that for that you can also send cmd: mjd duration defap 1 0 0)

with the deltaglider

cmd: 51989.2247 1 sendkey 0 0 0 g

will lower or raise the gear, as if the G key was pressed

and so on.

Now just some minor fixes and... documentation, which will be quite huge since the addon is very big... I'll do my best about it...

 

[fred18]

I'm supposed to be writing documentation but, while I write, new features come to my mind and I start to add them.

The latest one: it will be possible to preload via scenario file a text file of messages to send automatically from ground network at simulation start. This will allow the users to save commands for a specific ship in a specific scenario in one file and then simply pass everything with the possibility of replicate anytime the scenario all in automatic.

Example situation: I want my rocket to fire its engines at a specific MJD and my tower to retract its arms in that moment? I simply write the two simple lines of commands in a txt file and I specify the filename in the scenario file of the SpaceNetwork: when I'll load the simulation, the commands will be sent automatically and I'll see them happening without having to do anything.

Note: the filename of the commands will not be automatically saved in the scenario file on simulation closing, otherwise anytime the user would close and reopen the scenario to continue the mission, the original commands of the first scenario would be resent, leading to unwanted situations, so the filename must be specified manually in the first scenario file.

 

[fred18]

And this is the latest addition.

It's going to be a basically just for fun thing, with the main screens working and nothing else in particular, but I think it's consistent with the whole Space Network idea and it can be fun as well.
It's not going to be a mandatory part of the addon. Simply in the network configuration file the user can add the item "MCC" or not, the whole system will work either with or without.

---------- Post added 4th Aug 2017 at 11:54 ---------- Previous post was 3rd Aug 2017 at 13:34 ----------

some updates with the screens starting to work. the update frequency is very low (once every 1.5 seconds) in order to not impact fps since the screen update operations are highly intensive. Those will happen only in the virtual cockpit of the MCC anyway, so no general issues for low end pc.

 

[fred18]

here's from the flight director position, you can have the mfds while looking at the big screen. Of course the MFDs will refer to the MCC vessel, but some of them may be used with the target vessel as reference (multistage 2015 mfd can, orbit mfd etc)

I had at first the idea of letting the user choose what to see in each screen but it rapidly escalated in a super complicated deal to organize, that would have become tedious to code and to use, so that's the solution I thought about:

 

[fred18]

Here's the updated station's list that will be included in the package:

# Item Name Lng Lat
1 DSN DSN Goldstone -116.89 35.426667
2 DSN DSN Madrid -4.248056 40.431389
3 DSN DSN Canberra 148.955778 -35.628611
4 DSN Esa - Cebreros -4.367782 40.45298
5 DSN Esa - New Norcia 116.191612 -31.048475
6 DSN Esa - Malargue -69.39806 -35.776062
1 TDRS TDRS 6 -46 0
2 TDRS TDRS 7 85 0
3 TDRS TDRS 8 89 0
4 TDRS TDRS 9 -12 0
5 TDRS TDRS 10 -174 0
6 TDRS TDRS 11 -171 0
7 TDRS TDRS 12 -41 0
1 TS Nasa - Fairbanks -147.723056 64.843611
2 TS Nasa - Wallops -75.45736 37.9386
3 TS Ksat - Svalbard 15.397458 78.229656
4 TS Ssc - Welheim 11.080743 47.880495
5 TS Nasa - Guam 144.736776 13.321624
6 TS Ssc - Dongara 115.354337 -29.045054
7 TS Nasa - McMurdo 166.666102 -77.839449
8 TS Sansa - Harteb 27.705663 -25.887554
9 TS Ksat - Troll 2.533368 -72.012368
10 TS Ssc - Santiago -70.667673 -33.150244
11 TS Nasa - White Sands -106.41953 32.943241
12 TS Esa - Kourou -52.700853 5.167234
13 TS Esa - Kiruna 21.10653 67.891797
14 TS Esa - Redu 5.14796 50.002369
15 TS Esa - Villafranca -3.951459 40.442623
16 TS Esa - Maspalomas -15.630838 27.763474
17 TS Esa - Santa Maria -25.136393 36.997287

 

[N_Molson]

Awesome, always thought there was a need for something like that ! :thumbup:

 

[Kyle_E]

Amazing work so far! Are you open to beta-testing volunteers?

 

[fred18]

Amazing work so far! Are you open to beta-testing volunteers?

Sure I am.

I had to pause the development even if it's almost finished because I just became father :sweet:, but if anyone is interested in testing the space network I'd be pleased to share!