Space Engineers

Space Engineers

Pipelines And Powerlines
85 Comments
AgitatedAlice 2 hours ago 
Cool mod but I would wish the power lines didn't require a battery block to attach to so I could actually do this before finding lithium in Industrial Overhaul. I really just want the power lines without terminal or conveyor access because that would solve an issue with assemblers being annoying and taking "priority" over all other blocks even when on a connected grid, meaning it opens up that block regardless of what other block I use and all the other blocks play nice with each others.
SOBEK 25 Jul @ 2:59pm 
Helo. Nice to have screenshots with first steps , guide screenshots. Stay save.
KEJWII 20 Jul @ 5:42am 
Does this mod need the original mods to work? I can't find these blocks.
qm  [author] 30 Jun @ 2:32am 
The pipelines absolutely require connecting to stationary (static) grids; their models and collision are essentially even more static than static grids.

To support connecting moving grids would require recalculating pipeline piece placement and generating a new collider every time either end moved (potentially every frame), doing a bunch of collision checks for validity, and synchronizing it all in multiplayer. The performance cost wouldn't be unworkable for few pipelines (but still expensive for what it is), and would spiral out of control for one of the intended use cases (which is long and numerous pipeline arrays). The current way they work keeps their performance cost very low.

Powerlines are currently redrawn every frame and have no collision, so there was no real reason not to support moving grids (and their distance limit is mostly arbitrary).
jump101wa 29 Jun @ 12:25pm 
is their a way to toggle it being stationary, like i have a subgrid on my station i would like to rotate
to make pipelines more convienent
Þēros 6 Jun @ 10:35pm 
i believe all it does is try to balance power
chrishoule1366 18 May @ 1:16pm 
datalines work perfectly fine
chrishoule1366 18 May @ 1:16pm 
i dont think powerlines work right even with batteries on either end it doesnt seem to transfer power
triaxx3 7 May @ 8:30am 
Rotorhead has to be completely built and has to be physically on a battery.
The Canadian 6 May @ 10:06pm 
Furthermore, ir only wont let me connect *power* lines.
The Canadian 6 May @ 10:03pm 
Heyo, am i missing something? i have the basic rotorhead and it dosnt seem to work. i have my welder and everything. am i being stupid?
Nalesh 4 May @ 3:16am 
Would it be possible to add the Truss Light as an optional connector for the power lines? Would give a much cleaner look especially on large grid.
qm  [author] 3 May @ 10:45am 
Two separate pipelines. Stuff transferred is based on the destination container; if it's a gas tank, it checks the start of the pipeline for gas to transfer, if it's not a gas tank but is a cargo container or sorter, it checks the start of the pipeline for items to transfer.
Tardo The Ass-Monkey 2 May @ 9:46pm 
Can one pipeline transfer both gas and blocks (assuming they are connected properly), or would I need to do two separate lines?
Sardaukar 29 Apr @ 6:45pm 
Super cool. Tyvm for the reply and guidance. Once I fix my missing g-menu blocks issue(something to do with the update), I'll get back in game and test it out. Will report back with my findings.
qm  [author] 25 Apr @ 4:38pm 
The distance limits were primarily selected for gameplay / balance reasons. Shouldn't be any stability implications. Minor performance implications for cables due to needing to increase render distance for them, probably slight performance benefit for pipelines to be longer in place of multiple shorter connected pipelines. Shouldn't be any literal engine limitations, but math approximations may make some of the pipeline positioning sloppy with large enough distances.

You can just change MAX_STATIC_LENGTH up near the top of the file. Pipelines should tolerate increases fairly well, cables will have rendering issues unless you increase MAX_RENDER_LENGTH to compensate (should probably remain half of MAX_STATIC_LENGTH) which will have a non-zero rendering cost if you have it turned up high and have lots of cables placed.

