20,741
edits
Telnet usage: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
mNo edit summary |
||
| Line 65: | Line 65: | ||
This makes it possible to "remote control" FlightGear by using the telnet protocol. This can for example be used to change environment settings (weather, time, visibility etc). But you can also remotely fail equipment: Use the telnet/http interface to unset the "serviceable" flags on the affected instruments and systems. All you need to write is a little script (perl,python, netcat) to do the 25-to-1 multiplex/demultiplex operation. | This makes it possible to "remote control" FlightGear by using the telnet protocol. This can for example be used to change environment settings (weather, time, visibility etc). But you can also remotely fail equipment: Use the telnet/http interface to unset the "serviceable" flags on the affected instruments and systems. All you need to write is a little script (perl,python, netcat) to do the 25-to-1 multiplex/demultiplex operation. | ||
Many internals are exposed through the property tree, which is accesible in many ways. There is a http and a telnet interface ready for use. A powerful thing is the interface with a freely configurable protocol to send and receive properties. This interface can talk via tcp or udp. | |||
So you need some kind of gui to trigger the failures, a layer that translates this to flightgear properties and a communication layer that communicates | |||
with the flightgear instances. This is an independent application, so you can write it in c, c++, c#, java, php or whatever you like, but you might keep | |||
cross platform usability in mind. | |||
Probably not every aircraft developer has implented every failure feature in his aircraft, since most of them are happy if the "normal procedures" work. | |||
Also, some systems are implemented, some are not. So for most GA aircraft for example, the landing gear has no model for the hydraulic system but a | |||
simple "if you operate the gear lever, the gear is extending" functionality. | |||
But a telnet connection can also be used for inserting scenery objects or [[Interactive traffic|AI aircraft]] models dynamically. It is also possible to trigger arbitrary [[Nasal]] code by writing to a property with a registered Nasal listener. In fact, it is even possible to insert and run Nasal code via telnet, by writing the code to a property and call()'ing it then [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00150.html][http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00965.html]. | But a telnet connection can also be used for inserting scenery objects or [[Interactive traffic|AI aircraft]] models dynamically. It is also possible to trigger arbitrary [[Nasal]] code by writing to a property with a registered Nasal listener. In fact, it is even possible to insert and run Nasal code via telnet, by writing the code to a property and call()'ing it then [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00150.html][http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00965.html]. | ||
Information on nearby multiplayer entities is provided in the property tree so you can access this information at least within flightgear. You could | |||
query this data via the property interface, or build some sort of nasal script. | |||
Multiple connections are possible at the same time. For an example in Java please refer to [http://gitorious.org/fg/flightgear/blobs/next/scripts/java/FGClient/src/FGFSDemo.java $FG_SRC/scripts/FGClient]. | Multiple connections are possible at the same time. For an example in Java please refer to [http://gitorious.org/fg/flightgear/blobs/next/scripts/java/FGClient/src/FGFSDemo.java $FG_SRC/scripts/FGClient]. | ||