Thrust Mechanics Explained

[Ithirahad]

I think we need an EMP buff or rework mechanics-wise, then...

 

[cyberus111]

Its now 2 weeks shy of a year since the original post, are we ever going to see an improved thrust system?

 

[Drakkart]

a few problems i see with this concept.

1st i just see it as an additional gui thing because everyone will need all 6 directions maybe a bit more on the forward thrust. meaning from your 100% pool you are taking 1/6 and put that in every direction. basically cutting down effectiveness of thrusters to 1/6 which is an aweful change for the slight gain.

also assigned %age relates to %age server max speed - seriuosly?
how about thrust total assigned to direction vs mass of the ship determines max speed?

exponential power usage... i thought i'd hate that... but seriously i love it. This will cripple capital ships which could be considered a bad thing but think about it our capships right now are agile as fighters so with the new system i finally see small ships becoming less useless which i really appreciate.

regarding the effects sorry TL;DR not relevant for my estimation of the thrust system. what i really do not like still is that you guys just told us that 2:1 thrust:mass ratio ships will crawl in the future and that still sucks.

hyperdrive - don't like it to much drawback.

Also with these changes coming i want to pledge for a seperation of sector space and max server speed because in order to really have agile fighters they need to be able to dodge stuff they are getting shoot with and i don't want sectors to be 10k wide tall and long to achieve that.

please take this into consideration.

 

[cyberus111]

I don't see any problems, given that this is the One Year Anniversary of the op and zero movement on *actually* changing thrust

 

[Ithirahad]

Yeah, after shipyards and fauna are done we could really use this, along with rail optimization and stuff. However, compared to all of this stuff with GUI and changing percentages, wouldn't it be a lot easier to just add a second, more powerful type of thruster that only adds forward thrust, then make the current thrusters also provide a (somewhat minor) turn rate boost?

 

[cyberus111]

Yeah, after shipyards and fauna are done we could really use this, along with rail optimization and stuff. However, compared to all of this stuff with GUI and changing percentages, wouldn't it be a lot easier to just add a second, more powerful type of thruster that only adds forward thrust, then make the current thrusters also provide a (somewhat minor) turn rate boost?

Sadly, given the deafening silence from developers on the subject the this thread started 1 year ago today even though the thread is stickied it *seems* to be an orphan. <waits for fanboi assault>

 

[Parameter]

I'm just very disappointed that thrust is being discussed as a % of max speed. Thrust is all about accelerating mass. It has nothing to do with the maximum speed of an object. That is determined by its structural integrity and the "drag" of the medium you're flying through. Starmade simplifies that by imposing a hard limit on max speed. Why should that speed be different for ships of different size?

This is space. If I have a tiny thruster on a big ship I should accelerate sloooowly, but eventually reach max speed. Slow acceleration is what balances small ship movement versus capital ships. Is the capital ship chasing me? I better make good use of the 5-10 seconds the capital ship needs to get to max speed in order to put some distance between us. Maybe once it's up to speed I can fake it out in that upcoming asteroid field. By the time it slows down enough to turn I'll be hidden among the giant rocks.

Did I get ambushed by a capital ship? I need to get out of the field of view of its guns. It's dangerous, but if I can get close to it I can fly by it faster than it can turn to track me.

Thrust to mass should be the main deciding factor on ship acceleration. There's no air resistance is space (Starmade space drag not withstanding), so dimensions shouldn't play any part in it. You can still play games with thrust/block/energy and scalability to shape how quickly you want ships of different masses to move. I even like the concept of different thrust amounts for different degrees of freedom.

That said, please don't apply arbitrary speed limits beyond the "speed of light." It makes me sad.

 

[Tobyz28]

This is perfect, the only addition I have is that thrust vector changes should require a reboot to apply changes .

Greetings Citizens!

As there are still planned improvements to the way the game and ship designers handle thrust (Which will be explained further on in this thread), I have continued to look for optimal basic mechanics for the thrust blocks on which the control system will be built. Players have asked that more discussion be had with the community well in advance before any more such changes occured, so this thread is to gather opinions on the proposed solution.

(Please note, this is not in the suggestion forum, it is meant to detail the plans for the Directional Thrust system and to explain and ask for opinions on a change to the basic thrust blocks values. If you have a suggestion on alternate methods of setting up the thrust in the game, please use the suggestion forum.)
​

