[Flightgear-devel] Multiplayer ports
Hi guys, Without wishing to start a flame war and perhaps starting another thread!! Anyone transmitting un-encrypted data across a world wide internet (as opposed to a private intranet) needs to think ahead a little. Every hacker will be rubbing their hands with glee before trying to hit you on these ports you have just announced. A server/client or even peer-to-peer client can implement TLS/SSL fairly easily. For those with restricted firewalls you can tunnel through SSH port 22 if you want to keep it simple. Firewall/NAT configurations are difficult enough for admins to configure without having to allow special FlightGear port rules to allow access to ports on machines in-the-clear which may then get hacked thus compromising the security of everyone behind the firewall. Maybe I am paranoid (well known for it in my previous job!) but a denial-of-service attack on your multi-player ports will soon wreck your response times! cheers Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: jsclient and js_server
Hi, I notice that Plib library allows: #define _JS_MAX_AXES 16 #define _JS_MAX_BUTTONS 32 #define _JS_MAX_HATS 4 so maybe we should stick to these limits. I am also in discussions with Jon (JSB) about server/client communication to and from JSBsim for passing property values back and forth. XML-RPC looks interesting for heterogeneous multi-processor/process communications. General RPC can be used for passing any parameter and with XDR dont have to worry about endianness,packing, and general socketry etc. With RPC js_server wouldnt need to do wait and the jsclient bit could just overload the normal joystick reading with an RPC call. With XML-RPC we could just pass the property list /jsclient/axis[i] directly. Extending this idea the js_server would be just one of a class of input/output servers eg engine_server - modelling engines,cockpit display server -for eg OpenGC,motion platform server etc. cheers Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RFE for jsclient,js_server
Hi, Can the jsclient and the js_server code be extended to allow up to eight joystick axis and the jsclient.cxx code enhanced to accept the button bits? It looks like the js_server.cxx code is encapsulating the button word as long integer but it is not being decoded on jsclient.cxx side. cheers Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: code optimisation
Hi, One comment and some documentation has indicted that FDM doesnt consume much CPU. I ask myself why? The modelling of a generalised rigid body with six degrees of freedom in a rotating frame of reference should max out anyones and everyones CPU! Of course any model is only as good as the approximations used so we apply symmetry to an aircraft (what happens if an engine drops off!) and various other restrictions. From my point of view I would rather devote spare CPU to the accuracy of the FDM. I notice that JSBSim uses a simple single step method for integration whereas LaRCSim uses a multi-step method. Spare CPU could be utilised in doing a multi-step predictor/corrector integration with variable step size especially for more esoteric aircraft types with high speeds and high altitudes and even near orbital capability in JSBSim. Anyone with any comments or advice or done anything similar? cheers Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] optimisation of FlightGear code
Hi folks, Hopefully I would like to start a discussion of Flightgear code optimisation. My first thoughts are that fgfs divides logically into a number of sub-systems: a) Flight Dynamics Modelling (FDM) b) Exterior View c) Cockpit input and output ie joystick controls,switches and displays. d) Motion system but for time being I am going to disregard the last!! These sub-systems could be physically separated into processes (programs, threads - whatever you like to call them) and inter-linked with IPC eg tcp/ip, Unix sockets,etc. This would enable: 1) a critical block analysis (CBA) to be run on each sub-system to identify the most frequently used code which can then be optimised by any number of techniques. eg compiler optimisation,manual optimisation, re-writing in a more efficient language (without wishing to start a flame war, C++ and Object Orientated languages may be ideal for code development but I know of no object orientated hardware so they may not get the best out of the available hardware.) 2) running the different sub-systems on different inter-linked computers and indeed on different hardware (Intel is not famed for its floating point arithmetic so FDM may be better on PowerPC,UltraSPARC etc but there is a great range of graphics hardware which makes Linux/Intel flexible for view and cockpit). 3) tuning the frame rate of individual sub-systems (the FDM itself may benefit from different and variable frame rate for the lateral and rotational elements of the aerodynamical derivative integrations) These are just my first thoughts without tracking through every line of code as yet so maybe some of this has already been done? I dont want to repeat things that have already been chewed over so any ideas would be welcome. cheers Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] keyboards etc
Hi, Someone once said that Britain and America are two countries only separated by a common language!! To get away from keyboard I am cannabalising cheap USB gamepads to make switch boxes. My first try is the Logic 3 JP260 which has 10 buttons I can use. However MACOSX reports unknown Vendor although the JP260 reports correctly a vendor id and product id. Anyone any idea whether the vendor list is hard-coded in the driver or is there a property list somewhere.? cheers Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] carb-heat
Hi,
On the Cessna 172/150 range of aircraft the carb-heat control is a
progressive
knob as for mixture. The operators recommendation is indeed that only
FULL or
off should be used and it is represented as bool in flight gear but
is this a correct
interpretation. If the actual aircraft panel is a variable control
should the representation
be variable and up to the pilot to use in the recommended fashion.
Anyone any opinions
on this point (maybe I am just being too pendantic!!)?
cheers
Jim
FGControls::set_carb_heat( int engine, bool val )
{
if ( engine == ALL_ENGINES ) {
for ( int i = 0; i MAX_ENGINES; i++ ) {
carb_heat[i] = val;
}
} else {
if ( (engine = 0) (engine MAX_ENGINES) ) {
carb_heat[engine] = val;
}
}
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] diffs requested for joystick mods
Apologies guys for not providing diff files for previous suggestions
on joysticks.
Wanted to see if anyone was interested before I did so!
Here we go:
For Nasal/controls.nas:
diff -up controls.nas.orig controls.nas
--- controls.nas.orig Sat Jun 18 15:50:59 2005
+++ controls.nasSat Jun 18 16:02:44 2005
@@ -76,6 +76,12 @@ propellerAxis = func {
if(size(arg) 0) { val = -val; }
props.setAll(/controls/engines/engine, propeller-pitch, (1 -
val)/2);
}
+carbheatAxis = func {
+val = cmdarg().getNode(setting).getValue();
+if(size(arg) 0) { val = -val; }
+props.setAll(/controls/anti-ice/engine, carb-heat, (1 -
val)/2);
+}
+
##
# Wrapper around stepProps() which emulates the old flap behavior for
For Input/Joysticks/Saitek/X45.xml:
diff -up X45.xml.orig X45.xml
--- X45.xml.origMon May 10 16:30:02 2004
+++ X45.xml Sat Jun 18 16:18:30 2005
@@ -10,16 +10,19 @@ Only a few stick controls have been mapp
+ Stick button A:Gear toggle
+ Stick button C:Reset view (hackish)
+Corrections here when Plib fixed to recognise dial
+([EMAIL PROTECTED] 17/6/2005)
+
Linux/Windows/Mac Axis Numbers:
0Roll (positive == right)
1Pitch (positive == down/back/nose-up)
- 2/5/4 top rotary dial on the throttle (positive == CCW)
+ 2/5/5 top rotary dial on the throttle (positive == CCW)
3Rocker switch (rudder control) on the throttle (positive ==
right)
4/2/2 Throttle (positive == back/down/idle)
- 5/4/? Bottom rotary dial on the throttle (positive == CW)
+ 5/4/4 Bottom rotary dial on the throttle (positive == CW)
Strange this axis doesn't seem to exist on Mac OS X!
- 6/6/5 Lower right hat horizontal axis (positive == right)
- 7/7/6 Lower right hat vertical axis (positive == down (Mac positive
is UP))
+ 6/6/6 Lower right hat horizontal axis (positive == right)
+ 7/7/7 Lower right hat vertical axis (positive == down (Mac positive
is UP))
Button Numbers (Identical b/w Linux/Windows/Mac):
0 Trigger
@@ -55,6 +58,7 @@ $Id: X45.xml,v 1.11 2004/05/06 16:12:32
nameSaitek X45/name
nameSaitek Saitek X45/name
nameSaitek X45 Flight Controller USB/name
+ nameSaitek X45 Flight Control Stick /name
axis n=0
descAileron/desc
@@ -103,7 +107,7 @@ $Id: X45.xml,v 1.11 2004/05/06 16:12:32
number
unix6/unix
windows6/windows
- mac5/mac
+ mac6/mac
/number
descView Direction/desc
low
@@ -127,7 +131,7 @@ $Id: X45.xml,v 1.11 2004/05/06 16:12:32
number
unix7/unix
windows7/windows
- mac6/mac
+ mac7/mac
/number
low
repeatabletrue/repeatable
@@ -163,6 +167,7 @@ $Id: X45.xml,v 1.11 2004/05/06 16:12:32
number
unix2/unix
windows5/windows
+ mac5/mac
/number
binding
commandnasal/command
@@ -175,11 +180,11 @@ $Id: X45.xml,v 1.11 2004/05/06 16:12:32
number
unix5/unix
windows4/windows
-!-- mac???/mac --
+ mac4/mac
/number
binding
commandnasal/command
- scriptcontrols.propellerAxis(-1)/script
+ scriptcontrols.carbheatAxis()/script
/binding
/axis
For plib-1.8.4/src/js/jsMacOSX.cxx :
diff -up jsMacOSX.cxx.orig jsMacOSX.cxx
--- jsMacOSX.cxx.orig Tue Sep 21 12:45:55 2004
+++ jsMacOSX.cxxMon Jun 20 17:14:46 2005
@@ -183,7 +183,7 @@ void jsJoystick::open()
plugin, score);
if (rv != kIOReturnSuccess) {
- ulSetError(UL_WARNING, error creting plugin for io
device);
+ ulSetError(UL_WARNING, error creating plugin for io
device);
return;
}
@@ -275,7 +275,7 @@ void os_specific_s::enumerateElements(js
elementEnumerator, joy);
}
-static void os_specific_s::elementEnumerator( const void *element,
void* vjs)
+void os_specific_s::elementEnumerator( const void *element, void* vjs)
{
if (CFGetTypeID((CFTypeRef) element) !=
CFDictionaryGetTypeID()) {
ulSetError(UL_WARNING, element enumerator passed
non-dictionary value);
@@ -315,6 +315,7 @@ void os_specific_s::parseElement(jsJoyst
case kHIDUsage_GD_Ry:
case kHIDUsage_GD_Rz:
case kHIDUsage_GD_Slider: // for
throttle / trim controls
+case kHIDUsage_GD_Dial:
//printf( axis\n);
/*joy-os-*/addAxisElement(joy, (CFDictionaryRef) element);
break;
cheers
Jim
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] newbee
Hi guys,
Just returning to flight simulation after many years abscence (well
used to have a real job to do!!).
Flightgear looks like a really good project to get involved in.
I am hoping to look at code optimisation in the refresh loop of the
bits that do sums.
I am more familiar with compiler optimisation in Fortran which as it
has intrinsic functions
and arrays (and complex!!) you could let a decent compiler to a lot of
the work. With C and
C++ (especially with overloading) I guess its back to the code writer
to manually optimise arrays and sums!!
A few things I have fixed already in setting up MacOSX (10.3) with
Saitek X45 joystick
are the Plib library routine jsMacOSX.cxx which didnt recognise one of
the rotary dials
on the X45 as it doesnt recognise kHIDUsage_GD_Dial:
if (page == kHIDPage_GenericDesktop) {
switch (usage) /* look at usage to determine function */
{
case kHIDUsage_GD_X:
case kHIDUsage_GD_Y:
case kHIDUsage_GD_Z:
case kHIDUsage_GD_Rx:
case kHIDUsage_GD_Ry:
case kHIDUsage_GD_Rz:
case kHIDUsage_GD_Slider: // for throttle / trim
controls
case kHIDUsage_GD_Dial:
//printf( axis\n);
/*joy-os-*/addAxisElement(joy, (CFDictionaryRef)
element);
break;
case kHIDUsage_GD_Hatswitch:
//printf( hat\n);
/*joy-os-*/addHatElement(joy, (CFDictionaryRef)
element);
break;
default:
ulSetError(UL_WARNING, input type element has
weird usage (%lx)\n, usage);
break;
an addition to Nasal/controls.nas to allow this dial to be used as
carb-heat (was specified as propellor-advance in original X45.xml but I
dont remember C172 having variable pitch!?):
# Joystick axis handlers (uses cmdarg). Shouldn't be called from
# other contexts.
throttleAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
props.setAll(/controls/engines/engine, throttle, (1 - val)/2);
}
mixtureAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
props.setAll(/controls/engines/engine, mixture, (1 - val)/2);
}
propellerAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
props.setAll(/controls/engines/engine, propeller-pitch, (1 -
val)/2);
}
carbheatAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
props.setAll(/controls/anti-ice/engine, carb-heat, (1 - val)/2);
}
and of course the X45.xml now needs to cater for extra axis (so no need
for comments on MacOSX not having this dial!!):
?xml version=1.0?
!--
Only a few stick controls have been mapped here:
+ Rocker switch: Rudder
+ Top rotary dial: Mixture
+ Bottom rotary dial: Prop Advance
+ Top stick hat: Elevator Aileron trim
+ Bottom stick hat:View direction
+ Top throttle hat:Flaps Rudder trim
+ Stick button A:Gear toggle
+ Stick button C:Reset view (hackish)
Corrections here when Plib fixed to recognise dial
([EMAIL PROTECTED] 17/6/2005)
Linux/Windows/Mac Axis Numbers:
0 Roll (positive == right)
1 Pitch (positive == down/back/nose-up)
2/5/5 top rotary dial on the throttle (positive == CCW)
3 Rocker switch (rudder control) on the throttle (positive ==
right)
4/2/2 Throttle (positive == back/down/idle)
5/4/4 Bottom rotary dial on the throttle (positive == CW)
Strange this axis doesn't seem to exist on Mac OS X!
6/6/6 Lower right hat horizontal axis (positive == right)
7/7/7 Lower right hat vertical axis (positive == down (Mac positive
is UP))
Button Numbers (Identical b/w Linux/Windows/Mac):
0 Trigger
1 Stick top A switch
2 Stick top B switch
3 Stick top launch/fire switch
4 Throttle D switch
5 Throttle mouse switch (tiny black thumb button)
6 Stick pinkie switch
7 Stick front C switch
8 -+left position (M1)
9 +- Throttle mode 3-way switch: middle position (M2)
10 -+right position (M3)
11 -+left position
12 +- Throttle Aux 3-way switch: middle position
13 -+right position
14 Upper left hat in up position
15 Upper left hat in right position
16 Upper left hat in down position
17 Upper left hat in left position
18 Throttle forefinger hat in up/back position
19 Throttle forefinger hat in right position
20 Throttle forefinger hat in down/forward position
21 Throttle forefinger hat in left position
22 Throttle thumb hat in up position
23 Throttle thumb hat in right position
24 Throttle thumb hat in down position
25 Throttle thumb hat in left position
$Id: X45.xml,v 1.11 2004/05/06 16:12:32
