SGPropertyNode to guarded ones. This is also done for JSBSim/JSBSim.hxx,
for which JSB had given explicit permission a while ago. I postponed that
back then, but now is the time.
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
These changes represent some attempts to bandaid and patch a hopelessly
flawed system to impliment basic battery charging/discharging as well as
provide the ability to model ammeter gauges and draw current from multiple
sources (like load balancing multiple alternators in a multi-engine aircraft.)
The system design forces all these things to be horrible hacks or depend
on extremely subtle system side effects and call ordering so they may or9
may not work to one degree or another.
As mentioned in the mailing list, my recommendation is to move away from
using this system and instead build a procedural electrical system using
nasal. Sometime in the future we hopefully can impliment a better conceived
data driven electrical system model.
support an attached property name and an intial state, but this can easily
be extended to configure a switch to be a circuit breaker with a max rating,
etc.
current draw. This is only one piece of the puzzle, but as we move forward,
the idea is better modeling of the ammeter, and we could automatically pop
circuit breakers if the current gets too high.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
The code reads the electrical system config and contructs an internal model.
Nothing is done beyond that yet ... the electrical system is not updated,
nor is it connected to the property system in anyway.
