Rotator. Is this intended behavior?

[Dagreff]

If you have two blocks with one block space between them and you place a rotator in the space, then unlock the rotator, one side of the rotator will spin freely in spite of being hard up against the block adjacent to the spinning section of the rotator!
Is this intended behavior or a bug? I hope it's a bug!

[Vrmithrax]

If I understand your build method correctly, then it's not unusual to see that kind of behavior. The problem is that the rotor will only attach one base plate to a block, not both. So, if you did the exact same thing, but built 1 block, added the rotor, then the 2nd block, the rotor would only spin when one of the 2 end blocks were able to move (not anchored as part of a rigid structure).

It's a weakness in the block building system. Similar issues are found with conveyors, you have to build in a single direction if you want the conveyor system to be connected. You can't build a part of a conveyor from one end, go start another route from another end until it meets the first conveyor, and have them connected. A bit irritating at times, but if you always built "outwards" you can get used to the process fairly quickly.

[Indigo]

In myriads of experiments trying to construct a viable crane without any sort of motorized blocks, I've tried a few things and noticed something that make be related here:

Although I can build a "ring" of blocks that has a hole in it, it is quite a challenge to actually make another brick pass through this hole consistently and evenly.

For example, if I make a ring of 8 1x1 blocks with an empty space in the center, and position a 1x1x8 wall column to pass through this space (by attaching it to a small "L" of 1x1 blocks directly over the center, then removing the supporting 1x1's and letting it fall into place, it will pass through the hole at least once. Subsequently lifting this 1x1x8 column will work once or twice, until it becomes cocked slightly in some direction or another and "stuck" and no longer moves.

Likewise, when I was attempting to construct a large roller using 1x1's and curved 1x1's, I could make the drum shape, but could not attach a rotor on each end. Reconstructing it so that parts of one side of the drum were longer and parts of the other side of the drum were shorter, so the two halves interlocked like gears worked somewhat - though at times one set of blocks or another would end up passing through other blocks, causing some very amusing (after the fact) physical mishaps (like a drum that bounced up and down or flipped the vehicle it was attached to over like a pro wrestler's body slam).

Never run into issues connecting conveyors, and I have made some "meet in the middle" connections.



A good bit of the plumbing here was assembled as "meet in the middle" - the "T" piece on the right was not even there originally, but added later, along with the refinery it's attached to - so unless I'm missing something... I have no issues getting materials from the overhead bins to the refinery, or refined Uranium out to any of the 3 reactors on this mobile base.

[Vrmithrax]

I'd be curious, Indigo, if you destroyed one of those straight conveyor pipes and replaced it, if you'd still have complete connection between all machines and storage? Make sure you have a save first, of course...

Maybe the conveyor 1-way building issue has been fixed along the way, and I missed it (or nobody mentioned it). Because it's been the bane of many conveyor network builders for the last year. And one of the big reasons that the devs introduced the conveyor connector block.

[JAAHAS]

Those machines are in the same grid, the meet in the middle bug only happens when you try to join two existing grids together.

[Vrmithrax]

Well, I've had it happen on the same grid between 2 machines that only needed a single straight pipe to connect them. It's always been a weird sporadic issue that can occur on the same grid. The initial build is usually fine, but any destruction or mod of the pipeline can cause a breakage (which is why I wondered if replacing a straight pipe in Indigo's setup there would break the connections). I'm so used to just destroying and rebuilding along a line to fix the issue that it's become second nature. In fact I stopped using straight pipes just to avoid the issue, and always use at least a T or X instead of a solid pipe when routing - saves headaches later.

But yes, it always happens if you happen to break a conveyor that leads to machinery that is not physically attached somehow to your current grid. If the conveyor is the only thing tying 2 pieces of hardware together, and you break that conveyor (like to put a T junction in place of a straight pipe), you have just created 2 grids. It seems like autominer setups feeding a storage container are usually the ones that easily display the conveyor break issues.

[Indigo]

Those machines are in the same grid, the meet in the middle bug only happens when you try to join two existing grids together.

I will confess, I'm not 100% on PN lingo - by grid... I'm a bit unclear what constitutes a separate grid, or why anyone would want to connect them.
I get, for example if a vehicle is considered one grid, and a base anchored in the ground is considered another that attaching a vehicle to a building by means of a hard physical connection (a conveyor) might be attempting to join to grids, but at the same time, doing so would render the vehicle rather useless, since it would now be rooted to the ground as part of the base building. For this sort of thing, use a Conveyor connector.

An example of what constitutes two separate grids someone might want to join would be helpful to me.

[Vrmithrax]

Here's a common example of grid separation.

Say you find a spot with a good ore vein that you want to set up to mine. So you lay down a few floor blocks nearby, get some storage put together, whatever power source you plan to use, etc. Then you start routing conveyors out to the vein, put in an elbow facing down, attach your autominer, and wire it up. Everything is great. The system considers it a single grid.

Now, you decide you want to put a second autominer nearby in another section of this ore vein. So you snap out a section of the conveyor tubing and put in a T junction, then start plumbing conveyor connections to the new location and finish by putting down the second autominer. Everything seems fine. Until you notice that your containers aren't filling up like you'd have thought, and so you look and see that you can only see one of the autominers in the container network now (the second one, the one you just added). Or, even worse, you can't see either autominer. This is because the moment you destroyed that conveyor section to put in a junction, you split the miner and conveyors attached to it off on its own grid. Unintentional, but it happened. Even though they were built on the same grid, perfectly aligned, nothing moved even a micron when you quickly removed and replaced that conveyor part, that extra section of conveyor and miner are forever on their own grid now. And there is no way to physically see that the conveyor piece you put in has not connected on both ends, so you have no outward evidence that you have split the grids. You had a 50/50 shot on which end of the conveyor your new junction would attach to, which decided if you could see the new autominer in the container inventory list, or if it decided that it was connected to the other autominer and you created a small independent grid of 2 miners and some tubes.

It's been a common issue for a long while, the source of a lot of suggestions and requests to fix, and resulted in the introduction of the conveyor connector - basically the equivalent of a roll of duct tape for us, when it became obvious to the devs that they couldn't get the conveyor ports to reconnect on more than just the 1 side. Didn't fix the problem, but turned out to be a rather elegant solution because it also solved another request / suggestion - being able to tie mobile containers to base containers for loading/unloading.

[Menzagitat]

An example of what constitutes two separate grids someone might want to join would be helpful to me.

https://docs.unity3d.com/ScriptReference/Grid.html

A hinge is composed from two grids, linked together and rotating around an axis.
Same with rotating plates (or joints)
Suspensions are also composed blocks, connecting who grids on both ends, and we solder to one end the wheel and to the other one the vehicle.

In the Planet Nomads saves, there are grids and "sub-grids" when defining the structures. The relative position of an armored block inside a grid is the only way to find out it's position. There are no angles- there are only x,y,z. One can change these values and obtain a grid (a rigid body) made by parts which are not in contact with each-other



- - - Updated - - -

If you have two blocks with one block space between them and you place a rotator in the space, then unlock the rotator, one side of the rotator will spin freely in spite of being hard up against the block adjacent to the spinning section of the rotator!
Is this intended behavior or a bug? I hope it's a bug!

It is intended at coding level. It is a bug at concept level made by those who were designing this game. They think more like programmers and less like players. They use those technical terms so often every day that they forget that their customers are supposed to have fun.

[Indigo]

Thanks Menzagitat - never really looked into the Unity documentation, so that's actually a big help. Never worked with the Unity Engine actually, but I have delved a bit into the Unreal Engine (2 and 4), Gamebryo, and ID Tech, so this isn't foreign to me at all. Of course those designing the game think like programmers - they are programmers - that's what 70% of game design is. It's tough to do both well at the same time. :-)

[Dagreff]

Wow! Looks like we will have to put up with it, as I doubt we will get a re-code any time soon, if ever! As for build it in one direction, there is a problem with that.

The end your building towards will not join with any pre existing structure. So for instance, the end of a spinning shaft cannot easily be fixed solid and would flap about or, as happened in my case, the mechanism seizes up at the rotating joint. This makes the whole thing unusable without doing some well thought out bracing.

I thank you for your prompt and candid answer. Most enlightening!

[Indigo]

Wow! Looks like we will have to put up with it, as I doubt we will get a re-code any time soon, if ever! As for build it in one direction, there is a problem with that.

The end your building towards will not join with any pre existing structure. So for instance, the end of a spinning shaft cannot easily be fixed solid and would flap about or, as happened in my case, the mechanism seizes up at the rotating joint. This makes the whole thing unusable without doing some well thought out bracing.

I thank you for your prompt and candid answer. Most enlightening!

As I understand, rotators are now Locked into position when placed, and can be set to "Locked" once unlocked, which will keep them from spinning. I will confess to being a bit less than clear on why one would be attaching a conveyor to a rotator, though I suppose there could be some reason for it. Other sorts of blocks, sure.

I don't think a "re-code" would be required, but perhaps an added function to "MergeGrid" would address this. Not sure.

[Menzagitat]

I am not sure why merging two grids in not possible.
Blocks, not matter how big they are, if the player selects a square on a grid and a square on the other one, the two grids could be rotated and translated until they merge.
The realism of such an action might be questionable though, if it happens like if a Jedi is doing this.

Anyway, can you tell us a bit more about the blueprints?
How will they work? What should we NOT expect?
In the above example, if I would like to weld two grids together, I wonder if I could save one of them as a blueprint, deconstruct it, and build it again, attached to the other grid.
Or, if I would like to make a 8000 km long suspended rail, I could easily do it by using one 400m long sample saved as a blueprint, placing them 20 times (but breaking them again to have segments).
Will such scenarios be possible?

It is not completely impossible, but we must do it in physical-safe way, as we do not want to make whole buildings shake and launch to the skies. So we need to compute appropriate forces to move it where you want to. So at least one of them must not be grounded and also have low enough mass, to be able to be moved by safely small forces. Also there should be not obstacles in the way and the shapes of the parts must be suitable. Sometime there is only one way to connect the two shapes, and doing wrong move could make parts block each other.

After you have joined the two parts (grids) by forces to nearly precise alignment, you can delete one and re-add all contained blocks to the another one while correctly recalculating in-parent positions and maintaining block settings in one giant lag. That will change the weight and other physics properties by one big jump and that is risky from physics point of view.

It is somehow doable, but general feeling will be similar to winch, which we honestly do not consider the best part of the game.

At least I am still thinking about adding possibility to re-join once divided grounded grid, if both parts have not moved (kept grounded all the time). This eliminates the necessity to move grids and the risk of physics glitches as well as does not need to introduce any artificial player interaction. And will make possible to fix mistakenly split conveyors and allow to replace one or more connecting blocks with another if both resulting parts are still grounded. If this will be successful, we could try to reuse it to make more sophisticated version with physics manipulation working on non-grounded parts.



Currently we can save the machine you point on to a file. With all block settings and contents. We use it to spawn shipwrecks, monuments etc. at the start of the new game.

We are working on scenario where you point on some empty ground and the blueprint spawns there as an unapproachable "construction site" box that you finish by your multitool while consuming resources. Once you will have finished it, construction box will disappear and you will be able to use your (or somebody else's) creation. So it will be separated grid. Currently we still do not have a way how to build it on another grid, at least we can use some variation of the re-add all contained blocks function mentioned earlier.

It is more an user interface question - how should be player supposed to point with big grid (or connected grids) in hand on another grid and tell exactly which block from the new (not yet existing) grid should fit on which one in the grid in the scene. You know how difficult is to put 8x5x3 block precisely, and imagine yourself doing it with 20x30x50 size blueprint by means we have now in game. This is the thing we should solve now.

This is the latest discussion I guess, about trying to join separate grids

[Vrmithrax]

If they can work out a way to safely combine grids and subgrids when necessary, I'd honestly rather have a "welder" tool to apply the change. It could actually be an easy way to select which is the primary grid and which will lose its identity to become part of the primary grid...

- Point the welder at the junction between 2 grids that you want to weld.
- At that time, each grid highlights (maybe like the ghost block view when building). Green highlighted grid is primary, red is secondary
- Use scroll wheel to toggle which grid is primary, toggles back and forth when rolling the wheel
- Click mouse button to "weld" merge the secondary grid into the selected primary
- Smile, take a sip of your margarita, and get on with the game

[Dagreff]

[QUOTE=Indigo;17198]As I understand, rotators are now Locked into position when placed, and can be set to "Locked" once unlocked, which will keep them from spinning. I will confess to being a bit less than clear on why one would be attaching a conveyor to a rotator, though I suppose there could be some reason for it. Other sorts of blocks, sure.

Just for clarification. No conveyor involved in my example, just ordinary blocks. However that gives me an idea on how to make a switch for connecting and disconnecting a conveyor system!