Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter SDK
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter SDK Orbiter software developers post your questions and answers about the SDK, the API interface, LUA, meshing, etc.

Reply
 
Thread Tools
Old 12-16-2016, 09:46 AM   #1
GLS
Addon Developer
 
GLS's Avatar
Default Getting the position of another vessel during the first clbkPreStep

Like the title says, is there a way to find the global or relative position of another vessel during the first run of clbkPreStep? The usual means don't work: v->GetGlobalPos() gives (0,0,0), and v->GetRelativePos() uses (0,0,0) as the other vessel's position... is this a bug, or a feature?
GLS is offline   Reply With Quote
Old 12-16-2016, 09:50 AM   #2
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Is it an attached vessel?

(I think those values should already be established at clbkPostCreation, but I am not sure)
Urwumpe is offline   Reply With Quote
Old 12-16-2016, 10:36 AM   #3
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by GLS View Post
 Like the title says, is there a way to find the global or relative position of another vessel during the first run of clbkPreStep? The usual means don't work: v->GetGlobalPos() gives (0,0,0), and v->GetRelativePos() uses (0,0,0) as the other vessel's position... is this a bug, or a feature?
I could imagine that the info is simply not there yet, because Orbiter's engine did not load/decode/calculate the position information for all vessels at this point of time. Then it might be a feature to return at least zero instead of NaN or somesuch.

But according to Martin's diagram, this is not the case:
Click image for larger version

Name:	orbiterorder.jpg
Views:	17
Size:	101.0 KB
ID:	14984

There it is made clear that the initial world state (S_0) should be established before the first clbkPreStep goes out, so a function taking positions of other vessels into account should return the proper values. Therefore, I'd say it is a bug.
Face is offline   Reply With Quote
Thanked by:
Old 12-16-2016, 11:37 AM   #4
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 Is it an attached vessel?

(I think those values should already be established at clbkPostCreation, but I am not sure)
Yep, so we know where SSU's payloads are.


Quote:
Originally Posted by Face View Post
 I could imagine that the info is simply not there yet, because Orbiter's engine did not load/decode/calculate the position information for all vessels at this point of time. Then it might be a feature to return at least zero instead of NaN or somesuch.

But according to Martin's diagram, this is not the case:
Attachment 14984

There it is made clear that the initial world state (S_0) should be established before the first clbkPreStep goes out, so a function taking positions of other vessels into account should return the proper values. Therefore, I'd say it is a bug.
The (own) vessel's position is available, so some calculations occur.
Changing the order of the vessels in the scenario file changes nothing. I'll try to get the position of vessel A from vessel B and vice-versa in the first step to see what happens.
GLS is offline   Reply With Quote
Old 12-16-2016, 12:22 PM   #5
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 Yep, so we know where SSU's payloads are.
Shouldn't work in the first time step because of the ordering of the vessels in Orbiter... during the first time step, they are not fully attached, but attach during the first propagation of them. They float around somewhere else and then jump to the right places during the first timestep. (You can observe it when you start paused)

Of course, we actually know where the payloads are, because they are attached. But Orbiter doesn't tell the truth then.
Urwumpe is offline   Reply With Quote
Old 12-16-2016, 12:50 PM   #6
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by GLS View Post
 I'll try to get the position of vessel A from vessel B and vice-versa in the first step to see what happens.
Here are the interesting results I got when calling GetGlobalPos() for the own vessel and for another (vessels are attached, vessel B has no RPOS, etc):
Code:
vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

vessel B
A {-76975518214.058441, -7176475.6313778162, -129628502440.62596}
B {-76975518215.850647, -7176472.5618840335, -129628502442.09454}
Switching the order of the vessels in the scenario gives this:
Code:
vessel B
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}
...and no, there is no mistake on the second run, vessel B really gets (0,0,0) for it's own position....
The order in which the 2 GetGlobalPos() calls are made doesn't change the results.

Separating the vessels (and adding RPOS, etc to vessel B) gives this:
Code:
vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {-76975518145.262268, -7176473.0902761770, -129628502441.52844}

vessel B
A {-76975518213.739502, -7176476.3046060400, -129628502440.38686}
B {-76975518145.262268, -7176473.0902761770, -129628502441.52844}

(switch order)
vessel B
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {-76975518145.262268, -7176473.0902761770, -129628502441.52844}

vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {-76975518145.262268, -7176473.0902761770, -129628502441.52844}
This indicates the issue is only for attached vessels.
Re-attaching the vessels, keeping the state vector in vessel B's scenario block, give this:
Code:
vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

vessel B
A {-76975518214.058441, -7176475.6313778162, -129628502440.62596}
B {-76975518215.850647, -7176472.5618840335, -129628502442.09454}

