Pistons, alot of people have issues.

CptSavarus ●

Voted in the hope that we can have some new armour blocks with smaller collision models - like how blast door blocks work but with a construction recipe / mass / visual appearance more in keeping with regular armour blocks so as to blend better & not add ridiculous amounts of mass where undesirable.

I believe this will solve many problems when it comes to placing blocks in adjacent cubes to pistons & rotors.

Reply URL

2

Sammiches ●

In my observations, this issue is hard to describe. It's really just the fact that piston heads (not necessarily the piston itself) and the sub-grid they create cannot be placed directly adjacent to a block on the parent grid. The piston head and anything attached to it are a sub-grid and blocks on it cannot occupy the same space as a block on a parent grid. Placing the sub-grid adjacent to a parent grid block technically ends up taking up a small amount of the same space. The dimensions of the blocks technically aren't any different, but as a sub-grid, there needs to be at least a little empty space between blocks. This isn't accounted for in any way (I don't really have an easy solution) so it ends up falling on the physics engine to determine how to handle the collisions between the blocks. This appears to be what most players refer to as "CLANG". The ability to configure the forces of the piston are simply a stop-gap fix that happens to work because the physics engine can sorta handle it. However, push it too far and it blows up completely. Basically it's just very weird circumstances in the physics engine that produce some crazy high numbers for a moment... BOOM.

I don't expect Keen will resolve anything on the level of the physics engine, as that would likely be pretty difficult to do. Even slight modifications to how a physics engine works could have serious ramifications elsewhere, so I'd figure they'd avoid that.

The simple fix is to simply do what others have suggested. Create a few variations of armor blocks that have ever-so-slightly different collision models (similar to blast door blocks) so they can be placed directly next to the sub-grid of a piston. The models of these blocks don't actually have to be any different, though it seems very easy to create a slightly different sized cube (from a 3D modelling perspective). The hardest part would be testing the various ways it could be used to ensure it satisfies the community (you can have my vote for making elevator shafts), or creating a slightly different texture to use on the blocks to make it visually different (so players know the difference). Actually, naming them is probably the hardest part, now that I think about it.

I think of it like rotors... at least you can change the offset so as not to interfere with adjacent blocks on the parent grid... without having to put an entire block's worth of space between them.

That's all we're asking for, Keen. I think modders have already done this anyhow, but it should be in the base game. It would allow pistons to be utilized in more ways that are also less CLANG-y.

In my observations, this issue is hard to describe. It's really just the fact that piston heads (not necessarily the piston itself) and the sub-grid they create cannot be placed directly adjacent to a block on the parent grid. The piston head and anything attached to it are a sub-grid and blocks on it cannot occupy the same space as a block on a parent grid. Placing the sub-grid adjacent to a parent grid block technically ends up taking up a small amount of the same space. The dimensions of the blocks technically aren't any different, but as a sub-grid, there needs to be at least a little empty space between blocks. This isn't accounted for in any way (I don't really have an easy solution) so it ends up falling on the physics engine to determine how to handle the collisions between the blocks. This appears to be what most players refer to as "CLANG". The ability to configure the forces of the piston are simply a stop-gap fix that happens to work because the physics engine can sorta handle it. However, push it too far and it blows up completely. Basically it's just very weird circumstances in the physics engine that produce some crazy high numbers for a moment... BOOM.

I don't expect Keen will resolve anything on the level of the physics engine, as that would likely be pretty difficult to do. Even slight modifications to how a physics engine works could have serious ramifications elsewhere, so I'd figure they'd avoid that.

The simple fix is to simply do what others have suggested. Create a few variations of armor blocks that have ever-so-slightly different collision models (similar to blast door blocks) so they can be placed directly next to the sub-grid of a piston. The models of these blocks don't actually have to be any different, though it seems very easy to create a slightly different sized cube (from a 3D modelling perspective). The hardest part would be testing the various ways it could be used to ensure it satisfies the community (you can have my vote for making elevator shafts), or creating a slightly different texture to use on the blocks to make it visually different (so players know the difference). Actually, naming them is probably the hardest part, now that I think about it.

I think of it like rotors... at least you can change the offset so as not to interfere with adjacent blocks on the parent grid... without having to put an entire block's worth of space between them.

That's all we're asking for, Keen. I think modders have already done this anyhow, but it should be in the base game. It would allow pistons to be utilized in more ways that are also less CLANG-y.

Reply URL

1

Christoph Ninding ●

To be fair the real problem is just the piston head collision box. I don't see how "fixing" it would create any problems, but I'm probably just lacking insight.

URL

1

Sammiches ●

I'm not sure that's correct. Just last night I was creating an elevator (a stack of 4 pistons) and I was able to wrap a number of blocks around the pistons as adjacent blocks directly on the parent grid. Essentially, I created a spiral staircase that reaches the top of the highest piston, which is where you board the elevator that goes up 40 additional meters. The wrapping staircase was made using the new stairs and catwalk blocks.

