On 1 Nov 2010, at 18:05, James Turner wrote:
'preset-commit' should possibly not trigger a full-reset - but I'd worry
about introducing subtle bugs in re-position from the GUI, if we change that
behaviour now. On the other hand it is fairly testable, if breakage does
occur.
My 'least bad' option is to save control state (from the -set.xml, or config,
or command line) as part of the initial state, so that it's re-applied after
the controls are reset. That seems to most robust to me, but I need to check
if there's knock on effects (possibly rather subtle ones) from saving and
then restoring more properties during the reset process.
Fixes for this are pushed to Git now, please test. I went for the 'consistent'
approach, rather than introducing more special-case behaviour.
Here's what happens:
- reset and reposition now use the same codepath (something I've been
working towards for many months). They do a full control reset, but after that,
a full initial state restore.
(it would be possible to support a 'nearby' re-position that doesn't
touch the tile-manager, AI manager, or so on, and just re-inits the FDM - but
that's something for the future, if people want it)
- we already saved all the initial state at the end of the main init -
but Nasal scripts run before that state is saved - so running presets-commit
then confuses things mightily. What I do now, is special case position changes
(presets-commit) that happen during startup, and skip the reset path entirely,
since it's unnecessary.
This gives us:
- Nasal can merrily re-init during startup if it chooses
- control values specified on the command line, -set files or config
survive the init process
- Reposition and reset from the GUI both work, and will give you the
state as specified in the -set config files, and command line. Since
reposition from the GUI *is a* reset (now), some properties may change that
previously did not, but I can't imagine a situation where the old behaviour was
better - since we already wiped the FDM and control state regardless.
This would be a good change to test. Note that JSBSim is experience NaNs for me
on reset/re-position, much of the time - I think I'm more prone to this than
other people, for some reason. I see the same behaviour before and after the
change, and Anders informs me it's a long-standing bug, but obviously if you're
testing reset or reposition you're likely to encounter it.
(If someone could get to the bottom of it, that would of course be even better)
Regards,
James
--
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware,
phishing sites, and compromised hosts - saving your company time,
money, and embarrassment. Learn More!
http://p.sf.net/sfu/hpdev2dev-nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