All testing was done with the current limits and while I tried to make sure the rest of the code would adapt to those values being changed, no guarantees.
Sardaukar 25 Apr @ 3:48pm 
Is the 1km limit due to engine limitation/stability requirements/performance load, or can it be increased safely? I think I've found where/how to change it in the script, but I would prefer it work correctly instead of being able to have lengths over 1km...
Nalesh 23 Apr @ 9:24pm 
Yeah did figure out that putting another piston head a few blocks before on the same grid worked well, though there's still quite a bit of clipping when it comes that due to how it's oriented.

Been thinking about if it was possible to, exclusively on the midpoints if needed for balance, make it so that instead of 45 degrees it was 180 degrees instead and had no collision detection on the receiving piston head.
This would allow you to place a piston head with the port side down and the blank side facing up, making both the input and output pipe able to hit the node connecting them with no clipping.

I did peek at the code a bit before heading to bed and it seems possible to try out pretty easily, just need to be more awake to figure out which raycast check to nuke to let it do this without allowing for it to go through other blocks than the piston head. Feel free to ping me on the discord(same name), if it's easier to talk about that there.
qm  [author] 23 Apr @ 7:34pm 
The logistical overhead of letting the piston tops be usable effectively backwards, only at the destination if attached to a suitable destination, and then how to have it behave if the destination is removed, plus the confusion for a new user learning that they can only connect pipelines within certain angle constraints between piston heads, but then the rule being way different for the destination? I am wary of doing any of that.

What you could do, is place a piston top adjacent to your destination to guide the final one-block-length of pipe in at an angle you find more aesthetically pleasing. With the small gas tanks for example, I try to have a pipeline only enter from the top or bottom end since it looks much better than at a weird angle or from the side.