Originally, I was thinking that Keen made those blocks use slightly smaller collision models, which had me pretty stoked. Then I placed one of them on the head of the top piston (where you ride the elevator) and it started interfering with other adjacent blocks (even catwalk blocks). So my hopes were dashed and I knew I needed my elevator shaft to be 3x3 unless I wanted to stand directly on the piston head.

So basically this exact problem occurred again as soon as I placed a non-piston block on top of a piston. Piston blocks seem to be an exception, since none of the piston bodies or heads that slide past the spiral staircase blocks seem to interfere in the slightest. All smooth! So I don't believe that the piston heads' collision models are a problem. Just the collision models of blocks you place on top of them. Ex: placing conveyor tubes works just fine in tight spaces because they have much smaller collision models. I take advantage of this often to create compact piston mechanisms that extend quite far for their retracted size.

A quick test can confirm this. Make a grid (in space, not attached to voxels), attach a piston, surround the piston in normal armor blocks, stack them so high that your retracted piston (and head) are buried a few blocks deep, then extend the piston. It should rise out of the 1x1 hole with no CLANG, not interfering with adjacent blocks on the parent grid. The same should happen if you stack a second piston. It should be smooth. HOWEVER, the moment you attach a normal (conventional full collision model) block to the tip of the piston, it will NOT go into the hole. The piston will stop short, create phantom CLANG forces that move/spin your parent grid, or if your tensor settings are high enough, it will simply explode. If you try to attach the block to the retracted piston head (while it's buried in the 1x1 hole), if you are even able to place the block at all, it will almost certainly jump around a bit and then explode half a second later.

I've done quite extensive testing with rotors, pistons, and all manner of sub-grids in many of my builds. I cannot remember the last time I created any ship or vehicle that was a single grid. IMO, that's not what this game is about. I'm not saying that I'm 100% correct here. Just offering information based on my observations while creating sometimes ridiculous contraptions.

I'm not sure that's correct. Just last night I was creating an elevator (a stack of 4 pistons) and I was able to wrap a number of blocks around the pistons as adjacent blocks directly on the parent grid. Essentially, I created a spiral staircase that reaches the top of the highest piston, which is where you board the elevator that goes up 40 additional meters. The wrapping staircase was made using the new stairs and catwalk blocks.

Originally, I was thinking that Keen made those blocks use slightly smaller collision models, which had me pretty stoked. Then I placed one of them on the head of the top piston (where you ride the elevator) and it started interfering with other adjacent blocks (even catwalk blocks). So my hopes were dashed and I knew I needed my elevator shaft to be 3x3 unless I wanted to stand directly on the piston head.

So basically this exact problem occurred again as soon as I placed a non-piston block on top of a piston. Piston blocks seem to be an exception, since none of the piston bodies or heads that slide past the spiral staircase blocks seem to interfere in the slightest. All smooth! So I don't believe that the piston heads' collision models are a problem. Just the collision models of blocks you place on top of them. Ex: placing conveyor tubes works just fine in tight spaces because they have much smaller collision models. I take advantage of this often to create compact piston mechanisms that extend quite far for their retracted size.

A quick test can confirm this. Make a grid (in space, not attached to voxels), attach a piston, surround the piston in normal armor blocks, stack them so high that your retracted piston (and head) are buried a few blocks deep, then extend the piston. It should rise out of the 1x1 hole with no CLANG, not interfering with adjacent blocks on the parent grid. The same should happen if you stack a second piston. It should be smooth. HOWEVER, the moment you attach a normal (conventional full collision model) block to the tip of the piston, it will NOT go into the hole. The piston will stop short, create phantom CLANG forces that move/spin your parent grid, or if your tensor settings are high enough, it will simply explode. If you try to attach the block to the retracted piston head (while it's buried in the 1x1 hole), if you are even able to place the block at all, it will almost certainly jump around a bit and then explode half a second later.

I've done quite extensive testing with rotors, pistons, and all manner of sub-grids in many of my builds. I cannot remember the last time I created any ship or vehicle that was a single grid. IMO, that's not what this game is about. I'm not saying that I'm 100% correct here. Just offering information based on my observations while creating sometimes ridiculous contraptions.

URL

1

Acynder Ignitus ●

I would like the ability to trigger simple actions when a piston or a rotor reaches and stops reaching one of its limits.

Like:

Action one: Piston reaches Botton Limit

Action two: Piston is no longer on Botton Limit

Action three: Piston reaches Top Limit

Action four: Piston is no longer on Top Limit

I know that actions 2 & 4 seems redundant, but some uses necesitates these and since the sume is 4 like the buttom panel, I feel that is adecuate. Also Sensors have this feature so I think that is logical for both actuators (Pistons and rotors) to have it.

URL

1

Jonni ●

Sammiches. YOu might be right. I didn't have any clang with my "transforming" attempts, until I decided my platform should go inside the parent grid--so it looks better when retracted because it's inside the parent grid. I was stoked to find out the things on the piston were treated seperately and could actually go inside. However I soon discovered problems with clang, especially when i added another pistons for what I thought would add stability. It ended up exploding and shooting off like a rocket :/

URL

Pistons, alot of people have issues.

Replies (2)