I'll start by explaining the change that I am looking for opinions on first, and below that I will explain the Directional Thrust system that we have planned so that you can better see how the scope of changes might affect gameplay later on.

Linear Thrust, Exponential Power Usage​

Currently the thrust blocks on a ship are added up to determine the amount of thrust a ship gains. The thrust gained per block is slightly less for every additional block added, while the power usage is linearly based on the amount of thrust granted.

1 thrust block = 4.4 ship thrust & 4.4 power used
100 thrust blocks = 1795 ship thrust & 1795 power used
*Rough estimates*
​

The change to thrust blocks we are considering is to make the thrust gained per block linear, while putting the power usage on an exponentially increasing curve.

1 thrust block = 5 ship thrust & 5 power used
100 thrust blocks = 5000 ship thrust and 7500 power used
*Rough example*​

What this means is that ships can achieve higher amounts of thrust with the same number of blocks that they have now, however, this increase comes with an even higher cost to power the more thrust blocks their are on a ship. However, larger ships incurring this larger power usage can mitigate this power usage by slowing down when they need more power, or stopping entirely.

This is the change that I would like to ask for your opinions on in the comments below.
Thank you.​

Overall Plan for Movement​

• Direction Thrust Setting

This topic has previously been discussed in Q&A's, but it has been some time since those and most players are unaware of this planned system. So I'll try to catch you up on what we would like to try to set up for improved directional designs for ships.

Currently a player need only place thrust blocks anywhere on their ship without concern for orientation or location. They are then granted an amount of thrust that may be applied in any direction. Although simple, this leads to things like capital ships flying maximum speed backwards while firing their primary guns at any ship persuing them.

While it would be technically possible to use the orientation of thrusters and trying to force their placement in specific locations on a ship, this would not only effect performance, but would greatly hinder current and future ship designs (how to make a "Warp Nacelle" when forced to use conventional rockets?)

