Re: [Flightgear-devel] the new telnet server and scripting
Curtis L. Olson wrote: First, let me point out the new telnet server is *very* nice. Bernie has rewritten it based on the plib net libs. It can handle multiple concurrent connections. This is a big improvement! I'm not sure why you would need to run two or more sessions but there you go. The server design is based on Curt's httpd classes so I can't take full credit. Along with this, Bernie has also provided a demo python script that shows how you can use the telnet interface to remotely interact with and control a FlightGear application. In the cvs source (run cvs update -d of course) look in $toplevel/scripts/python for the demo script. So, to try this out run: fgfs --telnet=5500 python demo.py Then watch the action. This is a demo of functionality so you aren't going to see any earth shattering visual effects. But, it's very cool from the geeky perspective of running an external script which has complete control over flightgear. The python code is very experimental, really just proof of concept stuff. I was just toying around seeing how to use the props interface. I was thinking that this concept could be developed into a full blown demostration for exhibitions. A takeoff, circuit and landing, complete with cut-aways to external views, zooms and pans, all under script control would be really cool. Bernie, on the subjects of building additional commands into the telnet interface, I agree with Melchior. I'd rather not see the telnet interface being crammed with a bunch of extra commands that only the telnet interface knows about. I haven't looked at this in a while, but the property manager should be able to manage commands as well as values. The command management is a bit of a hack (kind of but not really) but since we can tie variables to funtions (usually getters and setters) we can expose additional functionality through the property interface. I think that would be the more appropriate way to do this and to develop additional commands. This way, these commands will be available (and consistant) for any other interface mechanisms including joystick, keyboard, mouse in addition to remote scripts or web browsers, etc. I don't have a complete handle on the property system yet. However if we can do these sort of things through properties and/or the command manager then that is definitely the way to go. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] the new telnet server and scripting
Bernie Bright writes: Curtis L. Olson wrote: First, let me point out the new telnet server is *very* nice. Bernie has rewritten it based on the plib net libs. It can handle multiple concurrent connections. This is a big improvement! I'm not sure why you would need to run two or more sessions but there you go. The server design is based on Curt's httpd classes so I can't take full credit. Perhaps you'd want to run concurrent scripts while running a remote operater gui. The python code is very experimental, really just proof of concept stuff. I was just toying around seeing how to use the props interface. I was thinking that this concept could be developed into a full blown demostration for exhibitions. A takeoff, circuit and landing, complete with cut-aways to external views, zooms and pans, all under script control would be really cool. Yes, that would definitely be very cool ... Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] the new telnet server and scripting
Curtis L. Olson wrote: [snip] Bernie, on the subjects of building additional commands into the telnet interface, I agree with Melchior. I'd rather not see the telnet interface being crammed with a bunch of extra commands that only the telnet interface knows about. I haven't looked at this in a while, but the property manager should be able to manage commands as well as values. The command management is a bit of a hack (kind of but not really) but since we can tie variables to funtions (usually getters and setters) we can expose additional functionality through the property interface. I think that would be the more appropriate way to do this and to develop additional commands. This way, these commands will be available (and consistant) for any other interface mechanisms including joystick, keyboard, mouse in addition to remote scripts or web browsers, etc. Bear with me while I get up to speed with the property system but I'm just brainstorming... Assuming we create some write-only properties that are tied to commands. Perhaps something like: /command/view/next /command/view/prev Writing a value to /command/view/next switches to the next view. Now this functionality duplicates the view-cycle builtin command so I'm wondering if should combine these two concepts? Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] the new telnet server
The new telnet server has really become nice. It's great to be able to connect more than just once. :-) But I don't like the new commands: view set n display view 'n' view get return current view index view current return current view index Why bloat the interface when this can easily be done with the normal set and get commands? view current is not even consistent. It gets a simple value. This should be: get /sim/view/current or something like that. Comments in the telnet.cxx file leave me even more worried: * TODO: possible future commands: * panel visible 0|1 * panel height - h, Retrieve panel height * panel width - w, Retrieve panel width * panel xoffset - x, Retrieve panel x offset * panel yoffset - y, Retrieve panel y offset [and lots more] Please don't let that happen! Make this get /sim/panel/visible etc. There's no need for dozens of commands that do all just set and get properties. That's useless bloat and we'll lose consistency with the http interface. Don't re-invent the property system! The only thing that might make sense is: view nextdisplay next view view prevdisplay prev view But I'd rather drop them, too, and make some write only property: set /sim/view/next true would then always switch to the next view, while get /sim/view/next would always return false. m. :-( ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] the new telnet server and scripting
First, let me point out the new telnet server is *very* nice. Bernie has rewritten it based on the plib net libs. It can handle multiple concurrent connections. This is a big improvement! Along with this, Bernie has also provided a demo python script that shows how you can use the telnet interface to remotely interact with and control a FlightGear application. In the cvs source (run cvs update -d of course) look in $toplevel/scripts/python for the demo script. So, to try this out run: fgfs --telnet=5500 python demo.py Then watch the action. This is a demo of functionality so you aren't going to see any earth shattering visual effects. But, it's very cool from the geeky perspective of running an external script which has complete control over flightgear. Bernie, on the subjects of building additional commands into the telnet interface, I agree with Melchior. I'd rather not see the telnet interface being crammed with a bunch of extra commands that only the telnet interface knows about. I haven't looked at this in a while, but the property manager should be able to manage commands as well as values. The command management is a bit of a hack (kind of but not really) but since we can tie variables to funtions (usually getters and setters) we can expose additional functionality through the property interface. I think that would be the more appropriate way to do this and to develop additional commands. This way, these commands will be available (and consistant) for any other interface mechanisms including joystick, keyboard, mouse in addition to remote scripts or web browsers, etc. Regards, Curt. Melchior FRANZ writes: The new telnet server has really become nice. It's great to be able to connect more than just once. :-) But I don't like the new commands: view set n display view 'n' view get return current view index view current return current view index Why bloat the interface when this can easily be done with the normal set and get commands? view current is not even consistent. It gets a simple value. This should be: get /sim/view/current or something like that. Comments in the telnet.cxx file leave me even more worried: * TODO: possible future commands: * panel visible 0|1 * panel height - h, Retrieve panel height * panel width - w, Retrieve panel width * panel xoffset - x, Retrieve panel x offset * panel yoffset - y, Retrieve panel y offset [and lots more] Please don't let that happen! Make this get /sim/panel/visible etc. There's no need for dozens of commands that do all just set and get properties. That's useless bloat and we'll lose consistency with the http interface. Don't re-invent the property system! The only thing that might make sense is: view nextdisplay next view view prevdisplay prev view But I'd rather drop them, too, and make some write only property: set /sim/view/next true would then always switch to the next view, while get /sim/view/next would always return false. m. :-( ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
