Friday Facts #161 - Infinite Research and Blueprint Library

[DaveMcW]

I wonder if they bother to balance each bucket? So you don't end up with 300 chunks to process one tick, 3 the next.

The circular nature of pollution clouds makes that unlikely. The only way to make such an unbalanced pollution cloud is to play a vertical ribbon map.

[jcranmer]

well. i don't mean the process to get to Infinite, but rather what it would need to actually have it. just Displaying a Infinitly Long Number or Infinite amount of Follower Robots would be Impossible in a Limited Universe.
and i'm just gonna assume the Universe is a Closed object, with Limited Matter and Energy.

Here's an infinite number: ω. It's the ordinal corresponding to the cardinal א-naught, the size of the set of natural numbers (and rational numbers, too).

[impetus maximus]

love the idea of a blueprint library.

as for resource sink, i would love if after you launch a rocket you are contacted by someone who will buy from, or trade with you.
kind of like tight spot game mode. maybe a ship comes and picks up orders etc. i'm sure there is a mod for that, but i want it in vanilla damn it.

[dstar4138]

This queue mechanism is interesting for modders. Super useful if a modder would be enabled to create different types of future events (plus data).

In this context: viewtopic.php?f=28&t=33441&p=212499&hil ... er#p212481
forget the first part, ---> Timers

Oh I could definitely see this generalized for use by mods. maybe something like:

Code: Select all

LuaBootstrap.on_scheduled_event(event, schedule, f)

where
    event :: defines.events or array of defines.events or string: The events of custom-input name to invoke handler on
    schedule :: uint: The index into the modulo queue schedule on which to push the handler
    f :: function(Event) : The handler to run

example
    script.on_scheduled_event(defines.events.on_tick, 60, myCallbackFunction)
        runs myCallbackFunction every 60 emissions of the on_tick event.

Mabye it only works for timed events such as on_tick, on_sector_scanned, etc. Maybe call it LuaBootstrap.on_tick_modulo(schedule, f) instead? But I could definitely see a use for things like re-balancing internal structures after N players join/leave or after so many entities constructed. Might be more efficient that straight up timer threads for every registered callback.

[Rseding91]

I think he means something like this:

1) On start, create 60 vectors of chunk pointers
2) On chunk creation, insert it into one of the vectors
3) Every tick, update pollution for the chunks in the (tick % 60)th vector with a simple loop

That way there'd be no need to re-insert the chunks into queue for 60 ticks ahead.

The chunk position is used to determine which of the 64 queues it ends up in and then map.tick % 64 determines which queue gets pollution logic handled. It uses % 64 so it ends up as tick & 63 for a cheap check.

[Gergely]

Can you tell me the "best case" release date for 0.15?

[Ormek]

Do we really need to have different libraries for blue prints? I propose

• One storage that contains all blue prints automatically, once they are created
• That one storage is accessible from any game.
• Let the player assign any number of labels to each blue print.
• Provide a label oriented view on the blue prints, e.g.
  • Use the labels as folders that I open
  • Use the labels as filter settings that reduce the set of all blue prints by selection
  • ...
• Assign some labels automatically (I do not really know which would make sense): e.g. Used Mods, Single Player, Multiplayer, Contained part types.

If I address the topic from the current situation (I have a blue print in my current game and want to share it with other games or players) the additional storages are the obvious choice.
But, if I think about this from the view of a player who only knows the final result: Would he not wonder:

• Why do I have to move blue prints around from one storage to another?
• Oh, I forgot to move the blueprint I created yesterday in game X to the library, now I cannot use it in game Y today. The only consequence is: Stop game Y, start game X, move the blue print to the library, stop game X, start game Y again. How tedious! Adds nothing to the game.

Having a blue prints libray is fun just like a photo book: "Ahh. Look at all my creations. Lets organize them even further." So having mutliple folders or labels in the blue print library will probably eventually become a requirement anyway.

[Koub]

Can you tell me the "best case" release date for 0.15?

the "best case" release date for 0.15.

You're welcome.

[bulldog98]

isn't Infinite Research impossible?
as it would Requere Infinite Data Storage and Infinite Processing Power to actually do that and use it.

Well humans don't have infinite storage or brain power, but you can get a piece of paper and keep multiplying the same number over and over

Infinite just means there will be no ceiling to the calculations, the research number will just increment, and the modifier it affects will just keep increasing

Actually there would be a limit in the data format you choose to represent it in game, no?

[steinio]

Do we really need to have different libraries for blue prints? I propose

• One storage that contains all blue prints automatically, once they are created
• That one storage is accessible from any game.
• Let the player assign any number of labels to each blue print.
• Provide a label oriented view on the blue prints, e.g.
  • Use the labels as folders that I open
  • Use the labels as filter settings that reduce the set of all blue prints by selection
  • ...
