Pistons and Merge Blocks

Has anyone else noticed that it is possible to use merge blocks on pistons so long as each merge block is connected to a piston? If only one of the merge block is connected to a piston while the other is connected to a solid structure, then the merge block connected to the piston will remain in place along with the piston head (even though the piston head still show as attached in the K menu.)

Additionally; consider the following setup on a planet:

(I won't spell it out in the scenario, but you'll obviously need a power source for each station...)

Build a Piston that moves blocks up and down.
Build armor blocks off of the piston head horizontally in any direction (starting on top of the piston head.)
Build a rotor at the end of the armor blocks such that it rotates around the horizontal axis.
Place a few blocks on the rotor head and then place a merge block with connections pointed down.
Place a merge block with connections up directly below first merge block.

Now, once the piston is lowered and the merge blocks connect - the rotor head will be "stuck" in place and will no longer move even after turning the merge blocks off and there are no other contact points between the stations. The piston moves and the piston head remains where it should, but the structure will twist as the rotor head forward can no longer move along with the piston.

Has anyone else observed either of these problems recently? I've noticed a few old posts that seem to be related to the first scenario I've outlined, but nothing at all of the second can be found. I only mention the first as none of the other posts seem to have a response to go off of...

On a side note - I'm a professional, full-stack software developer with over 10 years of experience working with C# and the .Net framework in general. If anyone can point me in the general direction of where these "problems" stem from, then I'd be happy to try and get a pull request together that resolves them. I've already got Git and a professional SKU for Visual Studio primed and ready-to-go!

=)

 

Thanks Dan!

Sorry for positing in the wrong area =)

 

Any sort of help that pistons/rotors can get would be amazing. More power to you!

 

I used that on one of my old wheeled mining rigs for planets. Fairly large rig with upside down piston to drill array. I didn't like the amount of sway that was happening when moving around, so when not drilling it was in the UP position locked to the rest of the chassis by a merge block and piston deactivated. Only once did I make the mistake of moving the piston while merge blocks were still locked, but the explosion was spectacular.

After plaYer2k's message : Never posted a pic before. Will try.

 

I cant quite visualize it, maybe because i just woke up, but could you please upload some images?

It sounds like you refer to the fact that you can merge grids, each end of a rotor/piston is a different grid, as long as there is no block occupying the same block position in the resulting merged grid and thus with multiple rotors/pistons you can merge a "loop".

 

Didn't have a save file with this rig, so rebuilt it quick. The original was before beta release and the merge block isn't working any more.

But here is the image

 

Yeah, I'm pretty sure that I saw somewhere in the merge block's code that two blocks will not connect if they are already a part of the same grid. I don't really understand that myself, as I cannot imagine what problem would be caused by allowing it or what benefit is gained by disallowing it. If I am understanding you correctly, then the merge blocks simply stay white and never even turn yellow when they are close to one another. I've seen that happen as well recently.

I'll see if I can throw some examples together of the issue that I am describing sometime later tonight.

I think I need to read the merge block's code some more, but I am just not seeing the piece that actually combines all of the blocks into a single grid. If I can find that bit of code, then I can reverse engineer my way into why the rotor and piston heads seem to get stuck in place after a merge. They exhibit the same behavior as a ship that merges to a station in that the ship no longer responds to thrusters until you convert it back to a dynamic block grid. The only big difference there is that the rotor and piston should have already been classified as a static grid, so I am still at a loss.

I guess one other possibility is that the detachment algorithm is not splitting the grids correctly due to the fact that rotor and piston heads are "sub" grids. I can definitely see a scenario in my mind where the algorithm inadvertently finds the rotor as the beginning of the blocks to detach from the main station. If that is the case, then the blocks from the merge block to the rotor head (or piston head, whichever comes first) can never be detached from the main station once the first merge is complete.

If that is what is happening, then I know exactly how to fix it! I just need to know where it is happening in the code base...
--- Automerge ---
Winner, winner, chicken-dinner! I think that I've found the issue within the partial class spec defined in MyCubeGrid.static.cs for Sandbox.Game.Entities.MyCubeGrid. I'm going to need to find time this weekend but I'll debug and try and get a PR submitted if possible.

My goodness, what a read! I love you guys, and this game is phenomenal, but has anyone ever heard of the single responsibility principle? I think that 12k lines of code for one object would be considered extreme by most people. Just sayin...

=)

 

For multiplayer merge blocks are straight broken right now.

 

How so? I do see a lot of effort going into synchronizing merges between the server and the client. There's likely a bug in there somewhere.

Is it specific to local server or dedicated server multiplayer?

 

I think the problem you have there is not so much the merge blocks wont connect, so much as they can't (to preface, yes there was a bug a couple of patches ago that really buggered the merge blocks ability to attach to sub grids, but i don't think thats the case here.) Pistons by design are slightly longer than 2 blocks, this is so that you can sit the base "flush" with another grid and you won't have any collision issues, in the particular case of this rig, you have 4 times this little offset, which is making it so that the grids cannot merge. if they were to, the heads of the pistons would need to be forced into the base, and I don't really think you particularly want that.

 