The computational cost of an additional piston head along a pipeline route on the same grid as another (in this case, the same as the destination container) is practically nonexistent.
Nalesh 23 Apr @ 5:04pm 
Or even just having the midpoint check ignore collision so it doesn't clip into that model, would help a lot with the clipping of the endpoint since then you can at least align it properly before sending it into the storage.
Nalesh 23 Apr @ 4:29pm 
Any chance you could put the node start point model also on the end point? It just clipping into the cargo model(especially if it's not a 1x1 block) just doesn't look great.
qm  [author] 13 Apr @ 11:29am 
Powerlines are slightly on the tricky side to use. They don't connect the power subsystems of two grids, but instead balance power between the batteries directly connected to the (basic) rotor part on each end of the powerline.

Why do they work this way? Game engine limitation; unless you have a full logical connection (terminal access) between grids, an electrical connection won't work. Magically transferring power between batteries allows for some method to move power between grids that aren't otherwise connected so was better than nothing.
chrishoule1366 13 Apr @ 8:44am 
they connect but they do not transfer power
chrishoule1366 13 Apr @ 8:43am 
can confirm power lines do not work
stevegw63 7 Apr @ 6:43am 
well as it turns out i need to learn how to read instructions better the only one that doesnt work is the power lines the data lines work though
stevegw63 6 Apr @ 2:20pm 
pipe lines and power lines are not working but the data line is working fine i have tried with just vanilla and this mod only and got the same result
qm  [author] 23 Mar @ 7:22pm 
Overhauled pipeline visual and collision creation. Should be far less picky about obstructions right near the final point of connection. Also even more efficient for physics collision tests related to the pipeline.
qm  [author] 11 Mar @ 3:39pm 
Okay, added some voxel collision tolerance to pipeline placement. A voxel that blocks the dead center of the pipeline will still block placement, but for the 8 raycasts done along the circumference of the pipeline, up to 2 can be blocked and still allow placement. For example, this should allow placement where a pipeline skims along the ground.

Also added a feature to help with fixing blocked placement: with the welder, aim at an otherwise valid endpoint where it shows the yellow obstructed symbol and left-click; then switch directly to a grinder or drill and the preview with collision checks will persist and let you drill/grind away obstructions and see an updating preview of placement validity. Unequip any tools or switch to welder and build/cancel to remove the preview.
qm  [author] 8 Mar @ 7:19pm 
Currently there's no easy way.

While I generally have just hand-drilled small sections of ground that I was barely colliding with, I did have a location where I gave up and used voxel hands with a long cylinder oriented like the pipeline to obliterate a path for the pipeline.

I've been brainstorming ways that would feel fair but haven't settled on anything yet. For anyone who has played Deep Rock Galactic, I was considering their approach where the basic pipeline path has to be valid, but then anything that's slightly still in the way gets magically carved out when the pipeline is placed. I think the equivalent for this would be if the dead center of the pipeline path was clear of voxels, pipeline placement would be allowed.

But I'm also not sure I'm okay with the pipelines clearing voxels on their own, so I might just make voxel collision more tolerant than grid collision when connecting (and let the pipelines be slightly sunken in to voxels).
A Pimp Named Slickback 8 Mar @ 6:32pm 
i was wondering if there was a way to make it so i could put pipelines through voxels, not a lot just a little i dont mind having to dig if i want my pipes to go through something i was just wondering if i could have the pipes slightly in the ground
qm  [author] 6 Mar @ 3:57pm 
Oh, and mod load order is unlikely to have any effect. A shot-in-the-dark guess would be some other mod doesn't like the game objects that make up the physical pipeline model.
qm  [author] 6 Mar @ 3:55pm 
It must be a conflict of some sort. This mod itself is programmed decently robustly with exception handling in network packet processing and custom entity creation for good measure and often excessive sanity checking everywhere else.

Post crash / exception info from the game's logs if you want any chance I could help, because I personally have not faced any crashes since early in this mod's development.
jamstraz 6 Mar @ 3:45pm 
This mod is causing a good deal of crashes for me. Twice in a row while laying pipeline it's crashed. I think we might be conflicting or it needs to be in a certain order?
Croy07 25 Feb @ 2:56pm 
Yep! I can confirm that it works for me too. Thank you for looking into it and fixing it so quickly, qm! It's such a great idea, and looks really nice too, so im happy I can use it without fear of floating pipeline caps now lol
qm  [author] 25 Feb @ 9:48am 
Ok, the pipeline cap piece not being removed when a piston top is destroyed should be fixed.

Pipeline caps are owned by the piston top they're attached to, but are generally added or removed by an incoming pipeline connection which is owned by a different piston top. When a piston top is directly removed, any incoming pipeline has a delay before it notices (there's no signaling because pipeline logic isn't bidirectional), and the end cap's piston top's logic component has generally been removed before the incoming pipeline can signal it to decrement its cap's reference count.

The solution was to just make sure removed piston tops also forcibly remove their associated end cap, if they have one.
qm  [author] 24 Feb @ 11:48am 
I was able to reproduce the issue, working out what needs to be fixed.
Croy07 24 Feb @ 10:57am 
I had the start of the pipeline connect to that midpoint, and that midpoint to the end container. It was the midpoint that stayed.
It comes up with both actual destruction, such as turrets blowing it up, and with grinding. I didnt try deleting with creative tools.
I hope this helps!
qm  [author] 24 Feb @ 10:19am 
That really just isn't supposed to happen. A short-term fix while I figure out what mistake in my programming makes that happen is to just restart the game; pipeline pieces aren't themselves saved in the world save file, but are regenerated based on connection info saved on the piston top blocks.

Those pipeline cap pieces are reference counted because of pipeline branching and such, so it could be a mistake there, but when their parent piston top is destroyed, it's supposed to throw them out regardless, so the problem could also be there.

Are there any other details you can give me on the circumstances? I get the midpoint part; did you destroy the piston top with a grinder, damage, creative tools block right click, whole grid cut / delete? Was it a single pipeline, or a point where two+ pipelines merged? Info like that.
Croy07 23 Feb @ 11:35am 
How do I remove a piece of pipeline, specifically an midway connection point rather than the start or end of a pipeline, when the piston top was destroyed? It just leaves a floating, uninterractable, invincible connection object.
Here is an image of what i mean: https://imgur.com/a/4tFCoQl
KevMeUp 22 Feb @ 9:39pm 
Loving the mod. Thank you! https://imgur.com/a/Q5rZrBz
The Canadian 22 Feb @ 6:27pm 
Were going satisfactory with this one
qm  [author] 8 Feb @ 11:51am 
The ideal (for performance and design simplicity) is to not need intermediate containers, but to be able to do piston tops for all joints between the start and destination containers.

So, pictures may help. Here's a quick upslope pipe I built where it gave me no issues:
https://i.imgur.com/Hw8YTUt.png

In contrast to that simple of a joint, what are you wishing would connect but doesn't?
qm  [author] 8 Feb @ 11:51am 
Short answer is changing or adding a new pipeline start variant isn't something I intend to do, but let's discuss it more in detail as it's not impossible to convince me, and there may be another solution (as I am interested in making the pipeline connection system less picky).

I can't (or rather, shouldn't) change the origin point of the pipelines because that will potentially break existing designs. I'm not sure that having a block-centered origin would solve all that many collision/angle failures though, as it's usually clipping an adjacent block that causes a failure.

