Project Mission Control For Orbiter (Rebirth)

[davewave]

It was done this way to avoid conflicts between multiple clients trying to use the same ids, and the additional exception handling involved. What's the issue?

well the problem is that until now, my program recognises the incoming command based on the initial bit of text, eg: "ORB:SIMTIME" and my program disects the ORB and SIMTIME and then knows to update the simtime based on that.
But now with the subscription all I get is the UID number which is difficult to match up to the command because with a thousand other things incoming at the same time the program can't compare the uID as an integer as opposed to text.

Look, long story short, I think that if you want to keep things kosher, provide two commands:

the first is the one that already exists which makes the orbconnect module assign a unique ID.

the second should be one which allows the client to assign a UID.
In my program i would develop this so that its nearly impossible for another client to get the same ID.

so for example the command might be: "SUBSCRIBECLIENT:UID:25:Command"
keep the UID as an integer though

where the "subscribeclient" is the command which your orbconnect recognises to assign the command to the provided UID.

Would that make both our parties happy?

Also there are so many other API command i would love to have access to.

Right now the elements1 and elements2 seem to be transmitted a bit messed up on my end for some strange reason.
I was wandering if you could provide an Elements3 which delivers the two combined in one transmission.
When you do create this PLEASE PLEASE include what each element in the array in your documentation because otherwise im constantly having to look up the API guide and your guide.

If you could do this one thing it would greatly simplify my code because having to make two calls (even if they are subscribed) means getting the data at different times but I'm trying to render all the displays at the same time

 

[yagni01]

well the problem is that until now, my program recognises the incoming command based on the initial bit of text, eg: "ORB:SIMTIME" and my program disects the ORB and SIMTIME and then knows to update the simtime based on that.
But now with the subscription all I get is the UID number which is difficult to match up to the command because with a thousand other things incoming at the same time the program can't compare the uID as an integer as opposed to text.

There are several ways to solve this. For example if you want to match the message name (SIMTIME), you can use the subscription to create a map/dictionary entry that when it received "1000" it would lookup "SIMTIME" and pass that on. Take a look at the RemoteMFD code on sourceforge for a working example.

Also there are so many other API command i would love to have access to.

Let me know what they are, and I'll see what I can do.

Right now the elements1 and elements2 seem to be transmitted a bit messed up on my end for some strange reason.
I was wandering if you could provide an Elements3 which delivers the two combined in one transmission.

See the Orbiter API reference. Both messages return data from the ELEMENTS struct (in order) and the optional ORBITPARAM struct for elements2. If data is messed up, thats usually a sign that you're converting the string value to an improper type or they're not being populated in the correct order. Try checking the values against the Java test client included with Orb:Connect.

 

[davewave]

hi,
when i send the command
"SHIP:FOCUS:Elements2:Earth:0:0" I get the following in my message log:

SHIP:FOCUS:Elements2:Earth:0:0=Earth,3189783.472588,0.997341,
0.276173,4.755459,4.164698,1.023105,0.000000,0

Why does earth appear twice and then0=earth and how come all the kepler elements from the expected ELEMENTS structure are missing? I only count 6 or 7 not the 12 as listed in the API????!?!?
please help

Edit:
Yagni I don't think the elements1 and elements2 is working properly because when i call them i get the same numbers for each and also the same number of variables returned.

 

[Hielor]

well the problem is that until now, my program recognises the incoming command based on the initial bit of text, eg: "ORB:SIMTIME" and my program disects the ORB and SIMTIME and then knows to update the simtime based on that.
But now with the subscription all I get is the UID number which is difficult to match up to the command because with a thousand other things incoming at the same time the program can't compare the uID as an integer as opposed to text.

Look, long story short, I think that if you want to keep things kosher, provide two commands:

the first is the one that already exists which makes the orbconnect module assign a unique ID.

the second should be one which allows the client to assign a UID.
In my program i would develop this so that its nearly impossible for another client to get the same ID.

so for example the command might be: "SUBSCRIBECLIENT:UID:25:Command"
keep the UID as an integer though

where the "subscribeclient" is the command which your orbconnect recognises to assign the command to the provided UID.

Would that make both our parties happy?

That would unnecessarily complicate the server and present the potential for multiple clients to end up with the same ID for different messages. You say you would "develop this so it's nearly impossible for other clients to get the same ID." The way it is currently, it is impossible for two clients to get the same ID (within the reasonable expected lifetime of an Orbiter session). Moreover, you don't have control over all of the clients which are connected to the server, so you can't guarantee that anyway.

There's a very, very easy way to do it in the client, which is what RemoteMFD does: when you request the subscription, you get the reply containing the "network ID". Then you put that "network ID" into a dictionary or map as the key, with the "local ID" being the value (and in this case, the "local ID" could easily be a text string). When you get a message containing a network ID, you simply look up what your local ID is.

