Trunk nightly

[Cody]

Interestingly there's a code comment on the witchspace blocking function that sets out a series of calculations necessary to get a blocking range of about 10km for an old-style Coriolis (the Griff one is slightly heavier)...

Ah, that is interesting - 10km would feel better, I reckon.

[cim]

Okay ... next time anyone sees a fully white planet, could they get to about orbital station height, and enable wireframe graphics mode, please. This should make it pretty obvious whether it's a white planet, or a white atmosphere layer very slightly above the planet - send us a screenshot.

EDIT: and if there's not obviously two overlapping meshes from orbital height, also have a look and take a picture from about 1km above the surface, please.

It may also be helpful to preemptively set texture.planet.generate = yes; in your logcontrol.plist - this might give us a few clues about what happened (tonight's build will increase the logging under that log group further)

[Switeck]

Interestingly there's a code comment on the witchspace blocking function that sets out a series of calculations necessary to get a blocking range of about 10km for an old-style Coriolis (the Griff one is slightly heavier)...

Ah, that is interesting - 10km would feel better, I reckon.

As for me, the Cobra 3 is hard-pressed to start a hyperspace countdown from the moment of launch and not be mass-locked after the end of 15 seconds even though moving at max throttle away from the station. If the mass-lock radius for the Coriolis station were made larger, I'd find using a slower ship even more painful.

[Cody]

Okay ... next time anyone sees a fully white planet...

Xeorusge has obliged - several pics, normal and wireframe (hope I got them right), and the log here. Xeorusge was completely missing on F7, btw.

[cim]

Thanks - definitely the atmosphere generation, then, though I'm not sure what part of it is going wrong. I'll have a closer look.

EDIT: okay, tonight's nightly will have even more logfile entries around the atmosphere generation - there was definitely something a bit odd in the last part of that log file, but I'm not sure what happened yet.

[Cody]

Enbean is at it now - pics and log here.

[cim]

Hmm... interesting. Something very strange is happening.

[boring details]
It "completes" the atmosphere texture generator, which should put it into the async work manager for "performAsyncTask" and then "completeAsyncTask".

The "OOConcreteTexture" holding the results ends up permanently in "loading" state in the cache - so the F7 planet never gets drawn because the texture isn't loaded yet - but then what happens?

When the real planet is viewed, [_material apply] gets called on the atmosphere material. That's an OOSingleTextureMaterial containing the OOConcreteTexture, so that calls OOSingleTextureMaterial::doApply which calls OOConcreteTexture::apply ... which should force the texture to be set up. The texture loading state should either become its size 1024x1024 as happens with the earlier successful atmosphere set ups - or if something went wrong, it should be "LOAD ERROR". It shouldn't be possible for that call to setUpTexture to leave _loading as NO in the concrete texture - but it also shouldn't be possible to get out of the [_material apply] call without calling that and binding the texture.

If isFinishedLoading on the OOSingleTextureMaterial is returning false - to stop the F7 planet appearing - then the OOConcreteTexture must be !_loaded (which we know) ... but also ![_loader isReady] ... which means that "completeAsyncTask" is never being called for that material, despite it being added to the async queue.

So ... the enqueuing operation adds the task to _pendingCompletableOperations, and _taskQueue (or the Mac equivalent).

When the texture loader tries to get the texture, it calls waitForTaskToComplete which blocks until it's complete ... but that's only true if the task has previously been added to the task queue. For conventional OOTextureLoaders that's guaranteed - they add themselves to the task queue in initialisation. The atmosphere texture doesn't do that - it adds itself to the task queue when it's finished generation.

That would mean that OOTextureLoader::getResult could continue without the texture actually being ready yet, which would really mess things up...

With basic planets, this is still protected against, since the planet drawable gets rendered first, and this blocks until the main generator is complete ... but with Povray installed, the planet drawable is just a standard file texture, so the completion of the atmosphere texture generator is independent of it.

I think, therefore, that this can be fixed for now by making the atmosphere generator waitForTaskToComplete on its parent planet texture generator, before it does the same on itself...
[/boring details]

Okay, I think this should be fixed in tonight's nightly build. We'll see... Thanks for your testing.

[Cody]

<ponders the 'boring details' - scratches head> Cool!

[Cody]

I'd meant to mention this before - whilst dealing with a bunch of assassins recently, I saw another firefight in the distance. I had no time to investigate, but a couple of comms messages caught my eye - something like: '... here's an Sidewinder... '. A little problem with 'a' and 'an' perhaps?

[cim]

A little problem with 'a' and 'an' perhaps?

Possibly. That's going to be irritating if so, since the way it builds the messages doesn't really leave much room to choose a/an. I can probably reword them to avoid it entirely, though.

[Cody]

This may be normal behaviour, but if so, I've never noticed it before (not that I can recall, anyway): I was loitering around the aegis waiting for a free ride, when a squad of hunters launched and formed-up for hyperspace, led by a Cobra III. I analysed the wormhole, saw about 90 seconds on the clock, and the destination (which was on my route), so I headed for the wormhole. Thing was, as each ship dived into it the time to collapse increased - pics here and here. Please tell me this is not normal behaviour, 'cos if it is, I don't know how the hell I've not seen it before!

[Tricky]

This may be normal behaviour, but if so, I've never noticed it before (not that I can recall, anyway): I was loitering around the aegis waiting for a free ride, when a squad of hunters launched and formed-up for hyperspace, led by a Cobra III. I analysed the wormhole, saw about 90 seconds on the clock, and the destination (which was on my route), so I headed for the wormhole. Thing was, as each ship dived into it the time to collapse increased - pics here and here. Please tell me this is not normal behaviour, 'cos if it is, I don't know how the hell I've not seen it before!

Over the past 2 years of playing (since 1.76.1) I have seen this all the time. I always thought it normal behaviour.

[cim]

Yes, that's normal. Adding extra mass to a wormhole holds it open for longer, though most ships you'll commonly see hitchhiking are only going to be heavy enough to add a couple of seconds. (Oddly, the Wiki page for the Sidewinder suggests that adding extra mass collapses a wormhole faster, which would be an interesting mechanism but not what we have)

[Diziet Sma]

(Oddly, the Wiki page for the Sidewinder suggests that adding extra mass collapses a wormhole faster, which would be an interesting mechanism but not what we have)

Indeed..

It has no hyperspace capability. The normal technique is for the Sidewinder pilot to keep the ship close to the 'mothership', and then use its wormhole to reach the destination. Being small, many Sidewinders can pass through the wormhole without collapsing it, meaning a trader using this ship as an escort is likely to come out of the other end of the jump with a full compliment of escorts.

That could use some re-working, methinks..

[Cody]

Oh dear! Nurse, nurse! Is it time for my medication?