Request Gateway transport system

[gattispilot]

This might be right. I ran the debug but could get it to break

 

[gattispilot]

ok numbers seem better:
+ gaterelative_pos {data=0x00aefdfc {-0.82128906250000000, 7.4505805969238281e-009, -690.24271583557129} x=-0.82128906250000000 ...} VECTOR3

What was odd is the release dll was a different name than the debug that was why it would not break:
but I do get this warning:
Warning 1 warning MSB8012: TargetPath(C:\orbiter100830\Orbitersdk\samples\WORMGATE1\..\..\..\Modules\wormgate.dll) does not match the Linker's OutputFile property value (C:\orbiter100830\Modules\wormgatenew.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile). C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppBuild.targets 1186 5 wormgate
Warning 3 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/SAFESEH' specification C:\orbiter100830\Orbitersdk\samples\WORMGATE1\NEWWORM2.obj 1 1 wormgate

 

[Urwumpe]

Warning 1 warning MSB8012: TargetPath(C:\orbiter100830\Orbitersdk\samples\WORMGATE1\..\..\..\Modules\wormgate.dll) does not match the Linker's OutputFile property value (C:\orbiter100830\Modules\wormgatenew.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

Yes. This means you have a contradicting configuration. You say the output of the project should go somewhere else than where the linker stage generates the final output.

 

[gattispilot]

Thanks, I will take a look at what i have.

 

[jedidia]

What was odd is the release dll was a different name than the debug that was why it would not break:

A release build won't trigger breakpoints at all.

Warning 3 warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/SAFESEH' specification C:\orbiter100830\Orbitersdk\samples\WORMGATE1\NEWW ORM2.obj 1 1 wormgate

That just means that you have edit and continue enabled (compile on the fly while debugging), but that it's not possible because of another compiler option. Don't worry about it. If you want to, you can disable edit and continue in the compiler settings and the warning will be gone.

 

[gattispilot]

Yes. But I noticed I built a release dll and then switched to debug to run it an noticed that there were no breaks. Then I looked at the module folder there was wormgate1.dll (release) and wormgate.dll (debug). I then made the linker output of the debug the same as release. Then I got breaks. It looked like the values were better. I ran it in debug and noticed watching the z relative position. It might be -17 and then then next cycle 20. So it would have never set the jump based off the z
I attached the latest files earlier on post 222

 

[Urwumpe]

A release build won't trigger breakpoints at all.

Exactly. You won't find INT3 instructions (the break points as the CPU gets them, a single byte instruction vs the two bytes for a regular software interrupt... must have been a 0xCC if my memories of writing a disassembler serve me right) in a release build and usually no debug symbols or line number mapping.

That is the difference between Debug and Release: In debug, you have no optimizations, additional data and can have breakpoints. If you look at the code carefully, you can even find many gaps in the machine code where the debugger can quickly put breakpoints into without needing to recompile the software. Also, memory locations are always initialized with binary patterns to make it easier to detect memory leaks and array boundary violations.

In Release, you don't want any of this. Not a single byte of data that you don't need for running the software. And you want to optimize the software for different goals, which means the instructions are maybe no longer in the order of the source code lines - they can even be completely missing, because the optimization engine of the compiler detected a better way to get to the same results during the intermediate code stage.

That is also why buggy code can run well in debug and crash in release. Missing variable initializations have different results in debug and release for example, because the variables are generally initialized in debug - with test pattern.

 

[gattispilot]

Thanks. So Not sure my the property sheet isn't working. Otherwise I guess the way is to make a new project and open the properties and edit them.
But I guess the next step is to get it to jump to the other gate.

 

[jedidia]

It might be -17 and then then next cycle 20. So it would have never set the jump based off the z
I attached the latest files earlier on post 222

Well, there's a little quirk here. Unless you have fixed timesteps set in the orbiter config, the time you spend in the debugger actually count as simulation time. So if you break, and look at stuff for a minute, Orbiter will propagate the entire simulation forward by one minute in the next frame. Any intermediate space the vessel should have been in is never occupied by it.
So it's well possible that you missed the window while debugging, but wouldn't have missed it if the simulation was running uninterrupted.

In any case, that you are now seeing reasonable values does indeed indicate that the compiler settings in your old project were thouroughly messed up for a debug build. Glad we sorted that out.

 

[gattispilot]

In any case, that you are now seeing reasonable values does indeed indicate that the compiler settings in your old project were thouroughly messed up for a debug build. Glad we sorted that out.

This begs the question how do you set up a new project?


I guess the next step is if x, y, z rel position is within range do something, right?

 

[jedidia]

This begs the question how do you set up a new project?

As far as I can see, you just did.

I guess the next step is if x, y, z rel position is within range do something, right?

Yes, although most of that is already in there as far as I can tell.

 

[gattispilot]

Thanks. So I have basically this:

(-500<gaterelative_pos.x) && (gaterelative_pos.x>500)

isn't this if gaterelative_pos.x greater than -500 AND gaterelative_pos.x less than 500

 

[Urwumpe]

Thanks. So I have basically this:

(-500<gaterelative_pos.x) && (gaterelative_pos.x>500)

isn't this if gaterelative_pos.x greater than -500 AND gaterelative_pos.x less than 500

If you write it more standardized, you can see:

(gaterelative_pos.x > -500) && (gaterelative_pos.x > 500)

Anything bigger than -500 goes with your code, not as intended.

