Question Rwarp and flying in atmo

[Face]

Thanks. for you it might be but for others maybe not.

At least those who are willing (and capable) of coding that thing seem to think so. I guess that's what counts here.

Dreaming up something is one thing, doing it another. With the former, you can skip all the rules you want, with the later, you have to obey at least some. Lucky for us, we don't really have to obey physics in Orbiter, but mathematics still apply. The problem at hand is not a physical one, but a mathematical one. It is called "vector math".

However, if you get your ideas straight, and if those ideas also happen to spark some enthusiasm in coders because of their sound appearance, chances are higher to get help or even implementations.

I doubt that "Scenario Editor with fancy effects" will do that, though.

I used the RTF stargate one at Cape Canaveral and added one at White sands.

But the code for the stargate is lost. But the concept is there. But rather than place a star gate where you want to go. You just dial it in the mfd

I selected the White sands gate. Increase thrust measured in the HUD as Groundspeed on Earth and move into the gate and after leaving Earth visually I arrived at White Sands at about the same speed.

Ok, since you are talking about gates, you are also talking about speed conservation in relation to those gates, NOT Earth. If you'd put one of those gates into orbit, the departing vessel's speed relative to the departure gate would be added to the target gate and applied to the vessel on arrival. Thus it would be in orbit together with the gate, and NOT overtaken by the gate with orbital speed and fall down to earth because only the groundspeed was conserved. Because if somebody would implement it like that later way, you'd be the first to point out excessive speed on arrival, right?

The stargate concept is no problem to put into code, precisely because of the clear definition of speed frames of references. After all, the user of such a system already declared what the later should be, namely the departure and target gate's frame of reference, which he conveniently placed in the scenario before, perhaps with something like... the scenario editor .

You think that this is just the same if you put the gates away, but it isn't. There is no magic sauce in that gate-source, so to say.

 

[gattispilot]

Dreaming up something is one thing, doing it another.

Agreed. As a maker of addons I look for others ideas and try to make them if I am interested.

The stargate concept is no problem to put into code, precisely because of the clear definition of speed frames of references. After all, the user of such a system already declared what the later should be, namely the departure and target gate's frame of reference, which he conveniently placed in the scenario before, perhaps with something like... the scenario editor .

You think that this is just the same if you put the gates away, but it isn't. There is no magic sauce in that gate-source, so to say.

Ok. So how would someone do it. Where rather than place a gate at your designation, you select the designation and engage the ID (Inter Dimensional) drive and some effect and your vessel is moved there. But not in a instance but maybe minutes versus a longer time.

 

[Face]

Ok. So how would someone do it. Where rather than place a gate at your designation, you select the designation and engage the ID (Inter Dimensional) drive and some effect and your vessel is moved there. But not in a instance but maybe minutes versus a longer time.

Unfortunately, what you describe is skipping (if not to say cheating) over the problem part.

The point is how you "select the designation". "Designation" not only incorporates the target position, but also the target frame of reference. And since you are not having a departure gate, you also have to select a source frame of reference.

So if you do not have an automatic frame of reference selection (like with JumpDriveMFD, where it is the global frame of reference for both source and target velocity), your ID user would have to select the following before the jump show:

1. Target position. Predefined list (e.g. all bases, all pads on all planets, perhaps in a tree-view control), or free coordinates (in either global frame, gbody frame - also select which gbody -, base local coordinates - also select which base -, or gbody long/lat coordinates - also select which gbody). In other words: a scenario editor dialog.
2. Source velocity frame of reference, i.e. against what thing you measure the velocity value/direction you want to conserve during jump. That could be selected just like the target position. In other words: another scenario editor dialog.
3. Target velocity frame of reference, i.e. what you want the conserved value/direction be added to to form the resulting speed of the jumping vessel. Again this could be selected like the target position. Or to repeat yet again: another scenario editor dialog.

So it would end up with a device implementation that presents the user 3 times a scenario editor dialog complexity just to go somewhere "in style". Well, this is all easy to implement, but not really worth the time IMHO.


However, since you are a developer yourself, why don't you just go and code that 3 pages of selection dialogs (I recon it to be possible to re-use the appropriate pages from the Scenario Editor code), coupled with some vector math to plug in the numbers into the VESSELSTATUS2 struct to feed the eventual DefSetStateEx() call? Is it the effect that makes you hesitate?

 

