1
0
Fork 0
Commit graph

5 commits

Author SHA1 Message Date
curt
2b721e8443 Return to original property names. 2004-03-23 02:44:24 +00:00
curt
00002357b3 Roy Vegard Ovesen:
I've done som more work on the gps instrument.

- You can now input airport-, nav- or fix-ID to select a waypoint.
- You have to specify either "airport", "nav" or "fix" in the waypoint-type
  property (some fixes and navs have identical IDs).
- Formatted the time to waypoint output.
- Cleaned up and changed some propery names (wp-heading -> wp-bearing).

- I've also added a name member to the FGNav class so that the gps instrument
  can get the name of the nav.
- Changed the airport name parsing in simple.cxx.
2004-03-15 19:23:39 +00:00
ehofman
980012e168 Move FGEventMgr and FGSubsystemMgr over to SimGear, add SGEventMgr to FlightGear's globals structre and some small code cleanups 2003-09-24 17:20:55 +00:00
curt
2119db35c3 This is step "1" of probably "many" in the process of separating out the
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.
2003-05-06 23:46:24 +00:00
david
2908bd995d Added simple GPS support (no waypoints yet). 2003-03-10 14:09:43 +00:00