Instead, we would like to try using an Omni-Directional thrust assignment system.
Basically, you will continue to be allowed to place your thrusters anywhere on your ship, and they will continue to put all available thrust into a single pool. From here however, things change. Instead of being able to simply apply that pool of thrust in any direction, a player must first enter a GUI (I don't have a sample for you currently, sorry) and assign the amount of thrust from their pool that they would like to use for each direction of movement. This means that if you want to fly forward (relative to your front of your ship) you must assign a % of your thrust in that direction. If you want to be able to stop moving forward, or even begin to move in reverse, you must assign a % of thrust to the rear direction of your ship (or rotate your ship and retro-burn with your forward thrust.)

This assignment process applies to all 6 directions on you ship, forward/back, up/down, left/right, you may assign any amount of your thrust that you like (in percentages) until you have used the entire 100% available in your thrust pool.

Caution should be used when assigning the % of thrust to each direction of your ship, as this same % will apply to the maximum speed (based on the server setting) that you can acheive in the given direction. So that a 50% forward thrust also means a maximum of 50% server max speed in the forward direction.

Rotating your ship might also cost a % from your ships thrust pool, although this should not impact the maximum speed in any of your 6 directions of linear travel. (Essentially rotating your ship would divert potential thrust before it enters your thrust pool.)​

• Momentum Subsystems

These as a whole are all of the systems that can affect a ships movement besides the thrust blocks. These all serve to modify the behavior established by the Direction Thrust system detailed above. Not all of these systems are finalized, this is just the basic concepts we are currently working with, many of these are also different from what is currently in game.

1. Defensive Push (self buff)
   • This system will operate on a system/ship ratio, you will gain up to a cap, an increase to your ships thrust amount (acceleration), at the cost of even higher power usage than normal. (This will not affect maximum speed)
2. Offensive Push (effects target)
   • This system converts the damage of the weapon it is linked to into momentum to shove the impacted target.
3. Defensive Pull (self buff)
   • This system will operate on a system/ship ratio, you will gain up to a cap, an increase to the rotational acceleration of your ship, at the cost of even higher power usage than normal. (This will not affect your maximum rotation speed)
4. Offensive Pull (effects target)
   • This system converts the damage of the weapon it is linked to into momentum to pull the impacted target.
5. Defensive Stop (self buff)
   • This system will operate on a system/ship ratio, you will gain up to a cap, resistance to outside forces pushing/pulling/stopping your ship
6. Offensive Stop (effects target)
   • This system converts the damage of the weapon it is linked to into momentum to stop the impacted target.
7. Defensive Overdrive (self buff)
   • This system will operate on a system/ship ratio, you will gain up to a cap, an increase to the maximum speed of your ship (based on server max speed)
8. Anti-Gravity Module (self buff)
   • This system will allow your ship to hover in the gravity of a planet
9. Thrust Supply/Drain (Very hypothetical idea's currently, they might not be in game)
   • A pair of support weapon systems, they will work similarly to power supply/drain beams, in that they will transfer thrust (instead of power) between your ship and the target. Based on the size of the system, an amount of thrust is given to one ship as a buff for a period of time, and the other ship is given an equivalent nerf to its thrust. This does not remove control of either ship, nor impart any specific momentum of its own, it simply modify's the available thrust of both targets for a period of time.
10. Jump Drive / Interdiction
    • The plans for FTL are listed below, but the same system blocks may be usable offensively to tackle other ships preparing to use their Jump Drives.

• FTL

To everyone wanting a jump drive, or a wormhole gate, or a hyperspace, fret not, your getting all three!
But first, more warnings, these are still working concepts, and until they are implemented and working (or even after :p ) they may be subject to change, as pretty much anything is in an alpha. I appreciate your understanding and not mobbing me in the future if we change something

There are three basic ways of getting around really fast, (even in all of your sci-fi's they all boil down to some variation of these three.) We will of course put our own spin on them to fit the universe of StarMade, while allowing you to treat them as the FTL system of any sci-fi universe you prefer.

Jump Drives (any ship type, short range)

This system can be installed on any ship, it will require power to be channeled into it for a period of time to charge up (based on system and ship size.) After charging has completed it will instantly jump the ship to a pre-selected sector coordinate. This system however has a limited travel range, so going longer distances may require multiple charge-ups. (The distance we are considering is about 8 sectors distance currently, this may change)​

Gates (Station only, long range)

These gates are installed in pairs, up to 8 Systems apart (1 system = 16 sectors currently) They constantly drain power from their host stations to open and maintain a ring of blocks. Withing this ring, a passageway between the two gates forms allowing instantanious travel between the two stations by flying through the rings Any looped shape may be used, so caution is advise on flying through unknown gates, as you may have parts of your ship lost if the paired gate on the other end is too small to fit you. ​

Hyper-Drives (Capital Ship Systems)

This subsystem, when placed on your ship, will activate a "capital ship" flag in your ships meta data, imparting a permanent debuff to your ship (currently we plan to have it set your ships thrust to 0 and reduce the ships max speed to 0%, based on server max speed.)

However, in exchange for this debuff, your newly minted Capital Ship will have the ability to charge up and activate its new hyperdrive, dropping the ship into a sort of hyperspace. You will have a few seconds to orient your ship, and then the acceleration will kick in, you cant slow down, and you cant stop without dropping from hyperspace (and loosing all of your charge) you can still steer however. You will have a set amount of time to navigate while in hyperspace, after which you will drop out. Charging takes a good deal of power and time (based on ship mass), so this is not something most smaller ships will want to do on their own, instead they are advised to hitch a ride with a carrier, or to use a Gate network.
​

​

Thanks for taking the time to read all that, and thanks again if you decide to provide your opinion on the Thrust Block's - Power Vs.s Thrust settings I proposed near the top of this post.

Calbiri​

 

[cyberus111]

This is perfect, the only addition I have is that thrust vector changes should require a reboot to apply changes .

Too bad that post is over a year old.

 

[GaeasSon]

The post may be old, but since the thread has been bumped...

I'd like to express my support for certain Thrust mechanics related ideas

Structural Vectored thrust:
For each group of thruster blocks, divide the thrust proportionately by the dimensions of the group's bounding box. So, a single block would accelerate evenly (1/3) in all directions. A line of three thrusters would provide 3/5 acceleration along it's long axis, but provide 1/5 acceleration in the other two dimensions. Thrust proportionality would be recalculated at reboot.

Dockable Rotatable Vectored Thrust:
Allow a docked structure to integrate its thrust system into that of the host. Thus you could attach an external engine that could be rotated one way for thrusting against planetary gravity, or another for deep space travel.

Relativistic mass increase instead of speed limits:
Leave your thrust output as it is, but let your mass increase without bound as you approach the server speed limit, affecting your acceleration and rotational dynamics.

 

[Parameter]

The post may be old, but since the thread has been bumped...

I'd like to express my support for certain Thrust mechanics related ideas

Structural Vectored thrust:
For each group of thruster blocks, divide the thrust proportionately by the dimensions of the group's bounding box. So, a single block would accelerate evenly (1/3) in all directions. A line of three thrusters would provide 3/5 acceleration along it's long axis, but provide 1/5 acceleration in the other two dimensions. Thrust proportionality would be recalculated at reboot.

Dockable Rotatable Vectored Thrust:
Allow a docked structure to integrate its thrust system into that of the host. Thus you could attach an external engine that could be rotated one way for thrusting against planetary gravity, or another for deep space travel.

Relativistic mass increase instead of speed limits:
Leave your thrust output as it is, but let your mass increase without bound as you approach the server speed limit, affecting your acceleration and rotational dynamics.

I don't know how expensive the dockable thrusters would be to calculate on the fly, but that's a cool idea.

I also like the idea of relativistic mass increase as you approach max speed. The only caveats I'd throw out are that the relativistic mass should only be used for thrust (not weapon block mass ratios), and that the server speed limit is high enough that you feel like you're going fast when you hit the relativistic speed soft cap.

 

[Ithirahad]

I don't know how expensive the dockable thrusters would be to calculate on the fly, but that's a cool idea.

I also like the idea of relativistic mass increase as you approach max speed. The only caveats I'd throw out are that the relativistic mass should only be used for thrust (not weapon block mass ratios), and that the server speed limit is high enough that you feel like you're going fast when you hit the relativistic speed soft cap.

It would probably be cheapest to just treat the dockable thrusters as an extra (available) thrust force in the direction they're pointing. (In other words, ignoring the position of the thrusters.)

 

[Dark-life]

The post may be old, but since the thread has been bumped...

I'd like to express my support for certain Thrust mechanics related ideas

Structural Vectored thrust:
For each group of thruster blocks, divide the thrust proportionately by the dimensions of the group's bounding box. So, a single block would accelerate evenly (1/3) in all directions. A line of three thrusters would provide 3/5 acceleration along it's long axis, but provide 1/5 acceleration in the other two dimensions. Thrust proportionality would be recalculated at reboot.

Dockable Rotatable Vectored Thrust:
Allow a docked structure to integrate its thrust system into that of the host. Thus you could attach an external engine that could be rotated one way for thrusting against planetary gravity, or another for deep space travel.

Relativistic mass increase instead of speed limits:
Leave your thrust output as it is, but let your mass increase without bound as you approach the server speed limit, affecting your acceleration and rotational dynamics.

Great idea but some more stuff would be done. Since you can now rotate docked objects and move them around (thanks rails) how would you handle the reboot to calculate thrust? Also how would you handle the mothership or docked thruster taking damage(or getting knocked off)?

 

[ltmauve]

Structural Vectored thrust:
For each group of thruster blocks, divide the thrust proportionately by the dimensions of the group's bounding box. So, a single block would accelerate evenly (1/3) in all directions. A line of three thrusters would provide 3/5 acceleration along it's long axis, but provide 1/5 acceleration in the other two dimensions. Thrust proportionality would be recalculated at reboot.

How well could you properly make a small ship with that? It just seems like a really inflexible way to do that.

 

[GRHayes]

First, I appreciate the developers are doing as usual.

Hyperdrive and Capital ships are going to have some serious problems if the speed is set to zero.
Capital ships will have no in system maneuverability. You could drop out in a system to close to a planet or black hole.
You won't be able once in a system to maneuver to close range on targets and bases. I can see doing something like limiting the speed to 10 or 20% of the servers max speed but zero will be a nightmare. But I am sure you will figure this out about the time you test it.

 

[RODLON]

Hi,
I don't like some of these ideas. These are what I don't like of space videogame and some of them are senseless "hard limits" or "artificial drawbacks" to balance the gameplay, full of inconsistency effects. Yes, they might balance the gameplay a bit, but will also totally break the space experiencie. These kind of ideas are the easy/lazy way to develop a game, just limiting the gameplay features, even limiting the physics engine(wtf?), just because of yes in attempt to keep it balanced instead of looking for an actual solution that is coherent and actually makes sense.

To better understand my opinion you must know some things:
- I think that a game doesn't need to be realistic in the way its mechanics matches our universe. It is another universe with its own rules, its own laws of physics, etc. But it should be coherent, have consistency.
- I expect starmade to keep the newtonian physics for ships, so my opinions are based on a game with newtonian physics (which is the current implementation, excepting the max speed and space drag, which you can turn off in the settings).
- Actually the space drag could be explained by adding an invisible unknown layer to the starmade universe that cause objects to be dragged, just like our universe have "something" expanding it faster and faster.
- I don't like space engineers because it's too realistic, they won't add nothing that is not possible in our universe.

1 thrust block = 5 ship thrust & 5 power used
100 thrust blocks = 5000 ship thrust and 7500 power used
*Rough estimates*
​

​

An exponential increase to thruster block power usage will make big ships accelerating really slow, as energy generation doesn't grow exponentielly and at certain point, you won't be able to handle more thrust blocks. The current bonus to power reactor shape doesn't count because is not actually exponential and it's capped at 1M (which is completly senseless).
Also, it makes no sense, you could just place them in individual small groups and if that is not possible there is a contradiction: Imagine 100 thrust blocks in a big ship, divided in 10 individual and unconnected groups. They would consume that 7500 power. And now imagine 100 thrust blocks divided in 10 small ships, they would generate the same thrust power for less energy. How is that possible?


I will also comment the other things:

• Direction Thrust Setting

First, having a big capital ship flying a maximum speed backwards while firing the primary gun is less problem than flying forward while being tailed by a similar sized ship. You could do nothing about it, just wait to your death. Very unbalanced.
Also if you had directional thrusters and you accelerate to the max speed, you are still able stop accelerating, turn your ship around and make a few shots before the space drage slows you down. Basic physics.

I think omnidirectional thruster using a thrust pool would be nice if it's well implemented. But not like that...
If you can change the % in a gui it should require a system reboot or something. If not, nothing prevents the process to be be automated(well yes, a lazy game developer that prefers to impose senseless limits rather than find a good solution) so the ship would autoselect the best distribution for the direction you want to go, making the entire system useless.

Max speed is max speed. Thrust power is thrust power. They are two completly different concepts and shouldn't be merged, never ever. And of course that idea is full of inconsistencies, just think about it for a moment.

I won't comment the momentum subsystems, I barely readed them but their names sound promissing.

FTL

Ok, jumpdrives and warp gates are already implemented. But the hyperdrive is a very interesting thing that might be in the future. I would really want to see it implemented, but without these senseless drawbacks:
The hyperdrive system could just make an interference or something with the "drag field" I mentioned, but that is just something I made up. It just stops the ship because of yes, because of a metadata tag, to attempt to create some game balancing using the easy way. So what happens when adding an hyperdrive to the ship? The thrusters just stop working and the ship is frozen in space. Why? because someone couldn't think of anything better nor ask the huge players community for ideas that make sense.
PD: The millenium falcon is still the fastest ship while carrying a hyperdrive...

​

I keep watching people saying things like "I like these ideas" without any explanation. If you like them, please, read my post and answer it if you dissagree.
What do you think about what I said?

 

[GaeasSon]

So... In general, what I hear you saying is: "I don't like space games to be too realistic, but I have some problems with the way StarMade doesn't sem to be internally consistent"... OK, I can understand that.

I'm with you on hard limits being annoying. It's worth noting, though that the only hard limits are on bonuses. You never reach the point where one more thrust, or energy block doesn't increase your thrust or energy.

>>Also, it makes no sense, you could just place them in individual small groups and if that is not possible there is a contradiction: Imagine 100 thrust blocks in a big ship, divided in 10 individual and unconnected groups. They would consume that 7500 power. And now imagine 100 thrust blocks divided in 10 small ships, they would generate the same thrust power for less energy. How is that possible?

These are not Newtonian thrusters. They are based on some reaction-less drive technology that no doubt involves higher dimensions and imaginary particles. In small numbers they heterodyne become more efficient. In larger numbers, harmonic dissonance degrades efficiency. There. Imaginary physics answers for imaginary technology.


>> Max speed is max speed. Thrust power is thrust power. They are two completly different concepts and shouldn't be merged, never ever. And of course that idea is full of inconsistencies, just think about it for a moment.

As to thrust vs. speed... there's a problem. Our computational sub-reality has constraints that our physical reality does not. Within purely Newtonian physics, infinite speed should be possible given enough reaction mass. In a relativistic universe we have annoying relativistic time inconsistencies at high speeds. But on our computers, modeling these effects just produces lag. Lag is not fun. Games should be fun, so if we can't make thrust proportional to acceleration with unbounded velocity, then why not bind velocity proportionally to its bounded derivative? It will make sense to the bulk of the players , most of whom grew up in atmosphere on a planet.

 

[Megacrafter127]

Games should be fun, so if we can't make thrust proportional to acceleration with unbounded velocity, then why not bind velocity proportionally to its bounded derivative? It will make sense to the bulk of the players , most of whom grew up in atmosphere on a planet.

The question is, how many of those expect objects in space to have a terminal velocity determined similarly to how drag determines a terminal velocity in an atmosphere. After all, spacegames do attract spacenerds, to most of who that would not make sense. The big question is: how many of the people attracted by starmade are amongst those, to whom thrust dependent max-speed makes sense, or amongst those, to whom thrust dependent max-speed makes no sense whatsoever in the context of space. Without an answer or informed guess on that question, the best choice is not clear, to me at least.
As for the general speed limit, most of those, to whom thrust dependant max speed makes no sense, can be expected to know, that hardware limitations have to be accounted for, and the naïvely most fair way is a general thrust limit independent of anything.

IMO there is also a slight balancing problem, that might arise from a linear non-constant relation between thrust and max-speed, but at this point in time, this is just a lonely opinion, as I didn't really discuss it yet, outside of a discussion on how configurable it should be, in which my position was, that one should be able to undo it in the serverside configs.

 

[NeonSturm]

Realism is dependent on how you assume thrusters to work.

Some thrusters might only work up to 0.5c (50% light speed) as they rely on super-fluids or super-symmetric-matter going both forward and backward to produce thrust, producing a breaking effect when they travel forward at more than 1c (0.5c ship + 0.5c component).

But without that tech-stuff, thrusters are assumed to be rocket-muzzles by the majority and treated as such. (cap ~ 1c, because acceleration gets lower when approaching it).

But if force=speed^2, there is an important question:

• What is the absolute ZERO-velocity?
  
  • The galaxy moves away from it's origin,
  • the sun moves around the galaxy centre,
  • the planet(e.g: earth) travels around the sun...
  • the object either moves along or against the planet-orbit, depending on if it is day or night, goes west or goes east.
• +1m/s east = +1m/s west? (f=(5*5->6*6)=(25+5+6)) compared to (f=(5*5->4*4)=(25-5-4))
  • Theoretically there is a difference in the required force depending on the direction and magnitude of change.
    • Except the planet's gravity creates it's own ZERO-velocity's point of reference.
    • Or some quirk in the laws of physics (maybe related to time-compression --Xm/s = n*dist/time).

 

[Dire Venom]

Greetings Citizens!

Caution should be used when assigning the % of thrust to each direction of your ship, as this same % will apply to the maximum speed (based on the server setting) that you can acheive in the given direction. So that a 50% forward thrust also means a maximum of 50% server max speed in the forward direction.

Rotating your ship might also cost a % from your ships thrust pool, although this should not impact the maximum speed in any of your 6 directions of linear travel. (Essentially rotating your ship would divert potential thrust before it enters your thrust pool.)​

​

This all sounds amazing! However, one part caught me up ^.
Why should our max speed be different in different directions? The acceleration in each direction will be different (and the balancing factor) so I don't see why the max speed should be capped. e.g I could spend 1 minute reaching the server max speed going forwards or 10 minutes reaching the max speed going backwards, its all about momentum.
If someone wants to spend their time trying to reach max speed with an in-efficient use of their thrust then why should they be further penalised?

Could you please elaborate on this part?
Thanks