Request Gateway transport system

[gattispilot]

I usually answer the request. But now I/we are asking for a gateway vessel. Something like the B5 gateway. Where a vessel flies into and and now transported to where the other gate is. Like a Worm hole.

 

[Urwumpe]

I usually answer the request. But now I/we are asking for a gateway vessel. Something like the B5 gateway. Where a vessel flies into and and now transported to where the other gate is. Like a Worm hole.

For Orbiter 2016?
Which user interface?
Which dimensions would a jump gate need to have?

Its called "Jump gate" in most examples, did you try any "jump gate" add-on already for compatibility?

 

[gattispilot]

Thanks. Do you mean like this:
[ame="http://orbithangar.com/searchid.php?ID=2609"]http://orbithangar.com/searchid.php?ID=2609[/ame]

But more like the b5 gates that act as entrance and exits to another area.

for Orbiter 2010p-1 or 2016

 

[Urwumpe]

But more like the b5 gates that act as entrance and exits to another area.

How large should it be? Not that you discover too late, that there is a PANAMAX for spacecraft because of the jump gates.

 

[Face]

Thanks. Do you mean like this:
http://orbithangar.com/searchid.php?ID=2609

JumpDriveMFD comes with source code. You could use it as a base for implementing such a gate transportation system.

 

[gattispilot]

I will take a look. What we are trying to you as I understand it is like a wormhole it is a portal to a different area.

 

[Urwumpe]

I will take a look. What we are trying to you as I understand it is like a wormhole it is a portal to a different area.

Yes. So minimally, it is just a DLL that defines some behavior should some object fly within a box defined inside it, all other parameters are defined in the default cfg. In the scenario, you just link it to another jump gate vessel by the name of the vessel.

In this case, a jumpgate would need three states in a state machine: IDLE, DEPARTING, ARRIVING.

In IDLE, nothing happens at all, it just waits for a trigger to define its next action. When a vessel enters the box, the jump gate switches itself to DEPARTING and the other jump gate to ARRIVING.

In DEPARTING, the jump gate lets all vessels that enter the BOX fly to the target. vessels that are docked to an transported vessel or attached are ignored (Orbiter should handle this)

In ARRIVING, the jump gate ignores its own box trigger and goes back to IDLE when the box is empty for a defined period of time (countdown).

That handling of docked and attached vessels, is the only complex task there.


A much better jump gate could allow defining lights and use some traffic light like function for communicating to the player (eg, position relative to the flight path) and have some strategy for orbit keeping.

 

[gattispilot]

So how far would it be to code?

 

[n122vu]

I'm liking the sound of this. Not sure how available I'll be, but let me know if I can help in any way. Would love to adapt something to an actual B5 Jump Gate. Might give me an excuse to dust off the Cortez and update her to 2016.

---------- Post added at 09:03 AM ---------- Previous post was at 08:58 AM ----------

For B5-type implementation, the Jump Gate would have multiple possible destinations.

A couple things to consider:
1) How to present the list of available Jump Gate destinations to the user. HUD? MFD?
2) How to handle velocity of the vessel as it exits the jump gate. Same as when it entered, but on the +Z-axis of the arrival gate?

 

[Urwumpe]

So how far would it be to code?

Recommended distance is about twice the screen diagonal between display and the mind of the developer. The distance to the keyboard depends on the individual developer, but it won't be further than the length of his arms. :lol:

I am not sure, how much effort it would take to implement a simple one. The issue of docked and attached vessels should be respected as challenge.

Maybe the simple solution of just transferring one parent vessel and then wait 60 seconds for the other vessel to clear the jump gate could be enough (though not like in B5, where multiple vessels are able to pass at once). But if that is not enough (eg, detaching payloads after transfer results in chaos), a more complex solution would be needed.

 

[Face]

I'm liking the sound of this. Not sure how available I'll be, but let me know if I can help in any way. Would love to adapt something to an actual B5 Jump Gate.

I remember the RTF Stargate addon to have a B5 gate exchange mesh (or at least it was planned).

AFAIK, gattico on Dan's forum mentioned that he has received the code from John during the "set course for sun" go down of the fleet. Perhaps you can contact him to ask for it?

 

[Urwumpe]

I'm liking the sound of this. Not sure how available I'll be, but let me know if I can help in any way. Would love to adapt something to an actual B5 Jump Gate. Might give me an excuse to dust off the Cortez and update her to 2016.

---------- Post added at 09:03 AM ---------- Previous post was at 08:58 AM ----------

For B5-type implementation, the Jump Gate would have multiple possible destinations.

A couple things to consider:
1) How to present the list of available Jump Gate destinations to the user. HUD? MFD?
2) How to handle velocity of the vessel as it exits the jump gate. Same as when it entered, but on the +Z-axis of the arrival gate?

Well, since Orbiter only allows one solar system, a real B5 jump gate would be hard to realize. It would always be different (no hyperspace).

The closest to B5 I could see there would be a jump gate as spawn point or exit from the scenario.

