Factorio Forums

NiftyManiac wrote:Alright, since everyone's been asking, I updated the OP with savefiles and some instructions on playing it. Have fun! Let me know if you do something cool with it or make a gigantic factory... I have no idea what the limits of it are in terms of size.

The project is amazing!
Could you please write a tutorial about creating and using fBasic ?

i have modified the factory to disable the power loss detector at night, so it can be used with day cycle on

EDIT: also added four chain signals to the cell blueprint to prevent gridlocks, so you can use more trains (YAY!)

miturion wrote:Could use the AAI mods to automate biter fighting too.

I'm trying to avoid extra mods, especially ones with "intelligence" like the AAI ones. The challenge of this project is building something within the limitations imposed by the game. At the end of the day, I could write a mod that identified resources, built optimal train routes to them, etc... but that's not as interesting. I think I can deal with biters without mods, but we'll see. Logistic Train Network is already more intelligence than I'd like; for the next iteration I'm thinking of writing my own, more limited mod for commanding trains.

PSS wrote:But where to find main part - fBasic blueprints?

Yeah yeah I'll post them. Just want to polish them up a bit and write a brief guide first.

steinio wrote:Well nice to look at but it looks strictly scripted without making decisions.
How does the base handle biters?
How does the base evolve from starting the game?

It makes decisions just like any computer program or AI. It figures out where there's ore, and places mining infrastructure only where needed. It makes decisions about calling the supply train and building solar fields.
No biters for now. It needs an initial base, which I provided in the save file, to start expanding and become self-sufficient.

DragonHeart996 wrote:i have modified the factory to disable the power loss detector at night, so it can be used with day cycle on

Nice work!

DragonHeart996 wrote:also added four chain signals to the cell blueprint to prevent gridlocks

That's not going to help though, as far as I can tell. The train would already stop at one of two chain signals before the first merge it does. By adding that extra signal at the entrance, the train is just going to stop one car earlier and block the same section of rail. Also, if you change the blueprints don't forget to update resource counts like I describe in the second video; otherwise it could run out of chain signals without calling in a supply train.

NiftyManiac wrote:

DragonHeart996 wrote:also added four chain signals to the cell blueprint to prevent gridlocks

That's not going to help though, as far as I can tell. The train would already stop at one of two chain signals before the first merge it does. By adding that extra signal at the entrance, the train is just going to stop one car earlier and block the same section of rail. Also, if you change the blueprints don't forget to update resource counts like I describe in the second video; otherwise it could run out of chain signals without calling in a supply train.

when waiting at a chain signal, a train will keep checking for alternate paths, so they won't gridlock because the extra chain signal is before the split, meaning they can change the route they are going if the other route is blocked for too long

(I am currently running 50+ trains on the network, without any gridlocks so far)

I've also heavily optimized the belts at the production factory.

DragonHeart996 wrote:

NiftyManiac wrote:

DragonHeart996 wrote:also added four chain signals to the cell blueprint to prevent gridlocks

That's not going to help though, as far as I can tell. The train would already stop at one of two chain signals before the first merge it does. By adding that extra signal at the entrance, the train is just going to stop one car earlier and block the same section of rail. Also, if you change the blueprints don't forget to update resource counts like I describe in the second video; otherwise it could run out of chain signals without calling in a supply train.

when waiting at a chain signal, a train will keep checking for alternate paths, so they won't gridlock because the extra chain signal is before the split, meaning they can change the route they are going if the other route is blocked for too long

Oh cool, didn't know that it'd look for alternatives.

DragonHeart996 wrote:I've also heavily optimized the belts at the production factory.

Yeah, I just kinda threw that part together. As inefficient as they are, they're not the bottleneck; scout speed is . Soon enough all of the production gets fully saturated anyway. (Of course if you want the factory to produce something useful at the same time...)

DragonHeart996 wrote:when waiting at a chain signal, a train will keep checking for alternate paths, so they won't gridlock because the extra chain signal is before the split, meaning they can change the route they are going if the other route is blocked for too long

