Request Gateway transport system

[fred18]

about the code I provided before, a check to exclude the "self transportation" of the gateway vessel must be added, since it's checking for all the vessels in the sim, it will check also for himself and its distance from himself will always be 0 and it will start to fly around in a loop until your pc melts down :lol:

---------- Post added at 17:07 ---------- Previous post was at 15:49 ----------

the quick and dirty example works with the following code (in pre or poststep of course), but it's still far to be perfect, it just could be a starting point

from now on have fun

for (UINT i=0;i<oapiGetVesselCount();i++)
	{
		OBJHANDLE hvessel=oapiGetVesselByIndex(i);
		
		if(hvessel!=GetHandle())
		{
			VECTOR3 rpos,rvel;
			oapiGetRelativePos(hvessel,GetHandle(),&rpos);
			double distance=length(rpos);
			oapiGetRelativeVel(hvessel,GetHandle(),&rvel);
			
			if((distance<2)&&(rpos.z>0)&&(rvel.z<0))  
			{
			
			VESSELSTATUS2 vs_vessel,vs_other_gate;
			memset(&vs_vessel, 0, sizeof(vs_vessel));
			memset(&vs_other_gate, 0, sizeof(vs_other_gate));
			vs_vessel.version=2;
			vs_other_gate.version=2;

			VESSEL *v;
			v=oapiGetVesselInterface(hvessel);
			v->GetStatusEx(&vs_vessel);
			OBJHANDLE h_other_gate;
			char myname[16];
			char GateA[16];
			sprintf(myname,GetName());
			sprintf(GateA,"Gate_A");
			if(strcmp(myname,GateA)==0)
			{
				h_other_gate=oapiGetVesselByName("Gate_B");   
			}else{
				h_other_gate=oapiGetVesselByName("Gate_A");   
			}
			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.vrot=vs_other_gate.vrot;
			vs_vessel.arot=vs_other_gate.arot;
			
			VECTOR3 outvel=_V(rvel.x,rvel.y,rvel.z);
			VECTOR3 rofs;
			GlobalRot(outvel,rofs);
			vs_vessel.rvel.x=vs_other_gate.rvel.x+rofs.x;
			vs_vessel.rvel.y=vs_other_gate.rvel.y+rofs.y;
			vs_vessel.rvel.z=vs_other_gate.rvel.z+rofs.z;
			
			




			v->DefSetStateEx(&vs_vessel);
			}
		}
	}

 

[Trekkie]

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:

I was thinking about this too, what if you have like 3 or 5 jump locations How would you Assign Where to go?

 

[Urwumpe]

I was thinking about this too, what if you have like 3 or 5 jump locations How would you Assign Where to go?

I would choose a MFD of course for handling the choice of the player... but the important trick would be the order if you would have multiple ships at once. In Orbiter maybe a more remote problem since we lack AI ships....

But technically, you would need to queue arrivals and departures for all pairs that are selected at both ends.

 

[Trekkie]

I would choose a MFD of course for handling the choice of the player... but the important trick would be the order if you would have multiple ships at once. In Orbiter maybe a more remote problem since we lack AI ships....

But technically, you would need to queue arrivals and departures for all pairs that are selected at both ends.

So that would require a timer for multiple ships, but since nobody quite uses multiple ships at once i think that would be not needed, Unless you would use multiple docked ships.. but Hey more functions more joy. Is it technically possible to use an MFD for that?

 

[Urwumpe]

So that would require a timer for multiple ships, but since nobody quite uses multiple ships at once i think that would be not needed, Unless you would use multiple docked ships.. but Hey more functions more joy. Is it technically possible to use an MFD for that?

Not alone... Lets say about the following concept.

The MFD is used for two tasks: Add jump functionality to vessels that don't have it themselves and provide a generic front-end for vessels that have a jump navigation included.

A similar component is in both cases used for talking to the jump gate and handle special visual effects (via DI).

The MFD would need to cover the following states of a vessel:

1. Initial - select destination and correct departure jump gate if needed.
2. Move to IP - if the ship is not yet close to it, the player is directed to an initial point, similar to Docking MFD.
3. At the IP - Here the player is expected to keep station until his transfer gets executed. By leaving the IP region (hysteresis), the MFD switches back to initial now.
4. Pass jump point - again, a docking MFD like view directs the player to the jump point, when the transfer gets executed. The jump point gets opened when the player is close enough.
5. Hyperspace - here the velocity vector is slowly equalized hidden as some kind of rapid motion in hyperspace, so that the crew can pretend to be alive.
6. Leave jump point - The MFD displays an egress route away from the jump point and other waiting ships. When distance is large enough, back to initial.

