Oolite Bulletins

Posted: **Fri Apr 06, 2007 12:04 pm**

...Player will be a type of Vessel.

...not containing too much 'Liquor/Wines', I hope...

Posted: **Fri Apr 06, 2007 12:13 pm**

Ahruman wrote:
From a coding perspective, making expressions like “player.position.x += 5000” work was interesting, but went surprisingly smoothly. … A broader issue is whether it should be possible at all. … I’m somewhat in favour of leaving it in purely because of the twisted elegance of the implementation. :-)

On further thought, the semantics of this would be problematic; code like:

Code: Select all

function rememberPosition()
{
    this.oldPosition = player.position;
}

function restorePosition()
{
    player.position = this.oldPosition;
}

would not work as expected, because this.oldPosition would track the player’s position instead of being a copy of it, and changes to its fields would teleport the player. Instead, I think Entity.position will be read-only; the question becomes, should there be a setPosition() method?

Posted: **Sat Apr 07, 2007 2:44 pm**

For all your getting confused needs: the JavaScript Quaternion class reference.

Minor clarification: part of the point of posting this stuff in advance is as a basis for discussion. If anything is missing, wrong, or unclear, please ask now; it’d be nice not to have to rearrange (and break) stuff after the fact. :-)

New (post-1.68) JavaScript documentation posted to date:

Posted: **Sat Apr 07, 2007 4:31 pm**

small error corrected towards end of quaternion desciption -

vectorRight
Vector vectorRight();
Returns the up vector from the quaternion. See vectorForward() for a definition.

...corrected to..

vectorRight
Vector vectorRight();
Returns the right vector from the quaternion. See vectorForward() for a definition.

..otherwise - very interesting! - I have really struggled with quaternions, despite being fascinated by them - the description of the difference exampled by the rotation of a book really got me going - I had to try it to fully realize what an enormous difference it makes!

Posted: **Sat Apr 07, 2007 11:25 pm**

Right, right it is. :-)

Cleaning up some ship loading stuff, I found that <key>smooth</key><false/> has the same effect as <key>smooth</key><true/>, or for that matter <key>smooth</key><array><string>an elephant.</string></array>. If you were relying on this behaviour, what were you smoking? Anyway, it’ll work like an actual boolean in future.

I noticed that trying to load a saved game with a ship that’s not installed causes a semi-crash, so I fixed it.

As mentioned elsewhere, subentities with shaders now get meaningful engine_level values.

The subject of mass has come up a few times recently. I’ve added a ''density'' shipentity key which can indirectly modify mass. Default is 1.0.

Posted: **Sun Apr 08, 2007 12:01 pm**

And now, a more-than-zero-times requested feature: arbitraryish laser colour. Laser colour can be specified as any of:

Code: Select all

<string>orangeColor</string> <!-- as before -->
<string>1.0 0.5 0.0</string> <!-- RGB components in the range [0, 1] -->
<string>255 127.5 0.0</string> <!-- RGB components in the range [0, 255] (used if any component is above 1) -->
<array><real>1</real><real>0.5</real><real>0</real></array>
<array><real>255</real><real>127.5</real><real>0</real></array>
<dict><key>red</key><real>1</real><key>green</key><real>0.5</real><key>blue</key><real>0</real></dict>
<dict><key>hue</key><real>30</real><key>saturation</key><real>1</real><key>brightness</key><real>1</real></dict> <!-- saturation and brightness are optional and default to 1, so: -->
<dict><key>hue</key><real>30</real></dict> <!-- Hue is colour wheel angle in degrees -->

For laser purposes, colours must have a minimum brightness of 0.5, or they will be brightened to that level. To realistically look like a single laser, it should be a fully saturated colour that’s not purple, but then, to realistically look like a laser it should be invisible.

Are colour names used anywhere other than lasers?

Posted: **Sun Apr 08, 2007 12:43 pm**

i think the turrets on npc ships use colour names to specify the plasma 'bullet' colour

Posted: **Sun Apr 08, 2007 12:51 pm**

So they do, but that’s technically the same thing. :-)

Posted: **Sun Apr 08, 2007 12:53 pm**

...what about when specifying nebulae?

Posted: **Sun Apr 08, 2007 1:02 pm**