I thought they only do that at regular signals, and keep their old path on chain signals? Which is also the cause of so many troubles when people try to make stations with multiple loading bays?

Zeblote wrote:I thought they only do that at regular signals, and keep their old path on chain signals?

Just checked, he's right. After a delay a train at a chain signal will take an alternate route if possible. It won't do that at a rail signal, since rail signals are binary; the train will always just wait until the next block is open. With chain signals there's the option to replan.

NiftyManiac wrote:

DragonHeart996 wrote:I've also heavily optimized the belts at the production factory.

Yeah, I just kinda threw that part together. As inefficient as they are, they're not the bottleneck; scout speed is . Soon enough all of the production gets fully saturated anyway. (Of course if you want the factory to produce something useful at the same time...)

but I'm OCD! and it's fun!

P.S. you did have some inserters backwards on the smelting arrays.

NiftyManiac wrote: That's not going to help though, as far as I can tell. The train would already stop at one of two chain signals before the first merge it does. By adding that extra signal at the entrance, the train is just going to stop one car earlier and block the same section of rail. Also, if you change the blueprints don't forget to update resource counts like I describe in the second video; otherwise it could run out of chain signals without calling in a supply train.

I never watched the videos, but I did found the resource count combinators while reverse-engineering the code and changed them.

I've also just added stone to the wood dropoff requester chest after the scout got clogged with it

Hey NiftyManiac,

I didn't actually change anything to your setting, but just wanted to let you know that your automation stops working after finishing the 436th area (including the 9 tiles starting area in the middle). (Tried on the basic save.)

Biter fighting can easly be done with turret creep. Possibly even done by an attack scout. Builder scout can come by and pick up inside walls and move them to the outside.

I am really interested to see how you tackle water. Perhaps rather then using just one scout have each scounted area send out 2 scouts (one continues to wrap around the base and 1 goes out away from the base). This would give you exponential growth. 2 challanges here are what happens if scouts run into a cell that can not make a train station and what happens if a scout runs into a cell that has already been setup.

DragonHeart996 wrote:I've also just added stone to the wood dropoff requester chest after the scout got clogged with it

Oh, I just realized! That confused me when I was building it... I just figured I left some stone lying around accidentally that it picked up. I completely forgot that deconstructed rocks will turn into stone. Good catch.

Nich wrote:Biter fighting can easly be done with turret creep. Possibly even done by an attack scout. Builder scout can come by and pick up inside walls and move them to the outside.

Correct. I'd really like to take a different approach though, moving the defensive perimeter outwards in all directions. Partly because it'd be a different challenge, and partly cause that'd be quadratic growth if done properly. The corners will need to do some kind of self-replication for that though so oil is a prerequisite.

Nich wrote:I am really interested to see how you tackle water.

My current plan is to replace the hard-coded spiral behavior and use a wall-following algorithm instead. Normally it could left-hand wall-follow the existing cells, and if it hits water it'd wall-follow around all impassible cells in the same way. This could also make multiple scouts easier.

Seru wrote:I didn't actually change anything to your setting, but just wanted to let you know that your automation stops working after finishing the 436th area

You can't leave it at that! Any screenshots of the massive result? If you upload a save I can try to figure out what went wrong. I've already got one bug report relating to tree deconstruction I don't know how to fix, and then there's stone clogging which is an easy fix as DragonHeart mentioned. Ideally we can get this factory to the point that it only stops when you run out of memory . If anyone who makes improvements wants to share a starter factory, I'll keep the "best" version linked in the OP (or make your own post or whatever).

really nice, and it mostly works well.
the smelters and assemblers could get some upgrades to work faster, but mostly the main bus (single red belts for iron, copper and steel) seem to be the bottleneck. i have modified the basic factory with creative mode :-) and after upgrading to assembler mk3 (and smelters) with speed3 modules and blue belts for the main bus (some parts even double blue belts) and also adding more green circuit assemblers, nothing has to wait any longer :-)

but while looking at some more details near the requester station, i saw that they have several problems (not gamebreaking, but ugly and/or harmless bugs):

