Progress

[JensAyton]

We have good news for those who enjoy changing the scanner lollipop colors. In 1.74, it will be possible to change any ship's lollipop color by script or shipdata.plist. To do that, you will need to use either:
- Any of the two or both keys in shipdata.plist: scanner_display_color1 scanner_display_color2 or
- The scannerDisplayColor1 and/or scannerDisplayColor2 from JavaScript. The syntax can be
scannerDisplayColor1="blueColor"; or scannerDisplayColor1=[r, g, b,a];

How it works: You just assign one or both lollipop colors to the ship of your choice. If any of the two colors is assigned, then the lollipop will have that color. If you assign both colors, then the lollipop will flash using those. To restore everything back to default behaviour, you just assign the null value to scannerDisplayColor1 and/or scannerDisplayColor2. Easy as that.

Now that I think about it, shouldn’t this be an array? Even if only two values are supported for now, it makes semantic sense and provides a hook for future enhancement.

[Dr Beeb]

the MS-DOS version of Elite had boxes when docking to the station.

Elite Plus certainly has boxes when docking/launching.

Beeb version had polygons - octagons on a corner - see movie at

http://wiki.alioth.net/index.php/Docking

maybe various options should be possible for each station type ?

[JensAyton]

We of the Nac Mac Feegle are a simple folk, but we write verra comp-lic-ated documents.

As proposed elsewhere, Oolite can now generate graphs of state transitions in AIs (controlled by the generate-ai-graphviz hidden setting). Here are graphs of all the built-in AIs: zip, 890 KiB. Warning: pirateAI is not for the faint of heart.

Some of the AI problems found while testing have been fixed before making these graphs, but not all; for instance, in minerAI, the ATTACKED handler in DOCK_WITH_STATION points at an isolated box marked ATTACK_SHIP_h_ENTER. This means that there’s a setStateTo: ATTACK_SHIP command, but no ATTACK_SHIP state – it should be FLEE. There’s a similar issue in sunSkimExitAI. It’s nice when things turn out to be actually useful. :-)

[another_commander]

Elite Plus certainly has boxes when docking/launching.

Beeb version had polygons - octagons on a corner - see movie at

http://wiki.alioth.net/index.php/Docking

maybe various options should be possible for each station type ?

They will be possible in 1.74. You can use in shipdata.plist:

Code: Select all

docking_pattern_model = "yourChosenModel.dat";

for your station and that's it. Actually, I am hoping that someone will soon come up with alternative models for the docking patterns that could maybe replace the original "ring.dat".

[DaddyHoggy]

How does this replacing the ring model actually work? Is it a sort of 3D object that you fly through when you exit or enter the station? Or always thought it was a purely graphical effect? Any chance of an explanation?

[Kaks]

When you go through the tunnel Oolite builds 8 (is it 8 ? I don't remember exactly) 3d rings (or whatevers, depending on the .dat used) If you pull up during the last second of a witchjump countdown you can see you really are inside a 'snake' of 3d rings, just before the inevitable misjump. However, the 3d models need to be some specific dimensions, which, afaik, only Giles knew for sure.

Unfortunately, if he's anything like me, he probably has forgotten those details by now, unless he wrote them down!

[Eric Walch]

How does this replacing the ring model actually work? Is it a sort of 3D object that you fly through when you exit or enter the station? Or always thought it was a purely graphical effect? Any chance of an explanation?

I have no idea, but currently oolite uses the file ring.dat for this. When examining with DryDock it is just a conical shaped ring. And as Kaks writes, it is probably displayed in a succession of a few different sizes.

[JensAyton]

The normal model appears to range from -50 to 50 in x and y, and -40 to 0 in z.

[another_commander]

Trying to answer DaddyHoggy's question in a bit more detail: The code generates ten "rings" one behind the other. Each one has a specific lifetime. They all have the same velocity. The entire system of rings (or other models as you see fit) is "sent" towards the player at the specified velocity, while all other entities seize to be displayed for the duration of the rings' lifetime. The entire system is rendered in its own little special way. Rings are removed when their lifetime expires, at which point the game redisplays entities as normal. That is all to it. Try downloading the latest nightly build and change the default Coriolis ring model to barrel.dat. You will witness a totally different tunnel effect (which is my current default, btw).

[Cody]

Try downloading the latest nightly build and change the default Coriolis ring model to barrel.dat.
You will witness a totally different tunnel effect.

I tried this out today... quite effective. I like it.

[Commander McLane]

If you want it to be most effective for docking with a normal station, you should try out "dock-flat.dat". But be warned, it is so effective that it actually looks a little boring.

BTW: I am currently using "buoy.dat" for fun.

[JensAyton]

I’m working on a complete rewrite of planets. There’s lots of boring drudgery to go, but here’s a preview of sorts: a collection of planet meshes with correct texture coordinates.
planet-tester.oxp.zip (750 KiB)

Usage:

• Install OXP
• Name your planet texture of choice “world.png” and stick it in your AddOns folder
• Summon a “planet-tester-l3”.

The L3 is a medium-detail planet with 1280 polygons. There are six levels, from L0 (20 faces – an icosahedron) to L5 (20480 faces, can take half a minute or more to load). The planets have a 500 m radius, about the size of a Coriolis station.

There are some problems. Each model has a few invisible triangles. I believe this is a problem in Oolite’s data loading rather than the planet generator itself. (In wireframe mode, it can be seen that these triangles are actually inside out, but a winding error in the generator would appear as a repeated pattern). There’s a visible edge running up the “back” of the planets due to a limitation in Oolite’s smoothing. Neither of these problems will affect the final version.

There’s no trivial way to smoothly spin a ship around its Y axis, but Commander McLane will be glad to hear that the poles do in fact line up with the Y axis.

Textures are still pinched at the poles. This problem is fundamentally unavoidable with latitude/longitude texture maps, although it could be made arbitrarily small by throwing twenty more triangles at it. I intend to support cube map textures for planets in future, which will make this problem disappear entirely.

[DaddyHoggy]

Ahruman - as ever - I bow down to your coding skills and dedication to the cause.

Thank-you.

[JensAyton]

When [credits_number] is used in a description, it will now yield a correct value with exactly one decimal place – no less and, more importantly, no more.

[Commander McLane]

I’m working on a complete rewrite of planets.

Nice!

Commander McLane will be glad to hear that the poles do in fact line up with the Y axis.

Duely noted.

I guess in the final stage they won't be treated as ships, though?