Factorio Forums

FactorioBot wrote:

• Minor Features
  • Holding the "drop item" key will keep dropping items.
  • Rocks can be mined while holding blueprints.

• Great!
• Why not everything else? It's really annoying to not be able to remove items that are in the way of blueprints. And rocks are marked for deconstruction when shift placing anyways so you don't need to mine rocks as much as everything else. I wish I could mine and autodeconstruct anything that is in the way of my blueprints.

[/list]

As always, Awesome work guys, loving the updates!!
Great to see "Holding the "drop item" key will keep dropping items." was implemented, as it will make testing setups and potential bugs by manually dropping a steam of items much easier - thanks!

Qon wrote:

FactorioBot wrote:

• Minor Features
  • Holding the "drop item" key will keep dropping items.
  • Rocks can be mined while holding blueprints.

• Great!
• Why not everything else? It's really annoying to not be able to remove items that are in the way of blueprints. And rocks are marked for deconstruction when shift placing anyways so you don't need to mine rocks as much as everything else. I wish I could mine and autodeconstruct anything that is in the way of my blueprints.

[/list]

You know you can force place a blueprint by holding down shift?

When you do this trees are automatically removed (not sure about rocks). Anything else in the way just means that entity is not placed so you then fine tune accordingly.

ChurchOrganist wrote:

Qon wrote:

• Great!
• Why not everything else? It's really annoying to not be able to remove items that are in the way of blueprints. And rocks are marked for deconstruction when shift placing anyways so you don't need to mine rocks as much as everything else. I wish I could mine and autodeconstruct anything that is in the way of my blueprints.

You know you can force place a blueprint by holding down shift?

When you do this trees are automatically removed (not sure about rocks). Anything else in the way just means that entity is not placed so you then fine tune accordingly.

That is what I said.

Qon wrote:

ChurchOrganist wrote:

Qon wrote:

• Great!
• Why not everything else? It's really annoying to not be able to remove items that are in the way of blueprints. And rocks are marked for deconstruction when shift placing anyways so you don't need to mine rocks as much as everything else. I wish I could mine and autodeconstruct anything that is in the way of my blueprints.

You know you can force place a blueprint by holding down shift?

When you do this trees are automatically removed (not sure about rocks). Anything else in the way just means that entity is not placed so you then fine tune accordingly.

That is what I said.

If you mean shift blueprint should also remove entities other than trees and rocks, then I have to second that. It will be convenient to clean up temporary early setups for larger and more efficient setups.

Qon wrote: That is what I said.

Oops! I misread your post

I'm not sure you'd want that behaviour all the time - maybe if you could use CTRL+SHIFT when placing a blueprint to force remove entities other than trees and rocks???

ChurchOrganist wrote:

Qon wrote: That is what I said.

Oops! I misread your post

I'm not sure you'd want that behaviour all the time - maybe if you could use CTRL+SHIFT when placing a blueprint to force remove entities other than trees and rocks???

But I can't find any reason why you want to shift place a blueprint but allow some parts of it being blocked by existing entities.

ChurchOrganist wrote:

Qon wrote: That is what I said.

Oops! I misread your post

I'm not sure you'd want that behaviour all the time - maybe if you could use CTRL+SHIFT when placing a blueprint to force remove entities other than trees and rocks???

Yes, that would be good. I don't want to lose the current shift+place behaviour, I want to add a new one.
I use the current shift+place a lot also.

Would be nice with some way to easily move structures also. Currently it's blueprint mark it -> exit blueprint -> mark and deconstruct the sam thing -> pick up your blueprint again -> place it. And marking the same things twice might be difficult for big structures. Way to often that I need to shift thousand things 1 tile and spend half a minute doing it when it could take a few seconds.

Mooncat wrote: But I can't find any reason why you want to shift place a blueprint but allow some parts of it being blocked by existing entities.

It's actually useful for blueprints that start one way but have a repeating part that is different and still use one blueprint for it. But maybe I mostly use it to place blueprints and then manually deleting the collided entities and then manually filling in the blueprint, so it will be less useful once we can autodeconstruct anything when placing.

Mooncat wrote:

ChurchOrganist wrote:

