Factorio Forums

but its very unlikely to happen (even if it happens there is a containment building etc).
Nothing (even car engine or robot) breaks in factorio by itself. There is 0 reason to introduce very different mechanic to the game.

afk2minute wrote:but its very unlikely to happen (even if it happens there is a containment building etc).
Nothing (even car engine or robot) breaks in factorio by itself. There is 0 reason to introduce very different mechanic to the game.

I saw the leaking and steaming containment buildings in Russia.
Don't trust ever that nature will not take its course ...

Are you talking about Chernobyl meltdown?

afk2minute wrote:Are you talking about Chernobyl meltdown?

No. I talk about the many sites the media never gets access to.

What's about the seemless mod integration mentioned in a fff earlier?

The developers promised that the game don't need to restart after installing new mods.
Also the data.lua phase should be moved to game state and not loaded at startup anymore.

Just want to remember

Tl:dr thread so it's possible someone already posted it but here goes anyway.

Nuclear power: uranium need to be reprocced before use, will result in both fuel and waste. The powerplant will also produce waste. The plant MUST have full water supply or it will blow up. Nuclear plants take time to start/stop and will cost power before its ip and running.

Rain: sometimes it rains on the planet which emphasise growth of trees if no concrete floor is present. Flashes can damage structures and disturb electric distribution. Hence you can't rely only on laser turrets.

Rocket in single player: more components and can only be produced at specific sites = to build a rocket multiple stages must be completed. The rocket will take you home.

PKing Zombie Spy wrote:

neurofish wrote:I haven't such a construction just now, but i think, it can be interesting to design it.

Could you please?

So the reason why I'm asking is that there was a specific claim made that this would be easy to do, and would ruin the game. It's unclear to me that it is easy, and my suspicion is that you might have just gotten a bit ahead of yourself in claiming something difficult was easy (as I myself have often done ) but I wanted to give you a chance to demonstrate it.

Such a provocation
I do not want imitate ability of assembler to change recipe: it is hard to do properly without knowledge how it will be realised in 0.14. When 0.14 with this recipe-changers be released i do mentioned construction.

Nuclear power plant should be inspired by IRL one. It also should be somewhat complex build, otherwise it'll be just mindless super-puper-item plonking.
I believe it should consist of 2-3 stages piped together (like steam power plant, but more complex) e.g.:

Double thermal circuit system (Inspired by IRL one):

[Reactor core] <===(primary coolant)===> [Heat exchanger] <===(secondary coolant)===> [Turbine(s)]

Unit quantity ratio may be not 1:1:1. Let it be, say, 1:3:3, or 1.5:5:3, or any another to make something to play with.
Thanks for reading, and sorry for looong post : )

Don't know if anyone mentioned it already, but if we are indeed going nuclear, i would like large stationary RTG's, which would be pretty simple, a entity like any other that generates a X amount of power for Y time, considerably less efficient than a full reactor and if possible with power output decay as time passes, to use in outposts and such, and give-me the high resolution pack... i didn't know it was even being discussed, but after seeing the difference... i simple can't take it of my head, i need it. And to RobertTerwilliger, going direct to a pool type molten sodium reactors isn't a little bit overkill? starting with a simpler BWR or PWR is a little easier don't you think?

Neoph wrote:Don't know if anyone mentioned it already, but if we are indeed going nuclear, i would like large stationary RTG's, which would be pretty simple, a entity like any other that generates a X amount of power for Y time, and if possible if power output decay as time passes, to use in outposts and such, and give-me the high resolution pack... i didn't know it was even being discussed, but after seeing the difference... i simple can't take it of my head, i need it. And to RobertTerwilliger, going direct to a pool type molten sodium reactors isn't a little bit overkill? starting with a simpler BWR or PWR is a little easier don't you think?

Yes i think this is a possibility

Klonan wrote:Yes i think this is a possibility

A stirling RTG with animated moving parts please

Following these last two FF I'm suddenly more interest into the game's development than the game itself.

No, it is not a sudoku , all the chunks with number 1 can be updated at the same time, as long as the logic doesn't change anything further than the neighbour chunks. Then we update chunks 2, 3 up to 9. We don't really have to wait for all of the 1s to be finished to start 2, but I don't want to run into details.

I honestly wish you would go into more detail on some topics because there are just so many things I would like to know as I'm tyring to wrap my head around parallel programming. For example, did you consider letting the GPU calculate part of your update logic seeing as you already devided the map / chunks / tiles into grid / thread blocks / threads? Oh well I can only imagine there would be way too many control flow statements.

Not to mention I'm dieing to know why 2 is not dependent on 1....

Escadin wrote:Not to mention I'm dieing to know why 2 is not dependent on 1....

From the FFF:

The first testing entity that will be ran in parallel is inserter. The selection is logical, they are tens of thousands of inserters in Factories regularly, they are usually one of the most cpu hoggers right after belts and they have limited operational range, meaning, one inserter can't directly access something 2 chunks away.

I think it's clear from context: this algorithm is only applied to inserters. You have chunks (32x32) tiles which are subdivided into 3x3 regions. Then you go through all the tiles labeled 1, looking only for inserters. I just realized now (as I'm talking about it) that a long-handed inserter has a reach of two tiles, so the sudoku grid has to be 3x3 rather than 2x2.

all the chunks with number 1 can be updated at the same time, as long as the logic doesn't change anything further than the neighbour chunks. Then we update chunks 2, 3 up to 9.

