Rotor + Piston Stability (Multiple Grid Ships)

At the moment it is very hard to make a ship with rotors and pistons (Which I will refer to as mechanics) while also making it possible to fly it.
Mechanics will break, and I don't think any amount of stability programming with their current functionality will help (I may be mistaken, I'm not a professional physics programmer)

I would like a variation for mechanical blocks that acts slightly different, and I would propose they would be named "Piston (Stable)" and "Rotor (Stable)".

The differences should be as follows:
1) They will act as part of the grid that it was placed on, and this "super-grid" will act uniformly in terms of inertia.
This means that if I ram your ships extendable arm, I will still do damage to it, but instead of applying force to just the arm, that then in turns transfer inertia to the main grid of the ship, it will apply the force directly to the entire super-grid.

This will help in the fact that if I accelerate my ship my mechanical blocks wont break from just the acceleration, it also means that I don't have to worry about my ship suddenly spinning and self destructing because a rotor starts acting weird.

2) These stable mechanical blocks wont attempt to push through anything, if they are about to hit another block they will stop, this is to avoid physical bugs where stuff on the same super grid will attempt to apply force to each other (And in turn affect themselves, potentially creating super-insane-warp drives and self destructing ships, which we are trying to fix)

This will make for some other physics bugs that the current system does not have, especially if you were to squeeze a block or another ship between two stable pistons on the same grid, but that can be fixed through ship design.

3) The main use for these new mechanical blocks would be specifically for gates, moorings, collapsible wings and a variety of other contraptions which are currently very much impossible to do with current functionality.

4) This would have less of a strain on physics calculation as moving one part of the ship doesn't start a weird calculation where every grid connected to the ship will have to be calculated individually. It does mean however that whenever one of these new mechanical blocks move the center of mass will have to be recalculated, BUT as far as I know that calculation is a LOT less CPU intensive than the physics calculations (Depending on the size of the ship) and could very well be minimized by just averaging together the different grids (And only the ones connected with stable mechanical blocks) mass and center of mass.

Questions you might have.
Why should we keep the old functionality? Since it keeps breaking?
Elementary my Watson, my dear. Since the old functionality allows for some quite marvelous mechanical contraptions, and I would hate to see them go.

But if this new functionality is more stable, how would that inhibit mechanical contraptions?
Because if a super-grid can only be affected as a whole, and all force applied to them is applied to the super-grid, then for example tank treads cannot turn.

So mechanical contraptions wont be possible anymore you say.
No, I dont. I propose this as added as ANOTHER feature, NOT! as a replacement feature.

If I rotate or extend these new "Stable mechanical blocks", would they move the ship they are placed on?
Nope. Since they should not apply a force but much rather "animate" it. If your main grid is stationary, it would merely extend that part of the ship from the main grid, without applying any force to anything, meaning everything will stay stable.


Will this help improve Space Engineers?
I personally think it would, as it would increase the options for building, especially in multiplayer.
Some servers may even want to disable the old functionality due to the cpu and network intensity it adds.
It will allow cooler ship designs with wings that are slanted perfectly, retractable weapons, piston operated drills and MUCH MORE!


Everyone so far that has replied, thanks for the civil discussion, and I hope to gather more support for this idea so that we may finally have carrier ships with gates that doesn't suicide your ship.

The old original topic is down here below, since I edited it, so it is easier to understand.

<div>

</div>

 

Ah yes, I also made a topic for this once. Somebody else did too, and called it lock mode.
It seems to be already possible when using merge blocks, although it can be hard to apply especially for rotors

 

