Variations for lamps: pictures_on, pictures_off

[Deadlock989]

Lamps have a "base" layer defined in picture_off. If the lamp is powered and daylight conditions are met or the new always_on flag is set, the picture_on sprite is then drawn over it, plus the light glow.

It would be super-cool if lamps could have a set of variants amenable to runtime scripting, much like the pictures[] list in SimpleEntityWithForce or ElectricEnergyInterface. So I guess you'd end up with

picture_off
pictures_off
picture_on
pictures_on

like SEWF and EEI do for their one sprite. Though for my own plans I don't need variants of the base, just of picture_on.

[Rseding91]

What's the use-case?

[Deadlock989]

Essentially it's like an electric sign. It needs the following, all of which exist in one entity or another, but there is no entity which ticks off the whole list:

- Is an electricity consumer
- Has health, a force, resistances etc.
- Has a sprite and light overlay which are only drawn when powered (like a lamp)
- Is circuit/logistic network controllable (like a lamp)
- Supports a list of variant pictures for its powered state accessible at runtime (like SimpleEntityWithForce does for its main sprite)

At the moment I'm simulating this by defining a whole set of lamp entities that all have the same placeable_by (WIP example shown below - those are lamps with the large icon being specified in picture_on) and then fast-replacing them on the gui interaction. But then you have an annoying proliferation of them in the electricity stats, one for every variant.

It can't be done with rendering because there's no UPS-friendly way to have the associated rendered sprite go away on power loss.

Edited to add when prompted on Discord: the circuit network functionality is probably the least important part, but if operationalising this meant that it wasn't a lamp but some new entity - something like a SimpleEntityWithForceAndPower - then in a perfect world it would have the "Enabled condition" function that lamps have. It wouldn't need the colour signal response that lamps do but it's not a problem if it does.

[justarandomgeek]

- Is an electricity consumer
- Has health, a force, resistances etc.
- Has a sprite and light overlay which are only drawn when powered (like a lamp)
- Is circuit/logistic network controllable (like a lamp)
- Supports a list of variant pictures for its powered state accessible at runtime (like SimpleEntityWithForce does for its main sprite)

This is exactly the entity I've always wished for and faked in various ways for nixies.

[Deadlock989]

Have been asked to describe this entity as if it weren't a lamp but a new kind of entity.

It would have as an absolute minimum:

- A force / owner
- Health, resistances, etc.
- Be an electric/void consumer - energy_source, energy_usage
- Has a "base state" sprite that is always drawn, powered or not
- Have the choice between a "picture on" (like lamps) or "pictures on" (like SimpleEntityWithForce's pictures), which are only rendered when the entity is powered and circuit conditions are met (if connected). This sprite layer is always rendered above the base sprite and supports additive rendering (like a lamp)
- Runtime R/W access to the currently selected variant of the above via entity.graphics_variation (like SimpleEntityWithForce)
- A light source definition which is only rendered when the entity is powered, regardless of time of day (like a lamp in always_on mode)
- Be circuit-connectable, with the same "Mode of operation" and "Enabled condition" GUI as lamps (like a lamp)

Bonus things which would be "nice to have":

- Has the same "use colours" option as lamps, which is applied to the light source glow - so I guess that's two light defintions, light and light_when_coloured (like a lamp)
- I'd prefer it not to also tint to the "on" picture as it currently does with lamps, but others might, so best case would be that this were controllable with a flag/property
- Logistic network connection (like a lamp)

Basically it's exactly like a lamp but it supports sprite variants for its on state and provides runtime access to which of the variants is "selected".

[justarandomgeek]

- I'd prefer it not to also tint to the "on" picture as it currently does with lamps, but others might, so best case would be that this were controllable with a flag/property

That would just be the apply_runtime_tint setting on the sprites anyway - and i want both tinted!

[Deadlock989]

- I'd prefer it not to also tint to the "on" picture as it currently does with lamps, but others might, so best case would be that this were controllable with a flag/property

That would just be the apply_runtime_tint setting on the sprites anyway - and i want both tinted!

That's fine, but it's not how lamp picture_on currently works. apply_runtime_tint is currently used for things like force colour on turrets, locomotive colours, fluid colours in pipes. With lamps, the sprite defined in picture_on is simply tinted by the colours defined in signal_to_color_mapping and there's no way to disable it for a particular layer - although I suppose you can disable all the colours by simply not defining signal_to_color_mapping for the specific lamp.

[Deadlock989]

Another thing for the wish-list, in a perfect world - if we're talking about some new electric entity that isn't a descendant of lamps, then having animated sprites would also be a winner. Lamps define pictures, not animations.

e.g. like SimpleEntityWithForce can have any of these:

Untitled.png (27.73 KiB) Viewed 2483 times

Perfect world, AnimationVariations would also be tinted by the signal_to_color_mapping.

[eradicator]

+1

I found a usecase where it would be nice to have a simple entity that supports reading of LuaEntity.electric_network_id without actually consuming/producing energy, instead of having to use say an EEI with input/output flow of 0. Animations would also be a really good bonus.

[Deadlock989]

Another attempt at defining this thing. @Bilka, maybe ignore my previous posts in this thread, hopefully this is clearer.

The entity is a descendant of EntityWithHealth, so it gets all of that.

In addition it has the following properties. Those with an asterisk (*) are not "must haves" but would be very nice to have. No asterisk = must have.

light, Types/LightDefinition (see Lamp) - similar to a lamp, i.e. it is only rendered when entity receives power, but ignores daylight state, i.e. behaves like a lamp does when always_on is set to true

light_when_colored, Types/LightDefinition (see Lamp) - ditto

glow_size, Types/float (see Lamp)

glow_color_intensity, Types/float (see Lamp)

energy_source, Types/EnergySource (see Lamp) - electric or void

energy_usage_per_tick, Types/Energy (see Lamp)

circuit_wire_connection_point, Types/WireConnectionPoint (see Lamp)

circuit_wire_max_distance, Types/double (see Lamp)

circuit_connector_sprites, Types/CircuitConnectorSprites (see Lamp)

signal_to_color_mapping, Types/table of Types/SignalColorMapping (see Lamp)

*render_layer, Types/RenderLayer (see SimpleEntityWithForce)

*random_animation_offset, Types/bool (see SimpleEntityWithForce)

*draw_copper_wires, Types/bool (see Lamp)

*draw_circuit_wires, Types/bool (see Lamp)

*signal_to_variation_mapping, Types/table of new type Types/SignalVariationMapping (see below)

Types/SignalVariationMapping is a way of getting the circuit network to directly change the current graphics_variation. It's very similar to SignalColorMapping except it maps a signal name to an integer index for the graphics variations, instead of to a color value for tinting. It would have the following three properties:

type, Types/string - type of signal
name, Types/string - id of the signal
index, Types/integer - graphics variation index (default 1, minimum 1)

The entity prototype must also define one (and only one) of the following three "base pictures". These are always drawn regardless of power state. They are not affected by signal_to_color_mapping or signal_to_variation_mapping. (They could be affected by runtime tint but I don't have any use for that myself.)

base_picture, Types/Sprite (see picture in SimpleEntityWithForce)

*base_pictures, Types/SpriteVariations (see pictures in SimpleEntityWithForce)

*base_animations, Types/AnimationVariations (see animations in SimpleEntityWithForce)

It must also define one (and only one) of the following three "active sprites". These are only rendered if the entity is fully powered and not disabled by the circuit/logistics network. So the native GUI for the entity essentially gets the same circuit and logistic network controls as a lamp. (If you can do the SignalVariationMapping thing then I guess it would need an extra checkbox for that.)

active_picture, Types/Sprite (see picture in SimpleEntityWithForce) - tinted by signal_to_color_mapping

active_pictures, Types/SpriteVariations (see pictures in SimpleEntityWithForce) - this is R/W at runtime, like LuaEntity.graphics_variation - it is also tinted by signal_to_colour_mapping, and the variant is also set by signal_to_variation_mapping

active_animations, Types/AnimationVariations (see animations in SimpleEntityWithForce) - this is also R/W at runtime and tintable/mapped, as with active_pictures

So the base_ sprites/animations are much like a lamp's picture_off, and the active_ sprites/animations are like a lamp's picture_on, except that they also have variants which work the same way as a SimpleEntityWithForce's picture variants.