[gattispilot]

Thanks. Presently that is beyond my coding level. Not done dialog boxes as yet. Now that I got VS2013 pro I can. But I had express.

What makes me hesitate is the level of coding to do it. As I have to be a Jack of all trades and Master of none. Since I have 4 orbiter projects in various levels.

 

[Urwumpe]

Thanks. Presently that is beyond my coding level. Not done dialog boxes as yet. Now that I got VS2013 pro I can. But I had express.

What makes me hesitate is the level of coding to do it. As I have to be a Jack of all trades and Master of none. Since I have 4 orbiter projects in various levels.

Why aim for the ultimate edition already? You could also design a jump drive interface to be integrated as component in panel2D or VC projects. Like a special display screen to be painted on a surface with SketchPad and be controlled by simple mouse events.

Not that it is much easier than Windows dialogs IMHO, but it spares you from leaving the safe confines of the Orbiter SDK behind.

 

[Face]

What makes me hesitate is the level of coding to do it. As I have to be a Jack of all trades and Master of none. Since I have 4 orbiter projects in various levels.

I think you underestimate your skills.

Why not starting small if some of those "trades" are currently outside of reach?

You could perhaps start with a simple - but extensible - skeleton implementation. Let's assume the following:

• As display the MFD system is used, so you implement the whole thing as MFD mode first.
• Forget about the complex frame of reference selection first, just select position, and then only the position of another vessel. Display which other vessel is selected in the MFD.
• To select the vessel, just open a text input window as per Orbiter API, wired to a MFD button click. The name of the vessel should be the key to select the target.
• With another "JMP" button, you displace the current vessel instantly to the position of the target vessel, copying the velocity and attitude of the target vessel. This equals a frames of reference selection where the source frame is the current vessel itself, and the target frame is the one of the target vessel. Well, not totally, but close enough for a first-timer.

Upon this already working minimal jump implementation, you can then gradually add details:

• finer target selection possibilities (not only name for vessel, but also bases/planets/coordinates),
• explicit frame of reference selection (e.g. source measures ground speed to nearest gbody, target applies it to ground speed on target nearest gbody),
• effect during displacement (e.g. dummy mesh around the current vessel with rotating textures or somesuch),
• sound,
• other means of user experience than MFD (e.g. dialog, HUD, VC add-on).

BTW, the above described minimal jump feature is already implemented in the OMP client. There you can target another vessel, enter "%jump to XY" into a box, and POFF... you are there, 1 klick away and with the same speed.

 

[gattispilot]

Ok. I am going to step into the new make a MFD world.

I copied the MFD Template folder and loaded it renamed the files IDDRIVE. But there is one file it didn't find.
MFDTemplate.rc I didn't even see it on the computer

https://dl.dropboxusercontent.com/u/71242599/IDDRIVESETUP.jpg

I fixed it by removing it

 

[gattispilot]

I have been working on this with FACE's help. I wondered why a MFD I guess the answer is you would have to code this in any ship.

enter your target

case 0:
			
			oapiOpenInputBox("Enter target name:", TargetSelect, 0, 20, (void*)this);

			break;
		}

get the handle of target

bool TargetSelect(void *id, char *str, void *data)
{
	sprintf(targetselected, "%s", str);
	OBJHANDLE targethandle = oapiGetObjectByName(str);
	return 1;
}

This should get the status of target and then apply that to my vessel, right?

void IDDRIVE::MOVEVESSEL(double SimT, double SimDT)
{
	OBJHANDLE targethandle = oapiGetObjectByName(str);  // gets the handle of target
	VESSEL *v = oapiGetVesselInterface(targethandle);  //gets interface of target
	
	vessel->GetStatusEx(&targethandle);  //get status of target
	//sprintf(targetselected, "%s", str);
	OBJHANDLE me = vessel->GetHandle();  //get the focus ship handle
	VESSEL *v2 = oapiGetVesselInterface(me); // get the focus ship interface

	vessel->DefSetStateEx(&me); 


}

But It does nothing

 

[Face]

This should get the status of target and then apply that to my vessel, right?