• Assign some labels automatically (I do not really know which would make sense): e.g. Used Mods, Single Player, Multiplayer, Contained part types.

If I address the topic from the current situation (I have a blue print in my current game and want to share it with other games or players) the additional storages are the obvious choice.
But, if I think about this from the view of a player who only knows the final result: Would he not wonder:

• Why do I have to move blue prints around from one storage to another?
• Oh, I forgot to move the blueprint I created yesterday in game X to the library, now I cannot use it in game Y today. The only consequence is: Stop game Y, start game X, move the blue print to the library, stop game X, start game Y again. How tedious! Adds nothing to the game.

Having a blue prints libray is fun just like a photo book: "Ahh. Look at all my creations. Lets organize them even further." So having mutliple folders or labels in the blue print library will probably eventually become a requirement anyway.

Sounds reasonable.

I hope we can manage our blueprints without loading a save.

Greetings steinio

[Mooncat]

Can you tell me the "best case" release date for 0.15?

the "best case" release date for 0.15.

You're welcome.

If the new things mentioned in the previous FFF will be implemented in 0.15, then I think it won't be in this year. Maybe Jan - Feb of 2017.

[ssilk]

Code: Select all

LuaBootstrap.on_scheduled_event(event, schedule, f)

where
    event :: defines.events or array of defines.events or string: The events of custom-input name to invoke handler on
    schedule :: uint: The index into the modulo queue schedule on which to push the handler
    f :: function(Event) : The handler to run

example
    script.on_scheduled_event(defines.events.on_tick, 60, myCallbackFunction)
        runs myCallbackFunction every 60 emissions of the on_tick event.

Hm. We need to distinct beween "one-time events" (... delayed events) and "intervall events" (repeating timer).

One time events mean: They should happen at a tick.
Intervall event mean: They should repeat every X ticks from now on.

Also a somehow nice idea would be, if I could delay an event into the future (I have obviously not thought much about naming yet):

Code: Select all

LuaEventBlaFasl.defer_to(event, event_type, tick)

LuaEventBlaFasl.defer_delta(event, event_type, ticks, repeat)

