Wow -- It seems you of all people should be aware that centrifugal force/acceleration is, in fact, fallacious. All rotational force/acceleration is centripetal. Better not to argue for the sake of arguing.
Wow -- It seems you of all people should be aware that centrifugal force/acceleration is, in fact, fallacious. All rotational force/acceleration is centripetal. Better not to argue for the sake of arguing.
That depends on the frame of reference. From a static frame of reference outside the rotation, the force goes inwards, but the frame of reference of the orbiting object only "sees" the outward counter-force.
I believe the word yer looking for is "perception" -- the perception of gravity produced by a perception of acceleration away from the center of rotation. It's only a perception, however. You are, in fact, accelerating toward the center in a centrifuge, for example. This is still "centripetal" not centrifugal.
To be even more to the point of my statement, you all know very well that in referring to Artificial Gravity I specifically mean the ability to walk along a floor surface in a space-ship as if there were sufficient mass beneath it to produce earth-like simulation -- which of course will be eternally impossible -- and yet the concept is necessary for movies/television because it's impractical for actors to be weightless, la, la, la.... and so we have it in video games too.
(Really, it's like saying the sky is blue. Do I have to explain that the sky is actually colorless and can appear to be any color or many different colors based on circumstance?)
I'm new to the game; I'm not an astrophysicist, nor a mathematician, and I readily admit when I'm wrong or ignorant, but I'm not a dullard. If yer gunna argue, you'd better be right or have a valid point. This is not a "See How Smart I Am" contest. Please return to thread topic.
This is the current system that every shipwright hates with the passion of a thousand main-sequence stars. Chunk-based calculations are the way to go.
Calculation-wise, using boxdims is great! In every other possible way I can think of (realism, gameplay, balance, ship aesthetics, etc.) this is the most horrible idea besides having ships of all sizes turn at the same rate.
Using chunks as discrete masses in the inertia calculation would probably be the best way to go. It wouldn't be nearly as computationally intensive as calculating the inertia of every single block (instead using chunks as massive 'blocks') and would also take into account negative space up to a certain degree of accuracy.
The total mass of a chunk would be calculated and the center of said chunk would be the location of the mass point. So basically, an empty chunk would rate as 0 mass, a filled one for 409.6 and then there's every value in between. Smaller ships wouldn't really be affected by the rather low accuracy (16x16x16 chunks) as they already have good turning speeds. A system like that would require something like 4000 times less points to be calculated and would still retain decent accuracy.
I don't code btw, so this is all just speculation. I am fairly familiar with the concepts though.
it is simple, and may be the most lite weight in terms of impact to performance of the game.
lets say the following
Mass = 1000
Thrust = 1000
turning should be normal or slower depending if you can't obtain thrust/mass, but if you get a percentage above then you can turn faster the higher you go.
ie:
Mass = 1000
Thrust = 1250
this would turn your ship 1/8 faster than normal or 12.5% faster
we could then go up 100% faster, which would then technically be about the size of a 200 mass ship or less depending on the mass of the ship. Also, we know the thrust output lessens the more thrust blocks you add, so leviathans may only get to be able to turn maybe 25% - 60% faster?
just throwing this out there, I haven't scripted in a long while, so some things may be off, but those code-fu people out there will get the gist of what I mean.
I don't mean to necro-post, but this forum was marked as 'brainstorm' so I figured this recent thought I had was better put here than in a new thread.
All of the discussion in the thread has been within the confines of having only one block (thruster coil) and one ship value (thrust). What if there were a different block for adjusting maneuverability?
I was thinking about how space shuttles handle turning and slight maneuvering. The ships thrusters on the back are huge engines that burn fuel, but the slow precision turning is compressed air jetted out of small openings along the ship. Two completely different systems.
The Block:
Lets call it a maneuverability enhancement module (MEM). It can be rotated in 6 directions and applies its value to the turn speed according to the way it is facing. The turning of a ship can be calculated by looking at the list of these blocks used and which way each is facing. Ship engine systems would then need both Thrusters and MEMs.
Option 1: Completely Different Values
Thrusters only apply to acceleration/deceleration, and a ship with no MEMs will use the base-line turn speed. Adding MEMs will add to the turn speed in each direction adjusted for ship dimensions. To achieve equal speeds in all directions, a perfect sphere would need equal numbers of MEMs in each orientation but a hot-dog-shaped ship will need more MEMs oriented along the long sides.
Option 2: Chunk-Based Inertia-Tensor Calculations
When building a ship and adding/subtracting a block, the weight of the block is stored in the chunk of the ship. A chunk stores one weight value which is the summation of all blocks in the chunk; also one thrust value, and 6 MEM values (one for each orientation). The ship totals are determined by adding up the values in the chunks. I assume this is the way chunks are utilized already.
The tensor calculation adjusts the weight of a block according to its distance from the center of the ship. Instead of looking at each block, look at the summation stored in the chunk and then adjust by the chunk's distance from the ship center. This cuts down the calculation dramatically. Then we adjust this using the MEM value for each axis stored in the chunk. This allows the Inertia Tensor to adjust the turn speed of the chunk based on its distance from the center of the ship, but also makes MEM's farther from ship center balanced to the weight of blocks at that distance.
Option 1 allows for a single centralized engine to adjust turning for the whole ship, like Starmade currently operates. Option 2 discourages the use of a centralized engine hub, and ships would instead need to put engines at various spots along the ship. You could either have a large engine every few chunks, or small engines on every chunk.
Option 2 would probably need a way to view chunks in build mode and see which chunks are causing the most slow down - maybe a chunk-overlay of greens/yellows/reds.
I don't know if a chunk-based inertia-tensor will still be too resource intensive on larger ships.
Anyway, this keeps getting better and better. First I hear that the HP system is being worked on, then I hear that the center of mass is no longer the core... What's coming next, control chairs? Diminishing returns on weapons? "Warp drive"-type FTL? Particle system integration? Every single other thing about this game that bugs me being fixed? :p
Anyway, this keeps getting better and better. First I hear that the HP system is being worked on, then I hear that the center of mass is no longer the core... What's coming next, control chairs? :p
Are you serious?! This is monumental! I thought the shipyard update was going to be next. Will it be the HP system instead!? I would consider that a more sensible priority.
I don't mean to necro-post, but this forum was marked as 'brainstorm' so I figured this recent thought I had was better put here than in a new thread.
All of the discussion in the thread has been within the confines of having only one block (thruster coil) and one ship value (thrust). What if there were a different block for adjusting maneuverability?
I was thinking about how space shuttles handle turning and slight maneuvering. The ships thrusters on the back are huge engines that burn fuel, but the slow precision turning is compressed air jetted out of small openings along the ship. Two completely different systems.
The Block:
Lets call it a maneuverability enhancement module (MEM). It can be rotated in 6 directions and applies its value to the turn speed according to the way it is facing. The turning of a ship can be calculated by looking at the list of these blocks used and which way each is facing. Ship engine systems would then need both Thrusters and MEMs.
Option 1: Completely Different Values
Thrusters only apply to acceleration/deceleration, and a ship with no MEMs will use the base-line turn speed. Adding MEMs will add to the turn speed in each direction adjusted for ship dimensions. To achieve equal speeds in all directions, a perfect sphere would need equal numbers of MEMs in each orientation but a hot-dog-shaped ship will need more MEMs oriented along the long sides.
Option 2: Chunk-Based Inertia-Tensor Calculations
When building a ship and adding/subtracting a block, the weight of the block is stored in the chunk of the ship. A chunk stores one weight value which is the summation of all blocks in the chunk; also one thrust value, and 6 MEM values (one for each orientation). The ship totals are determined by adding up the values in the chunks. I assume this is the way chunks are utilized already.
The tensor calculation adjusts the weight of a block according to its distance from the center of the ship. Instead of looking at each block, look at the summation stored in the chunk and then adjust by the chunk's distance from the ship center. This cuts down the calculation dramatically. Then we adjust this using the MEM value for each axis stored in the chunk. This allows the Inertia Tensor to adjust the turn speed of the chunk based on its distance from the center of the ship, but also makes MEM's farther from ship center balanced to the weight of blocks at that distance.
Option 1 allows for a single centralized engine to adjust turning for the whole ship, like Starmade currently operates. Option 2 discourages the use of a centralized engine hub, and ships would instead need to put engines at various spots along the ship. You could either have a large engine every few chunks, or small engines on every chunk.
Option 2 would probably need a way to view chunks in build mode and see which chunks are causing the most slow down - maybe a chunk-overlay of greens/yellows/reds.
I don't know if a chunk-based inertia-tensor will still be too resource intensive on larger ships.
It seems to me that option 1 is less calculation heavy and easier to program. I would be fine with option 2 and even like it if the thrusters didn't require a large number of blocks (they'd be a pain to deal with and make to look nice).
Here's another thought: what if there were some sort of electromagnetic-based rotation engine that gains effectiveness similarly to power reactors? It would make sense to have a very similar algorithm as maneuverability and power recharge go hand in hand for limiting capships' abilities.
Here's another thought: what if there were some sort of electromagnetic-based rotation engine that gains effectiveness similarly to power reactors? It would make sense to have a very similar algorithm as maneuverability and power recharge go hand in hand for limiting capships' abilities.
I have been thinking about the things discussed in this thread and have come to see some flaws in the things I have agreed with/suggested as well as some new things I'd like to bring up.
Moment of inertia use, though very realistic, would be abhorrent gameplay wise if just used on its own. The main reason for this is that the moment of inertia scales linearly with mass and quadraticaly with dimensions. Since every block in starmade currently has equal mass, mass scales cubically with dimensions. In total this means that your turning acceleration would be roughly 10000 times smaller for a ship of 100 length compared to a ship of 10 length. If one were to compare a core to a 1000m vessel , the difference would be a factor 1.000.000.000.000.000 (One Quadrillion) Even if you don't like big ships that's still too much of a nerf.
I still think moments of inertia are useful to distinguish between the turning abilities of different shaped/sized ships, but we may need to take the physics with a grain of salt this time.
Something along the lines of a rotational thruster block/reaction wheel block might be in order to compensate. Which would then most likely have to increase their output more than linearly ( total blocks to the power 1.4 or so perhaps) to keep up with rotational inertia. Something along the lines of the power generator calculations might also be applied.
I'd just keep the directions limited to 3, perhaps distribute it in the same way that is planned for regular thrusters. (left and right having the same value, same with up/down and both roll directions)
As for showing which chunks are slowing you down the most, moments of inertia are really simple in that regard: the further away you place a block from the COM, the more it slows you down, so visualizing this does not seem all that useful to me.
I'll keep my new things for another post in this thread/an edit.
As for showing which chunks are slowing you down the most, moments of inertia are really simple in that regard: the further away you place a block from the COM, the more it slows you down, so visualizing this does not seem all that useful to me.
Well, what I meant to say with this is that since (in my suggestion) chunks store variables for thrust, turn, and weight they might not affect turn speeds based solely on position. If I have one chunk with no thrusters, one that is entirely thrusters, and another that is hollow, they won't all be affecting thrust/turn to the same degree even if they had the same position relative to ship center.
Having a colored overlay would help a builder determine where to add thrusters/MEMs. I find a red chunk that is slowing down my turn speed, add in some MEMs to it, and because I've adjusted the variables for the chunk it turns yellow. I add more MEMs and it turns green. I add even more, and it turns blue and compensates for nearby yellow chunks.
Over a year ago... You mean, with only AMCs and no multi-group penalty? This is a very different game now weapons-wise... Data that old isn't exactly reliable.
that would be accurate, yes. there is no reason to use a diminishing returns system with weapons. damage scales linearly but power consumption scales exponentially. this works well for both big and small ships.
small ships dont need much power since their guns are small, but since bigger guns require more power, that in combination with the usage of dockable batteries allows for an appropriate and fair creation of superweapons at the same time
One mistake that the current game has is not allowing shipwrights to customize turning characteristics except by changing the mass and boxdims of their ships. We need a maneuvering system block. For balancing big and small ships, it might make the most sense to use the same algorithm as power generation for a maneuvering subsystem.
The hard part is figuring out if something like this can be added without breaking current builds (probably not).
The other mistake is limiting max turning SPEED rather than ACCELERATION. Realistically a large ship can get itself spinning over time, but might not be able to stop a the desired angle if it goes too fast. It's another aspect of pilot skill that goes into flying big ships which this game currently lacks. Big ships should have skill requirement drawbacks rather than tedium.
The other mistake is limiting max turning SPEED rather than ACCELERATION. Realistically a large ship can get itself spinning over time, but might not be able to stop a the desired angle if it goes too fast. It's another aspect of pilot skill that goes into flying big ships which this game currently lacks. Big ships should have skill requirement drawbacks rather than tedium.
Agreed, even a large ship can go into a super-fast spin given enough time. Keep in mind that even though we have arbitrary things like server speed limits and friction coefficents we are still in space, and therefore our thrusters should be putting out FORCE, and the amount of force should determine ACCELERATION and not SPEED. The amount of thrusters on your ship and the mass of your ship factor into how quickly your ship can change its velocity, not the velocity itself. Remember a=v/t, basic high-school physics here.
That being said, looks like I might start playing dev-build again :P
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
It seems you of all people should be aware that centrifugal force/acceleration is, in fact, fallacious. All rotational force/acceleration is centripetal. Better not to argue for the sake of arguing.
