Improvements to ship movement system
- Thread starter asmageddon
- Start date
As removing the speed limit seems to be impossible i suggets to add a teleportation module, I\'m sure that opening a wormhloe and loading a chunk is even more efficent (in aspect of performance and lags) than a regular flight, moreover, it\'s an additional step of ship development (possibly expensive in cash and energy consumption).
I Agree that controls are quite irritating (can\'t turn and roll in the same time), creators of KSP had solved the problem like so: SHIFT - increse thrust CTRL - decrese thrust WASD - turn QE - roll, in my opinion it\'s better option
I Agree that controls are quite irritating (can\'t turn and roll in the same time), creators of KSP had solved the problem like so: SHIFT - increse thrust CTRL - decrese thrust WASD - turn QE - roll, in my opinion it\'s better option
I agree with changing roll to Q&E. For a smaller fighter to be able to manuver around a large ship this is a must. The ability to Roll and turn at the same time is very important!
An easy way to adjust the balance without having a max speed is to increase power consumtion for engine blocks exponentialy or at least at a much higher rate. Rather than having each engine block require x power, regardless of quantity. It makes sense that a engine twice the size of the same type would require 4 times the power. Now a way around that would be to seperate your engines rather than having them all connected. However you could run the count on total on the ship rather than total connected.
An easy way to adjust the balance without having a max speed is to increase power consumtion for engine blocks exponentialy or at least at a much higher rate. Rather than having each engine block require x power, regardless of quantity. It makes sense that a engine twice the size of the same type would require 4 times the power. Now a way around that would be to seperate your engines rather than having them all connected. However you could run the count on total on the ship rather than total connected.
also, manuevering thrusters would be nice addition(altough not necessary) in order to be able to roll when your engines are gone. Also would be cool for a vertical take off from a planet.
In mentioning vertical takeoffs, it would be awesome if you could make gravity on stations affect ships as well. that way if you forget to brake your ship it doesn\'t float up to the ceiling an make you exit the station gravity to get to it.
Would also be more realistic(and functional) to have gravity affect all entites rather than just the one who activates the unit..
In mentioning vertical takeoffs, it would be awesome if you could make gravity on stations affect ships as well. that way if you forget to brake your ship it doesn\'t float up to the ceiling an make you exit the station gravity to get to it.
Would also be more realistic(and functional) to have gravity affect all entites rather than just the one who activates the unit..
Loving the game so far, it is just awesome.
Just thought I\'d add my own thoughts on the flight mechanics. As a long time player (and fan) of the X-series (X3:Albion Prelude etc) I think the ship controls could benefit a lot from the flight mechanics used within those games, which is also a newtonian \"atmospheric\" (in regards to upper limit on speed) flight simulator.
Currently the two systems are very similar (apart from keybindings) in the mechanics used except one, and I think important to user control over their ship, difference. In starmade the player has only one level of acceleration and has to hold it a button to maintain speed. However in the X series the player determines the speed they want to travel at (if they don\'t turn) by using speed up/down buttons (to a maximum forward/reverse speed). The reality of this system is that the player is actually controlling the thrust output of their engines, with an effective drag slowing them down to their chosen speed (probably with the force of the drag simply being F_drag=constant*velocity). The reason I believe the developers of the X games chose to let the user select their speed rather than their thrust, in comparison to KSP, is that it is a more intuitive to players to control their speed than their thrust and in KSP there is no drag (once in space) so thurst is a more intuitive control system.
The system of controlling speed I think is better than having a constant acceleration is two fold. Firstly it is more intuitive to the player as they can control other ship movements (rolling/strafing) without having to hold a forward key. Secondly as the player can pre set their speed they can do things while travelling between places, like chat to people, manage inventory, hell even eat a sandwich!
Anyway thanks schema for making such an awesome game! Literally a dream to be able to combine minecraft creations with a space sim.
p.s. to the guy who implied Python is slow. looking at asmageddon here. As a Python developer and a physicist Python used correctly can be very fast indeed (personally I have used it to do highly intensive numerical calculations in quantum mechanics)
Just thought I\'d add my own thoughts on the flight mechanics. As a long time player (and fan) of the X-series (X3:Albion Prelude etc) I think the ship controls could benefit a lot from the flight mechanics used within those games, which is also a newtonian \"atmospheric\" (in regards to upper limit on speed) flight simulator.
Currently the two systems are very similar (apart from keybindings) in the mechanics used except one, and I think important to user control over their ship, difference. In starmade the player has only one level of acceleration and has to hold it a button to maintain speed. However in the X series the player determines the speed they want to travel at (if they don\'t turn) by using speed up/down buttons (to a maximum forward/reverse speed). The reality of this system is that the player is actually controlling the thrust output of their engines, with an effective drag slowing them down to their chosen speed (probably with the force of the drag simply being F_drag=constant*velocity). The reason I believe the developers of the X games chose to let the user select their speed rather than their thrust, in comparison to KSP, is that it is a more intuitive to players to control their speed than their thrust and in KSP there is no drag (once in space) so thurst is a more intuitive control system.
The system of controlling speed I think is better than having a constant acceleration is two fold. Firstly it is more intuitive to the player as they can control other ship movements (rolling/strafing) without having to hold a forward key. Secondly as the player can pre set their speed they can do things while travelling between places, like chat to people, manage inventory, hell even eat a sandwich!
Anyway thanks schema for making such an awesome game! Literally a dream to be able to combine minecraft creations with a space sim.
p.s. to the guy who implied Python is slow. looking at asmageddon here. As a Python developer and a physicist Python used correctly can be very fast indeed (personally I have used it to do highly intensive numerical calculations in quantum mechanics)
This is impossible unfortunately due to natural reasons. Lagginess wouldn\'t be the only problem. Also the work for physics would increase exponentially (since for high speed collisions you\'d either have to cast the object (which is unbelivably expensive), or increase the sub steps of a physics update by at least 100 times.
Firstly, I want to make it clear that I have no idea how your physics engine works or why it would necessarily increase the processing load significantly.
That out of the way, this seems like a trivially easy problem to solve given that the game already takes the mass of a ship into question. My hypothesis (Massive emphasis here) is that the mass of an object would have to be calculated on each physics update to cause any issues with calculations involving it.
The simplest way out of this is to simply not calculate the mass of the ship when physics related operatiosn are performed. Rather, this should be calculated whenever the mass of the ship could change. This value would then be stored for whenever it\'s necessary in physics calculations. This can and will get jenky during combat with the mass of a ship can change rapidly if not handled properly.
From there, it\'s a simple matter of calculating a ships maximum velocity based on its mass and its accelleration based on its inertia.
Further, I\'d like to address this bit:
Players built huge ships with 3-4k thrusters, which made them pretty much invincible, since the ship had max weapons and unlimited speed (so you were unable to hit it).
Specifically the \"unlimited speed\" bit. If you actually had a completely uncapped speed, then this is, indeed, an issue. However, physics can rescue us thanks to Relativity. The amount of energy required to speed a ship of that size (3-4k thrusters is a LOT of mass) to any sufficiently advanced speed requires a lot of power. Naturally, as speed approaches c, the amount of energy required approaches infinity.
If thrusters push at a fixed rate with variable energy requirements - that is, they accellerate a given mass a given amount for an amount of energy that increases with velocity - we should, theoretically, never have an issue with ships traveling so fast that they cannot possibly be hit. Any sufficiently large ship would require too much energy to move at any great speed while smaller ships would hit similar soft caps.
To provide an example:
A thruster accellerates 50kg at 1m/s2 for 1 unit of energy (e) and has a mass of 10kg
A ship, without any thrusters, is 1000kg. To accellerate this ship at 1m/s2, you would need 25 thrusters (20 for the mass of the ship, and 5 for the mass of the thrusters) and 25e * Velocity to continue accellerating. Accellerating this ship to 10m/s would require ~9072000e
Thus, the energy required to increase the velocity of the ship 1m/s increases exponentially with the speed of the ship. Granted, this is a contrived example using far from balanced numbers, but it shows how such a system could work and could allow for theoretically uncapped speeds while still being fair.
The numbers would have to be heavily balanced, but the underlying equations should be sound. Mine was a simple Velocity! * Energy Cost, but a real calculation could use actual formulas (that I don\'t know offhand and are overkill for my example).
Firstly, I want to make it clear that I have no idea how your physics engine works or why it would necessarily increase the processing load significantly.
That out of the way, this seems like a trivially easy problem to solve given that the game already takes the mass of a ship into question. My hypothesis (Massive emphasis here) is that the mass of an object would have to be calculated on each physics update to cause any issues with calculations involving it.
The simplest way out of this is to simply not calculate the mass of the ship when physics related operatiosn are performed. Rather, this should be calculated whenever the mass of the ship could change. This value would then be stored for whenever it\'s necessary in physics calculations. This can and will get jenky during combat with the mass of a ship can change rapidly if not handled properly.
From there, it\'s a simple matter of calculating a ships maximum velocity based on its mass and its accelleration based on its inertia.
Further, I\'d like to address this bit:
Players built huge ships with 3-4k thrusters, which made them pretty much invincible, since the ship had max weapons and unlimited speed (so you were unable to hit it).
Specifically the \"unlimited speed\" bit. If you actually had a completely uncapped speed, then this is, indeed, an issue. However, physics can rescue us thanks to Relativity. The amount of energy required to speed a ship of that size (3-4k thrusters is a LOT of mass) to any sufficiently advanced speed requires a lot of power. Naturally, as speed approaches c, the amount of energy required approaches infinity.
If thrusters push at a fixed rate with variable energy requirements - that is, they accellerate a given mass a given amount for an amount of energy that increases with velocity - we should, theoretically, never have an issue with ships traveling so fast that they cannot possibly be hit. Any sufficiently large ship would require too much energy to move at any great speed while smaller ships would hit similar soft caps.
To provide an example:
A thruster accellerates 50kg at 1m/s2 for 1 unit of energy (e) and has a mass of 10kg
A ship, without any thrusters, is 1000kg. To accellerate this ship at 1m/s2, you would need 25 thrusters (20 for the mass of the ship, and 5 for the mass of the thrusters) and 25e * Velocity to continue accellerating. Accellerating this ship to 10m/s would require ~9072000e
Thus, the energy required to increase the velocity of the ship 1m/s increases exponentially with the speed of the ship. Granted, this is a contrived example using far from balanced numbers, but it shows how such a system could work and could allow for theoretically uncapped speeds while still being fair.
The numbers would have to be heavily balanced, but the underlying equations should be sound. Mine was a simple Velocity! * Energy Cost, but a real calculation could use actual formulas (that I don\'t know offhand and are overkill for my example).
As long as we are talking about ship movment, I think that if we are to move where the ship points with the mouse, then it should be more like Star Conflict. There, the farther the mouse is from the center the faster the ship moves. To stop yaw/pitch movment you move the mouse to within a radius of the center of the screen.
- Joined
- Jun 20, 2013
- Messages
- 1
- Reaction score
- 0
Just looking through random stuff, and I saw this, this is REALLY what this game needs, I\'m working on a mothership 240 blocks long atm, the time it takes just to accelerate is INSANE, so how about you need 2 things, 1: A multiblock \"Fusion Hyperspace Core\" This produces TONS of power, but has a large mass and is required for the second part, can only be purchased or crafted perhaps?
And 2: The HPR Fusion thrusters, when you set co-ordinates over the navigation, you press the assigned key and over the course of 10 seconds to a minute (depending on the amount of them) All of your power would be drained and you would enter FTL mode and \"teleport\" to your navigation point, the range varies from 3,3,3 sectors away to about 10,10,10 sectors away, allowing for long range travel, it can ONLY be used from full power and after jumping, you regeneration is tenthed unless coupled with and exceedingly rare Combat Jump module which lowers the debuff to 50% instead of 10%, the jump style could be similar to Mass Effect.
And 2: The HPR Fusion thrusters, when you set co-ordinates over the navigation, you press the assigned key and over the course of 10 seconds to a minute (depending on the amount of them) All of your power would be drained and you would enter FTL mode and \"teleport\" to your navigation point, the range varies from 3,3,3 sectors away to about 10,10,10 sectors away, allowing for long range travel, it can ONLY be used from full power and after jumping, you regeneration is tenthed unless coupled with and exceedingly rare Combat Jump module which lowers the debuff to 50% instead of 10%, the jump style could be similar to Mass Effect.
I am seeing this on the 24th at 10pm. the time stamp says this was posted on the 25th.
edit: I am so smart. this was three months ago
edit: I am so smart. this was three months ago