Usage:
script.on_event(defines.events.on_built_entity, function(event)
    if currently_not_useful then
        LuaEventBlaFasl.defer_to(event, defines.events.on_tick, event.tick + 60)
    end
end

or equal functionality:

script.on_event(defines.events.on_built_entity, function(event)
    if currently_not_useful then
         LuaEventBlaFasl.defer_delta(event, defines.events.on_tick, 60, false)
    end
end

[mdqp]

To be honest, I am not sure if I am interested in having resource sinks, I produce stuff in order to increase the size of my factory, and then to better defend myself and to reach/transport more resources to mantain the factory and meet the production goal. If I get more goals, I'll try to reach them, but infinite research seems like a waste of time. If I am at a point where I want to pursue them, is probably just because I have no other goals, and since they are infinite, they don't work as new objectives (since they can never "get done"), and are likely worse than any goal I could set for myself.

It's not something that will harm my enjoyment of the game, though, so I guess as long as some people like it, it's still a worthwhile addition.

[Rseding91]

Code: Select all

LuaBootstrap.on_scheduled_event(event, schedule, f)

where
    event :: defines.events or array of defines.events or string: The events of custom-input name to invoke handler on
    schedule :: uint: The index into the modulo queue schedule on which to push the handler
    f :: function(Event) : The handler to run

example
    script.on_scheduled_event(defines.events.on_tick, 60, myCallbackFunction)
        runs myCallbackFunction every 60 emissions of the on_tick event.

Hm. We need to distinct beween "one-time events" (... delayed events) and "intervall events" (repeating timer).

One time events mean: They should happen at a tick.
Intervall event mean: They should repeat every X ticks from now on.

Also a somehow nice idea would be, if I could delay an event into the future (I have obviously not thought much about naming yet):

Code: Select all

LuaEventBlaFasl.defer_to(event, event_type, tick)

LuaEventBlaFasl.defer_delta(event, event_type, ticks, repeat)

Usage:
script.on_event(defines.events.on_built_entity, function(event)
    if currently_not_useful then
        LuaEventBlaFasl.defer_to(event, defines.events.on_tick, event.tick + 60)
    end
end

or equal functionality:

script.on_event(defines.events.on_built_entity, function(event)
    if currently_not_useful then
         LuaEventBlaFasl.defer_delta(event, defines.events.on_tick, 60, false)
    end
end

The main problem with any such queue system or delayed calling is handling save/load. I can't serialize a closure with upvalues and ones without aren't guaranteed to point at anything valid when de-serialized (maybe you changed your function names between saving/loading).

[aubergine18]

The main problem with any such queue system or delayed calling is handling save/load. I can't serialize a closure with upvalues and ones without aren't guaranteed to point at anything valid when de-serialized (maybe you changed your function names between saving/loading).

What if it triggered a remote call? So instead of function name we'd supply interface name and function name. If the interface of function is missing when the event triggers, it's simply ignored (or removed if repeating interval event).

[Ormek]

To be honest, I am not sure if I am interested in having resource sinks, I produce stuff in order to increase the size of my factory, and then to better defend myself and to reach/transport more resources to mantain the factory and meet the production goal.

Same here.

[dstar4138]

The main problem with any such queue system or delayed calling is handling save/load. I can't serialize a closure with upvalues and ones without aren't guaranteed to point at anything valid when de-serialized (maybe you changed your function names between saving/loading).

What if it triggered a remote call? So instead of function name we'd supply interface name and function name. If the interface of function is missing when the event triggers, it's simply ignored (or removed if repeating interval event).

Actually yeah LuaRemote would be a good callback registration mechanism for this. It pushes some of the work onto the plugin maintainers.

1. Mod registers callbacks as constant hash-able values (i.e. strings).
2. Mod instead uses these values instead as function pointers in all on_event, on_scheduled_event, defer_* functionality.
3a. On save, we maintain the constants instead of the function along with all schedule and progress information (we would need to avoid preemption here).
3b. On load, we load the registration table and hard block until all callbacks are registered (must be done on init() probably).
4. Mod upgrades will need to maintain all old registered callbacks or mark them as invalid in all future versions (or else be non-backwards compatible).

I don't think this would make mods any more brittle, and it gets around the need to serialize closures.

[Klonan]

The main problem with any such queue system or delayed calling is handling save/load. I can't serialize a closure with upvalues and ones without aren't guaranteed to point at anything valid when de-serialized (maybe you changed your function names between saving/loading).

What if it triggered a remote call? So instead of function name we'd supply interface name and function name. If the interface of function is missing when the event triggers, it's simply ignored (or removed if repeating interval event).

Actually yeah LuaRemote would be a good callback registration mechanism for this. It pushes some of the work onto the plugin maintainers.

1. Mod registers callbacks as constant hash-able values (i.e. strings).
2. Mod instead uses these values instead as function pointers in all on_event, on_scheduled_event, defer_* functionality.
3a. On save, we maintain the constants instead of the function along with all schedule and progress information (we would need to avoid preemption here).
3b. On load, we load the registration table and hard block until all callbacks are registered (must be done on init() probably).
4. Mod upgrades will need to maintain all old registered callbacks or mark them as invalid in all future versions (or else be non-backwards compatible).

I don't think this would make mods any more brittle, and it gets around the need to serialize closures.

I don't see how any of this is simpler than any of the current solutions many mods use:

Code: Select all

script.on_event(defines.events.on_tick, function(event)
  if game.tick % global.interval ~= 0 then return end
  do_something(global.my_entity) 
end)

Code: Select all

script.on_event(defines.events.on_tick, function(event)
  if game.tick ~= global.my_scheduled_update_tick then return end
  do_something(global.my_entity)
  global.my_scheduled_update_tick = game.tick + how_many_ticks_in_the_future 
end)

Code: Select all

script.on_event(defines.events.on_tick, function(event)
  for k, entity in (global.my_table) do
    if (k + game.tick) % global.interval == 0 then
      do_something(entity)
    end
  end
end)

[Mehve]

To be honest, I am not sure if I am interested in having resource sinks, I produce stuff in order to increase the size of my factory, and then to better defend myself and to reach/transport more resources to mantain the factory and meet the production goal.

Same here.

That's a perfectly valid playstyle, but this game's underlying goal is one of production. And that production needs to go somewhere, or you just turn into an industrial hoarder. Furthermore, unless you're running on extremely lean resource settings, base expansion and defense setups will virtually always give you access to more resources than they cost. Sooner or later, you need something to produce, whether it's research or rockets or something else entirely.

[Andrzejef]

To be honest, I am not sure if I am interested in having resource sinks, I produce stuff in order to increase the size of my factory, and then to better defend myself and to reach/transport more resources to mantain the factory and meet the production goal.

Same here.

That's a perfectly valid playstyle, but this game's underlying goal is one of production. And that production needs to go somewhere, or you just turn into an industrial hoarder. Furthermore, unless you're running on extremely lean resource settings, base expansion and defense setups will virtually always give you access to more resources than they cost. Sooner or later, you need something to produce, whether it's research or rockets or something else entirely.

It's an Idle-game mechanism as such (constant resource sink with diminishing value and increasing cost), but I think it's needed. Otherwise the resource, mostly research packs useless otherwise, and a lot of factory infrastructure would be laying to waste, completely useless, especially for people with huge R&D sectors. It would be simply too big issue to recyclce or care. Might as well do something semi-productive and semi-useful in the meantime, right?
Even if that means adding another 9 after "0 point".