Kovarex also mentions some complications like the circuit network. If an inserter is hooked up to the circuit network it may affect other items that are far away. In the simple case (ignoring circuit network and logistic network) it seems clear to me that an inserter won't affect anything three tiles away.

mattj256 wrote:it seems clear to me that an inserter won't affect anything three tiles away.

2 tiles away in one direction and 2 away in the other when we're talking long handed inserters so a total span of 5 tiles

mattj256 wrote: I think it's clear from context: this algorithm is only applied to inserters. You have chunks (32x32) tiles which are subdivided into 3x3 regions. Then you go through all the tiles labeled 1, looking only for inserters. I just realized now (as I'm talking about it) that a long-handed inserter has a reach of two tiles, so the sudoku grid has to be 3x3 rather than 2x2.

First of all I can only guess what a tile is and my guess is the easy answer would be:
1 tile is a small part of the map that is just just large enough to either have an inserter in it, to offer the space for placing an inserter, to contain all the entities an inserter can grab or to offer all the space an inserter can move entities to.

If that's the case then I don't see why in a 3x3 grid no inserter of the same number will conflic with it's neighbours.



#1 could be a long-arm inserter which moves things to #7 while the #1 in one grid below takes things from #7 one grid above it. If we're talking just normal inserters then fine there is no conflict... vertically. However, a #1 inserter can still move things from #3 to #2 and yet he says "We don't really have to wait for all of the 1s to be finished to start 2". You can't work on #2 while you're working on #1 at the same time. It would make more sense if he just meant they don't need a barrier synchronization that stops all threads working on #1's until the last one is done before these threads can move on to #2's. However, then again If your #2 inserter grabs something from #3 while the neighbour thread is still handling his #1 which also grabs from the same #3 to it's left...
The fact alone that every thread requires data from grids that belong to somebody else is fishy to me. Passing that data around in it's updated form is something you'd want to avoid normally if I understood that much at least. That said, they could just work the map as it is and make updated tile data an issue of the next game tick. I mean would it matter if #2 places something on #3 but doesn't tell #1 (right neighbour grid)? #1 Should get the new tiles data next game tick and act on it then.

Perhaps the issue is I have no idea how inserters actually work game-logic wise

This is one of the most hyped thread for several months

I just have to throw in a couple of my thoughts on details.

1. Circuit network.
In the poll the idea about radars sounds like "The # of enemies nearby" but the actual target of idea was to trigger defences when enemies approach so the output should be "distance to closest enemy"

2. Liquid tanker.
Loading/unloading mechanism should have a "filter" to prevent liquids mixing. Like a smart inserter - only transfer selected liquid.

3. Nuclear power.
You may invent whatever complex process you like. But in the end it is a complex boiler and a steam turbine. Please do introduce them as separate entities so you can use steam turbine with alternate boilers but being much more effective from a space perspective. You might however introduce new type of solid fuel high-temperature boilers allowing heating steam to the same grade as nuclear boiler does but using common fuel. These boilers might even be 3x3 size and alongside steam turbine might make use of modules.

YoggYG wrote:Another thing that would be nice is to have the ability to dig up the landfill that the player placed. Not necessarily the ability to create water, but only to recreate water where at some point there was water. Maybe this is possible by having the landfill not create dirt/soil, but a bridge type surface? This makes it clear that the water is still present, but that the surface now is buildable. This also would make it really clear which tiles can be converted back into water (just mine/deconstruct the "bridge" flooring, which obviously should not be possible if a structure is placed on top of it).

These are some of the ideas I had in the past weeks that I can think of right now. It this comment seems rambly and incoherent then I'm sorry. It's 2:30 AM right now and I really need to sleep.

I would prefer landfill being replaced by concrete bridge-like flooring which could be handled just like common floorings work but it can be placed on the water and you can walk/build on it. Landfill as it is leaves you no way back.

P.S. Thumbs up devs! Keep up the good work on the one of most exciting games I ever met!

Escadin wrote:


Perhaps the issue is I have no idea how inserters actually work game-logic wise

You are confusing two things here.
Grid above is in chunks aka 32x32 tiles each.
Using grid like this gives a guarantee that inserter from chunk number 1 will not collide with any inserter from other chunks numbered as 1. Since there are at least 2 chunks between them even if inserter is near border of chunk it can only affect it's direct neighbour. This nets the effect that when processing inserters in same numbered chunks you won't try to modify same entities in parallel.
It needs some special handling for stuff that can span chunks like wire networks and logistic networks to prevent collisions there.

Would love the nuclear update! its a good fit, we already have "easy to setup, low risk coal power" "Costly, lots of room, no risks solar panels." now we need something that consumes alot of power and generates alot of power for the ones that feel more lucrative.

Spidertron??? Please? Pretty please??

I love the idea of nuclear but I think it shouldn't manage itself. It should be a requirement to use a basic circuit to manage it. Like managing control rod position and water/steam flow. If you've played the big reactors mod in minecraft I really think that's the right way to do it. If you could separate the components like the reactors and turbines and then connect them with pipes etc I think it would make for a very interesting design problem that would be enjoyable to solve and scale.

You could even just use the turbines in place of steam engines in a simple boiler->steam engine build, make them able to handle a higher flow or higher temperatures than the steam engines it would allow for the basic steam setup to be more scalable while also introducing nuclear which would replace the boilers in later game.

I think this is a good chance to make something really interesting, a single building with dumb input and output would be a waste.