- LTN only considers a delivery order to be finished when the train is back again at any depot. since you have only one depot, 1 train finishes properly, and the other 4 trains are waiting with unfinished orders after unloading. to fix that, you can add a depot right behind each single requester stop instead of having one common depot for all trains, so that (after unloading) trains can advance 2 tiles to the depot and properly finish their LTN order.

- currently, you don't notice the effect since trains leave the depot and get new orders often enough, and thus no timeout is shown. but i think that these many orders are mostly caused by the "strange" programming of the requester stations. is that intended (see below)?

- you have 8 requester chests for every resource, resulting in 19200 storage in those chests, and you also have set this exact amount as the goal. when the current amount is below a threshold, you send the signal for requesting items to the requester stations which you have chained. thus all five stations have a request for 1k resources when they really need 1k total only. this causes all 5 trains to be sent to get a delivery of 1k each (and the same resource for all trains!) when it might be good enough to send 1 or 2 trains only, and then send the 3rd train for another resource. THIS is also the reason why trains get no timeout: even when only one train is needed (and the other trains could wait, and then get a timeout), all 5 get orders.
depending on how fast the trains return and how much is used in the meantime, the network can end up with up to 24k+. this is not harmful since you have 4x8 storage chests which can buffer the additional 4x4k+, but is this intended?

- the storage chests are located next to the requester chests, but they will get random resources when buffering, and thus eg copper can end up on the opposite side next to iron, requiring bots to fly back and forth an additional unnecessary time. by chaining more requester chests (eg simply having one new requester behind each existing requester, with an inserter between them, instead of two rows of storage chests), resources would immediately be stored near the correct belt. and if you don't send all trains to get 5x1k instead of few trains to get what is really needed for 19200, you wouldn't have any such surplus at all, and thus not need the additional storage chests as buffer.

I thought they only do that at regular signals, and keep their old path on chain signals?

After a delay a train at a chain signal will take an alternate route if possible.
It won't do that at a rail signal, since rail signals are binary; ...

binary? you mean only red and green!? indirectly yes, but the real scandalreason is that a waiting train at a normal signal never has alternatives but must go through that signal, and thus repathing makes no sense for that train. but for a waiting train in front of a blue chain signal there is a split with the planned route red, but at least a second route with a green signal exists that can be checked whether it leads to the same destination. i don't know whether trains only check on blue or also on red chain signals, but checking on red and green chain signals would make no sense (just like at normal signals).

NiftyManiac wrote:

Seru wrote:I didn't actually change anything to your setting, but just wanted to let you know that your automation stops working after finishing the 436th area

You can't leave it at that! Any screenshots of the massive result? If you upload a save I can try to figure out what went wrong. I've already got one bug report relating to tree deconstruction I don't know how to fix, and then there's stone clogging which is an easy fix as DragonHeart mentioned. Ideally we can get this factory to the point that it only stops when you run out of memory . If anyone who makes improvements wants to share a starter factory, I'll keep the "best" version linked in the OP (or make your own post or whatever).

i found an issue when factorio gave the supply station the same backer name as an existing station, which made logistic train network mark it as a duplicate. it's not something you can fix, but i think LTN makes the station output a signal when that happens, so maybe you could detect that and re-build the station when that happens?

also, i found the issue with the trees: your power poles are only in construction range of the scout if the new copy's roboports still have power, so if trees take too long to deconstruct, the port loses power and will never regain it. then there is the fact that occasionally trees are just outside construction range but still in the way, so i reccomend expanding construction range by two tiles to fix it

Anson wrote:

I thought they only do that at regular signals, and keep their old path on chain signals?

After a delay a train at a chain signal will take an alternate route if possible.
It won't do that at a rail signal, since rail signals are binary; ...