---------- Post added at 09:10 PM ---------- Previous post was at 09:06 PM ----------

hi,
when i send the command
"SHIP:FOCUS:Elements2:Earth:0:0" I get the following in my message log:

SHIP:FOCUS:Elements2:Earth:0:0=Earth,3189783.472588,0.997341,
0.276173,4.755459,4.164698,1.023105,0.000000,0

Why does earth appear twice and then0=earth and how come all the kepler elements from the expected ELEMENTS structure are missing? I only count 6 or 7 not the 12 as listed in the API????!?!?
please help

Edit:
Yagni I don't think the elements1 and elements2 is working properly because when i call them i get the same numbers for each and also the same number of variables returned.

The elements struct in the API is

typedef struct { 
  double a;  //semi-major axis [m] 
  double e;  //eccentricity 
  double i;  i//nclination [rad] 
  double theta;  //longitude of ascending node [rad] 
  double omegab;  //longitude of periapsis [rad] 
  double L;  //mean longitude at epoch 
} ELEMENTS;

OrbConnect adds the name of the reference body for your convenience.

 

[davewave]

Im not getting the 12 elements returned to me when i request elements2, why?

here is what i get:
SHIP:FOCUS:ELEMENTS2:EARTH:0:0=Earth,6720345.766465,0.001961,1.300071,2.949855,5.756207,3.786123,0.000000,0

 

[Hielor]

Im not getting the 12 elements returned to me when i request elements2, why?

here is what i get:
SHIP:FOCUS:ELEMENTS2:EARTH:0:0=Earth,6720345.766465,0.001961,1.300071,2.949855,5.756207,3.786123,0.000000,0

I believe this is a bug in the version that's on OH. Get the newest from SourceForge, it (should be) fixed there.

 

[davewave]

I believe this is a bug in the version that's on OH. Get the newest from SourceForge, it (should be) fixed there.

could you provide a link to the latest compiled dll please?

 

[Hielor]

could you provide a link to the latest compiled dll please?

The latest released version was the one on OH. You can get the source from Sourceforge and compile it yourself, or if you need a compiled DLL I can have it for you in ~15min. I'd recommend getting the source anyway, as there have have been several changes that haven't yet been documented.

 

[n72.75]

I am intrested.

Will talk more in the morning.


-Matt

 

[Hielor]

Up-to-date OrbConnect binary:
https://webspace.utexas.edu/btb289/www/Orbiter/Modules/OrbConnect.dll

 

[davewave]

Up-to-date OrbConnect binary:
https://webspace.utexas.edu/btb289/www/Orbiter/Modules/OrbConnect.dll

thanks muchly i will try this now. without a working elements2 function, there really is no point

---------- Post added at 05:51 AM ---------- Previous post was at 05:46 AM ----------

thanks muchly i will try this now. without a working elements2 function, there really is no point

arg, worse now, none of the element functions work at all, i just get back an err02 message.
has the input arguments changed?

 

[Hielor]

thanks muchly i will try this now. without a working elements2 function, there really is no point

---------- Post added at 05:51 AM ---------- Previous post was at 05:46 AM ----------



arg, worse now, none of the element functions work at all, i just get back an err02 message.
has the input arguments changed?

This is why I said you should look at the source.

The following messages have been moved from the SHIP namespace to the NAV namespace:
Elements1
Elements2
EquPos
GlobalPos
GlobalVel
RelPos
RelVel
RelPosVel
GravContrib
GravRef
Navaids
NavaidRelPos
NavaidRelVel

So for example, while your ELEMENTS2 would have been "SHIP:FOCUS:ELEMENTS2" previously, it is now "NAV:FOCUS:ELEMENTS2"

 

[davewave]

almost all working but what happened to "ATMCONDITIONS"???

and also my code looks a bit like this:
ListBox1.Items.Add("SUBSCRIBE:20:NAV:FOCUS:ELEMENTS1")
ListBox1.Items.Add("SUBSCRIBE:4:ORB:SIMTIME")
ListBox1.Items.Add("SUBSCRIBE:20:NAV:FOCUS:ELEMENTS2")
ListBox1.Items.Add("SUBSCRIBE:3.33:FOCUS:EQUPOS")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:ATTITUDE")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:Name")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:Alt")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:NavModeStates")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:AirSpd")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:Atmconditions")
ListBox1.Items.Add("OBJ:Earth:Size")

just ignore the listbox1.items for a second.
now for some reason I'm not always getting data back on time or at all.
Should i be setting different update rates?? how do i spread it out because some or all of the above need to be close to 25hz to allow a real time appreciation of the situation.

 

[Hielor]

almost all working but what happened to "ATMCONDITIONS"???