(switch order)
vessel B
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}

vessel A
A {-76975518215.262268, -7176473.0902761770, -129628502441.52844}
B {0.00000000000000000, 0.00000000000000000, 0.00000000000000000}
.. the same as the if vessel B has no RPOS, etc, so it seems like something is slipping thru the cracks somewhere...


BTW: only vessel B had the ATTACHED scenario entry, I didn't test playing with that.

---------- Post added at 12:50 PM ---------- Previous post was at 12:47 PM ----------

Quote:
Originally Posted by Urwumpe View Post
 Shouldn't work in the first time step because of the ordering of the vessels in Orbiter... during the first time step, they are not fully attached, but attach during the first propagation of them. They float around somewhere else and then jump to the right places during the first timestep. (You can observe it when you start paused)

Of course, we actually know where the payloads are, because they are attached. But Orbiter doesn't tell the truth then.
That's what I'm trying to fix, hence my doubt about this Orbiter behaviour.
GLS is offline   Reply With Quote
Old 12-16-2016, 02:45 PM   #7
martins
Orbiter Founder
Default

I'll look into it. Attached vessels don't go through a full update phase, but simply wait to be updated by their parent vessel. This may mean that they skip some initialisation step and only update once the parent has gone though its own first update. I'll try to initialise the attachment before clbkPostCreation.

Incidentally, I was wondering if it is time to retire the attachment interface altogether. It may be more trouble than it's worth, and now that the docking interface is a bit more robust (works for landed vessels) there may be no more need for attachments. Attachments cause major problems when they are mixed with docking connections, since this breaks the clear parent-child relationships, causing all hell to break loose when it comes to the update pipeline.

Is anybody particularly attached to attachments?
martins is offline   Reply With Quote
Thanked by:
Old 12-16-2016, 02:53 PM   #8
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by martins View Post
 I'll look into it. Attached vessels don't go through a full update phase, but simply wait to be updated by their parent vessel. This may mean that they skip some initialisation step and only update once the parent has gone though its own first update. I'll try to initialise the attachment before clbkPostCreation.

Incidentally, I was wondering if it is time to retire the attachment interface altogether. It may be more trouble than it's worth, and now that the docking interface is a bit more robust (works for landed vessels) there may be no more need for attachments. Attachments cause major problems when they are mixed with docking connections, since this breaks the clear parent-child relationships, causing all hell to break loose when it comes to the update pipeline.

Is anybody particularly attached to attachments?
The main problem with docking connections currently are that they can't be moved dynamically like attachment points can (current uses of the attachment points are mainly for RMS End Effectors which can be changed in position as well as direction dynamically). Docking ports currently can't undergo this.

This is what lead me to create this issue back in 2015: http://www.orbiter-forum.com/project.php?issueid=1204
DaveS is offline   Reply With Quote
Thanked by:
Old 12-16-2016, 02:59 PM   #9
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by martins View Post
 Anybody nostalgic about attachments?
Not nostalgic, but I wonder if modelling things like Shuttle stacks with docking points is really the way to go. The term "attachment" already is a better fit.

If attachments go away, the only other option to model these vehicles (vs. docking it together) is the "classic" way of having a monolithic vessel that hides meshes and spawns vessels at jettison of elements.

Then again I always liked that later approach much more, even if it's just for the cleaner vessel list that doesn't get polluted by things like blabla_Booster or whatsit_Bay (no offense, Doug ).
Face is offline   Reply With Quote
Thanked by:
Old 12-16-2016, 02:59 PM   #10
gattispilot
Addon Developer
 
gattispilot's Avatar
Default

Attachments, YES!!!. You can move a attachment point but not a dock point. They can be used for cranes,....
gattispilot is offline   Reply With Quote
Old 12-16-2016, 03:05 PM   #11
indy91
Orbinaut
Default

Quote:
Originally Posted by Face View Post
 Not nostalgic, but I wonder if modelling things like Shuttle stacks with docking points is really the way to go. The term "attachment" already is a better fit.

If attachments go away, the only other option to model these vehicles (vs. docking it together) is the "classic" way of having a monolithic vessel that hides meshes and spawns vessels at jettison of elements.
This exactly was the plan for the first Orbiter 2016 compatible version of NASSP.

Simulating the Saturn, CSM and LM separately already on the launch pad and not as one vehicle, as it works right now, will be a huuuge simplification and will allow much more flexible launch scenarios.

As long as there is a good method to stack vessels like this I don't care if it is called docking or attachment.

Last edited by indy91; 12-16-2016 at 03:13 PM.
indy91 is online now   Reply With Quote
Old 12-16-2016, 03:20 PM   #12
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by indy91 View Post
 Simulating the Saturn, CSM and LM separately already on the launch pad and not as one vehicle, as it works right now, will be a huuuge simplification and will allow much more flexible launch scenarios.