binary? you mean only red and green!? indirectly yes, but the real scandalreason is that a waiting train at a normal signal never has alternatives but must go through that signal, and thus repathing makes no sense for that train. but for a waiting train in front of a blue chain signal there is a split with the planned route red, but at least a second route with a green signal exists that can be checked whether it leads to the same destination. i don't know whether trains only check on blue or also on red chain signals, but checking on red and green chain signals would make no sense (just like at normal signals).

trains repath whenever they reach/pass/are waiting at any signal, to compensate for other traffic since the initial departure, but the only time this makes a difference in terms of gridlocks is at a blue chain signal, because this is the only time that there are two independent paths to choose from. all other times either all paths are blocked (red), or all paths are open (green), and it makes no difference which path the train chooses.

you can see this if you ride in a train at max zoom while hovering over it - occasionally, as the train passes or waits at any signal, the route will change. normally this is a small change like trying (and failing) to pass another train by detouring through an inline station/siding. other times this change is to choose to enter another lane in a stacker than the one it initially planned to enter (because the other one filled up). i have abused this property to make a train that never reaches it's station by making it path to a station with the same name on the other end of a loop using circuits to block the closer one, then repeating at the other end, ad infinitum. my setup used zero chain signals.

NiftyManiac wrote:

Seru wrote:automation stops working after finishing the 436th area

I've already got one bug report relating to tree deconstruction ...

on the reddit they wrote that the stopped map was 21x21 ...
that would be 441 (or shortly before that), and the other stopped at 436 ...
maybe both stops have the same cause ?
the reason might be some unlucky combination of low power, a skipped instruction because of that, etc.
to check the exact cause, the map would have to be rerun again, with a breakpoint after 433 or 434 ... :-)

fix as always is recommended by service technicians, first do a reset of your computer (the virtual one, of course), and see if the problem vanishes by itself :-) LOL

edit: what DragonHeart996 wrote in the meantime sound very plausible. fix would be to first build the two near roboports, then the center, and then the far roboports (and on each step the corresponding power poles too), thus guaranteeing that they always are powered !?

Anson wrote:

NiftyManiac wrote:

Seru wrote:automation stops working after finishing the 436th area

I've already got one bug report relating to tree deconstruction ...

on the reddit they wrote that the stopped map was 21x21 ...
that would be 441 (or shortly before that), and the other stopped at 436 ...
maybe both stops have the same cause ?
the reason might be some unlucky combination of low power, a skipped instruction because of that, etc.
to check the exact cause, the map would have to be rerun again, with a breakpoint after 433 or 434 ...

fix as always is recommended by service technicians, first do a reset of your computer (the virtual one, of course), and see if the problem vanishes by itself LOL

the program will never skip instructions - it only moves on once the previous instruction was completed.

i have had a fair few lock-ups on my map, and every time the cause is the poor placement of large power poles, in combination with many trees draining roboports too fast.

DragonHeart996 wrote:every time the cause is the poor placement of large power poles, in combination with many trees draining roboports too fast.

as i just had edited my last message:
edit: what DragonHeart996 wrote in the meantime sounds very plausible. fix would be to first build the two near roboports, then the center, and then the far roboports (and on each step the corresponding power poles too), thus guaranteeing that they always are powered !?

or maybe as temp fix: build a single solar cell next to the center. it would take ages to power the roboports with it, but eventually the bots have enough power to build the poles and do a proper connection, and the whole system wouldn't be stopped forever.

Anson wrote:

DragonHeart996 wrote:every time the cause is the poor placement of large power poles, in combination with many trees draining roboports too fast.

as i just had edited my last message:
edit: what DragonHeart996 wrote in the meantime sounds very plausible. fix would be to first build the two near roboports, then the center, and then the far roboports (and on each step the corresponding power poles too), thus guaranteeing that they always are powered !?

or maybe as temp fix: build a single solar cell next to the center. it would take ages to power the roboports with it, but eventually the bots have enough power to build the poles and do a proper connection, and the whole system wouldn't be stopped forever.

it's not order. it's that in order to place the pole to power the roboport, said roboport must have power. the fix: move the pole to the external side of the cell relative to the roboport, rather than the internal side. then the pole is in range of the roboports of the previous cell