That is why it is important to use the principle of the least surprise. In your case, you are confused because the variable part is once left of the constant part and the next time right of the constant part.

 

[gattispilot]

So I have this now:

				if (((gaterelative_pos.x > -500) && (gaterelative_pos.x > 500)) && ((gaterelative_pos.y > -500) && (gaterelative_pos.y > 500)) && ((gaterelative_pos.z > -10) && (gaterelative_pos.z > 10)))

ran it and press K open the gate. And flew thru it.

And I started to run the debugger but it stated another orbiter was running.

 

[Urwumpe]

I'll just mark the errors, OK?


if (((gaterelative_pos.x > -500) && (gaterelative_pos.x > 500)) && ((gaterelative_pos.y > -500) && (gaterelative_pos.y > 500)) && ((gaterelative_pos.z > -10) && (gaterelative_pos.z > 10)))

 

[gattispilot]

Thanks. It works.

				if (((gaterelative_pos.x > -500) && (gaterelative_pos.x < 500)) && ((gaterelative_pos.y > -500) && (gaterelative_pos.y < 500)) && ((gaterelative_pos.z > -10) && (gaterelative_pos.z < 10)))

One thing I did notice was when you jump the speed is zero when you come thru.

				if (((gaterelative_pos.x > -500) && (gaterelative_pos.x < 500)) && ((gaterelative_pos.y > -500) && (gaterelative_pos.y < 500)) && ((gaterelative_pos.z > -10) && (gaterelative_pos.z < 10)))

					//if ((-500<gaterelative_pos.x>500) && (-500<gaterelative_pos.y>500) && (-10<gaterelative_pos.z>10))//ship is near gate and key pressed
				{
					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;




					jump = false;

					v->DefSetStateEx(&vs_vessel);
				}

So I guess the next thing might be to detect if it is within the cirle using your formula?

---------- Post added at 05:19 PM ---------- Previous post was at 04:40 PM ----------

				double r_squared = pow(gaterelative_pos.x, 2) + pow(gaterelative_pos.y, 2);
				if ((r_squared < GATE_RADIUS_SQUARED) && (gaterelative_pos.z > -10) && (gaterelative_pos.z < 10))

	const double GATE_RADIUS = 500.0;
	const double GATE_RADIUS_SQUARED = pow(GATE_RADIUS, 2);

 

[Urwumpe]

One thing I did notice was when you jump the speed is zero when you come thru.

Yes, likely because rvel is not used and not used properly.

Define the behavior first properly in your concept and then create the math accordingly. If you for example want to just have the velocity along the axis of the gate, this would be calculated differently. Or if you want the full relative velocity transfered with the gate, you need much more math... at least one matrix multiplication among it.

 

[gattispilot]

OK. Not sure why or if this is correct.

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;

So when it jumps it matches the other gate rvel+rofs.

But if I apply thrust going into the gate the same thrust setting remains but the speed is different.

 

[jedidia]

vs_vessel.rvel.x = vs_other_gate.rvel.x + rofs.x;

Could you please attempt to describe what this is supposed to do, step by step?

 

[gattispilot]

Thats was Fred18's code. So I now sure.
To be is seems that what what speed you came in you come out.

For me what I might do is add the Gate is open always. it detects that you are in range it jumps and then the gate closes for x time. So if you are moving going into the gate once jumped you would be moving out.

I took that code out and it jump but it put me further away from the gate B
going into the gate.

BEGIN_SHIPS
Gate_A:WORMHOLE
  STATUS Orbiting Earth
  RPOS 1405568.71 -0.02 6865713.13
  RVEL -7388.442 -0.000 1512.585
  AROT 0.00 -0.00 0.00
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 0
END
Gate_B:WORMHOLE
  STATUS Orbiting Moon
  RPOS 1591445.99 1496805.63 169749.37
  RVEL 883.910 879.877 30.203
  AROT 0.00 -0.00 0.00
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 0
END
dg:Deltaglider
  STATUS Orbiting Earth
  RPOS 1405567.75 -0.02 6865520.24
  RVEL -7388.466 -0.000 1546.626
  AROT 0.00 -0.00 0.00
  RCSMODE 2
  AFCMODE 7
  PRPLEVEL 0:0.983452 1:0.992303
  THLEVEL 0:0.122449 1:0.122449
  NAVFREQ 0 0 0 0
  XPDR 0
  AAP 0:0 0:0 0:0
END
END_SHIPS

exited the gate:

BEGIN_SHIPS
Gate_A:WORMHOLE
  STATUS Orbiting Earth
  RPOS 1362282.34 -0.02 6874432.88
  RVEL -7397.825 -0.000 1466.003
  AROT 0.00 -0.00 0.00
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 0
END
Gate_B:WORMHOLE
  STATUS Orbiting Moon
  RPOS 1596608.53 1501945.31 169924.86
  RVEL 879.583 875.807 29.742
  AROT 0.00 -0.00 0.00
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 0
END
dg:Deltaglider
  STATUS Orbiting Moon
  RPOS 1588093.00 1501043.48 171454.83
  RVEL -7396.982 -0.716 1517.601
  AROT 0.00 -0.00 0.00
  RCSMODE 2
  AFCMODE 7
  PRPLEVEL 0:0.983008 1:0.992303
  THLEVEL 0:0.122449 1:0.122449
  NAVFREQ 0 0 0 0
  XPDR 0
  AAP 0:0 0:0 0:0
END