A spawn point/exit add-on could be interesting though...

 

[gattispilot]

I don't have the gate code.

Yes but you add new planets,... then you could use the gateway to them.

So can someone code a simple version?

 

[Urwumpe]

I don't have the gate code.

Yes but you add new planets,... then you could use the gateway to them.

So can someone code a simple version?

Not sure if I can do it today, wanted to develop something else when I have the time.

It shouldn't take very long to develop. There are just two small problems to solve as known problems, not sure about the unknown problems that require testing:

• Find the parent vessel of a group of attached vessels, when one vessel triggers the jump gate.
• Connect two jump gates and handle the state changes

Of the unknown problems:

• How do docked vessels behave?
• Can attached payloads be detached correctly after a jump?
• Can you make sure, that crews of some add-ons are not killed during a jump? (possible mitigation: Use the jump process to gently equalize the velocity vectors)

Just getting the state vector of the target jump gate and setting the state vector data of the vessel to the state vector of the target should be easy.

 

[fred18]

a quick and dirty that comes to my mind:

1 dll, 2 vessels in a scenario, pre-placed in orbit around the planets we want to connect
first vessel named "Gate A"
second vessel named "Gate B"

the procedure will be for both A and B:

pseudo code:

for (i=0;i<oapiGetVesselCount();i++)
{
    OBJHANDLE hvessel=oapiGetVesselByIndex(i);
    VECTOR3 rpos;
    oapiGetRelativePos(hvessel,GetHandle(),&rpos);
   double distance=length(rpos);
   if((distance<2)&&(rpos.z>0))  // 2 meters is an example and rpos.z is used only to check if the ship is approaching from the right side, but depends on mesh and other things
   {
     VESSELSTATUS2 vs_vessel,vs_other_gate;
     VESSEL *v;
     v=oapiGetVesselInterface(hvessel);
     v->GetStatusEx(vs_vessel);
     OBJHANDLE h_other_gate=oapiGetVesselByName("Gate_B");   //if this is gate A, you can play around to make the same code for both vessels
     VESSEL *v_other_gate;
     v_other_gate=oapiGetVesselInterface(h_other_gate);
     v_other_gate->GetStatusEx(&vs_other_gate);
     vs_vessel.rbody=vs_other_gate.rbody;
     vs_vessel.rpos=vs_other_gate.rpos;
     vs_vessel.rvel=vs_other_gate.rvel;
     vs_vessel.vrot=vs_other_gate.vrot;
     vs_vessel.arot=vs_other_gate.arot;
    v->DefSetStateEx(vs_vessel);

   }
}

---------- Post added at 15:20 ---------- Previous post was at 15:14 ----------

• Find the parent vessel of a group of attached vessels, when one vessel triggers the jump gate.

I don't know if that's necessary, or if you just can wait for the parent to trigger the gate itself, depends on level of precision you want in that I think

• Connect two jump gates and handle the state changes

if there are only two is easy, if you want more and if you want to even choose where to go it may become more complex

Of the unknown problems:

• How do docked vessels behave?
• Can attached payloads be detached correctly after a jump?
• Can you make sure, that crews of some add-ons are not killed during a jump? (possible mitigation: Use the jump process to gently equalize the velocity vectors)

Just getting the state vector of the target jump gate and setting the state vector data of the vessel to the state vector of the target should be easy.

1) that's good questions, I think they will just follow, but it's needed to check
2) I think so: they query the mother ship for status when they detached, so it should be ok
3) I'm pretty sure the crews will be killed, since the instant transfer will be read as a super high acceleration

 

[gattispilot]

Thanks. I can try it out later today. So basically this takes the vessel that is close by (2 ) and puts in where GAte B is?

So same code just 1 vessel Gate a and the other Gate B?

 

[fred18]

Thanks. I can try it out later today. So basically this takes the vessel that is close by (2 ) and puts in where GAte B is?

yes

So same code just 1 vessel Gate a and the other Gate B?

suggestion is to use something like ... if this vessel is Gate_A then look for Gate_B otherwise look for Gate_A in the code, so you can just build one dll, place two vessels of the same class in a scenario and simply name those vessels Gate_A and Gate_B

 

[gattispilot]

yes



suggestion is to use something like ... if this vessel is Gate_A then look for Gate_B otherwise look for Gate_A in the code, so you can just build one dll, place two vessels of the same class in a scenario and simply name those vessels Gate_A and Gate_B

Now I am confused.

So use that code to make a GATEway vessel and call it Gate A and another Gate B.

 

[fred18]

So use that code to make a GATEway vessel and call it Gate A and another Gate B.

Yes! don't be confused, is as simply as what you just said

 

[Urwumpe]

if there are only two is easy, if you want more and if you want to even choose where to go it may become more complex

Exactly. Way more complex. You would then need some kind of "jump gate traffic control" to make sure every vessel arrives at the proper destination.

But I can already describe such a situation in an activity diagram... it just requires about 50+ activities right now. :facepalm: