[BLOCK SUGGESTION] Lead Screw and Nut

DIO_SVK shared this feedback 2 years ago

Your 3D Printer have them so why not SE?

Lead Screw Block that can be stackable (eg. make 1x100 Screw) and Nut that goes to elevator platform.

For Lifts, Elevators, Doors.c03b929df79c83fbdc1cd181faae709b

Replies (1)


Good idea. Although personally I'd prefer if it was implemented somewhat simple still.

Namely, as a linear motor. Imagine something like a landing gear or magnetic plate, but with propulsion that acts while it sticks to a surface, either a dedicated rail block or any other armor block. This could provide propulsion without tempting clang due to it not needing any wheel physics. From a code perspective, while in contact, the blocks could be simply "defined" and "assumed" to be in alignment without needing to derive those properties with expensive collision checks, or at least with significantly less expensive checks as there are now fewer degrees of freedom left to be calculated.


The whole idea is just add infinite piston with fancy spining animation that not involve any Havok simulation.

The moving part of SE piston will be the "NUT" while piston base part will be "screw" that adopt to the size of screw.

Current version of SE Allow to make this as MOD but i have motivation to make a such a MOD.

I not like the way KeeN do stuff so i will not waste time making mod for this idea.


Infinite piston would imply that there be a base part along the direction of movement. Given how you replied specifically to my post, not to OP: that's not what I want. I specifically do not want a part that's at least at one end of the moving part, and forms the end stop in that direction. I want something that acts like a driven wheel but also, as said, like a landing gear or magnetic plate:

  • sticky
  • laterally movable
  • capable of active propulsion

And all of it on a toggle each, so that it

  • can stick or be detached from the surface (if it runs over an edge into empty space, it should not follow the contour and should detach on its own)
  • be movable or be fixed
  • be movable both under its own propulsion or under external force, either if propulsion is off or if the external force is stronger than the propulsion

Besides, game engines do not like "infinite" things; that's another reason why I wouldn't want it like that.

And the main motivation against "why not just use wheels then" is because wheels on blocks is dodgy. A functional block specifically made for sliding could potentially simplify the physics involved as it has fewer degrees of freedom than a bouncy suspended wheel and could therefore be simulated safer and faster.


I just want to say KeeN to make something without need to add new code.

Piston already can do this you only need to tell him to extend moving area when adding new block to stack (screw_part).

In Source Engine (Half-life2 / Portal) you have (func_movelinear)


SE Piston is basically this but KeeN limited travel area to only 3 blocks.

SE have huge problem with subgrids (piston_head, Rotor_head, Wheel) de-sync as "microshake".

Using wheels (subgrids) for lift is just sim-speed killer

Using Piston on Piston on Piston is good way to summon clang and eventualy have sim speed of 0.5 as CPU will be on fire computing positions of every subgrid you added to the piston stack.

That is why i say that piston head (moving part) will be nut and static will be screw that can be extended. Nut will not spin, only linear move and screw will spin.

Again I just want KeeN to make something without need to add new code, as that brings new bugs.

One minecraft clone had primitive Door_Rail that just push/pull block on that rail and you can create nice lifts and custom doors.


Any reason on insisting to spell "Keen" in a way that is currently in no way official, endorsed, sanctioned, tolerated, or otherwise reliably documented?

Anyway. Yes, there may be such a function in Havok. No, I never said I wanted something with subgrids. No, I don't want piston on piston. Yes, that Havok function may be a solution … if one wanted a longer piston. But I don't want a longer piston. I specified exactly what my user story entails, as in, what I, as a user, want to be able to do in the product, and AAU I don't care what code magic it uses under the hood to facilitate that. If your implementation does not match my user story, then your implementation does not fulfill my requirements. Yes, you may have different requirements, and for different reason, and by all means have them, I respect that. But you can go raise them somewhere else, and not in direct dismissal of my requirements.

Leave a Comment
Attach a file