Space Engineers Any Way to Read a Tread Stations

Thread Status:: This last mail service in this thread was made more than than 31 days erstwhile.

At the moment information technology is very hard to make a transport with rotors and pistons (Which I volition refer to as mechanics) while also making it possible to fly information technology.
Mechanics will intermission, and I don't think whatever corporeality of stability programming with their current functionality will help (I may be mistaken, I'g not a professional physics programmer)
I would similar a variation for mechanical blocks that acts slightly unlike, and I would propose they would be named "Piston (Stable)" and "Rotor (Stable)".

The differences should exist every bit follows:
i) They will human activity every bit part of the filigree 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 withal do damage to information technology, just instead of applying strength to simply the arm, that then in turns transfer inertia to the main grid of the ship, information technology will employ the forcefulness 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 send suddenly spinning and self destructing considering a rotor starts interim weird.

2) These stable mechanical blocks wont attempt to push through anything, if they are near to hitting another block they volition terminate, this is to avert physical bugs where stuff on the aforementioned super grid will try to apply force to each other (And in plow impact themselves, potentially creating super-insane-warp drives and cocky destructing ships, which we are trying to fix)

This will brand for some other physics bugs that the current arrangement does not have, especially if you lot were to squeeze a block or another ship between ii stable pistons on the aforementioned grid, but that can be fixed through ship blueprint.

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

iv) This would have less of a strain on physics adding equally moving 1 part of the transport doesn't get-go a weird adding where every grid connected to the ship volition have to be calculated individually. It does mean however that whenever one of these new mechanical blocks movement the center of mass will have to exist recalculated, BUT equally 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 eye of mass.

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

Merely if this new functionality is more stable, how would that inhibit mechanical contraptions?
Because if a super-grid can only be affected equally a whole, and all forcefulness applied to them is applied to the super-grid, then for case tank treads cannot plow.

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

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

Will this assist improve Space Engineers?
I personally think it would, equally it would increase the options for building, particularly in multiplayer.
Some servers may even want to disable the sometime functionality due to the cpu and network intensity it adds.
Information technology will allow cooler send designs with wings that are slanted perfectly, retractable weapons, piston operated drills and MUCH More than!

Anybody then far that has replied, cheers for the civil discussion, and I promise to gather more support for this thought so that nosotros may finally have carrier ships with gates that doesn't suicide your send.

The old original topic is downward here beneath, since I edited it, so it is easier to sympathise.

<div>
</div>

Last edited by a moderator: Nov 17, 2014
w0ps Apprentice Engineer

Ah yes, I also made a topic for this once. Somebody else did too, and called information technology lock fashion.
It seems to be already possible when using merge blocks, although information technology can be hard to utilise especially for rotors
Really I'grand not talking nearly locking a rotor specifically.
I'd similar them to still be able to rotate, pistons to move and then on, while physic engine wise making them part of the aforementioned origin grid.
(Basically if ane grid moves, the rest moves AUTOMATICALLY with the, they don't get "dragged" like they do now)
This will allow deployable weapons, send turrets and and so on to work perfectly while sacrificing a slight chip of realistic physics, simply I feel that is More than than reasonable to have a mechanic work.

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

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

Last edited past a moderator: Nov 14, 2014
The General trouble with this idea is, while being very convenient it is nearly impossible to implement.
The reason for this is the rotation/push button/pull being fully dependant on physics... You can't keep physics Rotation movement but stop the other physics impacts at the aforementioned fourth dimension, 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, equally I do believe likewise that sometime functionality has to be kept in the game.

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

If whatsoever strength 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 every bit normal Only! the turret cannot in any way or shape be snapped off.
It does mean that a gyro on a turret volition turn the entire ship then on.

The places I would notice this the about useful personally, would exist gates, sloped wings with rotors, elevators, and so on. Information technology would evidently 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 betwixt 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 1 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 utilise of piston gates to transport designs (And then you are non forced to wait for a gate pattern yous like on the workshop), basically for mostly static things.

Too it would be a practiced idea making this the base way the connector works, and volition reduce physics strain, although make it slightly more unrealistic. I still notice that a good trade off.
The solution is very very piece of cake: brand everything on the other end of piston/rotors share middle 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 but besides many glitches.
My builds are on hold, as many take 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 aforementioned) filigree when not in motility. The grid would still have the right hit boxes etc, simply would non wobble with ship movement.

