Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
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).
to make pipelines more convienent
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.
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.
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.
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.
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.
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).
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.
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.
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!
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.
Here is an image of what i mean: https://imgur.com/a/4tFCoQl
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?
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.
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).
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.
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.