Qon wrote: That is what I said.

Oops! I misread your post

I'm not sure you'd want that behaviour all the time - maybe if you could use CTRL+SHIFT when placing a blueprint to force remove entities other than trees and rocks???

But I can't find any reason why you want to shift place a blueprint but allow some parts of it being blocked by existing entities.

3x3 plan, power pole in the center and 8 laser turrets around the outside. If you place it alone, it makes a little turret outpost. If you place it outside a wall or mining outpost or whatnot, with 3 of the turrets placed over the already-placed entities, it makes a 5-turret ... well it makes a turret. But anyway, in that case I wouldn't want the blueprint to overwrite what I'd placed before. Nor would I want to have to hold on to 5 blueprints just to be able to account for all 5 situations. Especially because maybe I'd want to place them on corners, making even more blueprints necessary.

Ah, yes. I forgot that without Shift, you can't even place the blueprint if it collides with any entity.

Wait... did anyone notice.... 2000km x 2000km = 2M * 2M tiles = 4000000000000 square tiles. = 4x10^12!!!

I have just 8 gigs of ram. If every tile took up a single bit this wouldn't be enough by far. You would need 465 giga byte.

Now I am reeaaaly curious how you guys store the map in ram. There has to be some major compression going on (I'm thinking winrar in realtime )


What happens if I put an inserter on all of them

Jupiter wrote:Wait... did anyone notice.... 2000km x 2000km = 2M * 2M tiles = 4000000000000 square tiles. = 4x10^12!!!

I have just 8 gigs of ram. If every tile took up a single bit this wouldn't be enough by far. You would need 465 giga byte.

Now I am reeaaaly curious how you guys store the map in ram. There has to be some major compression going on (I'm thinking winrar in realtime )


What happens if I put an inserter on all of them

Only chunk which have entities to be updated (factory), chuck loaded by radar visible area, area covered with pollution and some chunk arround it are loaded. Even if you discover area 1000km away from your base, if you don"t build anything and go back, this area will be unloaded at some point and not loaded back until you go there again. No need to load chunk of map where nothing happen.

If you put inserter at interval all over the map (that's a lot of inserters), I think you will crash factorio by trying to use to many RAM.

Neemys wrote:

Jupiter wrote:Wait... did anyone notice.... 2000km x 2000km = 2M * 2M tiles = 4000000000000 square tiles. = 4x10^12!!!

I have just 8 gigs of ram. If every tile took up a single bit this wouldn't be enough by far. You would need 465 giga byte.

Now I am reeaaaly curious how you guys store the map in ram. There has to be some major compression going on (I'm thinking winrar in realtime )


What happens if I put an inserter on all of them

Only chunk which have entities to be updated (factory), chuck loaded by radar visible area, area covered with pollution and some chunk arround it are loaded. Even if you discover area 1000km away from your base, if you don"t build anything and go back, this area will be unloaded at some point and not loaded back until you go there again. No need to load chunk of map where nothing happen.

If you put inserter at interval all over the map (that's a lot of inserters), I think you will crash factorio by trying to use to many RAM.

You are not correct.

Indeed, after a bit of research I found that : viewtopic.php?p=3543#p3543

kovarex wrote:All generated chunks are active all the time.Providing event like "chunk-generated" could help.

So yes I was wrong, thanks for pointing that

Neemys wrote:Indeed, after a bit of research I found that : viewtopic.php?p=3543#p3543

kovarex wrote:All generated chunks are active all the time.Providing event like "chunk-generated" could help.

So yes I was wrong, thanks for pointing that

Then what is the "show_active_chunks" debug view option for?

All chunks use RAM.
Active chunks use RAM and CPU.

DaveMcW wrote:All [generated] chunks use RAM.
Active chunks use RAM and CPU.

kovarex wrote:All generated chunks are active all the time.

@DaveMcW
But if the set of all chunks generated is the same as the set of all active chunks then the "active" distinction is fairly meaningless, no? Or are you saying the quote from kovarex 2013 is not applicable for todays version? Or are you responding to someone else? Because your statement fails to adress my question and doesn't quote anyone.

show_active_chunks = chunks that use CPU

kovarex was referring to chunks that use RAM.