void IDDRIVE::MOVEVESSEL(double SimT, double SimDT)
{
    OBJHANDLE targethandle = oapiGetObjectByName(str);  // gets the handle of target
    VESSEL *v = oapiGetVesselInterface(targethandle);  //gets interface of target
    
    vessel->GetStatusEx(&targethandle);  //get status of target
    //sprintf(targetselected, "%s", str);
    OBJHANDLE me = vessel->GetHandle();  //get the focus ship handle
    VESSEL *v2 = oapiGetVesselInterface(me); // get the focus ship interface

    vessel->DefSetStateEx(&me); 


}

But It does nothing

It does nothing because it is completely wrong.

Getting the status of the target would be defining a VESSELSTATUS2 struct, then calling v->GetStatus(<pointer_to_that_INITIATED!_struct>), not vessel->GetStatus with a OBJHANDLE. You had it about right before, why did you do that now?

After having the status of the target vessel in the struct, apply it to the focus vessel. I assume your "vessel" member there is the MFD owner, so vessel->DefSetStateEx(<pointer_to_that_struct>) will do it in the end.

 

[gattispilot]

It does nothing because it is completely wrong.

Getting the status of the target would be defining a VESSELSTATUS2 struct, then calling v->GetStatus(<pointer_to_that_INITIATED!_struct>), not vessel->GetStatus with a OBJHANDLE. You had it about right before, why did you do that now?

After having the status of the target vessel in the struct, apply it to the focus vessel. I assume your "vessel" member there is the MFD owner, so vessel->DefSetStateEx(<pointer_to_that_struct>) will do it in the end.

So is this right?