Last edited by a moderator: Nov 14, 2014
If my suggestion is possible, this would quite literally be perfect for your builds then
That was ane of the reasons why I wanted to exercise this suggestion (Forth with gates on carrier ships)
This is no easy task it will cause huge adding lag and a lot of work on their engine I'm non so sure about this one.
Just curious here, since I'1000 non the all-time programmer in the earth (By even a tons of miles) but I've dabbled quite a scrap in it on an amateur level.
From my perspective (If they can programme it properly that is, but I'thousand nevertheless speaking from a relative sense of ignorance) information technology should really reduce the physics strain since it would reduce the amount of physical objects that you accept to calculate, would actually reduce the physic engine strain on the CPU.

I will say though I wont exist able to say this is accurate without a dev confirming information technology.

Thank you for your input though!
Merge blocks and pistons/rotors/connectors seem to apply a dissimilar method for connectedness. Merge blocks actually merge 2 ship grids while the others aplly position-keeping from ane grid to another, which is why they can have rotation and displacement effects or connect large ships to modest ones.
infAl Amateur Engineer

I agree. There's lots of things I'd like to build but don't because it volition essentially self destruct and have been a tremendous waste of time.
Eventually I'd similar to see the game offering a configurable level of physics realism. Personally I don't care about hyper-realism only for others information technology'southward an of import aspect of the game.
Yeah, but sadly enough even Connectors don't take true "position-keeping". It simply attempts to transfer some inertia from ane object to the next (In the connexion trees), so they are not even a good plenty option to help keeping the cool creations from suicideing.
If I accept a 10x10x10 box... connected past 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 only the empty 10x10x10 box, the box will receive it's harm, but considering aught 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 volition intermission.

The rotor completely ignores this, and works Exterior 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 unmarried block also fail, or have the rotor not neglect. In my opinion, because 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 beingness made needlessly complicated. The game only needs to know that multiple grids are 'connected' and motility as one entity (apart from their relative movement). This means differentiating between relative grid motility (rotation) and the motion of the 'supergrid'.

The rotor would simply act as an infinitely tough 'joint' between 2 grids (just every bit 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 instance, a thruster. This would impart linear acceleration on the entire structure; rotating bits included. Simply similar the residual of the game does.

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

All y'all need is take each grid 'know' it's continued to another grid. From that bespeak on, the grids act every bit one equally far every bit physics become, and for indirect stresses, both the piston and the rotor will exist infinitely tough when it comes to indirect stresses, simply like any other block. This volition save a big corporeality of physics calculations. And make a lot of builds possible, and also make the physics engine carry more than consistently.

I may exist thinking too simple, but this probably would also facilitate merging pocket-sized and large grids.
There is a point in that functionality existing though, and that is for mechanical contraptions, since such wouldn't exist possible with the Pistons and Rotors I speak of, that is why I opt for their to exist two options: Current mechanics and a block variation perchance named "Stable" that works similar yous and I have described. Those volition probably be the main ane used on ships, while people that enjoys making mechanical contraptions tin can keep doing that
There is pro'due south and con'due south with both methods and I think both methods should be because of that. Information technology volition make some really, truly unrealistic contraptions possible, but for gameplay purposes I retrieve that is fine, considering the suicidal trend of anything related to rotors and pistons
Because if you start doing physics where the local grid is the only grid capable of affecting individual parts of the filigree, for example tank treads would be impossible due to the fact that any kind of force acted upon them from the outside would movement them as one unit.
Same goes for any other number of mechanical contraptions which are dependent on either being bumped forth landing gear tracks and so on. And if they started to program in tons of dissimilar exceptions to these new rotors and pistons they would probably end up more than buggy and inconsistent as the new one.

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

EDIT:
And there would probably a meg contraptions I can't think of that would be injure by not having the old functionality. I'yard non large on building mechanical contraptions, and so I wouldn't know.
I also simplified the original postal service.

Concluding edited past a moderator: Nov 17, 2014
You're misunderstanding... I know I'm doing a wonky job of explaining, and it'south probably just me not finding the correct words to explain it (I don't actually want to blame me not being a native English language speaker, only it probably has its influence).
The grids themselves don't change. Anything that works now, would also work and then... it'due south merely missing the physics that brand the rotorhead wobble, pop off or fifty-fifty explode.

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

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

I'm merely wondering why indirect stresses harm rotors (and pistons), but as far equally I know (autonomously from wheels) there's no other blocks that act this manner. Especially since there's petty realism in the manner these physics piece of work currently. I'm basically request if information technology has a purpose other than 'just because'...

I'one thousand actually suspecting something like a game-engine brake beingness the cause for these weird inconsistencies in behaviour. Every bit the actual physics practise non seem to exercise the game any proficient, and instead consume a lot of time from the devs to brand information technology work in a way which doesn't seem to serve a purpose.

Hope I'm clearer now...
When y'all say game-engine restrictions in terms of making perfect rotors and pistons you are about certainly correct. Without them existence rigid, I am most certainly sure that such a affair wont work.
And you are also misunderstanding me obviously.

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

Which means rotors and pistons would still work, they but wouldn't piece of 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 connectedness never wobbles (If the other object is capable of movement). Because of the math involved information technology tin 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 animative, meaning that the physics of the ship it is on would never exist affected.

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

Do you wish further clarification or was this caption good enough?
Thank you very much for your caption. Though I'm nonetheless wondering well-nigh a few things:
- Can you explicate why merged grids with rotating parts would be unable to use tank threads (for example). Because the way I see information technology, there'southward something moving, that move may not impart a seperate centre of gravity on the principal transport... just it however moves. Tank threads won't ever be a role of the same 'grid', because even in reality, the tracks are simply 'held onto' the primary vehicle, simply they're not permanently fastened. Having a supergrid that works similar to grids right now shouldn't prevent something like this to exist 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 conspicuously stated in your opening postal service that this was outside of your area of expertise, I find such a claim a little bit odd to exist honest.

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

I'm sad, I kind of similar your general idea, but the details seem a lilliputian off to me.

Too, to anyone, I'm nevertheless 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'.
Considering even if another grid (The tank tread) is attempted to exist moved around, all the inertia that is applied to the tank tread would then be applied to the whole tank tread structure, which in plow means information technology wouldn't be able to be forced to plough effectually.
I know that it may audio weird, but if something is considered a super grid and will act in unison to strength applied to the structure, the forces practical wouldn't be able to just turn ane section, and if you try to turn it in one direction at one side, and another direction the other side, the forces would abolish out. I admit I might accept bit a bit brash on that 1, it is more from the experience of playing like games that allows rotating hinges and not-rigid connections between objects, while being physics simulated. I have so far non seen a single game where connections (Fifty-fifty infinite forcefulness ones) doesn't starting time "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 betwixt connected structures in a semi-realistic mode, without infinity popping out of the math (May be an exaggeration, merely some weird numbers can pop out in complex math like these physics calculation)
I may be incorrect in this, but I feel I am getting the gist of information technology. Well, the reason for the new function instead of "fixing" the rotors is two fold.
Firstly as I attempted to explain previously, considering making super grids where strength is applied uniformly beyond the unabridged 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 proficient idea. (Simply look at merge cake'south buggy behavior)
And I'm not the best person in the globe to explain so I'm more than than happy to clarify as many times as needed So keep asking if you are in doubt of what I hateful.
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 like, subjected to the same forces.
The difference is, the way they fabricated rotors and pistons piece of work so far crave them to be two distinctly different blocks that are connecting through the physic engine.

I hope this clarified a trivial bit at least.
I'm starting to empathize, though I think you're a little incorrect on how the tank-thread would work.
But I digress, we tin discuss this advertisement infinitium, simply without knowing how the physics ACTUALLY work, information technology'll but be guesswork. That'due south mainly why I'g asking the question I am request; why are the physics beingness applied to movement that is not function of the pattern of the mechanism? Since rotors only need to rotate (and extend a little), why allow sideways movement?

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

Cheers for your patience in explaining though!
As far as I empathise, do non quote me on this though, information technology 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 past physics calculations) it may result in some truly weird beliefs. If you lot accept e'er played in GMod and you tie stuff together correctly you are capable of making bouncy balls that bounciness on their own. Really weird stuff.
Nope. Your conception is wrong.
This game volition drown in ocean of bugs and die painful and slowly.
Just because devs tin can.
Не надейся, дружок-пирожок. Фигня твоя концепция.
Этой игре суждено долго и мучительно помирать в океане багов.
Просто потому что разрабы могут. (а точней не могут)

Terminal edited past a moderator: November eighteen, 2014
Welp, guess I'll but trash this game at present. Cheers for the alert m8
[sarcasm]That was truly something that added to the discussion[/sarcasm]
Sarcasm not needed.
I only want to say that it's pretty cool idea (whole discussion is very practiced), but devs can't done this anyway.
(i promise translate was valid)

И не надо сарказма.
Я просто хотел сказать, что все что вы тут напредлагали, конечно очень здорово и я сам это поддерживаю, да вот только разрабы за это ни за что не возьмутся, как ни крути.
Information technology would seem that either Keen has not seen this thread, (and they seriously should) or that they do not wish to (or intend to) reply to this thread. In either instance this is exactly what Keen should practice as the game is in its electric current state well-nigh of the ships that I have built are only adept as stations, I have become so frustrated with the lack of Applied science that is possible in Space Engineers ,that I take 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 non to use pistons or rotors. If this isn't fixed Space Engineers needs to be renamed to Infinite Send and Station Designer/ Minecraft, every bit the Applied science part will not exist. Is this a rant? Hell yes information technology is, I'm tired of and upset that I accept wasted sooooooo much time building ships and designing stations to resupply and repair my ships only to watch it all turn to South**t as soon as I move them. I realize that the game is still in early release stages and that Not bad is using all of us as play testers, who by the fashion paid them to do then (which I now regret and will never do again for whatever company and I honestly feel like if they don't fix this game they should reimburse and back pay united states all.)FIX OUR GAME KEEN!!!!!!!!!
Thanks for your rather passionate response
Practise recall though that the current systems allows you to build engineered devices (Just not actually useful for ships though), while my concept hither (That will work beside the old system) does not allow you to engineer in the same manner

Equally you said, I would really like Not bad to make this proposition and go on the old functionality meanwhile, as it would mean we could have our ships with hangar doors, retractable landing gear and and then on without worrying about center of mass nor about stuff breaking every two minutes.