I disagree. It DID work at one time, just not now, and I admit I might not have made it the same way this time. I know about the piston offset and tested many times with each attempt at 0.1 decrements. It should have locked, but the merge blocks just slid on top of each other. I'm sure I can get it to work again by having the pistons end with a connector and putting another connector on the top of the drill frame, making them two distinct unconnected grids.

I am not OP, and I feel this is may be taking away from the topic OP started. Sorry MadMax.

 

It's no problem at all! I posed a general question related to issues with pistons and merge blocks. I'm also looking to fix the problem if I can find the time so all of this could be pertinent. I've only had the game for 3 weeks (or so) and I've never worked with the code base before.

Hearing of unexpected and specific behavior is actually very beneficial towards increasing the rate at which I can digest how this all ties together. Think of it this way: if I'm reading through 12K lines of code that I am not entirely sure is even related to my problem, then I'm looking for a single piece of functionality in a giant haystack. However; if I also know that there is logic somewhere that prevents merge blocks from functioning if they are already on the same grid, then I have another clue that I could potentially latch on to I'm my search.

TLR: The more needles you're looking for, the better chance you have of finding one and (in my case) confirming you're on the right track. For the record, that's exactly what happened this time - so, thanks!

Can you confirm; however, that your merge blocks do not change at all in proximity to each other? Do the lights remain white?

 

Absolutely. I don't have software for creating video clips on my system, otherwise I'd show you.

As an example. Piston was set to max of 5 and there was plenty of room, set minimum to 4.5 and retract, still room, max to 4.9, extend, min to 4.4, retract, still come room, rinse and repeat. Each time I looked for color change. Tried in survival and creative.
--- Automerge ---
Follow up :
I'm bummed. Another project is using similar items so I'm trying different things. I said I could get it to work with connectors, but that will not work. Merge block will not lock onto another merge block that is connected in any (?) way even through just a connector.

 

Do they merge if you remove the connectors?
--- Automerge ---
Bummer. Spent a few hours yesterday and most of the day today thrashing about before I finally accepted the reality that the public GitHub master branch is not up to date with the latest version of the released code. I'm getting compilation errors screaming about missing objects and methods from the Havok namespace.

This is gonna have to wait until I can get my hands on a stable version of the code to build with. Guess we'll try again next weekend. Thanks anyways!

 

Building a reinforced piston arm for my semi-auto ice miner. If the merge blocks come together fully extended, it'll twist the entire arm. If fully retracted, it explodes. I accidentally got it to work once, but didn't blueprint and an update made my save unusable. [Murphy strikes again] Any ideas? Another way I've had some success is to put a rotor where the conveyor tube is, set it to off with no brake, and swing the bottom arm into the top. The whole thing will start spinning until I brake it, but it works and with no damage. Sometimes. But I'd rather not have the second rotor.

 

Necro of 8 month old topic is frowned upon.

I tested this again 2 days ago on another project. Merge block as in your drawing should not connect, and the discussion said so.

 

It can be even more frowned upon when you make a new thread for something that already exists though. In my opinion, as long as your post is relevant and not "I agree" (or something else inane) it should be acceptable.
New Threads: damned if you do and damned if you don't.

 

@Brian Nash I have more luck when I make sure all pistons have the very same orientation, then your build should work just fine.

 

Yeah. Sorry. Made a judgement call. "Similar Content vs. New Thread = The Great Debate." There's probably a thread already for my exact problem... somewhere. Just thought a new perspective might add some inspiration all 'round. My example, like the OP's, has us trying to multi-connect two grids.

But I'm definitely not an experienced forum-poster, so again, sorry if I've offended. And thanks for the comments and to the OP.

Malware, aren't all my pistons oriented the same? I just had the thought that perhaps gravity itself can change an orientation slightly. Maybe enough to cause problems? I do notice that when they come together, one or both arms will flex upwards to come in line. Perhaps if I build it so the pistons are positioned either straight up or down (or in zeroG). I've tried the way you have it in your picture (building off to the side, rather than straight on), but I get the same results. Another problems of a piston is the head has only one spot to attach to (that I know of), so when merging grids, whatever block you start with is what you're stuck with. So I'm guessing you're stuck with merge blocks on the ends of your pistons?

 

Not according to your image, no. Look at the positions of the control panels on the pistons.

That's my choice so it's easier to repair if broken. I could have placed another block, like armor, and then a merge block. Then I could remove that merge block after. But I don't want to

 

I n the info tab of the K menu, you should see a little check box for something along the lines of "show grid pivot" this will pop a little 3 axis XYZ orientation thing on the end of all of your pistons, just make sure all of them are matching (red same direction as red, blue to blue, green to green) and it should work just fine.

Do also be aware in a 0 g environment multi piston rigs like this can generate phantom forces in a grid which may cause random spinning of a grid. The heavy mass of a large ship usually can deal with it, but smaller craft may suffer.

 

Wow! I never would have guessed that to be an issue. Thanks! I'll try that. And I fully understand an efficiency approach to building, so please don't think I was harping on your positioning of merge blocks.

Grindy - Yeah. I took it out to space and it immediately started spinning. I stuck it to an asteroid. Thanks for the "info" tip.

 

sad having to bump this after last patch...