By having the main behavior in a component visible to the MFD and the jump gates, it should also be no problem to implement it in AI ships.

 

[jangofett287]

Could use the MFD to 'connect' one gate to another and if the far end is 'busy' it just fails.
How would replays react to these shenanigans?

 

[Trekkie]

Not alone... Lets say about the following concept.

The MFD is used for two tasks: Add jump functionality to vessels that don't have it themselves and provide a generic front-end for vessels that have a jump navigation included.

A similar component is in both cases used for talking to the jump gate and handle special visual effects (via DI).

The MFD would need to cover the following states of a vessel:

1. Initial - select destination and correct departure jump gate if needed.
2. Move to IP - if the ship is not yet close to it, the player is directed to an initial point, similar to Docking MFD.
3. At the IP - Here the player is expected to keep station until his transfer gets executed. By leaving the IP region (hysteresis), the MFD switches back to initial now.
4. Pass jump point - again, a docking MFD like view directs the player to the jump point, when the transfer gets executed. The jump point gets opened when the player is close enough.
5. Hyperspace - here the velocity vector is slowly equalized hidden as some kind of rapid motion in hyperspace, so that the crew can pretend to be alive.
6. Leave jump point - The MFD displays an egress route away from the jump point and other waiting ships. When distance is large enough, back to initial.

By having the main behavior in a component visible to the MFD and the jump gates, it should also be no problem to implement it in AI ships.

by Design, would you think of a gate which you just go through or just a Velocity gate which give you a huge boost instead of just a teleport (im sorry i might missed this part)

 

[Urwumpe]

Could use the MFD to 'connect' one gate to another and if the far end is 'busy' it just fails.
How would replays react to these shenanigans?

Well, you could record the events. The problem with just fail busy is the time that a jump gate pair is reserved. We are not moving fast in Orbiter. No deal when you have only one ship in a scenario moving actively by the player. But in this case, the question was how to solve AI ships.

In that case, you would just need to store the events in the replay and save the current transfer queue in the scenario file.

---------- Post added at 09:28 PM ---------- Previous post was at 09:25 PM ----------

by Design, would you think of a gate which you just go through or just a Velocity gate which give you a huge boost instead of just a teleport (im sorry i might missed this part)

The first case - the change in velocity is only included to play with those vessels which calculate acceleration by measuring the change of velocity in a single time step.

If we would just change position, no deal. But when we also change velocity vector, we would have an astronomic acceleration (eg, 16000g by going from one side of Earth to the other in LEO at 10 fps)

 

[Trekkie]

Well, you could record the events. The problem with just fail busy is the time that a jump gate pair is reserved. We are not moving fast in Orbiter. No deal when you have only one ship in a scenario moving actively by the player. But in this case, the question was how to solve AI ships.

In that case, you would just need to store the events in the replay and save the current transfer queue in the scenario file.

---------- Post added at 09:28 PM ---------- Previous post was at 09:25 PM ----------



The first case - the change in velocity is only included to play with those vessels which calculate acceleration by measuring the change of velocity in a single time step.

If we would just change position, no deal. But when we also change velocity vector, we would have an astronomic acceleration (eg, 16000g by going from one side of Earth to the other in LEO at 10 fps)

if i remember this correctly the Pilar of Autumn from Icarus at home has such an implentation of a Gateway/warpgate

 

[Urwumpe]

if i remember this correctly the Pilar of Autumn from Icarus at home has such an implentation of a Gateway/warpgate

I also remember a system of orbital linear accelerator gates being used for accelerating and decellerating vessels in the tabletop Turning Point. But I can't really tell all challenges of solving such a system in the real world. you would need to know months in advance, where each orbital linear accelerator gate would be after a number of transfers, each changing the orbit of the gate by conservation of impulse...

 

[BenSisko]

