Make a single Cmake value to expose the build type to code, and use
this to default a run-time ‘developer-mode’ property, which can be
over-ridden from the command line.
Use this to drive the different warning levels. Policies subject to
review, especially whether nightly builds should default to
developer mode or not.
Uses TTF fonts, and displays more information textually including
the application version and current aircraft.
Also rename FGRenderer::splashinit to preinit, as was suggested
a long time ago.
On Mac it was visible as random strings displayed in the route manager
dialog for selected SIDs and STARs.
Depends on a SimGear change which introduces SGStringValueMethods.
1. Add support for scaled floats; most of the floats we transmit are small and thus can fit into a scaled short.
2. Change most properties to use scaled floats.
Support for short int encoded values (32 bits with 16 bit for ID and 16 bits for value)
Added extra debugging options
1. Debug level
bit 1 - loopback (show your own model as an MP model)
bit 2 - dump outgoing packets
bit 3 - dump incoming packets
bit 4 - hexdump outgoing packets
2. Update property (/simwith packet
- configurable debug (loopback, packet trace (in,out), packet dump)
- prevent properties from being visible to V1 clients - to ensure reliable compatibility, with just the basic position message being processed. This allows more changes to the V2 protocol whilst giving basic V1 support
- add debug
Based on the comments in the list I think it is better to keep the type that was originally provided as a reference, take the address of it, and store that in a ref_ptr.
Possibly the problem was never compiler related rather OSG related; I'm using 3.5.x and it appears that there are better built in type conversions compared to the target version of 3.2 that we are currently using.
Whilst debugging I had a cannot increment nextIt - because it was at end(). No idea if this could ever happen in flight but it still seems sensible to protect against it.
Use pointers to allow compilation on Linux/Mac until this is fixed properly as OSG elements should always be accessed via the reference counting mechanism.
Change to use pointers rather than osg::ref_ptr<osg::Group> - based on http://andesengineering.com/OSG_ProducerArticles/RefPointers/RefPointers I think that it is not possible that the scenegraph can be modified between the visitor and the modify, provided that the methods are called after each other like this:
ReplaceStaticTextureVisitor visitor(name, new_texture);
branch->accept(visitor);
visitor.modify_groups();
return visitor.getPlacements();
