Trunk nightly

[Switeck]

(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..

Not that the game handles it, there's actually 2 separate wormhole issues:
First, there's the blue wormhole "ball" -- the entryway which gets larger and lasts longer the more mass you toss into it so long as you do so quickly.
Secondly, the chance of the wormhole "tunnel" collapsing into a misjump as a result of too many or too big/massive ships dogpiling into a single wormhole.
These 2 need not be closely related.

It also seems that misjump times and perhaps distances as well has been changed from v1.77 to v1.79. Crossing the Great Rift in Galaxy Chart 7 in particular results in LESS time used than it did in the past. This is somewhat beneficial, but I'm wondering if this is an accidental design change.

...On the subject of trunk nightly, I've seen white planets with Oolite development version 1.79.0.5713-140418-e68caf1 (x86-32 test release).

The asteroid Miner ships that launch from Rock Hermits often turn too fast after exiting the Rock Hermit...and crash into the station and die.
The glare from the sun seems to apply even through I was behind a Rock Hermit that I was docking with it.
I find the glare too bright as well.

[another_commander]

The glare from the sun seems to apply even through I was behind a Rock Hermit that I was docking with it.

If you go to external view when you get glare while behind a hermit, do you see your ship illuminated or is it dark? If illuminated, then there is probably not much we can do; the decision whether an object is lit/unlit is not really extremely accurate for complex geometry objects currently. You may think you are shadowed, when the algorithm decides that you get light. Moving just a few centimeters to any direction might be enough to "fix" this. In the vast majority of cases it should work correctly though.

[Switeck]

I was already "inside" the Rock Hermit's docking tunnel. If I moved to the sides, I would be scraping against its walls.

[Cody]

I was already "inside" the Rock Hermit's docking tunnel. If I moved to the sides, I would be scraping against its walls.

Curious - I've seen something similar inside the tunnel of a Kiota station in a test version of HIMSN. Was it a sunward hermit?

[cim]

It also seems that misjump times and perhaps distances as well has been changed from v1.77 to v1.79. Crossing the Great Rift in Galaxy Chart 7 in particular results in LESS time used than it did in the past. This is somewhat beneficial, but I'm wondering if this is an accidental design change.

Tiared - Maedrebe is 6.8, so a misjump should be 0.75 * 6.8 * 6.8 = 34.68 hours, and it appears to be that. Midpoint to Articeso is another 6.8, so that should be 46.24 hours, and it appears to be that, too. Total, just short of 81 hours, which seems right.

How long did it take before?

...On the subject of trunk nightly, I've seen white planets with Oolite development version 1.79.0.5713-140418-e68caf1 (x86-32 test release).

Yes. There's definitely still something going wrong occasionally, though I'm not quite sure what. A more reliable way to trigger the bug: start a new game, launch from the station, crash into the station, start a new game, launch from the station.

I'll keep looking at it.

The asteroid Miner ships that launch from Rock Hermits often turn too fast after exiting the Rock Hermit...and crash into the station and die.

Presumably selecting a mining target which is behind the station. I'll see what can be done about that.

The glare from the sun seems to apply even through I was behind a Rock Hermit that I was docking with it.

Because of how the shadowing algorithm works, travelling down the docking tunnel, it no longer casts a shadow on you, because you're closer to the sun than the hermit is. That's going to be very difficult to fix.

The glare algorithm really should work by counting the fraction of screen pixels which are displaying the sun, and getting the intensity from that. I have no idea how to even start on that, though.

I find the glare too bright as well.

It's tricky to balance - it needs to be bright enough to be temporarily a problem in a fight, which means that it ends up feeling too bright for casual flight - especially when going to sunskim.

[submersible]

The glare algorithm really should work by counting the fraction of screen pixels which are displaying the sun, and getting the intensity from that. I have no idea how to even start on that, though.

I was wondering something similar about this when tinkering with atmosphere effects - particularly in relation to the atmosphere when viewed from the dark-side.

I thought glHistogram() looked interesting but further reading made it seem both slow and not-well supported. I'm not too sure how true this is. Most of that reading lead me to http://developer.download.nvidia.com/SD ... mples.html , performing multipass rendering to texture.

[Switeck]

It also seems that misjump times and perhaps distances as well has been changed from v1.77 to v1.79. Crossing the Great Rift in Galaxy Chart 7 in particular results in LESS time used than it did in the past. This is somewhat beneficial, but I'm wondering if this is an accidental design change.

Tiared - Maedrebe is 6.8, so a misjump should be 0.75 * 6.8 * 6.8 = 34.68 hours, and it appears to be that. Midpoint to Articeso is another 6.8, so that should be 46.24 hours, and it appears to be that, too. Total, just short of 81 hours, which seems right.

How long did it take before?

Seems there may not be a problem after all. I rechecked my old notes on it and apparently I had it recorded ...that it took 80.92 hours.
But I probably got my original route to Oresrati goofed up...I had recorded that it took 185.45 hours ...but in re-testing it, that takes 181.01 hours.

Incidentally, due to using player.ship.scriptedMisjumpRange, it's now possible to save considerably on the time needed to cross the Great Rift in Galaxy Chart 7 or in reaching Oresrati in Galaxy Chart 8.
No fuel savings though, but with the way my jumper OXPs work that doesn't matter since it's the NPC ship's fuel that's getting used. I have to use that to quickly and accurately measure travel time for any non-trivial series of jumps.

I need to make a "Stopwatch" OXP that just starts or stops on activation and reports the time change. Would be very useful for contracts and testing while being game-balanced.

I'm still looking for faster routes even if they're normally impossible for the player to do. Potential mission material. I haven't found a route using player.ship.scriptedMisjumpRange to reach the "unreachable" systems in Galaxy Charts 3 and 6. I'm pretty sure there aren't any for Galaxy Charts 6, but the ones in 3 I haven't totally given up on yet. I can cross the Great Rift in Galaxy Chart 7 at 3 different places. It's possible to do without using auto-jumping OXP cheats...but requires either fuel tanks (and lots of missile slots) and/or very slow recharing using FuelCollector OXP. I guess if there were enough NPC ships around it could be done hitchhiking on their wormholes, but the odds of NPCs going the "right directions" for each misjump is unlikely.

The glare from the sun seems to apply even through I was behind a Rock Hermit that I was docking with it.

Because of how the shadowing algorithm works, travelling down the docking tunnel, it no longer casts a shadow on you, because you're closer to the sun than the hermit is. That's going to be very difficult to fix.

The glare algorithm really should work by counting the fraction of screen pixels which are displaying the sun, and getting the intensity from that. I have no idea how to even start on that, though.

I find the glare too bright as well.

It's tricky to balance - it needs to be bright enough to be temporarily a problem in a fight, which means that it ends up feeling too bright for casual flight - especially when going to sunskim.

The glare was still apparent even before I reached the Rock Hermit. It never dimmed as I approached or entered inside the docking tunnel area. Probably a very tough fix, especially for stations that have holes or transparent parts.

Maybe make the glare also depend on distance from the sun. At sunskim range, it can be as blinding as it is now...but at the distance of the planet-sun, maybe about half as bright as now -- still very annoying.

[another_commander]

Maybe make the glare also depend on distance from the sun. At sunskim range, it can be as blinding as it is now...but at the distance of the planet-sun, maybe about half as bright as now -- still very annoying.

Sun glare already depends on distance to the sun. You can see this by starting to move away from the sun at 16x TAF, possibly torus-driving for even more distinct effect. You can see that it reduces with distance, to a point where even facing it directly does not generate glare at all.

Having said that, the glare was tested with both core game and OXP suns and what we have now is probably a best possible compromise. In normal flight you are not facing the sun constantly, unless when you are going sun-skimming and that was tested too and we thought it was OK as set now. What might help could be an additional user-set factor to apply to the calculated glare so users could even disable it completely if they felt like it. I guess otherwise it would be very difficult to have everyone happy - and t be honest, I don't recall reading any complaints about glare before this post, but I can certainly see how subjective "proper glare" can be.

[Switeck]

I only recently started running recent trunk builds that have it. I did that to convert my OXPs to OXZs, with beta-testing the trunk builds only as a side-effect. So I had not seen the glare previously.

[Cody]

Distant planets look much better now (tested out to five AU) - thanks, cim.

[cim]

...On the subject of trunk nightly, I've seen white planets with Oolite development version 1.79.0.5713-140418-e68caf1 (x86-32 test release).

Yes. There's definitely still something going wrong occasionally, though I'm not quite sure what. A more reliable way to trigger the bug: start a new game, launch from the station, crash into the station, start a new game, launch from the station.

Did you see these with a planet texture OXP installed or with the default Oolite planets?

I think the bugs with the OXP installed should be fixed in tonight's build.

[Switeck]

I was testing my OXPs, so I had removed most other OXPs to speed things up slightly and reduce the dds of problems.
In short, the default Oolite planets.

[spara]

Adder has an undocumented role of "pirate-independent". Should it just be "pirate"?

[cim]

Adder has an undocumented role of "pirate-independent". Should it just be "pirate"?

Yes, thank you. Fixed in e1f6f95

[spara]

Adder has an undocumented role of "pirate-independent". Should it just be "pirate"?

Yes, thank you. Fixed in e1f6f95

Found another one. Ferdie has the role of "trader-freighter". Should be "trader" perhaps?