They seem to be set as RGB triplets. Generalizing is a possibility, but would have to be done in a slightly different way.

Bug fix: if a ship has a possibility of having a shield enhancer (i.e. has_shield_enhancer is a real between 0 and 1) it would get 50% extra recharge rate regardless of whether it actually got a shield enhancer. Fixed for future versions.

Posted: **Sun Apr 08, 2007 1:14 pm**

Thanks for the information on the current state of the <key>smooth</key>-command. I guess that explains the weird behaviour of that command I have reported elsewhere.

And thanks for the enhancements of the laser colour! I actually had played a bit with trying to use RGB-values, but obviously it wasn't implemented yet.

Two questions: (1) The use of RGB-components suggests that the full range of RGB-colours (16.581.375) will be available, which will be a huge improvement. Are you also planning to make more colour names available? I'm asking that because in v 1.65 there are effectively only 12 colors available (see wiki on shipdata.plist). All the other X11 Colournames simply don't work.

(2) The colour wheel is also used for flashers. But I actually don't know how it works. What are the values that can be used? Is it simply angles of 0--360 degrees and then the colours will be repeated? And a specific question: Is "white" somewhere on that wheel? I'm asking because I'd like to have a white flasher somewhere on a model. How could I get it?

Posted: **Sun Apr 08, 2007 1:48 pm**

Commander McLane wrote:
Thanks for the information on the current state of the <key>smooth</key>-command. I guess that explains the weird behaviour of that command I have reported elsewhere.

I’m not sure which behaviour you’re referring to. The “darkening” thing isn’t related.

Commander McLane wrote:
Two questions: (1) The use of RGB-components suggests that the full range of RGB-colours (16.581.375) will be available, which will be a huge improvement. Are you also planning to make more colour names available? I'm asking that because in v 1.65 there are effectively only 12 colors available (see wiki on shipdata.plist). All the other X11 Colournames simply don't work.

First, “16.581.375” does not represent the full range of RGB colours. There are an infinite number of colours, but in contexts where eight bits per channel are used, 16 777 216 colours can be represented.

Internally, Oolite uses much greater accuracy, but the range of colours you can actually get is limited by your display settings, and by the accuracy of blending in your video card. Since lasers are blended into the scene, the actual colour seen will vary depending on the background.

Additionally, to know which precise colours are represented by an RGB triplet, you also need a colour profile.

But to answer your real question: Oolite will not impose any artificial restraints on colours, beyond forcing them to at least 50% brightness.

Commander McLane wrote:
(2) The colour wheel is also used for flashers. But I actually don't know how it works. What are the values that can be used? Is it simply angles of 0--360 degrees and then the colours will be repeated?

Yes. See http://en.wikipedia.org/wiki/HSV_color_space.

Commander McLane wrote:
And a specific question: Is "white" somewhere on that wheel? I'm asking because I'd like to have a white flasher somewhere on a model. How could I get it?

No, this is not possible at the moment. I’ll look into a more flexible way of specifying flashers… or at least put it on the to-do list. :-)

Posted: **Sun Apr 08, 2007 2:26 pm**

Work on the freezing-up-when-thargoid-carrier-explodes thing:

All ships now have a fragment_chance attribute, ranging from 0 to 1. It defaults to 0.9; you’d probably want to set it 1 for really big things. For wreckage, it’s 0.2. This means there are less secondary explosions.
The amount of wreckage or alloys generated when something explodes is now proportional to the fourth root of the mass, rather than the square root.

Posted: **Sun Apr 08, 2007 2:47 pm**

Ahruman wrote:
Bug fix: if a ship has a possibility of having a shield enhancer (i.e. has_shield_enhancer is a real between 0 and 1) it would get 50% extra recharge rate regardless of whether it actually got a shield enhancer. Fixed for future versions.

Related: NPC ships with has_shield_booster or has_shield_enhancer now start with full energy banks, rather than the amount of energy they'd have had without the boosters.

Posted: **Sun Apr 08, 2007 9:08 pm**

New debugging toy, which may be of interest to AI writers and nosey people: the “dump state key” (key_dump_target_state). It writes a bunch of stuff about the current targeted ship to the log. It’s not bound to anything by default; I’m using shift-H (72), for “Huh?”. ;-)

Oolite Bulletins

Progress