[WIP][0.12.22+] Subsurfaces 0.0.4 : build beneath your base

[StanFear]

all ontick functions have been surrounded with the appropriate associative_table_count check similaraly to digging_robots_manager(event).

This is a bad idea. Rather than an optimization, this is an anti-optimization.

Code: Select all

if associative_table_count(t) ~= 0 then
    for k, v in pairs(t) do
        --do some stuff
    end
end

has strictly worse performance than just

Code: Select all

for k, v in pairs(t) do
    --do some stuff
end

this is because the associative_table_count version is equivalent to

Code: Select all

function waste_some_time (t)
    local time_to_waste = 0
    for k, v in pairs(t) do
        time_to_waste = time_to_waste + 1
    end
    return time_to_waste ~= 0
end

if waste_some_time(t) then
    for k, v in pairs(t) do
        --do some stuff
    end
end

Note how if the table is empty, you're doing the same loop setup and termination check in either case, but have added the overhead of a function call, a variable assignment, and a comparison. On the other hand, if the table isn't empty, you've added the overhead of a function call, a comparison, and an additional complete loop through the entire table (with variable assignments at each step). And by doing all this extra work, you've gained... absolutely nothing in return.

TL;DR: only use associative_table_count if you absolutely need to know how many things are in the table. If you just need to check if it's empty, replace

Code: Select all

if associative_table_count(t) ~= 0 then

with

Code: Select all

if next(t) then

or

Code: Select all

if associative_table_count(t) == 0 then

with

Code: Select all

if not next(t) then

