Idea Ports: an addon idea.

[n72.75]

So I had an idea but I have no idea how to implement it. If someone has an idea, feel free to point me in the right direction or tackle it your self.

Say I have an arbitrary number of vessels. These vessels are all compiled with ports.h. ports.h contains several functions for sending and listening for data on "ports". "ports" are assigned an integer value in the scenario or by user input.

The plugin: ports.dll runs under Orbiter and is responsible for getting data from the sender and transmitting it to the receiver.


Example implementation: Spacecraft controlling engine gimbals angles on it's launcher.


I can't figure out how to do it. Maybe there's already a plugin that does it already, if so I've never heard of it.

 

[Artlav]

Sockets in Orbiter!
Easy to make if it's really something worth having.

You can easily have all kinds of communication between unrelated vessels.
Some protocol would have to be made for that.

What kind of functions is it worth to have?
Status and control?
UMMU binding, something for generic environment simulation?
Authorization or anyone controls anyone?

And not only vessels, MFDs and other modules could communicate like that as well.

All in all, is it worth bothering?

Keep in mind, that probability of this becoming standard like UMMU is slightly less than nothing, so it won't be any vessel to any vessel, but rather a few freak vessels between themselves.
Things like reading fuel levels or thrust control could be emulated for unsupporting vessels, however.

 

[n72.75]

My intention is more like CVEL and less like UMMU in terms of developer demography.

EDIT:

functions:

sockets.transmit(double value, int sockets);
sockets.listen(double value, int sockets);

With these you could point any value from your vessel to 'value' or 'socket'. The only issue that I foresee is conflicting sockets. But that's a user problem.

 

[Grover]

so you mean communicating between vessels using a port?

that sounds incredibly useful, would it just be physically connected vessels? or any vessel to another?

 

[Artlav]

so you mean communicating between vessels using a port?

that sounds incredibly useful, would it just be physically connected vessels? or any vessel to another?

Think TCP or UNIX sockets - a common interface to define communications between vessels, modules, MFDs, etc.

Whether it would need being docked is entirely at particular add-on developer's discretion.

 

[Moach]

ehrm....

if i understand correctly, you mean to add a vessel-to-vessel control interface?

then let me get a different angle on it - you can only actively control one single vessel at a single time, right? (the "focused" one)....

so isn't what you mean to accomplish here is much like the vessel-stack module already does, enable one vessel to operate another by relaying pilot inputs and compensating for CoG and whatnot....

what i'm saying is... this just might already exist


i had thought of this a number of times already - and it's much simpler than what you're suggesting, really... you don't need a socket to communicate between vessels - you can pretty much have a them do it over user-type messages with the API

and if you're just trying to have them control eachother (like a capsule telling the launcher what to do) - it's even simpler, since you can pretty much just "remote-control" it

see the remote control sample in the sdk... it does just that :hmm:


and the advantage of this would be - you don't need the "controllee" vessel to "listen" to the controller.... you can just feed it a stream of overriding commands and force it to have it your way (ideally going without any self-launching autopilots would be best here)



but hear me out, for i think i just might be on my ways for eventually doing something towards this end... :stirpot:

if this is a flight-controls only deal, then it needn't really bother with adding "broadcast" stuff on the controller vessel.... these signals could very well be sent from the input interface module, which is not even really a vessel

remember that i built a little directinpput module a while back? - while the current version is little more than a hack to allow me use of my saitek rudder pedals and spacenavigator, the future plan for that very much unfinished project (heck, i haven't even started) is to create an SDK for it, much like OrbiterSound

this SDK would expose controls directly from the axes and buttons in a standardized way, that ANY vessels (focus or not) could read at any time....

this interface could very well be exploited as a way of remote-controlling another vessel, i.e. payload-to-launcher control coupling (focus the capsule, "man" the launcher)



so, if this is kinda like what you had in mind, then i have plans to build it in a near-ish future (wanna get more of the G42 working first...) :thumbup:

if not, then well... dunno... :shifty:

 

[n72.75]

Not just remote control, I need something that can read and from and to any variable between two vessels. Hence the sockets/ports idea.

 

[Urwumpe]

I have something similar here in the Black Dart, but this is a bit different to your idea, since it assumes radio or laser communication and fairly long separation between the vessels. Also, it assumes small amounts of data, at fairly low transmission speeds... but it does it with time delay and (only documented) doppler shift, also it supports a few antenna parameters. For higher data rates, I would need better data structures and possibly the ability to store transmissions on HD until needed.

It is a low level protocol for building C4I networks in it, but I already work on separating it into a library of its own for other projects. It is related to a radar simulation based on clbkGeneric.

 

[Hlynkacg]

Sockets in Orbiter!
Easy to make if it's really something worth having.

You can easily have all kinds of communication between unrelated vessels.
Some protocol would have to be made for that.

What kind of functions is it worth to have?
Status and control?
UMMU binding, something for generic environment simulation?
Authorization or anyone controls anyone?

And not only vessels, MFDs and other modules could communicate like that as well.

All in all, is it worth bothering?

this SDK would expose controls directly from the axes and buttons in a standardized way, that ANY vessels (focus or not) could read at any time....

this interface could very well be exploited as a way of remote-controlling another vessel, i.e. payload-to-launcher control coupling (focus the capsule, "man" the launcher)

so, if this is kinda like what you had in mind, then i have plans to build it in a near-ish future (wanna get more of the G42 working first...) :thumbup:

if not, then well... dunno... :shifty:

I'd be interested in this.

I eventually want to rig a proper .dll for my [ame="http://www.orbithangar.com/searchid.php?ID=5339"]Nuclear Shuttle[/ame] that would allow it to recieve user/autopilot commands (IMFDs autoburn for instance) from any docked vessel.

 

[Zatnikitelman]

Um, I know I don't have the experience of many of the developers that have posted above me, but why not just use the VESSEL3 clbkGeneric?

clbkGeneric  ( int  msgid = 0,  int  prm = 0, void * context = NULL)

If the vessel needs to respond to a particular message id, then it can return a nonzero value and pass data back and forth with the context void pointer.

 

[Urwumpe]

I exactly use this interface for my communication/Radar stuff. Is not that hard to use and as long as all follow some coding standards, a pretty reliable method at least for VESSEL3 based vehicles.

 

[n122vu]

I also see this being possibly useful for creating any sort of Mission Control setup for Orbiter. The sockets could also be used to transmit telemetry data to the 'ground control' location in Orbiter. The 'Ground Control' data could be saved as a separate file for later review (Is this already implemented? Think performance evaluation, possibly useful for refining autopilot guidance).

Just random thinking on the matter...

 

[Urwumpe]

I also see this being possibly useful for creating any sort of Mission Control setup for Orbiter. The sockets could also be used to transmit telemetry data to the 'ground control' location in Orbiter. The 'Ground Control' data could be saved as a separate file for later review (Is this already implemented? Think performance evaluation, possibly useful for refining autopilot guidance).

Just random thinking on the matter...

Thinking the same there.

But my experiment currently happens at very slow pace... my PC needs oil...which is a really bad sign.

 

[Hlynkacg]

...why not just use the VESSEL3 clbkGeneric?

clbkGeneric  ( int  msgid = 0,  int  prm = 0, void * context = NULL)

To be perfectly frank, I don't know how.