Orbiter 2016 - RC.3

[martins]

Any words on this? (ignore the first part of that post)
Should we only play with DefSetStateEx in the clbkPreStep call?

Ok, the next update should remedy the problem of creating vessels during clbkPostStep. But even so, depending on how you initialise the state of the new vessel, you might find that clbkPreStep is the correct location.

clbkPreStep is called at the beginning of the update phase, just after the vessels have copied their published states to their update states, so both states are in sync.

clbkPostStep is called after Orbiter has propagated the update state to the next time step, but before the new states are published. Since the new vessel is now inserted after the current update phase, it will miss the update for the state with which it was created. For example, if the new vessel was created with a copy of the spawning vessel's state, it will now be one update behind the parent vessel. If it is created in clbkPreStep, the spawning and the new vessel will go through the current update phase, and therefore remain in sync.

 

[GLS]

Ok, the next update should remedy the problem of creating vessels during clbkPostStep. But even so, depending on how you initialise the state of the new vessel, you might find that clbkPreStep is the correct location.

clbkPreStep is called at the beginning of the update phase, just after the vessels have copied their published states to their update states, so both states are in sync.

clbkPostStep is called after Orbiter has propagated the update state to the next time step, but before the new states are published. Since the new vessel is now inserted after the current update phase, it will miss the update for the state with which it was created. For example, if the new vessel was created with a copy of the spawning vessel's state, it will now be one update behind the parent vessel. If it is created in clbkPreStep, the spawning and the new vessel will go through the current update phase, and therefore remain in sync.

Makes sense, thanks!

 

[DaveS]

Will the next release include an updated tileedit that works with the new tree format? I would like to even out the runways of EDW and VAFB but I only have the tree files.

 

[martins]

I don't know yet. tileedit uses a Matlab utility to read dds files. I haven't got the sources for that, so it won't be easy to adapt that to read from memory, unless I write the entire dds interface from scratch. A quick hack would be to extract the dds data from the archive and write to a temporary file, where it can be picked up by Matlab. But then, I don't currently have any facilities to write changes back to the archive. Maybe with the treeman utility Face is currently working on this will be possible.

For now, the only option is to extract the entire archive to individual files (texpack -e), then edit with tileeedit, and then recreate the archive with texpack.

 

[Face]

But then, I don't currently have any facilities to write changes back to the archive. Maybe with the treeman utility Face is currently working on this will be possible.

Indeed the idea of treeman is just that: the possibility to selectively list, extract, update or even add tiles from/to the archive. So in essence an editing session could look like that:

• extract the tiles of interest from archive to tree via "treeman <planet_root> <Layer> -I <regex> -e"
• work on the tiles, e.g. with tileedit
• update the tiles in the archive via "treeman <planet_root> <Layer> -I <regex> -u"

With the timestamping/hashing idea I've outlined before, the <regex> part in the third action above could be eliminated. This would make the tree the check-out directory of the archive "repository", so to speak.

This is what I have done so far: http://www.snoopie.at/face/beta/treeman.zip . As you can see there, the tool can already do the first step, plus conversion from old-style *.tex and base tiles with the help of the included texconv tool from Microsoft. Those conversions are still very rough, though (*.tex only supported up to old-level 5, base tiles not split on higher resolution and not alpha blended nor histogram matched).

I will finish these conversion options first, then implement the update/add feature. Reason is: there is always the setting "cache first, then archive" to make the whole chain workable, while we don't have an automated conversion tool yet.

 

[martins]

=== Please continue the discussion in the RC.4 thread ===