void IDDRIVE::MOVEVESSEL(double SimT, double SimDT)
{
    OBJHANDLE targethandle = oapiGetObjectByName(str);  // gets the handle of target
    VESSEL *v = oapiGetVesselInterface(targethandle);  //gets interface of target
    
    vessel->GetStatusEx(&targethandle);  //get status of target

 

[Face]

So is this right?

void IDDRIVE::MOVEVESSEL(double SimT, double SimDT)
{
    OBJHANDLE targethandle = oapiGetObjectByName(str);  // gets the handle of target
    VESSEL *v = oapiGetVesselInterface(targethandle);  //gets interface of target
    
    vessel->GetStatusEx(&targethandle);  //get status of target

No, because you use "vessel" at the bottom, not "v", which you assigned the vessel interface from the targethandle to. You should instead use v->GetStatusEx. Where is "vessel" even defined? Is it a class member?

 

[gattispilot]

So confused.

H:

VESSEL *vessel;

So like this:

void IDDRIVE::MOVEVESSEL(double SimT, double SimDT)
{
	OBJHANDLE targethandle = oapiGetObjectByName(str);  // gets the handle of target
	VESSEL *v = oapiGetVesselInterface(targethandle);  //gets interface of target
	
	v->GetStatusEx(&targethandle);  //get status of target

Then how to apply that to the focus vessel?

 

[Face]

void IDDRIVE::MOVEVESSEL(double SimT, double SimDT)
{
    OBJHANDLE targethandle = oapiGetObjectByName(str);  // gets the handle of target
    VESSEL *v = oapiGetVesselInterface(targethandle);  //gets interface of target
    
    v->GetStatusEx(&targethandle);  //get status of target

Then how to apply that to the focus vessel?

Still wrong, because you've put OBJHANDLE into GetStatusEx. You have to define an VESSELSTATUS2 struct and initialise it, like so:

VESSELSTATUS2 status;
status.flag=0;
status.version=2;
v->GetStatusEx(&status);

In one of the snippets you've sent me, you already had that right, though.

As for applying, oapiGetFocusInterface() would be a good candidate. It will return a pointer to the focus vessel directly. Like this:

VESSEL *v2 = oapiGetFocusInterface();
v2->DefSetStateEx(&status);

 

[gattispilot]

OK here is what I have:

void IDDRIVE::MOVEVESSEL(double SimT, double SimDT)
{
	OBJHANDLE targethandle = oapiGetObjectByName(str);  // gets the handle of target
	VESSEL *v = oapiGetVesselInterface(targethandle);  //gets interface of target
	
	//v->GetStatusEx(&targethandle);  //get status of target

	VESSELSTATUS2 status;
	status.flag = 0;
	status.version = 2;
	v->GetStatusEx(&status);



	//sprintf(targetselected, "%s", str);
	OBJHANDLE me = vessel->GetHandle();  //get the focus ship handle
	//VESSEL *v2 = oapiGetVesselInterface(me); // get the focus ship interface

	VESSEL *v2 = oapiGetFocusInterface();
	v2->DefSetStateEx(&status);

}

no errors but no movement.
When should this called for instance when a key is pressed?
Thanks

 

[Face]

OK here is what I have:

void IDDRIVE::MOVEVESSEL(double SimT, double SimDT)
{
    OBJHANDLE targethandle = oapiGetObjectByName(str);  // gets the handle of target
    VESSEL *v = oapiGetVesselInterface(targethandle);  //gets interface of target
    
    //v->GetStatusEx(&targethandle);  //get status of target

    VESSELSTATUS2 status;
    status.flag = 0;
    status.version = 2;
    v->GetStatusEx(&status);



    //sprintf(targetselected, "%s", str);
    OBJHANDLE me = vessel->GetHandle();  //get the focus ship handle
    //VESSEL *v2 = oapiGetVesselInterface(me); // get the focus ship interface

    VESSEL *v2 = oapiGetFocusInterface();
    v2->DefSetStateEx(&status);

}

no errors but no movement.
When should this called for instance when a key is pressed?
Thanks

Yes, normally this code should be called from your key-press handler. Of course you have to implement it that way, there is no magic that jumps into that function without you making it so. So for example, you have a second key "JMP", and if that press is detected in your key handler, you call your MOVEVESSEL routine.

 

[gattispilot]

Thanks. I will add that. But does it look good?

 

[Face]

Thanks. I will add that. But does it look good?

If you're not sure that your "vessel" pointer is valid, I'd delete the "OBJHANDLE me" line, because it could crash your system right away.

Of course, without a valid vessel name in "str" (maybe due to forgetting to enter the correct! target name first), the MOVEVESSEL routine will crash, too. But at your level, I'd first try to get the concept by having working code at least in the proper input case.

 

[gattispilot]

Thanks
ok. But I guess I don't understand how it knows to apply to my focused vessel?
VESSEL *v2 = oapiGetFocusInterface();
v2->DefSetStateEx(&status);

I thought I needed to get my handle? Which is me and not status?
NOt sure though

 

[Face]

Thanks
ok. But I guess I don't understand how it knows to apply to my focused vessel?
VESSEL *v2 = oapiGetFocusInterface();
v2->DefSetStateEx(&status);

I thought I needed to get my handle? Which is me and not status?
NOt sure though

oapiGetFocusInterface() gets you the vessel pointer to the focused vessel, which should be the one you are in - in most cases. You can change that later for a better way, but it gets you to the point ATM.

DefSetStateEx is taking a VESSELSTATUS2 as argument, not an OBJHANDLE. Check the docs if you don't trust me. It is a VESSEL class method, though, thus you need to get the focussed vessel pointer first to invoke the method.

So you invoked the GetStatusEx on the target vessel with parameter status, then you invoked DefSetStateEx on the focus vessel with the same parameter status.

 

[gattispilot]

Ok I renamed the move vessel:
cpp

void IDDRIVE::MOVEVESSEL(void)
{
OBJHANDLE targethandle = oapiGetObjectByName(str); // gets the handle of target
VESSEL *v = oapiGetVesselInterface(targethandle); //gets interface of target

//v->GetStatusEx(&targethandle); //get status of target

VESSELSTATUS2 status;
status.flag = 0;
status.version = 2;
v->GetStatusEx(&status);



//sprintf(targetselected, "%s", str);
//OBJHANDLE me = vessel->GetHandle(); //get the focus ship handle
//VESSEL *v2 = oapiGetVesselInterface(me); // get the focus ship interface

VESSEL *v2 = oapiGetFocusInterface();
v2->DefSetStateEx(&status);

}

bool IDDRIVE::ConsumeButton(int bt, int event)
{

//static char *targetSelect = "Enter target name:";

//sprintf(oapiDebugString(), "Button Pressed: %d",bt);
if (!(event & PANEL_MOUSE_LBDOWN) || (bt >= 2) || (bt == 99)) return false;
//if (instance[mfdFocus].mode == mSTOP)
{

switch (bt)
{
case 0:

oapiOpenInputBox("Enter target name:", TargetSelect, 0, 20, (void*)this);

break;
case 1:

MOVEVESSEL();

break;
}
return true;
}
}

h.
void MOVEVESSEL();



No errors. I put a another vessel named DG. Enter DG as targetname and press enter. Press the Jump key and a CTD