Factorio Forums

I can't open factorio.com

Looks like a great step for the game. With the addition of better UI the game will just become better and user friendly which is always welcome. Also that pollution fix is just a solid choice to keep the game smooth running through-out a playthrough. Can't wait to see what is next. :3

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

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

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.

Right, what would happen if you just called /c game.player.force.research_all_technologies() ? This would probably caus an error for many things.

Infinite research looks great! I tend to leave my science factory operational in case I add a mod or something that needs research, but the ability to keep it busy and for tangible returns would be very welcome. I'm curious, though. Does only the cost increase, or can the associated bonuses also decrease algorithmically? Something like Bot speed X gives a speed boost equivalent to bot speed (X-1)/2.

Masterfox wrote:Right, what would happen if you just called /c game.player.force.research_all_technologies() ? This would probably caus an error for many things.

Infinite research is a single technology definition. They're simply applied once when "research all" is triggered and remain available to keep researching after that.

Is there a reason why blueprints use a different button sprite for renaming than train stations which already have a perfectly good edit button?
I never really understood the point of that arrow thing. Always looked like a "repeat" button to me.

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

For the pollution Map calculations: you might be able to further optimise it by dividing all the tiles into 60 chunks and always updating one of those chunks. The Advantage is that you don't have to skip so many tiles with each Access which should greatly improve Cache locality and thus give you faster memory Access

Keep up the great work ^^

Thunderbug wrote:For the pollution Map calculations: you might be able to further optimise it by dividing all the tiles into 60 chunks and always updating one of those chunks. The Advantage is that you don't have to skip so many tiles with each Access which should greatly improve Cache locality and thus give you faster memory Access

Keep up the great work ^^

What? "dividing all the tiles into 60 chunks" - chunks are composed of tiles currently. I'm not sure what you're talking about.

How do you plan to do infinite research for normal/stack inserter bonus? This one is slightly different because every level of tech isn't the same.

Rseding91 wrote:

Thunderbug wrote:For the pollution Map calculations: you might be able to further optimise it by dividing all the tiles chunks into 60 and always updating one of those chunks pieces. The Advantage is that you don't have to skip so many tileschunks with each Access which should greatly improve Cache locality and thus give you faster memory Access

Keep up the great work ^^

What? "dividing all the tiles into 60 chunks" - chunks are composed of tiles currently. I'm not sure what you're talking about.

I think what he meant to say is that you should distribute the chunks across the 60 ticks you have, However they/you are already doing that.

Or he's talking about grouping "Idle chunks" together which I dont know how that would help in this scenario.

I hope that blueprints also include the import export of Blueprint String. A lot of other websites use that, and I can't see a reason to not include that part.

I like to have a Goal for researchin and also make a big factor.
Maybe after the vanilla-research you get a new lab wich can do the invenite research, so for the player who like to Research "all-vanilla" there will be a goal for it

Rseding91 wrote:The GUIs used by the core game have far more complex requirements and use cross-GUI logic that would simply not work if done as a mod. Making something like the blueprint library GUI, or the trains GUI a mod is not likely to ever happen.

Because we control the GUI and when it's created, interacted with, and removed we can also make performance optimizations and skip extra checks because we can guarantee the state of the GUI compared to in mods *everything* has to be sanity checked and that slows it down by incredible amounts.

I was thinking more along the lines of the "always on" UI - the minimap, the buttons above it, the info panel below it, the tool/weapon inventory, the quickbar... If modders had the ability to turn those off (well, we already can I think) but then use those LuaGui regions to add our own GUI, I think we could achieve some interesting results without notable performance impacts.

We wouldn't need to interact with what's in the minimap, it would just be this black box GUI element that we could dump in to one of our GUI layouts. Same sort of thing with the "CCTV camera" things that you get in train UI - another black box that we could dump in to our layouts. In both cases, passing either a position or an entity, with optional zoom level, and the map/cctv focuses on that. Is there some way we could at least get something like that to experiment with, under full acceptance that it might be removed prior to final release?

Rseding91 wrote:

Thunderbug wrote:For the pollution Map calculations: you might be able to further optimise it by dividing all the tiles into 60 chunks and always updating one of those chunks. The Advantage is that you don't have to skip so many tiles with each Access which should greatly improve Cache locality and thus give you faster memory Access

Keep up the great work ^^

What? "dividing all the tiles into 60 chunks" - chunks are composed of tiles currently. I'm not sure what you're talking about.

I think he means that each tile's pollution is updated each tick. That would be really impossible.

@Thunderbug: A chunk is 32*32 tiles (1024) and the pollution is a property of a chunk, not a tile.

See https://wiki.factorio.com/index.php?title=Chunk

Rseding91 wrote:

Thunderbug wrote:For the pollution Map calculations: you might be able to further optimise it by dividing all the tiles into 60 chunks and always updating one of those chunks. The Advantage is that you don't have to skip so many tiles with each Access which should greatly improve Cache locality and thus give you faster memory Access

Keep up the great work ^^

What? "dividing all the tiles into 60 chunks" - chunks are composed of tiles currently. I'm not sure what you're talking about.

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.

Zeblote wrote:

Rseding91 wrote:

Thunderbug wrote:For the pollution Map calculations: you might be able to further optimise it by dividing all the tiles into 60 chunks and always updating one of those chunks. The Advantage is that you don't have to skip so many tiles with each Access which should greatly improve Cache locality and thus give you faster memory Access

Keep up the great work ^^

What? "dividing all the tiles into 60 chunks" - chunks are composed of tiles currently. I'm not sure what you're talking about.

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.

Hard to know without the dev's chiming in, but the version they show in the FFF is likely done that way. They don't keep shuffling the pointers forward, they just iterate along. When they hit 59, start back at 0. Sounded like they also only keep 'active' chunks in these buckets as well, so they don't need to touch the inactive ones at all.

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.