Friday facts #151 - The plans for 0.14

[afk2minute]

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.

[brunzenstein]

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 ...

[afk2minute]

Are you talking about Chernobyl meltdown?

[brunzenstein]

Are you talking about Chernobyl meltdown?

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

[steinio]

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

[Req]

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.

[neurofish]

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.

[RobertTerwilliger]

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.

Reactor core

consumes nuclear fuel (which probably shouldn't be just raw uranium)
- has pipe inputs for cold primary coolant AND warm primary coolant (consumes hot one first, then cold one. Hot one will require less energy to heat, obviously)
- has pipe output for hot coolant
- toxic waste pipe output (liquid would make most sense in both gameplay and realism)
It may be only one input for cold/warm coolant, but then we'll need to have some build that will allow us to make mixer which will use warm coolant first, then cold one if warm isn't enough. Yes, we can EASILY do it with circuit&pumps, but not everyone really bothers with circuits at all (I do though )
Recator should produce less hot coolant, than it consumes cold/warm one, so it'll require big coolant investment at start, and then will constantly drain quite lesser amount afterwards. Difference between input and output should be outputted as toxic waste (nuclear fuel should make it's contribution as well).

Primary coolant

is a liquid that is used to transfer huge amount of energy from reactor to secondary coolant (that would need insane pressure to handle all that energy if applied directly)
I'd suggest using IRL coolants like SODIUM, there are many other liquids as well, but this one is more common in complex "nu-clear" reactors.

Heat exchanger

is a simple unit that will cool primary coolant and heat secondary coolant. It will have
- hot primary coolant input
- warm primary coolant output
- cold (and/or) warm secondary coolant input (same mixing problem as at the reactor core)
- hot secondary coolant output

Secondary coolant

is water, obviously, as it evaporates in heat exchanger and moves generator via turbine.

Turbine

is quite same to steam turbine, but will have warm (condensed) coolant output to return part of water to heat exchanger. Since it'll be warm already - it'll further increase nuclear fuel efficiency. It should aslo produce less pollution, as quite a big part of steam is condensed, rather than thrown away into atmosphere.
As an option we may use old turbines, that won't return condensed water, and advanced turbines may be an upgrade gated by technology, however it may result in some annoying useless old turbines (even considering advanced turbine SHOULD be crafted from old ones)
Just like reactor core, turbine should return less water than it consumes to make sure system still drains some water.

scheme from wikipedia

TOXIC WASTE

is something to think about.
All my ideas require some new game mechanics, which isn't that good. E.g., toxic waste always emits radiation AND pollution (in pipes, tanks, even canned in barrels and stored in chest, laying on ground or in player's inventory!), and where radioactivity is over certain limit - it starts inflicting damage to player, vechicles, trees and biters. Armor should increase resistance to radiation, but not give immunity, and behemoth biters should have insane resistance or even be immune.
Radiation should emit pollution as well.
Probably there shouldn't be any way to get rid of toxic waste. Any way of destroying (shooting tank or chest with barrels) should cause devastating (depending on quantity stored) explosion with huge burst-out of pollution amount and probably remains of fallout, that will continue emitting radiation and can be cleared back to barrles (amount will be lesser that before explosion, because part was released as pollution.

Thanks for reading, and sorry for looong post : )

[Neoph]

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?

[Klonan]

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

[Neoph]

Yes i think this is a possibility

A stirling RTG with animated moving parts please

[Escadin]

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....

[mattj256]

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.

[dasiro]

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

[Escadin]

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

[Engimage]

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.

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!

[orzelek]

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.

[Yttrium]

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.

[willtree8]

Spidertron??? Please? Pretty please??

[pr0n]

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.