or ask yourself if checking for emptiness is even necessary in this case (for the use case in question, it's probably better to just let the loop terminate because there are no elements to loop through than to throw in a separate emptiness check).

OK, that's a fair point ...thanks for making me see that !
although in the next version it shouldn't even be necessary

...

actually, calling a function is really bad ?
my refactoring into classes, each capable of handling events might not be a good idea then ... (performance wise at least, because I find it much clearer to read!)

[Exasperation]

Calling a function isn't really bad, it's a very small amount of overhead. It's just that in this case, you're calling a function that you don't need to call, so you're doing a small amount of work just for the heck of it. The part that's potentially really painful is the case where you actually have a large number of elements in the table. Say you've selected a 100x100 area to be mined out and you call associative_table_count(global.marked_for_digging) ~= 0. Now, suddenly you've added 10,000 unnecessary count = count +1 assignments, as well as 10,000 unnecessary k,v = next(global.marked_for_digging, k) assignments, 10,000 unnecessary k ~= nil comparisons... this is a lot of overhead, and after you've done it you're just going to find that the table isn't empty and you have to loop through the table again to do the actual work.

associative_table_count isn't dangerous for performance because it's a function, but because it has a (potentially very large) loop inside of it.

[StanFear]

Calling a function isn't really bad, it's a very small amount of overhead. It's just that in this case, you're calling a function that you don't need to call, so you're doing a small amount of work just for the heck of it. The part that's potentially really painful is the case where you actually have a large number of elements in the table. Say you've selected a 100x100 area to be mined out and you call associative_table_count(global.marked_for_digging) ~= 0. Now, suddenly you've added 10,000 unnecessary count = count +1 assignments, as well as 10,000 unnecessary k,v = next(global.marked_for_digging, k) assignments, 10,000 unnecessary k ~= nil comparisons... this is a lot of overhead, and after you've done it you're just going to find that the table isn't empty and you have to loop through the table again to do the actual work.

associative_table_count isn't dangerous for performance because it's a function, but because it has a (potentially very large) loop inside of it.

ok, thanks for the clarification!

[Vas]

Is this multiplayer ready? I'd like to use it as a subway system.

The plan being, I drill into the ground at the base, and drill into the ground at a far away ore pocket, then I use the minimap/map underground to find where I dug a hole at and drill my way through the ground with the tunneling vehicle, and then I proceed to lay my tracks out and set up my ore to a conveyor that takes it underground and it then gets loaded onto the train.

[Szentigrade]

Is this multiplayer ready? I'd like to use it as a subway system.

The plan being, I drill into the ground at the base, and drill into the ground at a far away ore pocket, then I use the minimap/map underground to find where I dug a hole at and drill my way through the ground with the tunneling vehicle, and then I proceed to lay my tracks out and set up my ore to a conveyor that takes it underground and it then gets loaded onto the train.

we are using it multiplier atm for that exact thing running trains underground is fun
pics: http://imgur.com/a/Oj3LB

[Simcra]

all ontick functions have been surrounded with the appropriate associative_table_count check similaraly to digging_robots_manager(event).

This is a bad idea. Rather than an optimization, this is an anti-optimization.

Code: Select all

if associative_table_count(t) ~= 0 then
    for k, v in pairs(t) do
        --do some stuff
    end
end

has strictly worse performance than just

Code: Select all

for k, v in pairs(t) do
    --do some stuff
end

this is because the associative_table_count version is equivalent to

Code: Select all

function waste_some_time (t)
    local time_to_waste = 0
    for k, v in pairs(t) do
        time_to_waste = time_to_waste + 1
    end
    return time_to_waste ~= 0
end

if waste_some_time(t) then
    for k, v in pairs(t) do
        --do some stuff
    end
end

Note how if the table is empty, you're doing the same loop setup and termination check in either case, but have added the overhead of a function call, a variable assignment, and a comparison. On the other hand, if the table isn't empty, you've added the overhead of a function call, a comparison, and an additional complete loop through the entire table (with variable assignments at each step). And by doing all this extra work, you've gained... absolutely nothing in return.

TL;DR: only use associative_table_count if you absolutely need to know how many things are in the table. If you just need to check if it's empty, replace

Code: Select all

if associative_table_count(t) ~= 0 then

with

Code: Select all

if next(t) then

or

Code: Select all

if associative_table_count(t) == 0 then

with

Code: Select all

if not next(t) then

or ask yourself if checking for emptiness is even necessary in this case (for the use case in question, it's probably better to just let the loop terminate because there are no elements to loop through than to throw in a separate emptiness check).

Ok, what I'm trying to achieve with that is testing whether or not the table is empty. I thought there was a better way to do it but was not sure how to go about it. So you're saying do this?

Code: Select all

function table_not_empty(table)
	if next(table) then
		return true
	else
		return false
	end
end

[Exasperation]

Ok, what I'm trying to achieve with that is testing whether or not the table is empty. I thought there was a better way to do it but was not sure how to go about it. So you're saying do this?

Code: Select all

function table_not_empty(table)
	if next(table) then
		return true
	else
		return false
	end
end

You could do that, or you could just do the following:

Code: Select all

if next(table) then
    --the stuff in here will only be executed if the table is non-empty
end

But if the operations you want to perform on the table are in a for...pairs loop, you might as well just do this:

Code: Select all

for k, v in pairs(table) do
    --the stuff in here will only be executed if the table is non-empty
end

and it will work out basically the same as if you had wrapped the loop in a "if next(table) then" conditional, since the first thing the loop will do is call next(table) and exit the loop without doing anything if the table was empty - the work you expend to check for emptiness is about the same as the work you save by not letting the loop do it (I think it's very slightly more efficient to do the check yourself if the table is empty, but it's certainly slightly less efficient to do it yourself if the table isn't empty, since the loop will then have to duplicate the same not-empty check unnecessarily).

[StanFear]

Is this multiplayer ready? I'd like to use it as a subway system.

The plan being, I drill into the ground at the base, and drill into the ground at a far away ore pocket, then I use the minimap/map underground to find where I dug a hole at and drill my way through the ground with the tunneling vehicle, and then I proceed to lay my tracks out and set up my ore to a conveyor that takes it underground and it then gets loaded onto the train.

I didn't test the multiplayer with my mod, but when programming it, I tried to handle most cases, but I might have forgotten some cases, so you should be able to use it (it shouldn't break everything) but bare in mind that MP is not tested by me

[Simcra]

Ok, what I'm trying to achieve with that is testing whether or not the table is empty. I thought there was a better way to do it but was not sure how to go about it. So you're saying do this?

Code: Select all

function table_not_empty(table)
	if next(table) then
		return true
	else
		return false
	end
end

You could do that, or you could just do the following:

Code: Select all

if next(table) then
    --the stuff in here will only be executed if the table is non-empty
end

But if the operations you want to perform on the table are in a for...pairs loop, you might as well just do this:

Code: Select all

for k, v in pairs(table) do
    --the stuff in here will only be executed if the table is non-empty
end

and it will work out basically the same as if you had wrapped the loop in a "if next(table) then" conditional, since the first thing the loop will do is call next(table) and exit the loop without doing anything if the table was empty - the work you expend to check for emptiness is about the same as the work you save by not letting the loop do it (I think it's very slightly more efficient to do the check yourself if the table is empty, but it's certainly slightly less efficient to do it yourself if the table isn't empty, since the loop will then have to duplicate the same not-empty check unnecessarily).

Thanks for clarifying that, that clears up a few things for me.

[Lutra]

i don't mean to steal your work, but i was planning on making a mod that uses surfaces in a similar way to this. what i can't understand(and i've checked the control.lua of your mod) is how to check when the player is standing next to the elevator, and then to teleport them. this is a great mod by the way-i use it a lot for smelting machines: ore and coal go in one end and plates come out the other, in the space of an assembling machine

[StanFear]

i don't mean to steal your work, but i was planning on making a mod that uses surfaces in a similar way to this. what i can't understand(and i've checked the control.lua of your mod) is how to check when the player is standing next to the elevator, and then to teleport them. this is a great mod by the way-i use it a lot for smelting machines: ore and coal go in one end and plates come out the other, in the space of an assembling machine

well, I planned to make it usable by other mods, but I have much to do before I can do that, so, don't worry about using my work!
To understand how I move the player from one surface to the other, check the functions teleportation_check (line 634) and temp_teleportation_check (line 677)
the first one checks every 10ms if a player is near an elevator. if there is one, it starts the other one that update the progressbar and chech that the player is not moving then, when the tp progress is complete, teleport the player

[Vas]

I much prefer the graphic with the pole in the center of the elevator rather than having two on the sides of the elevator where items can "noclip" into it. What I mean is this;


Also, why is every single item 2 iron plates? I'm trying to balance out the recipes right now.

I'd also like to see a small version of this item elevator. Perhaps one that just takes two blocks of space max, where it has a one way path. Place one at the top end that points in a direction, and place one at the bottom flipped with the arrow pointing towards the belt. Basically it would be one belt and one underground belt, that would be the entire graphic. Same for a fluid transport, only a bit different. A small 1x1 sized buffer tank that stores 1/8th the MK1 tank with only one side with a pipe on it, though I've not used the fluid elevator yet so I don't know how it works.

I do not know what some of these items do yet, so I do not know what they should cost. The items I wanted to change don't appear to exist in game yet.
These are: digging-planner, deploy-digging-robots, assemble-digging-robots, digging-robots-deployment-center

This is what I got so far for recipes.

recipes.lua

(2.96 KiB) Downloaded 157 times

EDIT:
I can't understand the code used in this mod, so I am unable to find and make some changes myself.
1. Digging needs to take longer, could you put that in a config file?
DigDuration = x
2. Digging needs to take more power. Would you also put that in the config file?
DigPower = "50kW" (current takes 50)
I've set it to 500 myself. "energy_usage = "500kW"," in the entities file.
3. I am unable to find out how you rendered these entrances and elevators. I wanted to alter the tunnel entrance and exit to move the big power pole to the center again like in the image up top but I failed at that.

[kiba]

I much prefer the graphic with the pole in the center of the elevator rather than having two on the sides of the elevator where items can "noclip" into it. What I mean is this;


It's an acknowledged bug, not intended design.

Also, why is every single item 2 iron plates? I'm trying to balance out the recipes right now.

it's a WIP, which is why everything costs 2 iron plates.

[Vas]

Well, I did include a new recipe file for anyone who wants to make to cost more realistically

I feel like this is breaking the enemy AI though. I've been stuck at 0.000% evolution for 2 and a half hours so far. Enemies aren't evolving.

EDIT: I fixed the issue with the enemy AI by commenting out the map-settings LUA in "data.lua".

[RemTM]

EDIT: I fixed the issue with the enemy AI by commenting out the map-settings LUA in "data.lua".

So THIS was the source of all my issues!!!
https://www.reddit.com/r/factorio/comme ... tion_rate/
I'm gonna 'borrow' your recipe fixes and maybe tweak it a bit before adding it to my modpack.

[kinnom]

the item elevators don't work when rotated to the east/west http://imgur.com/yovj7Dr
also, item elevators, fluid elevators and tunnel entrances can destroy stuff on other levels

[Vas]

I've noticed two things today. I accidentally hit my tunnel exit when in the mobile bore destroying it, causing me o permanently be stuck down here forever. The other thing is, if you build a drill in the sub surface, it works and makes a second level of subsurface.

A suggestion for fixing these is to build a craftable tunnel exit that can only be placed in the subsurface to go up one level of subsurface territory.
Another suggestion is to make the second level subsurface a different texture, like the first one is dirt and rock, make the next one stone and rock.
A tier 3 subsurface could be darker and darker. Tier 5 could be molten rock and allow you to go no further.

I'd also like to suggest that there is no light in a second level subsurface or deeper, that you require using lights to light the path.
Vents should be half as effective per level meaning at a Level 5, a vent will only work 3.125% as efficient.

Also, disable solar panels from working underground. Or add a line that allows you to make structures unbuildable underground. "SubsurfaceEnabled = False" to items and then with anyone who wants, they can add that line to their items in any mod to stop it from being place-able underground.

I've also created a new group for the items of your mod out of personal preference and moved all items there.

EDIT: Further idea,
This idea came mostly from a mod "Simcra" made,
Add a logistic request chest that goes up or down a level. Placing a passive provider chest as the receiving end. The request chest sends items to the passive provider chest on the other level. The chest can only be up, or down. The Up chest can not be placed on the surface. Also add the invert as well, where you place a passive provider chest that goes up or down, so you can place it from the surface and see where you are placing it instead of just blinding sticking it somewhere.

One further idea I had is instead of forcing the structures in the way of an item to be deleted or destroyed, when placing an item on one surface or the other, is to give the player the item that needs to be placed on the other side in his inventory and place a ghost on the other side that lasts an infinite amount of time. Give it say 500 hours of life. If there is a structure in the way, or something blocking it, emit an error in the console and tell the player they must move their object. In the event that it is a drill, scan below where you want to place the other end at and check if it is buildable before the drill begins digging. If there is an object, don't let the drill dig and emit the same error.

I hope that my input and ideas have helped you plan out your next update to the mod.

[flabort]

It could be difficult to program a way to make drills/elevators different colors based on levels; perhaps possible, based on this person's skill, but hard. I would enjoy this as it would be a nice touch, though.

I don't agree on limiting depth; no point. Realistically, you could make a mineshat hundreds of levels deep, even on earth, before the heat got too much to bear, and I'm 90% certain this planet is bigger. If you were trying to go deep as possibly, you'd realistically run out of hard drive space before running out of depth to go. And even if that weren't tge main reason to allow going as deep as you want, air. Like you observed, vents are important to have, especially as you go deeper. While there may not be much producing pollution if your only goal is to go deep as possible, there will still be some. The only way to get rid of it is vents going upwards, into the next layer up, then the layer after that, etc. Vents cant always deal that fast, and if you're not turning around to build more infrastructure further up every so often, the layers above you could have lethal levels of pollution. I guess that serves as an argument against reducing the effectiveness of vents as you go down, too. Because even if you pump up the pollution and down air, it's already not going the whole way.

Making lights more nessesary underground, yes I would want that too. Disabiling solar panels underground, if it's possible I'd want it.

I don't think a "subsurface-enabled = false" flag is possible. According to what I've been told, any flags the game doesn't understand are ignored, and theres no way to script a way to make it understand them. The mod creator could possibly script a blacklist of items in the script which operates the sublevels (Im just snowballing here) and check each time the event for a player building something fires if that something was on the blacklist (and if it was in a sublevel, if it had to be a global script), and if it was remove it and put the item back in the players inventory. This means if you're building a modpack and want something not buildable underground youd have to add it to the blacklist yourself, but whatever.

I think a Go-Back-Up elevator is a good idea. If the blacklist to keep things from being built underground works, then hopefully a second script to keep this from being built aboveground would be in order.

(EDIT)

can you make a vent that takes pollution down a level? or is that too cheaty

do you want it just to get rid of the pollution to some surface you'll never go to ? or is there a real reason (and of so, which is it?)
If the answer is yes to the first, then I won't. if you can provide me with a good reason to have that, I'll think about it!

I can think of a reason. To keep pollution "contained" without spreading past an artificial border, via cycling it back towards the source. A similar effect can be obtained now, using a wall of passive vents around your base, and active vents in the center. The passive vents suck pollution down into the subsurface, which gets pulled towards the center and vented back into the most smog-heavy part of your base.

Granted, this doesn't do much to convince you to do it because its still the same principle at work, keeping it from affecting the overworld too much, and if you did intend to not go into the mine, then there wouldnt be much of a reason to use vents to pull it back up...
Honestly, I would stick to not using active-reverse-vents.

[Vas]

It could be difficult to program a way to make drills/elevators different colors based on levels; perhaps possible, based on this person's skill, but hard. I would enjoy this as it would be a nice touch, though.

What? I didn't say anything about drills being different colors based on levels. I said t make different subsurfaces with different kinds of floors and different kinds of walls, that's not difficult. Once you've already made one level, you can pretty much copy/paste and just change what materials that level is made up of. Each level is its own map from what it looks like to me.

I don't agree on limiting depth; no point. Realistically, you could make a mineshat hundreds of levels deep, even on earth, before the heat got too much to bear, and I'm 90% certain this planet is bigger.
I guess that serves as an argument against reducing the effectiveness of vents as you go down, too. Because even if you pump up the pollution and down air, it's already not going the whole way.

I want to limit the depth for gameplay reasons. Not "realistic infinite depth" reasons. Its harder to go down for one, no building really goes more than 5 stories deep, and in this game you are assumed to be going down much deeper than a story each time because you can place full sized structures inside each level. I simply want the limit for gameplay reasons and so each level can have a unique look to it, and eventually you land at the magma type sub level and can't go any deeper.
As for vents, I have yet to see anything happen with oxygen yet. I tried staying down underground for a long period of time in a tiny hole, nothing changed, I tried creating heavy pollution inside the hole with no vents of any kind, nothing changed. It is my assumption that air may work based on the pollution level. I don't really know. However, for pumping air further down, it should have reduced effectiveness because you have to get the air down each level to the bottom one. As for pollution moving, you can simply pump that up one level at a normal rate per level. Oxygen is different because you're not pulling oxygen straight from the top, but you have to fill each level with oxygen and supply the level below with more oxygen. It would take 2 vents to keep SubLevel1 supplied while giving SubLevel2 oxygen too and so on so forth.

Making lights more nessesary underground, yes I would want that too. Disabiling solar panels underground, if it's possible I'd want it.

Easiest to do by disabling the structure from being buildable underground, would likely be too difficult to make solar panels stop functioning underground and there are other items that'd need to be disabled too, so a table of items to disable would be better.

I don't think a "subsurface-enabled = false" flag is possible. According to what I've been told, any flags the game doesn't understand are ignored, and theres no way to script a way to make it understand them. The mod creator could possibly script a blacklist of items in the script which operates the sublevels (Im just snowballing here) and check each time the event for a player building something fires if that something was on the blacklist (and if it was in a sublevel, if it had to be a global script), and if it was remove it and put the item back in the players inventory. This means if you're building a modpack and want something not buildable underground youd have to add it to the blacklist yourself, but whatever.

Seems it is impossible to use the flag method. But you'd probably be able to do it in a table in control.lua according to Bob.

[StanFear]

I much prefer the graphic with the pole in the center of the elevator rather than having two on the sides of the elevator where items can "noclip" into it.

yeah, it's a known bug (I made some change but forgot to change the size of the picture to use for the entrance)

Also, why is every single item 2 iron plates? I'm trying to balance out the recipes right now.

just because it is a WIP mod and I don't want to have to mine a lot of stuff just to be able to test one functionnality

I'd also like to see a small version of this item elevator. Perhaps one that just takes two blocks of space max, where it has a one way path. Place one at the top end that points in a direction, and place one at the bottom flipped with the arrow pointing towards the belt. Basically it would be one belt and one underground belt, that would be the entire graphic. Same for a fluid transport, only a bit different. A small 1x1 sized buffer tank that stores 1/8th the MK1 tank with only one side with a pipe on it, though I've not used the fluid elevator yet so I don't know how it works.

As of 0.12.33, it is not possible to have non squared rotatable entites so a 2x1 entity is not possible (I could probably think a a way around the limitation but it would add too many lines to the coding and the end result would not be satisfying).
as for the small tank, I don't think I will add a 1x1 entity for that, maybe a 2x2 but not smaller, don't forget that it needs to be able to push liquids on level up, so it needs some kind of internal pump, and in a 1x1 entity, there wouldn't be enough place
and ... I don't really like the idea of small entities that don't use space when it should

I do not know what some of these items do yet, so I do not know what they should cost. The items I wanted to change don't appear to exist in game yet.
These are: digging-planner, deploy-digging-robots, assemble-digging-robots, digging-robots-deployment-center

well, these items are not available in the mod, unless you use the command I wrote in the OP.

This is what I got so far for recipes.

recipes.lua

ok, well, I'll take a look at it

EDIT:
I can't understand the code used in this mod, so I am unable to find and make some changes myself.
1. Digging needs to take longer, could you put that in a config file?
DigDuration = x
2. Digging needs to take more power. Would you also put that in the config file?
DigPower = "50kW" (current takes 50)
I've set it to 500 myself. "energy_usage = "500kW"," in the entities file.
3. I am unable to find out how you rendered these entrances and elevators. I wanted to alter the tunnel entrance and exit to move the big power pole to the center again like in the image up top but I failed at that.

yeah, sorry, my code is not the simplest ...
1 and 2. same reason as the recipe being all 2 iron plates, the mod is still a WIP project so I don't want to have to wait on minute to go to the underground (or even more)
the time and power needed will be changed but I don't think they'll be configurable.
3. I actually fixed it in the non released version, you can use the entity.luafrom the github repository to fix it (it's actually just the pole that has a problem, and the belts are other entities)

Well, I did include a new recipe file for anyone who wants to make to cost more realistically

I feel like this is breaking the enemy AI though. I've been stuck at 0.000% evolution for 2 and a half hours so far. Enemies aren't evolving.

EDIT: I fixed the issue with the enemy AI by commenting out the map-settings LUA in "data.lua".

well, the map-setting will probably be removed anyways, I wanted to use it to prevent the pollution to spread underground, but the changes I made weren't changing anything ... so... it'll be removed in the next version

the item elevators don't work when rotated to the east/west http://imgur.com/yovj7Dr
also, item elevators, fluid elevators and tunnel entrances can destroy stuff on other levels

Yes, it has been fixed (although I thought it was in the 0.0.4 version... might just be in the next one !)
and the fact that elevators and all crosssurface entities destroy items is known, it was simply tested to be working, but I had no clean way to warn the player that there was a problem, I now have an idea on how to handle it.

I've noticed two things today. I accidentally hit my tunnel exit when in the mobile bore destroying it, causing me o permanently be stuck down here forever. The other thing is, if you build a drill in the sub surface, it works and makes a second level of subsurface.

A suggestion for fixing these is to build a craftable tunnel exit that can only be placed in the subsurface to go up one level of subsurface territory.

Yes, it has already been discussed before, I will add a way to go back up when all entrences have been destroyed.
it might be an escape pod or stairs, I don't know yet, but it'll be added at some point

Another suggestion is to make the second level subsurface a different texture, like the first one is dirt and rock, make the next one stone and rock.
A tier 3 subsurface could be darker and darker. Tier 5 could be molten rock and allow you to go no further.

hum... no!
I won't limit the number of layers there are, I could, but I won't, and because I wan't the game to be able to handle any number of layers, I can't change the graphics on each new level (that would mean having an infinite amount of ground an wall tiles in the mod, which, is not possible, and even if it was, would make the mod way to big.

I'd also like to suggest that there is no light in a second level subsurface or deeper, that you require using lights to light the path.
Vents should be half as effective per level meaning at a Level 5, a vent will only work 3.125% as efficient.

having differents light levels on each levels is not possible yet (it will be in 0.13) but as soon as it is, the light level on each layers will change the deeper you go!

Also, disable solar panels from working underground. Or add a line that allows you to make structures unbuildable underground. "SubsurfaceEnabled = False" to items and then with anyone who wants, they can add that line to their items in any mod to stop it from being place-able underground.

as someone already replied, it is not possible to use custom data in the prototypes (sadly) I might add a remote interface to tell my mod to forbid placing some types of items underground, but I first have more important stuff to do!

I've also created a new group for the items of your mod out of personal preference and moved all items there.

EDIT: Further idea,
This idea came mostly from a mod "Simcra" made,
Add a logistic request chest that goes up or down a level. Placing a passive provider chest as the receiving end. The request chest sends items to the passive provider chest on the other level. The chest can only be up, or down. The Up chest can not be placed on the surface. Also add the invert as well, where you place a passive provider chest that goes up or down, so you can place it from the surface and see where you are placing it instead of just blinding sticking it somewhere.

maybe, at some point.

One further idea I had is instead of forcing the structures in the way of an item to be deleted or destroyed, when placing an item on one surface or the other, is to give the player the item that needs to be placed on the other side in his inventory and place a ghost on the other side that lasts an infinite amount of time. Give it say 500 hours of life. If there is a structure in the way, or something blocking it, emit an error in the console and tell the player they must move their object. In the event that it is a drill, scan below where you want to place the other end at and check if it is buildable before the drill begins digging. If there is an object, don't let the drill dig and emit the same error.

I hope that my input and ideas have helped you plan out your next update to the mod.

using ghosts would have undesired conséquences so this solution won't be used, but I have an idea that might be just fine



@flabort, Yes, I won't add the air vent that take the pollution down a level, still havn't read a good enough reason

@Vas, indeed, the air is based on pollution level, to be albe to not use it, I would have to recreate the pollution system, with small modifications, but then, it would be really performance heavy (even more than it is right now) so... I won't do it. although, I would love to be able to take the oxygens level into account, and have to pump air down, etc... but it won't be done.
In 0.13, sollar pannels won't be disabled underground, but will be useless
the flag method only allow some already defined flags. this is why it isn't usable



Also, sorry for the long time since I last posted anything, I had a lot to do, I should now be able to get back to codding the mod and responding to messages here !