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.
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();
The visitor would modify the scenegraph during the traversal by inserting groups; this is not valid when using vectors, and MSVC2015 debug RTL throws an exception when this happens.
The fix is to simply make a list of the textures that need to be modified and modify once the scenegraph traversal has finished.
This change is the logical counterpart of SimGear's change from commit
79f869a7f32910197be72b21f6489fbbba02c836 that moved the following files
from simgear/misc to simgear/io/iostreams:
gzcontainerfile.cxx
gzcontainerfile.hxx
gzfstream.cxx (formerly zfstream.cxx)
gzfstream.hxx (formerly zfstream.hxx)
sgstream.cxx
sgstream.hxx
sgstream_test.cxx
Each argument creates another log file, in the directory named. Symbolic
value ‘desktop’ creates logs on the user’s desktop.
Needs corresponding SimGear commit to build
Suggested by Emilian, I assumed packagers tend to replace these files
or make their own decision anyway but for a non-terminal startup,
requesting the launcher seems a clear benefit to me.
The mirror protocol now sends the position for internal as well as
leaf nodes, and the group uses this data to sort when no explicit
Z-indices exist. This gets the extra-500 much closer to working!
For unknown reasons this seems to alleviate the word-wrap / min-height
bug on Windows. Committing so we can test and verify this is really
the case before the next release.
