Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Beta Topics related to Beta releases of Orbiter and Orbiter development.

Reply
 
Thread Tools
Old 08-09-2016, 01:07 PM   #16
martins
Orbiter Founder
Default

Quote:
Originally Posted by Face View Post
 I have noticed that texpack now has the extraction feature. However, it seems like there is a small typo, because the usage page lists '-x' as option, when in reality it is '-e'. In addition, the '-L<x>' option seems to have no effect on it.
Thanks, I'll fix that.

Quote:
My treeman utility also gained the extraction feature now: Attachment 14694
It uses zlib's (1.2.8 statically linked) uncompress() function. However, treeman is twice as fast as texpack unpacking all Earth textures. Do you do some special checks on the unpacked files?
Not really. I am using the inflate() function. Is that in any way different to uncompress()? Do you set any particular flags when configuring the decompression stream? Maybe yours is using multiple cores and mine isn't, or something of that sort.
martins is offline   Reply With Quote
Old 08-09-2016, 01:30 PM   #17
martins
Orbiter Founder
Default

Quote:
Originally Posted by Enjo View Post
 How about using such template:
[...]
Ok, this is worth thinking about. My concern is however that this is quite a low-level approach, that catches problems at the last possible moment, just before an operation that would generate a nan. This would provide a good debugging start for me, but may not be much help for an addon developer who wants to find out why his dll is crashing Orbiter. I still think that parameter checks at the API function entry points would be useful in that respect.
martins is offline   Reply With Quote
Thanked by:
Old 08-09-2016, 01:48 PM   #18
Enjo
Mostly harmless
 
Enjo's Avatar


Default

My idea only partly addresses the NaN issues, and only if somebody cares about them. Think about it as an addition.
Parameters checking in API functions would definitely add much more. I have no data to confirm it, but I'd bet that most of the crashes result from trying to call functions which return NULL pointers. Maybe you could be returning references (or pointers like now) only if the objects exist and throwing exceptions otherwise? The parameter validity check would have to be checked via functions returning bool like -
bool HasVessel(const char * vesselName) const;
Only if true is returned, it would be safe (without throwing) to call:
VESSEL GetVessel(const char * vesselName);

I addressed this in this rant, but then I insisted on references. Now I'd say that it doesn't matter that much, as long as the above calling sequence is kept.

Of course, the exceptions would have to be caught in above the oapi::MFD2::Update() and printed in the MFD, similarly in oapi::Module refresh methods, but then you'd have to print them on screen somewhere.

Last edited by Enjo; 08-09-2016 at 02:30 PM.
Enjo is offline   Reply With Quote
Old 08-09-2016, 02:32 PM   #19
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by martins View Post
 Not really. I am using the inflate() function. Is that in any way different to uncompress()? Do you set any particular flags when configuring the decompression stream? Maybe yours is using multiple cores and mine isn't, or something of that sort.
I think inflate() uses streams, whereas uncompress(dest, &destlen, src, srclen) uses memory directly. treeman directly loads, uncompresses and saves with a 512kB buffer.

I use the CreateFile() API to open the tree with the sequential read flag, but the fopen() API for writing to the disk. Perhaps this makes a difference? I don't use threading, forking or any concurrency framework at all.

One more thing: I've compiled the static zlib myself, but without any special setting.

Did you try it? Perhaps it is only faster on my machine?

BTW, some thoughts about that time-stamping we discussed earlier: what about putting another list at the end of the archive, holding file-modified-time (64-bit) and a sha1 20-byte hash for each file, with the same order as non-dummy nodes.
This way your loader shouldn't have a problem with it, and management tools can easily extract the information by jumping over the archive and running down the linear node list.
It would cost a second file open and 32 bytes per node (e.g. high-res Mars Surf would grow by approx. 1MB = 0.03% ), but that is a small price to pay for advanced diffing between archive and tree (or another archive). In addition, this info can later be stripped off again pretty quickly.
Face is offline   Reply With Quote
Old 08-09-2016, 03:54 PM   #20
Enjo
Mostly harmless
 
Enjo's Avatar


Default

Just a side note for completeness sake:
I've made it possible to mix types of the SafeNumber template.
Enjo is offline   Reply With Quote
Old 08-15-2016, 01:42 PM   #21
martins
Orbiter Founder
Default

Quote:
Originally Posted by GLS View Post
 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.
martins is offline   Reply With Quote
Thanked by:
Old 08-15-2016, 01:54 PM   #22
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by martins View Post
 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!
GLS is offline   Reply With Quote
Old 08-15-2016, 11:33 PM   #23
DaveS
Addon Developer
 
DaveS's Avatar


Default

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.
DaveS is online now   Reply With Quote
Old 08-15-2016, 11:55 PM   #24
martins
Orbiter Founder
Default

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.
martins is offline   Reply With Quote
Thanked by:
Old 08-16-2016, 07:32 AM   #25
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by martins View Post
 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.
Face is offline   Reply With Quote
Thanked by:
Old 08-16-2016, 10:23 AM   #26
martins
Orbiter Founder
Default

=== Please continue the discussion in the RC.4 thread ===
martins is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 11:25 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.