Actually I'm not talking about locking a rotor specifically.
I'd like them to still be able to rotate, pistons to move and so on, while physic engine wise making them part of the same origin grid.
(Basically if one grid moves, the rest moves AUTOMATICALLY with the, they don't get "dragged" like they do now)

This will allow deployable weapons, ship turrets and so on to work perfectly while sacrificing a slight bit of realistic physics, but I feel that is MORE than reasonable to have a mechanic work.

EDIT: For the locking with Merge Blocks, if they do this change that wont be necessary to do.

Honestly though, instead of having a setting I'd probably just have a new block (That functions almost identical to old rotors and pistons) with this change and name them Stable Rotor, Stable Piston. This would also put less strain on the CPU since (if made correctly) it will have to do less physics calculations and in turn optimize the game.

 

The General problem with this idea is, while being very convenient it is almost impossible to implement.
The reason for this is the rotation/push/pull being fully dependant on physics... You can't keep physics Rotation movement but stop the other physics impacts at the same time, unfortunately.

 

I disagree with that, quite a bit.

Firstly, this is going to be an option, and if implemented would probably be another piston and rotor block, as I do believe as well that old functionality has to be kept in the game.

What it would do is making every grid connected to the ship become 1 physical object. All of the mass of the grids is added together, and Center of Mass will have to be recalculated relatively often (And I think the physics calculations for separate physical objects are more CPU taxing, but I may be wrong).

If any force is applied to any grid on this 1 physical object it will affect the entire physical object instead of only affecting localized grids, which means if someone rams my turret it will take damage as normal BUT! the turret cannot in any way or shape be snapped off.
It does mean that a gyro on a turret will turn the entire ship and so on.

The places I would find this the most useful personally, would be gates, sloped wings with rotors, elevators, and so on. IT would obviously not be useful for any mechanical designs, but that is not the point of it.

I will say it could potentially bring out some different physic related bugs, especially pertaining to squashing an object between two pistons, and personally I do not know how that would mathematically pan out (And honestly I don't think anyone can )

It would be nice of one of the dev's could give us a pointer whether this is functionality that the physic engine already contains or if it is something that would be possible for them to make in a decent time frame.

I personally would find this a nice addition as it would improve the use of piston gates to ship designs (So you are not forced to wait for a gate design you like on the workshop), basically for mostly static things.

Also it would be a good idea making this the base way the connector works, and will reduce physics strain, although make it slightly more unrealistic. I still find that a good trade off.

 

The solution is very very easy: make everything on the other end of piston/rotors share center of mass with what they are attached to. Drag problem won't be fixed but atleast you can fly straight

 

I was thinking of attempting a rotor swept wing that "locks" into a connector to stop wobble. But never did try as there were just too many glitches.

My builds are on hold, as many have moving armour/wings etc and pistons for docking/cargo pods. They exploded far too often.

And "easy" (read easier and quick) fix is to "lock" pistons and rotor grids (relative, not to the same) grid when not in motion. The grid would still have the correct hit boxes etc, but would not wobble with ship movement.

 

If my suggestion is possible, this would quite literally be perfect for your builds then

That was one of the reasons why I wanted to do this suggestion (Along with gates on carrier ships)

 

This is no easy task it will cause huge calculation lag and a lot of work on their engine I'm not so sure about this one.

 

Just curious here, since I'm not the best programmer in the world (By even a tons of miles) but I've dabbled quite a bit in it on an amateur level.

From my perspective (If they can program it properly that is, but I'm still speaking from a relative sense of ignorance) it should actually reduce the physics strain since it would reduce the amount of physical objects that you have to calculate, would actually reduce the physic engine strain on the CPU.

I will say though I wont be able to say this is accurate without a dev confirming it.

Thanks for your input though!

 

Merge blocks and pistons/rotors/connectors seem to use a different method for connection. Merge blocks actually merge two ship grids while the others aplly position-keeping from one grid to another, which is why they can have rotation and displacement effects or connect large ships to small ones.

 

I agree. There's lots of things I'd like to build but don't because it will essentially self destruct and have been a tremendous waste of time.

Eventually I'd like to see the game offer a configurable level of physics realism. Personally I don't care about hyper-realism but for others it's an important aspect of the game.

 

Yeah, but sadly enough even Connectors don't have true "position-keeping". It merely attempts to transfer some inertia from one object to the next (In the connection trees), so they are not even a good enough option to help keeping the cool creations from suicideing.

 

If I have a 10x10x10 box... connected by a 10 block long 1x1 shaft, connected to another 10x10x10 block with thrusters and power and everything.

It'll move like ONE object. If I crash into an asteroid with just the empty 10x10x10 box, the box will receive it's damage, but because nothing is actually damaging the 1x1 shaft, it won't break, because it is infinitely strong for indirect stress. Only if it is broken by direct contact the ship will break.

The rotor completely ignores this, and works OUTSIDE of the current physics, towards a more realistic physics engine. It WILL snap off due to indirect stress.

This is inconsistent behaviour.

Either have the single block also fail, or have the rotor not fail. In my opinion, considering the amount of problems resulting from this behaviour (wobbling stuff on rotors, rotors failing etc), and considering the amount of advantages this mechanic adds (of which I cannot name an example). I'm thinking this is being made needlessly complicated. The game just needs to know that multiple grids are 'connected' and move as one entity (apart from their relative movement). This means differentiating between relative grid motion (rotation) and the motion of the 'supergrid'.

The rotor would just act as an infinitely tough 'joint' between two grids (just as any other block). The mass of both of these grids is added together. and any force imparted on them affects both, be it an external force, or, for example, a thruster. This would impart linear acceleration on the entire structure; rotating bits included. Just like the rest of the game does.

I honestly do not see the advantage of spending so much effort on calculating such complicated physics that basically only serve to annoy people. Maybe I'm overlooking something, so please correct me if I'm wrong, but I'm wondering why there even are physics like that? Do they serve a significant function other than it being there just because it's possible?

All you need is have each grid 'know' it's connected to another grid. From that point on, the grids act as one as far as physics go, and for indirect stresses, both the piston and the rotor will be infinitely tough when it comes to indirect stresses, just like any other block. This will save a large amount of physics calculations. And make a lot of builds possible, and also make the physics engine behave more consistently.

I may be thinking too simple, but this probably would also facilitate merging small and large grids.

 

There is a point in that functionality existing though, and that is for mechanical contraptions, since such wouldn't be possible with the Pistons and Rotors I speak of, that is why I opt for their to be two options: Current mechanics and a block variation maybe named "Stable" that works like you and I have described. Those will probably be the main one used on ships, while people that enjoys making mechanical contraptions can keep doing that

There is pro's and con's with both methods and I think both methods should exist because of that. It will make some really, truly unrealistic contraptions possible, but for gameplay purposes I think that is fine, considering the suicidal tendency of anything related to rotors and pistons

 

Could you explain how that would inhibit mechanical contraptions? Because, again, I'm probably missing something I'm honestly thinking it would FACILITATE them at this moment.

 

Because if you start doing physics where the local grid is the only grid capable of affecting individual parts of the grid, for example tank treads would be impossible due to the fact that any kind of force acted upon them from the outside would move them as one unit.

Same goes for any other number of mechanical contraptions which are dependent on either being bumped along landing gear tracks and so on. And if they started to program in tons of different exceptions to these new rotors and pistons they would probably end up more buggy and inconsistent as the new one.

I simply propose to keep the old functionality and add a new block to deal with the new functionality.

EDIT:
And there would probably a million contraptions I can't think of that would be hurt by not having the old functionality. I'm not big on building mechanical contraptions, so I wouldn't know.
I also simplified the original post.

 

You're misunderstanding... I know I'm doing a wonky job of explaining, and it's probably just me not finding the correct words to explain it (I don't really want to blame me not being a native English speaker, but it probably has its influence).

The grids themselves don't change. Anything that works now, would also work then... it's just missing the physics that make the rotorhead wobble, pop off or even explode.

I'm wondering why rotors (and pistons) have breaking physics for indirect stresses? No other block has that, and thusfar it actually only HINDERS creations... I cannot see the practical applications of those physics, so I'm wondering why the devs are doing all this effort to retain physics which don't seem to have a purpose other than having a type of realism that is absent in the rest of the game. Thrust is linear, but everything that's a rotor, a piston or a wheel has far more complicated physics... but to what end? It just needs to rotate, I don't get why those blocks have to have such inconsistently more realistic features than EVERY other block in the game?

Obviously rotor-attached grids wouldn't become one rigid entity, that would be silly and defeat the purpose of a rotor. The grids themselves would be as flexible as they are now, just connected more securely by something that only breaks when it is actually damaged.


I'm just wondering why indirect stresses damage rotors (and pistons), but as far as I know (apart from wheels) there's no other blocks that act this way. Especially since there's little realism in the way these physics work currently. I'm basically asking if it has a purpose other than 'just because'...

I'm actually suspecting something like a game-engine restriction being the cause for these weird inconsistencies in behaviour. As the actual physics do not seem to do the game any good, and instead consume a lot of time from the devs to make it work in a way which doesn't seem to serve a purpose.

Hope I'm clearer now...

 

When you say game-engine restrictions in terms of making perfect rotors and pistons you are most certainly correct. Without them being rigid, I am most certainly sure that such a thing wont work.

And you are also misunderstanding me obviously.

A rotor that works rigidly as part of a grid, but allows it to animate itself should be possible.

Which means rotors and pistons would still work, they just wouldn't work exactly as they do now.

I have in all my life seen a singly game that uses the physics engine to bind two objects together where the connection never wobbles (If the other object is capable of movement). Because of the math involved it can't be done.

That is why I was posting this thread for an alternative solution.

Instead of using the physics engine to turn and rotate stuff it would be more like a model animating, meaning that the physics of the ship it is on would never be affected.

If I made a big pendulum with a rotor and made it swing back and forth it would NEVER enact any force to the ship it is attached to, meaning neither the ship nor the pendulum wobbles, it only goes back and forth.

Do you wish further clarification or was this explanation good enough?

 

Thank you very much for your explanation. Though I'm still wondering about a few things:

- Can you explain why merged grids with rotating parts would be unable to use tank threads (for example). Because the way I see it, there's something moving, that movement may not impart a seperate centre of gravity on the main ship... but it still moves. Tank threads won't ever be a part of the same 'grid', because even in reality, the tracks are merely 'held onto' the main vehicle, but they're not permanently attached. Having a supergrid that works similar to grids right now shouldn't prevent something like this to be honest.

- Can you explain to me exactly why the math involved couldn't be done, and what the source of this information is? Since you kind of clearly stated in your opening post that this was outside of your area of expertise, I find such a claim a little bit odd to be honest.

- Why do we need new parts for this? If it would be so easy to add, wouldn't it make sense to just fix the rotors?

I'm sorry, I kind of like your general idea, but the details seem a little off to me.

Also, to anyone, I'm still wondering why we're applying physics to functional blocks, while we don't to normal blocks, and it kind of seems those physics don't even serve a purpose other than 'being there'.

 

Because even if another grid (The tank tread) is attempted to be moved around, all the inertia that is applied to the tank tread would then be applied to the whole tank tread structure, which in turn means it wouldn't be able to be forced to turn around.
I know that it may sound weird, but if something is considered a super grid and will act in unison to force applied to the structure, the forces applied wouldn't be able to just turn one section, and if you try to turn it in one direction at one side, and another direction the other side, the forces would cancel out.

I admit I might have bit a bit brash on that one, it is more from the experience of playing similar games that allows rotating hinges and non-rigid connections between objects, while being physics simulated. I have so far not seen a single game where connections (Even infinite strength ones) doesn't start "pulling slightly apart" and wobbling. It seems to me that to avoid a ton of physics glitches, programmers may be doing the pulling slightly apart thing to make sure that the force is transferred between connected structures in a semi-realistic manner, without infinity popping out of the math (May be an exaggeration, but some weird numbers can pop out in complex math like these physics calculation)
I may be wrong in this, but I feel I am getting the gist of it.

Well, the reason for the new part instead of "fixing" the rotors is two fold.
Firstly as I attempted to explain previously, because making super grids where force is applied uniformly across the entire structure would mean that old functionality would be lost, and I seriously doubt that adding a toggle option to the current rotors would be a good idea. (Just look at merge block's buggy behavior)

And I'm not the best person in the world to explain so I'm more than happy to clarify as many times as needed So keep asking if you are in doubt of what I mean.

Physics is being applied to everything in the game except for asteroids.
From items to asteroid fragments, blocks to rotors. And they all use the same physic engine, and all act similar, subjected to the same forces.

The difference is, the way they made rotors and pistons work so far require them to be two distinctly different blocks that are connecting through the physic engine.

I hope this clarified a little bit at least.

 

I'm starting to understand, though I think you're a little wrong on how the tank-thread would work.

But I digress, we can discuss this ad infinitium, but without knowing how the physics ACTUALLY work, it'll just be guesswork. That's mainly why I'm asking the question I am asking; why are the physics being applied to movement that is not part of the design of the mechanism? Since rotors only need to rotate (and extend a little), why allow sideways movement?

I don't think either of us can, or is qualified to, answer that question...

Thanks for your patience in explaining though!

 

As far as I understand, do not quote me on this though, it comes down to rounding errors in floating point numbers as well as the fact that if the structure is to rigid (Since it is bound by physics calculations) it may result in some truly weird behavior. If you have ever played in GMod and you tie stuff together correctly you are capable of making bouncy balls that bounce on their own. Really weird stuff.

 

Nope. Your conception is wrong.
This game will drown in ocean of bugs and die painful and slowly.
Just because devs can.

Не надейся, дружок-пирожок. Фигня твоя концепция.
Этой игре суждено долго и мучительно помирать в океане багов.
Просто потому что разрабы могут. (а точней не могут)

 

Welp, guess I'll just trash this game now. Thanks for the warning m8

 

[sarcasm]That was truly something that added to the discussion[/sarcasm]

 

Sarcasm not needed.
I just want to say that it's pretty cool idea (whole discussion is very good), but devs can't done this anyway.

(i hope translate was valid)

И не надо сарказма.
Я просто хотел сказать, что все что вы тут напредлагали, конечно очень здорово и я сам это поддерживаю, да вот только разрабы за это ни за что не возьмутся, как ни крути.

 

It would seem that either Keen has not seen this thread, (and they seriously should) or that they do not wish to (or intend to) respond to this thread. In either case this is exactly what Keen should do as the game is in its current state most of the ships that I have built are only good as stations, I have become so frustrated with the lack of ENGINEERING that is possible in Space Engineers ,that I have stopped playing it. It is very unrewarding to see your creations break when you move them. I noticed that in their request for players to submit ship designs for use in their game that they stated not to use pistons or rotors. If this isn't fixed Space Engineers needs to be renamed to Space Ship and Station Designer/ Minecraft, as the ENGINEERING part will not exist. Is this a rant? Hell yeah it is, I'm tired of and upset that I have wasted sooooooo much time building ships and designing stations to resupply and repair my ships only to watch it all turn to S**t as soon as I move them. I realize that the game is still in early release stages and that Keen is using all of us as play testers, who by the way paid them to do so (which I now regret and will never do again for any company and I honestly feel like if they don't fix this game they should reimburse and back pay us all.)FIX OUR GAME KEEN!!!!!!!!!

 

Thanks for your rather passionate response

Do remember though that the current systems allows you to build engineered devices (But not really useful for ships though), while my concept here (That will work beside the old system) does not allow you to engineer in the same manner

As you said, I would really like Keen to make this suggestion and keep the old functionality meanwhile, as it would mean we could have our ships with hangar doors, retractable landing gear and so on without worrying about center of mass nor about stuff breaking every two minutes.