I have idea how to allow more colours lighting without risk of unwanted night lighting of already existing objects ... and probably without large change of code.
Addon colours could be set in dat file of object.
For example, there could be line
night_colour[colour1] = colour2
where
colour1 - colour that should light at night
colour2 - colour that would be used as pattern (colour that its night light will be used)
So, really there could be
night_colour[76,51,51] = 87,101,111
or
night_colour[63,51,51] = 77,77,77
This would give authors of (mostly building) addons colour freedom - for example to create railstation like this (see image below), with dark brown windows lighting at night.
(http://photos.wikimapia.org/p/00/00/92/50/13_big.jpg)
Of course, this station building is not much beautiful - but it is a very interesting for its very large windows of waiting hall (that are dark brown).
The colors can be only replaced paksetwide (at the moment), as this is shared with all other images. There are, in pricinple, still 240 slot open ...
Aren't those the player color slots?
The idea might be interesting: 255 special colors per pakset, but the dat file "activating" the desired ones for the given object.
We have 14 night colors and 16 player colors, but there could be easily space for more (pakset) dependent colros to replace. In principle there are more than 32000 entries left, but in practice less than 256 should be ok. (Just imagine drawing without accidently using any of those 256 colors ... )
The 32000 figure made more sense to me. But only the 14/15 (?) existing lights will be accessible as a special color throughout the game, the rest is only possible for images.
The best way of having any light one wants without affecting other objects is to have a special lights overlay (for each image, not for each object like a front image, so it wouldn't consume image numbers). As Simutrans in any case does preprocessing to generate the correctly lit images for objects, it shouldn't be too hard to get into Simutrans. Getting it into Makeobj in a user friendly might be more of a challenge. With a third overlay, one could also free up the colors currently mapped to player colors. Anti-aliasing would also be possible for player colors, but not for the others, so may be more confusing than useful.
Quote from: prissi on November 12, 2013, 10:33:19 PM
We have 14 night colors and 16 player colors
2*8 player colours, but only 10 night colours - but my sheet of special colours may be very old
Yes but more night colors are not a problem from the code. (Just the darkening will take up more time with more indices).
About the interface: An easy way out would be one special color which can be redefined by any object. That would keep the bloat of the images low and allow for enough flexibility without adding lots of special colors to shades and alike. And since we have a 65536 image limit, this shoudl be fine with almost any color.
Quote from: Ters on November 13, 2013, 06:07:13 AM
Anti-aliasing would also be possible for player colors, but not for the others, so may be more confusing than useful.
Ters, your fear is comprehensible, but on other hand, how much anti-aliasing is used?
In comic paksets it is not used, if I am not wrong - or very rarely. And for other paksets, if you create windows, they have a little different colour than their surroundings (walls and other decorations) - and also, you have control over colour of windows and doors.
Quote from: Václav on November 13, 2013, 10:18:05 AM
In comic paksets it is not used, if I am not wrong - or very rarely.
Old objects don't use it, but then maintainers started to ask for them. pak192.comic is already following the latest "standard" by adding them more.