[Bilka] [0.17.68] Rendering time_to_live is one tick too short.

[eradicator]

What?
A render with time_to_live=1 is invisible, while a render with =2 is only visible for one tick.

Details

Tested draw_text and draw_circle both of which are affected. I guess the background logic is the same for all of them anyway?

Example code draws a pair of texts and a pair circles with ttl=2, which redrawn every two ticks should thus be consantly visible, but can be clearly seen flickering. Reducing ttl to 1 will not render anything at all.

Code: Select all

/c
local p = game.player
pcall(script.on_event,defines.events.on_tick,function(e)
 
  game.speed = 0.1
  
  local odd = e.tick % 2 == 1  
  local ttl = 2
  
  rendering.draw_text{
    text = odd and 'odd' or 'even',
    color = odd and {r=1} or {g=1},
    surface = p.surface,
    target = p.character,
    target_offset = odd and {0,0} or {2,0},
    time_to_live = ttl,
    }

  rendering.draw_circle{
    radius = 1/16,
    filled = true,
    text = odd and 'odd' or 'even',
    color = odd and {r=1} or {g=1},
    surface = p.surface,
    target = p.character,
    target_offset = odd and {0,0} or {2,0},
    time_to_live = ttl,
    }
  end)

[Bilka]

The object gets created and updated in the same tick, but not rendered in that tick because rendering already happened for that tick. Yay update order.

[Bilka]

Changing the order of create-update-render/delaying the update could introduce other issues so just slap a +1 on there and call it a day.

Note that behaviour might be different with events that happen at another point in the tick.

[eradicator]

Changing the order of create-update-render/delaying the update could introduce other issues so just slap a +1 on there and call it a day.

If it's that easy wouldn't it be saner if you slap the +1 onto it internally? And if not i - as always - would like to request that this behavior is documented.

[Bilka]

Changing the order of create-update-render/delaying the update could introduce other issues so just slap a +1 on there and call it a day.

If it's that easy wouldn't it be saner if you slap the +1 onto it internally? And if not i - as always - would like to request that this behavior is documented.

No, that introduces other issues somewhere else. Like I said, not all events run at the same time - you just happened to pick on_tick which runs after rendering. Which also makes documentation hard - I'd have to explain that in some cases the ttl may appear 1 tick shorter when the object *is there* the entire time, just not rendered. In fact, slapping the +1 on internally would make the object exist for 3 ticks instead of 2. Not to mention that it depends on the event you're running the code in. I'd rather have people find this thread in the rare instance that they rely on the objects rendering in the tick that they're created in and are creating them in on_tick.

[eradicator]

Like I said, not all events run at the same time - you just happened to pick on_tick which runs after rendering.

I always assumed that on_tick was the first event to be run in any given tick like this:
tick1_render -> tick1_on_tick -> tick1_other_events -> tick2_render -> tick2_on_tick -> tick2_other_events
Causing renders to always be first evaluated in the next tick, and thus not rendering for ttl=1.

Would you care to entertain me with an example of a situation where a non-tick event runs before on_tick (and/or the renderer)? If my assumption isn't total bullshit anyway...

[Bilka]

I always assumed that on_tick was the first event to be run in any given tick like this:
tick1_render -> tick1_on_tick -> tick1_other_events -> tick2_render -> tick2_on_tick -> tick2_other_events
Causing renders to always be first evaluated in the next tick, and thus not rendering for ttl=1.

Would you care to entertain me with an example of a situation where a non-tick event runs before on_tick (and/or the renderer)? If my assumption isn't total bullshit anyway...

I went on an adventure through the main loop. Render prepare gathers data for what to render -> game update starts -> on tick -> main game update -> render. Inside "game update starts", input actions are processed, such a building an entity which can raise a lua event - which runs before on tick. I think you can understand why I don't want to mess with the main loop just to make script render objects render in the same tick that they're created. Right now what's happening with 1 tick objects is that you create them, then main update runs and goes "--ttl == 0 = true", destroys object, object gone before next render prepare.

[eradicator]

Render prepare gathers data for what to render -> game update starts [incl. input actions] -> on tick -> main game update -> render.

Input before on_tick is quite unexpected for me. But if that's the order things happen in then i still don't see any case where a mod could create a render which doesn't have it's ttl reduced by one before being visible for the first time. Looking at the list of events i guess robot building or projectiles hitting would be non-input-based and so happen in "main game update". So does "main game update" substract the ttl before processesing these events... and thus any render created during non-input-action triggered events is both rendered in the same tick and is visible for exactly ttl ticks?

I think you can understand why I don't want to mess with the main loop

Sure. I was hoping it was a simple off-by-one error initially. But now i'm curious to understand how it's happening. If only to make the thread more useful if anyone actually ever looks at it ;).