Friday Facts #161 - Infinite Research and Blueprint Library

Regular reports on Factorio development.
User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 3699
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by DaveMcW »

starholme wrote: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.
Last edited by DaveMcW on Sat Oct 22, 2016 12:29 am, edited 1 time in total.

jcranmer
Long Handed Inserter
Long Handed Inserter
Posts: 90
Joined: Wed Jun 29, 2016 9:59 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by jcranmer »

Proxy wrote: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).

User avatar
impetus maximus
Smart Inserter
Smart Inserter
Posts: 1299
Joined: Sat Aug 20, 2016 10:07 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by 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. :P

dstar4138
Burner Inserter
Burner Inserter
Posts: 8
Joined: Mon Sep 05, 2016 11:00 am
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by dstar4138 »

ssilk wrote: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.
Last edited by dstar4138 on Sat Oct 22, 2016 6:41 am, edited 1 time in total.

Rseding91
Factorio Staff
Factorio Staff
Posts: 13175
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by Rseding91 »

Zeblote wrote: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.
If you want to get ahold of me I'm almost always on Discord.

User avatar
Gergely
Filter Inserter
Filter Inserter
Posts: 595
Joined: Sun Apr 10, 2016 8:31 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by Gergely »

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

Ormek
Inserter
Inserter
Posts: 47
Joined: Mon Oct 03, 2016 8:44 am
Contact:

Re: Friday Facts #161 - Blueprint Library

Post by 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
Global Moderator
Global Moderator
Posts: 7175
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by Koub »

Gergely wrote:Can you tell me the "best case" release date for 0.15?
the "best case" release date for 0.15.

You're welcome.
Koub - Please consider English is not my native language.

bulldog98
Long Handed Inserter
Long Handed Inserter
Posts: 74
Joined: Tue Apr 08, 2014 6:40 am
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by bulldog98 »

Klonan wrote:
Proxy wrote: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?

User avatar
steinio
Smart Inserter
Smart Inserter
Posts: 2632
Joined: Sat Mar 12, 2016 4:19 pm
Contact:

Re: Friday Facts #161 - Blueprint Library

Post by steinio »

Ormek wrote: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
Image

Transport Belt Repair Man

View unread Posts

User avatar
Mooncat
Smart Inserter
Smart Inserter
Posts: 1190
Joined: Wed May 18, 2016 4:55 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by Mooncat »

Koub wrote:
Gergely wrote:Can you tell me the "best case" release date for 0.15?
the "best case" release date for 0.15.

You're welcome.
Image

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.

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12888
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by ssilk »

dstar4138 wrote:

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
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

mdqp
Inserter
Inserter
Posts: 20
Joined: Sat Jun 18, 2016 6:43 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by 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
Factorio Staff
Factorio Staff
Posts: 13175
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by Rseding91 »

ssilk wrote:
dstar4138 wrote:

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).
If you want to get ahold of me I'm almost always on Discord.

User avatar
aubergine18
Smart Inserter
Smart Inserter
Posts: 1264
Joined: Fri Jul 22, 2016 8:51 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by aubergine18 »

Rseding91 wrote: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).
Better forum search for modders: Enclose your search term in quotes, eg. "font_color" or "custom-input" - it prevents the forum search from splitting on hypens and underscores, resulting in much more accurate results.

Ormek
Inserter
Inserter
Posts: 47
Joined: Mon Oct 03, 2016 8:44 am
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by Ormek »

mdqp wrote: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
Burner Inserter
Burner Inserter
Posts: 8
Joined: Mon Sep 05, 2016 11:00 am
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by dstar4138 »

aubergine18 wrote:
Rseding91 wrote: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.

User avatar
Klonan
Factorio Staff
Factorio Staff
Posts: 5148
Joined: Sun Jan 11, 2015 2:09 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by Klonan »

dstar4138 wrote:
aubergine18 wrote:
Rseding91 wrote: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
Filter Inserter
Filter Inserter
Posts: 318
Joined: Sat Aug 06, 2016 9:12 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by Mehve »

Ormek wrote:
mdqp wrote: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.

User avatar
Andrzejef
Fast Inserter
Fast Inserter
Posts: 103
Joined: Sat Aug 27, 2016 1:16 pm
Contact:

Re: Friday Facts #161 - Infinite Research and Blueprint Library

Post by Andrzejef »

Mehve wrote:
Ormek wrote:
mdqp wrote: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".
Image

Post Reply

Return to “News”