Wouldn't that also mean that the whole code for all involved parts already needs to be run right from start? I.e. Pad, Stages, CSM, LM, perhaps even rovers and such must be loaded at launch scenarios, and their callback routines are run although the elements are effectively inactive at first. Could that influence performance in contrast to the previous approach?
Face is offline   Reply With Quote
Old 12-16-2016, 03:33 PM   #13
indy91
Orbinaut
Default

Quote:
Originally Posted by Face View Post
 Wouldn't that also mean that the whole code for all involved parts already needs to be run right from start? I.e. Pad, Stages, CSM, LM, perhaps even rovers and such must be loaded at launch scenarios, and their callback routines are run although the elements are effectively inactive at first. Could that influence performance in contrast to the previous approach?
Yes it will influence performance, but hopefully not too much. For the LM mostly a bunch of standby heaters and the rover should be completely off. Powered down systems shouldn't be very performance heavy.

The problem is, right now the CSM is fully integrated with the Saturn class. It's not a separate entity in the code. Recently the AGC version (Sunburst 120) flown on Apollo 5 became available for the Virtual AGC project. But there currently is no way to run it, because only the CSM and the Saturn are doing anything on the pad. The LM only starts existing upon separation from the Saturn stage.

Also, our simulation of the LVDC should be running in the S-IVB stage after CSM separation, to hold attitude for TD&E and to perform a maneuver to get away from the CSM/LM. That is also not really easily possible right now.

We already have an interface in place for transferring power from the CSM to the LM etc. We will be able to use that to transfer information from e.g. the IU to the Flight Control Computer of the S-IC.

So, it is certainly possible to do all this in the monolithic vehicle on the pad, but a lot of extra code will be necessary to integrate both the CSM and LM with the Saturn. I think it is the cleaner solution to separate them.
indy91 is online now   Reply With Quote
Old 12-16-2016, 03:47 PM   #14
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by indy91 View Post
 I think it is the cleaner solution to separate them.
I see. But do you think it is good to stack those elements together with the docking option (in contrast to attachments)? AFAIK, docked vessels still get influenced by gravity, bring in their mass, possibly unbalance the stack, get their aerodynamics updated and so forth. It sure will simulate reality closer, but is the added development complexity worth the effects?

I think for such things attachments are better suited. If they are gone, the classic implementation model will be easier to do. In your case, if you cleanly separate the classes, it should be not too hard to keep a monolithic vessel. I've done that with AscensionUltra already... each base elements (hangars, cranes, radars, etc.) were modeled as classes in such a way that the monolithic "super" class (the base as a whole) relayed the necessary callbacks to its "sub" classes. This architecture allowed a quick extraction of e.g. the radar-tracker dish functionality into its own vessel representation.

IF the attachments are gone... I'd keep them, if you ask me.
Face is offline   Reply With Quote
Old 12-16-2016, 04:06 PM   #15
indy91
Orbinaut
Default

Quote:
Originally Posted by Face View Post
 I see. But do you think it is good to stack those elements together with the docking option (in contrast to attachments)? AFAIK, docked vessels still get influenced by gravity, bring in their mass, possibly unbalance the stack, get their aerodynamics updated and so forth. It sure will simulate reality closer, but is the added development complexity worth the effects?
How are attachments different in that regard? Is there no Superstructure CG calculated with attachments? I don't really know how that works, luckily it most likely won't be my job to work on this anyway. But if we still have to define parameters for the whole vehicle, if we attach instead of dock the stages together, then attachments might not be the right way.

Our Saturns use the same implementation of the Thrust Vector Control as the real rockets. Same equations, same gains, etc. So having a more realistically behaving rocket should make control better, hopefully, not worse.

Quote:
I think for such things attachments are better suited. If they are gone, the classic implementation model will be easier to do. In your case, if you cleanly separate the classes, it should be not too hard to keep a monolithic vessel. I've done that with AscensionUltra already... each base elements (hangars, cranes, radars, etc.) were modeled as classes in such a way that the monolithic "super" class (the base as a whole) relayed the necessary callbacks to its "sub" classes. This architecture allowed a quick extraction of e.g. the radar-tracker dish functionality into its own vessel representation.

IF the attachments are gone... I'd keep them, if you ask me.
Also a problem, you can't switch between CSM cockpit and LM cockpit. What if we want a T-22h launch scenario with the LM Closeout procedures one day? Ok, ok, not all that big of an issue.

Last edited by indy91; 12-16-2016 at 04:09 PM.
indy91 is online now   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter SDK


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 08:53 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright 2007 - 2012, Orbiter-Forum.com. All rights reserved.