flashers

[Commander McLane]

There is an oddity with flashers that has been there forever. Probably it is even the intended behaviour, but it leads to unnecessary headaches on the scripters' side, so I'd vote for a change.

The definition for a flasher is

Code: Select all

*FLASHER* x y z hue speed offset size

and the oddity is that how fast the flasher pulses is determined by sin(speed * x), while its start is determined by an offset which is absolute. So the complete flasher formula is sin((speed* x) + offset). From the user's (scripter's/ship designer's) point of view this makes offset a function of speed, which is impractical. And if this makes no sense, please forgive me, and I hope my examples do:

Example: In order to have two alternating flashers with the same speed you would have to define them like this:

Code: Select all

*FLASHER* x y z hue 1 0 size
*FLASHER* x y z hue 1 0.5 size

This way the second flasher has its maximum brightness when the second flasher is at its minimum and vice versa.

But this only works for speed = 1. For speed = 2 you would need:

Code: Select all

*FLASHER* x y z hue 2 0 size
*FLASHER* x y z hue 2 0.25 size

They flash at double speed, so one complete circle only takes one half (unaltered) sine-wavelength. So half of that is just one quarter of the unaltered sine-wavelength, therefore 0.25.

In the same way you would need

Code: Select all

*FLASHER* x y z hue 1.5 0 size
*FLASHER* x y z hue 1.5 0.33333333 size

or

Code: Select all

*FLASHER* x y z hue 0.5 0 size
*FLASHER* x y z hue 0.5 1 size

or

Code: Select all

*FLASHER* x y z hue 0.4 0 size
*FLASHER* x y z hue 0.4 1.25 size

to make them flash alternately (you note that for speeds below 0.5 you have to leave the 0..1 range that offset according to the wiki has).

Therefore, while the definition as it is now is good for timing flashers on an absolute timescale (offset always means the same duration of time; actually, if the speed for speed = 1 is one second (haven't measured), it's always the same fraction of a second), this is not what I think to be the most common use of offset.

I think offset is practically always used to co-ordinate two (or a group of) flashers with the same speed, regardless of how other groups of flashers are handled.

Therefore—from a scripter's (ship designer's) point of view—it would be immensely more useful to have offset relate to the flasher's speed instead of an absolute amount of time (the unaltered sine-wave). So that two alternating flashers can always be started at 0 and 0.5 (or 0.25 and 0.75), regardless of their speed.

I think (if my mathematics are still correct) that would be achieved by changing the flasher code from sin((speed* x) + offset) to sin(speed * (x + offset)). Please prove me wrong, as my brain is starting to hurt now.

[JensAyton]

I have no intention of changing current behaviour, because it would change current behaviour. :-)

However, I have on various occasions felt that allowing subentities entries to be dictionaries would allow for significantly greater flexibility, and rethinking parameters while doing so would make sense. The new-in-1.72 ship registry provides a sensible means to convert existing string entries into dictionaries for internal use.

[Commander McLane]

I have no intention of changing current behaviour, because it would change current behaviour.

While I understand that, I would like to stress the point that in this specific case most likely the existing scripts don't take into account the actual current behaviour, but assumed the behaviour I am requesting in the first place.

Anyway: Could you expand a little bit on the ship registry thingy? I don't think I already got it.

[JensAyton]

Anyway: Could you expand a little bit on the ship registry thingy? I don't think I already got it. :oops: :roll:

The ship registry is an internal detail, but it has some ramifications that you’ve already noticed.

Previously, the various ship-related plists – shipdata.plist, shipyard.plist and demoships.plist – were just read when the game started up (converting it into array, dictionary and string objects in memory) and the different copies from Oolite and OXPs merged together. Interpreting the data was deferred until it was needed, which (among other things) meant that errors for a given ship were only reported when it was actually used, if at all.

Starting in 1.72, those plists (plus the new override ones) are loaded, verified and normalized at startup. Normalizing currently involves resolving like_ship references and removing templates, while verification involves checking that ships have models and roles and their subentity definitions have the right number of words. This is why you get a list of ship-related error messages at startup when rebuilding the cache.

Previously, changing the way subentities are defined would require dealing with two different types of definitions wherever subentities are used, while the new model allows us to convert the definitions to the new form when the definitions are loaded. As it turns out, the definitions are only used in one place anyway (I thought there were two), but the principle is sound. :-)