Adding a new variant is possible but quite a bit of work. It's not as simple as just saying "also use block type X", I already used both types of piston top so I'd have to pick another block type, hook up all the requisite logic, change tons of code to also accept whatever the other block type is as valid, and so on.
DISCO429 8 Feb @ 5:24am 
Hi, i really like what you have done here, actually being able to set the end point of the cables/pipes is brilliant. Im finding the piston heads frustrating to work with though. Being so offset its very awkward to get the connections when chains start climbing hills, having to use sorters/cargo to provide clearance. Would it be possible to re-purpose a different model that fills a 1x1x1?
qm  [author] 3 Feb @ 12:08am 
If you're using basic rotor heads, they have to be placed on battery blocks. Each end of the power line needs a basic rotor head on a battery.

If you're using advanced rotor heads, they don't need to be placed on battery blocks.

The basic rotor heads on batteries let you share power between grids without them having a logical (terminal) connection, and let you potentially recharge batteries instantly. The advanced rotor heads give full grid interconnection including power systems and logical connection (like when you connect two grids using connectors).
Vegas 1 Feb @ 11:42am 
The original power lines do not work. Found this mod and power does not work either. I can grab a line from a rotor head on the source. It will not connect to any part of my small block rover; highlight is red. Placed another rotor on rover and can connect the line but no power is transmitting.
qm  [author] 23 Jan @ 1:19pm 
Possibly fixed the batteries failing to continue charging issue. Needed to upload for more thorough testing.
qm  [author] 22 Jan @ 8:32pm 
Arg, finally pinpointed the battery problem, but not sure how to deal with it yet. Batteries have an inaccessible "m_isFull" flag, that is only set or cleared by normal power transfer, and I haven't spotted any sane way to force normal power transfer to set or clear the flag. When it's true, the battery won't request any power, so nothing will send it power. As straightforward as you observed; my simple tests were too simple to spot it, and my actual use case setups were never naturally (via power generator) completely filling any.

Anyway, update was to add conveyor sorters as pipeline destination targets to allow for more compact designs. I found I've been making long arrays of sorted small containers, and this should let me switch to a sorter on each side of a pipeline without the small containers.
Moros 22 Jan @ 5:28pm 
Good to hear.

In related news, since our discussions I've had zero issues making use of both the powerlines and pipelines. They've been very useful and feel like something the core game is missing.
qm  [author] 22 Jan @ 5:12pm 
Moros, I FINALLY got a battery to behave like you described, where it appears to fall asleep and stop recharging. Here's hoping that lets me work out a solution.