[Flightgear-devel] controls.throttleAxis mod for throttle factor and offset
Hi all,
I wanted to share my modification of the axisHandler Nasal function (the
one that implements control.throttleAxis, mixtureAxis, etc).
Purpose of the mod:
I have one of those joysticks that uses only 50% of the available
movement range for the throttle. Unfortunately for me, if a binding in
joystick.xml has a script target (eg. controls.throttleAxis) then the
offset, factor, etc modifiers are all ignored. This resulted in me not
being able to reduce throttle below 50%. I could have just mapped all
the /controls/engines/engine[n]/throttle properties to this axis
(Input/Joysticks/Logitech/wingman-force.xml does exactly that). Sadly at
the time I didn't know that I can bind multiple actions to an axis, and
somehow even after a lot of googling I didn't find the obvious
solution to this problem.
Also it strikes me that throttleAxis exists so you don't have to map
eight or more engines like that in the first place.
The mod:
The solution was really simple. I just extended the axisHanlder function
in Nasal/controls.nas with extra parameters for factor and offset, and
used those instead of the hard-coded values:
var axisHandler = func(pre, post) {
func(invert = 0, factor = 2, offset = 1) {
var val = cmdarg().getNode(setting).getValue();
if(invert) val = -val;
foreach(var e; engines)
if(e.selected.getValue()) {
setprop(pre ~ e.index ~ post, (offset - val) * factor);
}
}
}
My throttle binding now looks like this:
axis n=2
descThrottle/desc
binding
commandnasal/command
!-- throttleAxis params: invert (0 or 1), factor, offset --
scriptcontrols.throttleAxis(0, 1.1, -0.1)/script
/binding
/axis
Note that the invert param is really superfluous now -- you could just
use a negative factor instead. But I kept it for backwards-compatibility
with the way it works now. You could simplify the above function if you
got rid of it but fgjs will need to be edited as well.
I hope you find this mod useful and add it to the next Flightgear
release. If not, then at least it might show up in a Google search for
the next guy with this problem :)
Cheers,
Vik
PS: thanks for all the hard work on Flightgear so far! :)
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Immatriculation changing for SenecaII using Menu (as DR400 does)
Hi, I have added to the SenecaII the option to change immatriculation at runtime (Using the code from DR-400), at this link: http://brisa.homelinux.net/fgfs/SenecaII.tar.gz you will find the files to be replace (To the CVS version as this morning). It is an initial work, but should be ok, would it be possible to integrate it in the cvs ? Cheers Francesco -- Brisa Francesco Via Gabelli 16 22077 Olgiate Comasco (CO) http://brisa.homelinux.net france...@brisa.homelinux.net __ / / / / /___ ___ / / __/ / __ / / / __ \/ __ `__ \/ __ \ / /_/ / /___ /_/ / /___/ /_/ / / / / / / /_/ / \/_/\/\/_/ /_/ /_/\/ http://www.gl-como.it My public gpg key: http://minsky.surfnet.nl:11371/pks/lookup?op=getsearch=0xC67DC12DC4361693 -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/Omodules
Hi Mathias, Thank you very much for your comments. So, as far as I knor HLA/RTI, your problem is divided in two parts: 1. The problem with different RTI implementation libraries. 2. The problem with different fom's Regarding the RTI libs: As far as I can see the RTI c++ interface is defined in a way that you do not need to recompile anything. Everyting is done with pure virtual classes and factories to get them. So however this is implemented in the shared object/dll you should just need to get a 'standard' implementation dependent RTI header and compile with that. So you should in theory be able to change the RTI library of an already compiled binary. The basic HLA standard (both DoD and IEEE variant) provides only a C++ API compatibility at a compile-level. There is a SISO standard that should assure dynamic link compatibility (DLC). However, some RTI libraries may not be compliant to the SISO standard. For the case that a particular RTI implementation does not follow this rule, you need to compile flightgear explicitly for this particular library. I believe that this is accaptable. Not for me. :-( Regarding the different foms: I have seen your implementation and what I believe we can do more generic. Sure there is a part of your implementation that hard codes some attribute names of the foms into the binary. But this could be done in a more generic way, so that you can configure the attributes meanings at runtime instead. With this model, your two hardcoded implementaiton stubs for the those two fom's will be just a special configuration using the same c++ implementation. I've been thinking about this a lot. There is no simple mapping between FlightGear and FOM parameters. Sometimes it's necessary to translate units, geodetic/geocentric frames or perform other calculations. The generic mapping engine would have to be a very powerful scripting language like Nasal or Python. I've decided to start with a simple hardcoded interface and investigate all FOM attributes and interactions that may be supported by FlightGear/HLA. After we understand all possible features of the FlightGear/HLA interface, we will reconsider implementing the generic interface. Of course, unless somebody volunteers to implement it right now. ;-) I for myself would like to have such a flexible implementation at hands. So all together I would prefer to include a more generic HLA/RTI implementaiton in flightgear than introduce a plugin mechanism. Yes, it would be nice to have a generic HLA/RTI implementation. From the cost-benefit ratio perspective, a plug-in mechanism will significantly simplify the use of the hardcoded interface, so the need for the generic implementation is not so urgent. And it's much easier to implement a plug-in mechanism, than the HLA/RTI interface. Best Regards, Petr -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/Omodules
Hi, I'm (still) against binary runtime modules for FlightGear. And I respect that. We offer more possibilities than X-plane and MSFS and all the others put together -- by letting people look at/modify/redistribute our source code. For free. That's very generous, if you ask me. Yes, that is extremely generous. In fact, this allows me to implement the generic plug-in interface and distribute the modified FlightGear along with my binary runtime modules that are all under GPL. That linking non-GPL modules would be illegal, anyway, doesn't make the situation any better. Unless you can offer us a *lot* of money, time and personnel for filing lawsuits. Otherwise the GPL protection is rather weak and only theoretical. We shouldn't encourage corporate entities to rip us off. In my opinion not all commercial entities are trying to rip off open-source software. Both commercial entities and GPL software can benefit from each other if they are all fair. Which is not always true, I know. :-( Best Regards, Petr -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Immatriculation changing for SenecaII using Menu (as DR400 does)
Hi, I have added to the SenecaII the option to change immatriculation at runtime (Using the code from DR-400), at this link: http://brisa.homelinux.net/fgfs/SenecaII.tar.gz you will find the files to be replace (To the CVS version as this morning). It is an initial work, but should be ok, would it be possible to integrate it in the cvs ? Cheers Francesco Hi Francesco, I will be away from my keyboard for the next two weeks. There are many changes to the SenecaII piped on my todo list and I added your changes, too. I will have a closer look, when I am back. Greetings, Torsten -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ASTER world topographic data released
Just a heads-up to say that it seems that the ASTER 30 metre resolution world topographic data has been released, covering 83 degrees north to 93 degrees south. Apparently NASA is currently working to combine this with the SRTM data that FG already uses. http://www.theregister.co.uk/2009/06/30/nasa_japan_release_99_complete_topographic_map/ LeeE -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ASTER world topographic data released
Hi Lee, Have you seen a download link? Curt. On Wed, Jul 1, 2009 at 10:25 AM, leee wrote: Just a heads-up to say that it seems that the ASTER 30 metre resolution world topographic data has been released, covering 83 degrees north to 93 degrees south. Apparently NASA is currently working to combine this with the SRTM data that FG already uses. http://www.theregister.co.uk/2009/06/30/nasa_japan_release_99_complete_topographic_map/ LeeE -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ASTER world topographic data released
On Wednesday 01 Jul 2009, leee wrote: Just a heads-up to say that it seems that the ASTER 30 metre resolution world topographic data has been released, covering 83 degrees north to 93 degrees south. Apparently NASA is currently working to combine this with the SRTM data that FG already uses. http://www.theregister.co.uk/2009/06/30/nasa_japan_release_99_com plete_topographic_map/ LeeE Oops! - there's a typo there - it should have said 83 north to 83 south. LeeE -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ASTER world topographic data released
There's a download link at the end of the article, but the article also points out that it seems a bit overloaded atm. Hi Lee, Have you seen a download link? Curt. On Wed, Jul 1, 2009 at 10:25 AM, leee wrote: Just a heads-up to say that it seems that the ASTER 30 metre resolution world topographic data has been released, covering 83 degrees north to 93 degrees south. Apparently NASA is currently working to combine this with the SRTM data that FG already uses. http://www.theregister.co.uk/2009/06/30/nasa_japan_release_99_c omplete_topographic_map/ LeeE --- --- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ASTER world topographic data released
A review of the data is found here http://www.viewfinderpanoramas.org/reviews.html#aster It's not the holy grail of high resolution and artifact-free data, apparently ;( I found this insightful link on the osg-users (OpenSceneGraph) mailinglist. Christian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ASTER world topographic data released
On Wednesday 01 Jul 2009, Christian Buchner wrote: A review of the data is found here http://www.viewfinderpanoramas.org/reviews.html#aster It's not the holy grail of high resolution and artifact-free data, apparently ;( I found this insightful link on the osg-users (OpenSceneGraph) mailinglist. Christian Yes, I wouldn't expect the data to be perfect, but I would imagine that the idea behind combining it with the SRTM data is to help identify errors in both datasets so that they can be corrected. It'll be the combined dataset that will be most useful, of course. LeeE -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Hi Tim, On Thursday 25 June 2009 23:58:42 Tim Moore wrote: Mathias Fröhlich wrote: Hi Tim, On Thursday 25 June 2009 10:22:54 Tim Moore wrote: OK, but in case you hadn't noticed, libsgmath depends on OSG. Yes I have noticed that change in the quaternion/matrix. If you mean the methods in SGGeod that return osg::Matrix, I wrote them that way because the values get plugged directly into the scene graph. Sure, no problem or offense here. I just might replace that with something that removes that dependency. I believe that we should get rid of that. And yes, the vector storage is from osg. But it is a few line change to get rid of that. That was designed for that :) And then you can change the ~100 uses of '.osg()' to access that storage. :) Yes, I know. The read from SG write to osg portion is easy to handle. The other way was to ease the transition and will be way less to change if one needs to... If you want to I can change that so that we *are* independent instead of being nearly independent. Seriously, I didn't realize that reducing dependencies on OSG in simgear is a design goal. That's fine, but I would really prefer to not think about whether I need to pass an SGVec3d or an osg::Vec3d to a function, or whether a smart pointer should be an osg::ref_ptr or an SGSharedPtr or... I see you point. I would not tell that a hard requirement. But we definitely have parts in a simulation that just do not need to know that they run on osg/OpenGL. Imagine you want to change the viewer library. All the physics is still the same. By mixing osg classes into everything without any type abstraction in between, you need to rewrite the whole pile of code. Even for parts that do not depend on any viewing crap at all. I already did so when I started to switch to osg and plenty of that work was almost only for that reason we have all the sg types directly spread around. So please avoid having osg::whatever spread around in the whole application ... Appart from that, having more separate code paths in general for the simulation parts and the viewer/scene parts would help for plenty of our scalability problems a lot. So just thinking about general software design ... So nothing is set in stone here, but it makes sense IMO to head into that separation where possible/sensible. More in detail for the reference counting. I do not like the referenced implementation of osg. That is already very heavyweight. Has some members we do not need in any way in something simulation dependent. The observed_ptr stuff is not thread safe, also that observer implementation does not scale well if you have many observers. Referenced already has a vtable. Just to name a few ... What we have is a very weak thing that could be used in the same basic way but is way more flexible even for smaller objects. I would prefer to keep that own implementation. The same goes for the osg vectors. They are neat, but inconsistent over the member types. Also the collision system is missing there. Just to be more flexible with extensions in this area we might need, I would like to have our own stuff. So I do not need to introduce a change to Robert and then wait a few months before I can rely on people having that change available in flightgear ... I can find many more benefits of this stuff we have already. The rule of thumb when to use what is simple: If you are in the scene graph most probably osg::... might be a good thing to use. If you are in the simulation, network, input system, property system, wherever not scene graph dependent, use simgears own classes. So I would not tell that a hard design goal. But If we can make that I believe that we will get a benefit in doing so in the mid/long term. Greetings Mathias -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS SG RenderTexture fix
Hi All,
This is a 'fix' to sgscreen library,
for those with a glX extension implementation
that still reports version 1.2...
Wow, I got there!!! Boy I love coding when
you persist, and try, and try some more,
and you discover what makes it work ;=))
even when you do not fully 'understand'
all that is happening...
The discovery :
(a) While my installed implementation of
the service :-
glXQueryVersion(dpy, major, minor)
returns 1.2, it none the less supports
many features, services of 1.3!
(b) While my installed implementation of -
const char* extString =
glXQueryExtensionsString(dpy, screen);
does NOT contain the string GLX_SGIX_pbuffer,
BUT a call to the service :-
const char * extClient =
glXGetClientString(dpy,GLX_EXTENSIONS);
DOES...
This can be seen when running 'glxinfo'... so I added
this and continued...
(c) Although the documentation for the service
glXCreateGLXPbuffer seems to indicate that a NULL
attribute pointer can be used, this produced a
segfault in my system, so I add a pointer to
attributes (which had already been declared,
except I had to move it to a higher context)...
But in my case it still reported an X error, but
at least not a segfault, so...
(d) Since my implementation returns 1.2, the code logic of -
if (((1 = major 3 = minor) || 2 = major) ...
naturally stops 'glXVersion1_3Present' being set TRUE,
even though ALL the 1.3+ functions are resolved
using SGLookupFunction(glXChooseFBConfig), etc
And the code then seeks 'alternate' functions, like
SGLookupFunction(glXChooseFBConfigSGIX);
which are also _ALL_ found, but yield 'bad' results
when used...
So in 2 places in the code, I overrode the simple
if ( glXVersion1_3Present ), which is false in
my case, with more logic :-
Reasoning: If the 1.3 pointers are resolved, then
use them, instead of the old, failing!, 1.2
functions...
1.// if (glXVersion1_3Present)
if (glXCreatePbufferPtr glXGetVisualFromFBConfigPtr
glXCreateContextPtr)
{
2.// if (!glXVersion1_3Present)
if ((!glXCreatePbufferPtr || !glXGetVisualFromFBConfigPtr || !
glXCreateContextPtr)
(!glXVersion1_3Present))
{
BUT, this did NOT work in a 3rd case I tried :
-
// if (glXVersion1_3Present)
if ((glXVersion1_3Present) ||
(glXCreatePbufferPtr glXGetVisualFromFBConfigPtr
glXCreateContextPtr glXQueryDrawablePtr))
so left this back the way it was... the
GLXDrawable draw = glXGetCurrentDrawable();
worked, but the glXQueryDrawablePtr for GLX_WIDTH and GLX_HEIGHT
FAILED, and exited, with an X error.
AND glXQueryGLXPbufferSGIXPtr(...) with GLX_WIDTH_SGIX
and GLX_HEIGHT_SGIX also FAILED with -
X Error of failed request: GLXBadPixmap
This seems troublesome in that _iWidth and
_iHeight are left as per the buffer
request, and not adjusted if the buffer
size is different to that requested.
But, on checking further, at the time
this is done, the context and buffer
has been returned to the original, so I
see no reason, or problem, that this code
has been 'chopped' ;=()
---
*** ===
*** THEN IT ALL WORKED ;=))
*** ===
When I run TestRenderTexture I have a spinning
rectangle, containing a spinning torus, and
can toggle each of the init strings
(with the enter key) - most work, but some do
not, but I suspect this is true in ALL cases,
environments.
And the space bar toggles the color/depth
and effects some images, but not all...
which I think is correct.
The FIX :
To get here I added over 100 dbg_printf
statements, and hope that these are kept
to help future debugging. They can ALL
be defined away with -
#define dbg_printf
or enabled anytime with -
#define dbg_print printf
Some of these are in addition to an
existing SG_LOG(), but since the
application TestRenderTexture does NOT
'enable' sglog(), then none of these
show... hence the simple 'dbg_printf'
alternative added...
And some other debug code depends on
_DEBUG being defined... This includes a
big block of DEBUG code added to the
end of the file.
Version:
Also, for no particular reason I did
all these changes first on SimGear-1.9.0,
but was pleased to note that there are NO
CVS changes to the files changed, so
the attached 'patch' can be applied
directly to SG CVS...
Which is what I have done to my local
cvs copy, and the diff attached is using -
...simgear/source $ cvs diff -u
If someone would like to check my work,
I would be pleased to answer any question
as to why this, or that...
And of course, those that had the good
luck to have the TestRenderTexture working
in their system need to re-check that
nothing I did effects it still working in
their system... more reason to KEEP
the copious 'debug' code in place...
In most places, I only touched code in
the NOT _WIN32, NOT __MACH__ sections,
so only *nix code should be effected.
Use:
Of course, I have tested the new sgscreen
static library with Atlas/Map, and