What do you mean, what happened to it? As far as I can tell, it's still there. IE, "SHIP:FOCUS:AtmConditions" looks to me like it would be a valid message. Note that this won't work in space.

and also my code looks a bit like this:
ListBox1.Items.Add("SUBSCRIBE:20:NAV:FOCUS:ELEMENTS1")
ListBox1.Items.Add("SUBSCRIBE:4:ORB:SIMTIME")
ListBox1.Items.Add("SUBSCRIBE:20:NAV:FOCUS:ELEMENTS2")
ListBox1.Items.Add("SUBSCRIBE:3.33:FOCUS:EQUPOS")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:ATTITUDE")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:Name")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:Alt")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:NavModeStates")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:AirSpd")
ListBox1.Items.Add("SUBSCRIBE:10:SHIP:FOCUS:Atmconditions")
ListBox1.Items.Add("OBJ:Earth:Size")

just ignore the listbox1.items for a second.
now for some reason I'm not always getting data back on time or at all.
Should i be setting different update rates?? how do i spread it out because some or all of the above need to be close to 25hz to allow a real time appreciation of the situation.

I'm confused as to what you're asking. What do you mean, you're not getting data back on time or at all?

First off, if you want all of those to be "close to 25hz" then you'd want all of them to be 20, which is the maximum that OrbConnect can put out. Moreover, you may not even need that high--for RemoteMFD we've found 10 to be more than enough, and IIRC IRL the fastest NASA tracking data (high speed s- and c-band) is only 10Hz.

Secondly, you don't need both Elements1 and Elements2 -- Elements2, as you were complaining about previously, includes all of the data of Elements1.

As for "not getting data back on time or at all," without knowing more precisely what you mean I can't really help. We've never had a problem with it in RemoteMFD.

An explanation of how the subscription thing works:
Internally, OrbConnect divides each second up into 20 pieces, the technical term for which are "buckets." Each bucket represents 50ms, so bucket 0 is the time from 0-49ms, bucket 1 is 50-99ms, etc. When the system time on the server enters a bucket for the first frame (ie, last frame in Orbiter it was 5:26:59:998 on the server, this frame it is 5:27:00:001), it dispatches any subscriptions which are due to be dispatched. Upon dispatching a subscription, it puts it into a bucket which is enough buckets ahead to acquire the requested response rate. So, for example, with a 20hz subscription, it would be placed into the next bucket to be dispatched approximately 50ms later; with a 10hz subscription, it would skip a bucket and be dispatched approximately 100ms later.

A known potential issue with this system is that if your server is running less than 20fps (or has a frame which takes longer than 50ms to run), data may not get dispatched for another second. However, this was an acceptable problem, since any computer made after like 2001 can usually run Orbiter at > 20fps.

 

[yagni01]

This is why I said you should look at the source.
So for example, while your ELEMENTS2 would have been "SHIP:FOCUS:ELEMENTS2" previously, it is now "NAV:FOCUS:ELEMENTS2"

The documentation on SF has also been updated to show this.

 

[davewave]

What do you mean, what happened to it? As far as I can tell, it's still there. IE, "SHIP:FOCUS:AtmConditions" looks to me like it would be a valid message. Note that this won't work in space.


I'm confused as to what you're asking. What do you mean, you're not getting data back on time or at all?



As for "not getting data back on time or at all," without knowing more precisely what you mean I can't really help. We've never had a problem with it in RemoteMFD.

QUOTE]


Sorry, I wasn't getting upset at you but rather just trying to figure it all out.
And I tried the ATMconditions in space, but you don't get anything back but an error,weird.

 

[Hielor]

And I tried the ATMconditions in space, but you don't get anything back but an error,weird.

As I said:

Note that this won't work in space.

There is no atmosphere in space; therefore you cannot get the atmospheric conditions.

 

[davewave]

As I said:


There is no atmosphere in space; therefore you cannot get the atmospheric conditions.

yes i realise that but instead of returning a 0 for dyn, stat press etc, it returns an error thats all im saying.

anyhow. I need someone to help test this over the internet, could someone run the latest DLL and leave me an IP address and a DGIV orbiting the earth?

 

[Hielor]

yes i realise that but instead of returning a 0 for dyn, stat press etc, it returns an error thats all im saying.

Yes, it returns an error. If you read the documentation, I believe the error it returns is the error that indicates "no atmosphere." This is intentional.

anyhow. I need someone to help test this over the internet, could someone run the latest DLL and leave me an IP address and a DGIV orbiting the earth?

I'm at work atm, when I get home I can set it up to run on my server.

 

[davewave]

Yes, it returns an error. If you read the documentation, I believe the error it returns is the error that indicates "no atmosphere." This is intentional.


I'm at work atm, when I get home I can set it up to run on my server.

i think im in a different timezone so just pm your details like MSN and we can organise it through there