Thanks for the discussion of possibilities for a wormhole device in Orbiter. What Gattispilot and I are looking for however is a bit simpler than the devices you've described above. We've been working on the ships of the movie Interstellar. The Endurance is composed of five docked vessels (Endurance ring, two Rangers, and two Landers) with 16 attached cargo pods.
https://www.4shared.com/photo/_4hRzSigca/Endurance_full_complement_on_o.html
We need a two way "wormhole device to allow travel from the Sol system to the Gargantua-Pantagruel system portrayed in the movie. The only transit points are the wormhole portals orbiting Saturn (point A) and orbiting the Gargantua-Pantagruel system (point B). We're not looking at multiple transport sites but we do have a compound vessel with docked and attached elements.
Thanks for your suggestions!
Ben

 

[jedidia]

So how far would it be to code?

The quickest and dirtiest way: A vessel within a certain distance to a gate gets the state vectors of the linked gate (instant teleport). I'd guess that would be below 10 lines of code.

We need a two way "wormhole device to allow travel from the Sol system to the Gargantua-Pantagruel system portrayed in the movie.

Are those systems present in the same scenario? Because otherwise, there's only the hack of exporting a scenario and rebooting orbiter with it to make it happen.

 

[BenSisko]

No, is there a way to construct a scenario that encompasses two environments?

 

[jedidia]

No, is there a way to construct a scenario that encompasses two environments?

No. You can send orbiter a restart command and have a module immediately load a certain scenario, that's pretty much the only way I know to "connect" two systems.

 

[wingnut]

The MFD would need to cover the following states of a vessel:

1. Initial - select destination and correct departure jump gate if needed.
2. Move to IP - if the ship is not yet close to it, the player is directed to an initial point, similar to Docking MFD.
3. At the IP - Here the player is expected to keep station until his transfer gets executed. By leaving the IP region (hysteresis), the MFD switches back to initial now.
4. Pass jump point - again, a docking MFD like view directs the player to the jump point, when the transfer gets executed. The jump point gets opened when the player is close enough.
5. Hyperspace - here the velocity vector is slowly equalized hidden as some kind of rapid motion in hyperspace, so that the crew can pretend to be alive.
6. Leave jump point - The MFD displays an egress route away from the jump point and other waiting ships. When distance is large enough, back to initial.

About the IP: would it make sense to add a docking port to the gateway so that the MFD can clearly identify which vessel is to be teleported? Can the vessel be teleported to the docking port of the target gateway and be undocked automatically after the teleport?

 

[fred18]

No. You can send orbiter a restart command and have a module immediately load a certain scenario, that's pretty much the only way I know to "connect" two systems.

A trick could be to place the other "sun" as a planet orbiting our sun very far away, then make the planets around the second sun as moons of the "sun-planet". Of course no moons will be allowed in thajt system

About the IP: would it make sense to add a docking port to the gateway so that the MFD can clearly identify which vessel is to be teleported? Can the vessel be teleported to the docking port of the target gateway and be undocked automatically after the teleport?

That is possible, and was also on my mind about this topic, docking or attachments. It will solve some issues (for example arrival and departure recognition).
But it comes at a cost: you'll restrict to vessel with docking ports and if those vessel have special procedure for docking (for example open the nose cone or if the docking port is on top instead that in front of the vessel) the effect will be unrealistic. Maybe attachments fit better since you can identify them via ID. Of course this should mean that the addon will create an attachment point on every vessel in the sim, but that's not hard to do at all, we should give it a try

 

[Urwumpe]

About the IP: would it make sense to add a docking port to the gateway so that the MFD can clearly identify which vessel is to be teleported? Can the vessel be teleported to the docking port of the target gateway and be undocked automatically after the teleport?

Sure. But I consider it way more fluent to simply have an region where multiple spacecraft could be parked. The because the jump gate is a limited cross section, it would make sense to separate arriving and departing traffic.

But yes, that would only apply when multiple spacecraft could actively move.

 

[fred18]

Using attachments also another trick comes to my mind: instead of sending the ship from gate A to gate B you could swap the gates position when something's attached. of course it must be an instant transportation, not a simulated fast trip

 

[Urwumpe]

Using attachments also another trick comes to my mind: instead of sending the ship from gate A to gate B you could swap the gates position when something's attached. of course it must be an instant transportation, not a simulated fast trip

Sounds approximately like a jump ship in Battletech.

 

[fred18]

Sounds approximately like a jump ship in Battletech.

yep it is, I tried it with the code posted before. Gate A around the earth, Gate B around the moon. Getting close with a DG to gate A from the right side and ... :leaving: ...around the moon