Acceleration, physics, and other ship enhancements/rebalance

[Deus Siddis]

I'm thinking about tweaking linear speed governors up a bit, but I think that with faster SPEC travel, this patch could be applied for 1.5.2 or whatever the next release will be. Because all three of us who have tested it so far seem to agree that long distance travel is the roadblock problem with this patch. And that is exactly the type of problem SPEC is targeted to solve.

How do you modify the stats for SPEC? So if I'd like to make it ceiling at 1000c instead of 97c or if I wanted it to be more or less affected by the gravity produced by another unit's mass, how would I change that? Are these SPEC variables in a CSV, XML or Python file or are they hard coded in C++?

[klauss]

How do you modify the stats for SPEC? So if I'd like to make it ceiling at 1000c instead of 97c or if I wanted it to be more or less affected by the gravity produced by another unit's mass, how would I change that? Are these SPEC variables in a CSV, XML or Python file or are they hard coded in C++?

There are variables that can be tweaked in the .config (not sure which, I'd have to check the sources), and there's at least one units.csv column that controls how much of an influence units have on the "interdiction" field.

I'd warn against raising the maximum multiplier that high, because the higher it gets, the more likely it is the autopilot will act up, and that interdiction fields won't be enough to slow you down when reaching the target.

I believe we need a new SPEC ramping algorithm that takes into account your targetted destination in order to be able to move the max multiplier that high.

[Deus Siddis]

There are variables that can be tweaked in the .config (not sure which, I'd have to check the sources), and there's at least one units.csv column that controls how much of an influence units have on the "interdiction" field.

In the config I noticed that in addition to variables for min and max warp multipliers, there's "warp_orbit_multiplier" and "warpcruisemult", what do these do and under what circumstances do they take effect?

I'd warn against raising the maximum multiplier that high, because the higher it gets, the more likely it is the autopilot will act up, and that interdiction fields won't be enough to slow you down when reaching the target.

Well so this is the situation, I decreased linear speed governors to ~1/3 of what they were, but I want SPEC travel to be as fast as it was before without being any more error prone than it was before.

So if I increase the SPEC multiplier(s) by the same factor I decreased the speed governors (3x) then will this be achieved? Or will some weird precision issue or something crop up?

I believe we need a new SPEC ramping algorithm that takes into account your targetted destination in order to be able to move the max multiplier that high.

Well what we really need is actually working SPEC interdiction in general. Encounters in deep space no longer happen at all unless maybe it is between two multiple kiloton craft.

In the config I can see that "default_interdiction" is set to 0.01. I wonder what that was set to back in 0.4.3 when even a small interceptor craft could actually intercept something in deep space?

[klauss]

There are variables that can be tweaked in the .config (not sure which, I'd have to check the sources), and there's at least one units.csv column that controls how much of an influence units have on the "interdiction" field.

In the config I noticed that in addition to variables for min and max warp multipliers, there's "warp_orbit_multiplier" and "warpcruisemult", what do these do and under what circumstances do they take effect?

I don't see warpcruisemult, warp_orbit_multiplier is an ASAP parameter that controls how far the autopilot gets from obstacles before it heads in the direction it has to (likely doing an orbit around the obstacle untill it gets a clear line of sight). It's an rSize multiplier, default 4.

I'd warn against raising the maximum multiplier that high, because the higher it gets, the more likely it is the autopilot will act up, and that interdiction fields won't be enough to slow you down when reaching the target.

Well so this is the situation, I decreased linear speed governors to ~1/3 of what they were, but I want SPEC travel to be as fast as it was before without being any more error prone than it was before.

So if I increase the SPEC multiplier(s) by the same factor I decreased the speed governors (3x) then will this be achieved? Or will some weird precision issue or something crop up?

I think that'd work fine.

But, thinking back, I think I achieved the same max speed as I did before the patch (99C). There's a global speed limit set to 99C that's taking precedence, I believe. Not sure whether increasing that limit would be troublesome.

The perceived SPEC slowness must be related to ramp-up times, the time it takes to get away from obstacles, not max SPEC limits.

I believe we need a new SPEC ramping algorithm that takes into account your targetted destination in order to be able to move the max multiplier that high.

Well what we really need is actually working SPEC interdiction in general. Encounters in deep space no longer happen at all unless maybe it is between two multiple kiloton craft.

In the config I can see that "default_interdiction" is set to 0.01. I wonder what that was set to back in 0.4.3 when even a small interceptor craft could actually intercept something in deep space?

0.4.3 had real trouble with NPCs "intercepting" you unwittingly all the time.

I think interdiction ought to be voluntary. Ie: you ought to have to target the unit in order to interdict. How we explain that canon-wise is another matter, but I believe that's a much saner option, game mechanics wise.

[Deus Siddis]

But, thinking back, I think I achieved the same max speed as I did before the patch (99C). There's a global speed limit set to 99C that's taking precedence, I believe. Not sure whether increasing that limit would be troublesome.

Sound like you are talking about "warpMaxEfVel" which is set to the strange value of "29202510832.6". It tempts me to move that decimal point one place over to the right...

The perceived SPEC slowness must be related to ramp-up times, the time it takes to get away from obstacles, not max SPEC limits.

So "warprampuptime" is set to a value of "5" presently, what happens if I set it to "1"? Will anything break?

0.4.3 had real trouble with NPCs "intercepting" you unwittingly all the time.

I think interdiction ought to be voluntary. Ie: you ought to have to target the unit in order to interdict. How we explain that canon-wise is another matter, but I believe that's a much saner option, game mechanics wise.

Not having "random" encounters like that anymore makes the game feel really empty though. All you ever see are dots on the radar unless you get close to a station or jump.

[klauss]

The perceived SPEC slowness must be related to ramp-up times, the time it takes to get away from obstacles, not max SPEC limits.

So "warprampuptime" is set to a value of "5" presently, what happens if I set it to "1"? Will anything break?

I think that value has to be increased rather than decreased. It's not the limit I'm talking about. That value is like SPEC's momentum, how long does it take to achieve its full potential speed regardless of interfering masses around the ship.

No, what I'm talking about is the interdiction values. Now it takes your ship longer to get far enough from interfering masses than before. So SPEC ramps up more slowly, but not due to configuration, but the fact that your ship simply moves more slowly.

Fixing that would entail tweaking interdiction values. I think there's something on the config about that, besides units.csv (I don't think units.csv ought to be touched for sweeping adjustments like these).

[safemode]

I would just like to say that at least without hardware acceleration, this realistic physics patch makes dogfights impossible. I think even with hardware accel it would make them very annoyingly long.

I think this will destroy newcomers gameplay completely. In order for it to be usable, we need to include some kind of system similar to the targeting system you can get that shows you where to shoot to hit someone who is moving. We need to show where the ship will point if motion is stopped. That needs to be default. We can allow it to be damaged or whatever, but to ask players to visualize where the ship will be pointed when they stop turning is not acceptable.

I want this realistic physics patch, but it's simply not going to work without that other patch to show your end position if motion is stopped.

[klauss]

I want this realistic physics patch, but it's simply not going to work without that other patch to show your end position if motion is stopped.

I don't know. It could also give players, newcomers especially, a reason to buy a fighter. Because the Llama turns like that because it's a rather big cargo ship. A truck.

[safemode]

how long do you think it will take to get a fighter ? nobody is going to play 2+ hours of the game when they not only have to shoot at significant distances at significant speeds without any sort of computer assisted targetting , but they have to also guess at how much their ship will oversteer without any sort of assistance.

A newcomer is going to launch into the game.. first they're going to realize that they're a boat. Then they're going to realize that trying to open fire on any ships is pointless. Then they're going to realize that to dock (because autodocking doesn't work ) they have to travel at around 5kph so they dont slam into whatever they're docking at. (which also, btw, we need to fix undocking code to launch the ship safely from the docking bays instead of the insanity that exists currently).

I dont know, It seems like nobody is playing this game as a brand new install and starting a new campaign and trying to progress through the game as a newcomer would. And dont use time dilation. I'd like to see what the take is after that because that's how I've been testing the game and while I really like the idea of realistic motion, including it means we'll need to make certain guidance systems standard.

You can't tell newbies to suck it up with the horrible gameplay for a few hours until they can buy a ship that you can actually use something other than guided missiles to defend yourself with.

[klauss]

You can't tell newbies to suck it up with the horrible gameplay for a few hours until they can buy a ship that you can actually use something other than guided missiles to defend yourself with.

Wel... perhaps starting conditions should be tweaked, or made selectable. As we discussed starting in safer or harder places, we could try starting with a cargo ship, a fighter, or a multipurpose.

OTOH, Llama is supposed to be multipurpose. Perhaps it should maneuver better while empty.

[IansterGuy]

[...]it might be helpful to raise the linear speed governors. Unfortunately that will make ships become less visible and less frequently encountered at close range.

Not such a bad thing since I'm guessing that even if fighters where shrunk, then best ships and upgrades would still not be too over capable of dodging.

Plus the player can easily override the governor anyway by using travel mode or turning off the fly by wire computer.

If the player can turn it off then AI should be able to turn off the governor for advantage too. Tactically they should all the time. So I don't see much purposes in having the acceleration cap deactivatable, that is not consistent cannon unless I'm not understanding. The governor the way it was and still is, has unnecessary limitations presented in non optimal ways. I think governor modes should be more about ease of controls rather than putting restrictions on the ship. For example, when pressing accelerate while governor is on it should simply mark up the ship speed at the same rate that the ship is currently capable of accelerating. With it off then the speed would be set able freely in a similar way to how one sets a high quality alarm clock; slow at first then faster and faster so any exact number can be easily picked quickly.

So we might look at increasing the linear governors on some categories of ship but not others, like maybe shuttles need more speed while interceptors are fine where they are or vice versa.

It will take a good while to get speeds right. Having this example is great so that there is something tangible that everyone can see the same thing. Though if it get's thought of as finished too soon before enough of the puzzles pieces are placed, it wont look like much.

Personally I'm okay with the Llama being relatively easy to shoot, being just a shuttle. Though fighters like Oswald's Robbin should be able to defeat a noob player not only because he has better shields but because he can more so outmaneuver the Llama. The sudden shield recharge rates of shilds are over powered. I think the damage should linger longer and raising retracted and ready shields, should be faster than repairing shields after they are destabilized or even destabilized shilds should take longer to retract

Long distance travel is definitely too slow now though and the best way to handle that is for SPEC to be made faster.

Faster in specific ways though. I think the ramp up should be much slower and the stopping fast but the maximum speed should be unlimited except to run out of fuel. This way any distance no matter the size varience of the solar system would be reachable in similar amounts of time. This would be much more dynamic. If players had enough fuel they would be even possibly be able to SPEC to other systems in a decent amount of time. It would be good because SPEC would feel like no small feat. Slowing down would be discouraged because it cost both significant time and fuel.

I still think the easiest way to fix SPEC speeds at the moment is to make the speed upgradeable

I thought having "speeds [accelerations?]" upgradeable was just an extra game element in 'shady upgrades' to customize ships to go faster than 10 G's. It would have little to do with the main part of balance.

Because all three of us who have tested it so far seem to agree that long distance travel is the roadblock problem with this patch. And that is exactly the type of problem SPEC is targeted to solve.

Yea I agree, SPEC is useful, even if distances between specific destinations where shrunk to be quick to reach by thrusters. Anything close enough to be convenient to thrust there would also have their interdiction fields overlap sot block SPEC anyways. So SPEC could easily be saved for everywhere else in the system.

there's at least one units.csv column that controls how much of an influence units have on the "interdiction" field.

If we are calling specifically the SPEC inhibition an 'interdiction field' that sounds good and if there is interdiction tech built into the ship that column makes a lot of sense to me till it would be a upgradeable component.

I'd warn against raising the maximum multiplier that high, because the higher it gets, the more likely it is the autopilot will act up, and that interdiction fields won't be enough to slow you down when reaching the target.

I believe we need a new SPEC ramping algorithm that takes into account your targetted destination in order to be able to move the max multiplier that high.

A new algorithm sounds good. The ship should be able to be stopped by an interdiction field no matter what speed the ship is moving through space. SPEC is very buggy as all speeds though it would take some math deep math and programing thinking to get it perfect. I bet that it needs to look farther ahead for collisions and consume more CPU power during low frame rates rather than allowing large mistakes like passing through objects. It is important though since SPEC seems here to stay.

I don't see warpcruisemult, warp_orbit_multiplier is an ASAP parameter that controls how far the autopilot gets from obstacles before it heads in the direction it has to (likely doing an orbit around the obstacle untill it gets a clear line of sight). It's an rSize multiplier, default 4.

I would almost expect the parameter to be dynamically set according to the interdiction field of the object being avoided. It would be nice the get rid of that thing where the ship keeps turning back and forth over and over while going around an object too close.

I believe we need a new SPEC ramping algorithm that takes into account your targetted destination in order to be able to move the max multiplier that high.

Well what we really need is actually working SPEC interdiction in general. Encounters in deep space no longer happen at all unless maybe it is between two multiple kiloton craft.

In the config I can see that "default_interdiction" is set to 0.01. I wonder what that was set to back in 0.4.3 when even a small interceptor craft could actually intercept something in deep space?

0.4.3 had real trouble with NPCs "intercepting" you unwittingly all the time.
I think interdiction ought to be voluntary. Ie: you ought to have to target the unit in order to interdict. How we explain that canon-wise is another matter, but I believe that's a much saner option, game mechanics wise.

Exactly, like was discussed where interdiction would be stronger when activated, when deactivated only minimal to avoid collisions.

Not having "random" encounters like that anymore makes the game feel really empty though. All you ever see are dots on the radar unless you get close to a station or jump.

Voluntary interdiction would solve this. {If I'm lonely then I'd just turn on interdiction so that I can ask the crew if they will "be my friend" If they start attacking and saying I'm annoying like people normally do I would assume it's a no} :S .

we need to include some kind of system similar to the targeting system you can get that shows you where to shoot to hit someone who is moving. We need to show where the ship will point if motion is stopped. That needs to be default.

I had proposed weapon intercept markers at New thrust, speed, rotation, vector & intercept indicators. Nothing was discussed about making markers to avoid oversteering due to turning inertia. I imagine it could be accomplished many different ways, some more distracting
then others. Note the thrust indicators I drew in the bottom center may be replaced with momentum indicators with an optimal aiming mometum marked, or something like that. This is just one vague idea of many, there are tones of possiblilties when just starting to think about it.

how long do you think it will take to get a fighter ? nobody is going to play 2+ hours of the game when they not only have to shoot at significant distances at significant speeds without any sort of computer assisted targetting , but they have to also guess at how much their ship will oversteer without any sort of assistance.

A newcomer is going to launch into the game.. first they're going to realize that they're a boat. Then they're going to realize that trying to open fire on any ships is pointless. Then they're going to realize that to dock (because autodocking doesn't work ) they have to travel at around 5kph so they dont slam into whatever they're docking at. (which also, btw, we need to fix undocking code to launch the ship safely from the docking bays instead of the insanity that exists currently).

Saying "nobody" is an exaggeration but adjusting for a few exaggerations your completely right.

And dont use time dilation.

Blaaaaaa!!!! Don't call 'time acceleration' or 'time compression' "time dilation"!!! 'Time dilation' is a fact of the universe that describes the laws of gravity, not a feature that would be included in a game. You are creating confusion with what I was calling "SPEC Dilation" a while back. Neither would 'SPEC dialation' be usefull for final docking. Also I agree that 'time compression' should be be ignored in all balance discussion even if it was slated for inclusion in the game because ideal settings would work perfectly without it, especially for the new player.

You can't tell newbies to suck it up with the horrible gameplay for a few hours until they can buy a ship that you can actually use something other than guided missiles to defend yourself with.

Yup, there are solutions to this.

Wel... perhaps starting conditions should be tweaked, or made selectable. As we discussed starting in safer or harder places, we could try starting with a cargo ship, a fighter, or a multipurpose.
OTOH, Llama is supposed to be multipurpose. Perhaps it should maneuver better while empty.

Yes but the Llama should be half the size according to what I have been saying here. Then it would be more like a fast shuttle, the acceleration may be the same but the turning inertia would be less, and it would be twice as hard to hit in combat.

[loki1950]

Have any one played pioneer enough to get into a combat situation it is very much as safemode described and they don't provide any aids apart from smart missiles,laser are useless as you can not aim them to wear your enemy will be so beams and bolts are useless without computer targeting and fire control human reflexes are just not fast enough when the target window is milli-seconds no fun combat means no users.

Enjoy the Choice

[klauss]

Yeah, I tried it. Elite was exactly like that. It's an accurate remake of it, but not a particularly fun one.

[Deus Siddis]

Safemode, what frame rate are you getting with no hardware, and which specific ships did you test in combat, BTW?

I think even with hardware accel it would make them very annoyingly long.

The length a battle should be depends on- 1. does the player have enough to do during a long fight and 2. what kind of player are you looking to attract.

Combat flight simulator fans probably won't mind battles lasting up to ~10 minutes, but I think with this balance 2 minutes is more likely the limit. If you want to attract ADHD console gamers though then you need battles to never last longer than 20 seconds. VS has already tried to attract the ADHD crowd with its old combat balance though and look at where it's popularity is now... and then look at the popularity of Flight Gear.

We need to show where the ship will point if motion is stopped.

If as klauss suggested, you are mainly talking about the llama here, then we could halve its particular angular speed governor values and over steer won't be an issue. Also I think that as the big ~40 meter long craft that it is, the llama should have 2 of its forward guns replaced with 2 turrets, each housing a light gun and together providing quickly trainable firepower in every direction. The llama is twice as long and many times bigger than an old flying fortress, so how can you expect it to be a nimble fighter when it should be, at least partially, a gun turret platform. If you want a nimble fighter starting ship though, we could make the game start you out in something smaller or just scale the llama down and give it less cargo space.

But taking away too much of over-steer and linear drift will entirely gut a skill based space flight sim that VS has always pretended to be. Already you have no complex atmospheric physics like aircraft flight sims, no cover like in FPS games, no experience like in RPGs, etc. So if you take away all the skill and the dynamics of piloting a vehicle and you don't have a game anymore (again). Point your ship at enemy, kill enemy, point your ship at destination, drop off cargo, rinse and repeat until you have had enough and uninstall VS.

I want this realistic physics patch, but it's simply not going to work without that other patch to show your end position if motion is stopped.

If you want to code this feature then fine... assuming of course it doesn't overly clutter the GUI or anything. Personally I think the game could benefit a lot more from something that tells you the linear drift of ships, at least if linear speed governors end up higher than they are in the latest patch.

[log0]

I've been using a modified hud locally because I enjoy vectoring maneuvers http://forums.vega-strike.org/viewtopic ... 27&t=18458 . It differentiates between flight and heading direction and has an interception point marker as additional elements, and changes a few others. Not sure how much of it is interesting for vegastrike though.

[klauss]

But taking away too much of over-steer and linear drift will entirely gut a skill based space flight sim that VS has always pretended to be. Already you have no complex atmospheric physics like aircraft flight sims, no cover like in FPS games, no experience like in RPGs, etc. So if you take away all the skill and the dynamics of piloting a vehicle and you don't have a game anymore (again). Point your ship at enemy, kill enemy, point your ship at destination, drop off cargo, rinse and repeat until you have had enough and uninstall VS.

I agree, it's not supposed to be easy. But starting ships shouldn't be too hard either.

It's a matter of finding the right balance.

[Deus Siddis]

I have been thinking that at some point there should be a range established for the ratio of governor to acceleration, both for the linear and angular. It would be measured in seconds to reach the governor (maximum speed). So for turning, maybe the max would be 5 seconds and the minimum would be 1.

And perhaps the civilian oriented shuttles like the llama would have smaller delay times but not be able to perform as quick a turn as a result, the idea being safety and idiot proof-nees is what you want for an efficient cargo hauler with a minimum wage pilot. But then the combat craft and large craft would be all about performance and require more skill and planning to maneuver with higher governor to acceleration ratios.

[IansterGuy]

I've been using a modified hud locally because I enjoy vectoring maneuvers http://forums.vega-strike.org/viewtopic ... 27&t=18458 . It differentiates between flight and heading direction and has an interception point marker as additional elements, and changes a few others. Not sure how much of it is interesting for vegastrike though.

I actually think that is really cool. Is it finished the way you had drawn it? If so I'm surprised you have not released a patch on that thread. One would think that the pilots would want to have all the tools like this in their ships.

[log0]

I've been using a modified hud locally because I enjoy vectoring maneuvers http://forums.vega-strike.org/viewtopic ... 27&t=18458 . It differentiates between flight and heading direction and has an interception point marker as additional elements, and changes a few others. Not sure how much of it is interesting for vegastrike though.

I actually think that is really cool. Is it finished the way you had drawn it? If so I'm surprised you have not released a patch on that thread. One would think that the pilots would want to have all the tools like this in their ships.

Well, from the comments it seemed to me there was some confusion about the different symbols(I used an aircraft hud as reference btw) and a request about making it togglable. So I've got the impression it might be too much for the target audience. But yeah, I can post a patch when I get home.

[log0]

I have been thinking that at some point there should be a range established for the ratio of governor to acceleration, both for the linear and angular. It would be measured in seconds to reach the governor (maximum speed). So for turning, maybe the max would be 5 seconds and the minimum would be 1.

And perhaps the civilian oriented shuttles like the llama would have smaller delay times but not be able to perform as quick a turn as a result, the idea being safety and idiot proof-nees is what you want for an efficient cargo hauler with a minimum wage pilot. But then the combat craft and large craft would be all about performance and require more skill and planning to maneuver with higher governor to acceleration ratios.

I've tested the llama(without cargo) yesterday a bit. The delta to reach angular velocity limit is too large. Either the ang accelerations needs to be increased or the ang velocity limit reduced. Or as you say, there should be a fixed coupling between both. Maybe not more then 2 secs from max negative ang velocity to max positive (full rotation reversal), to avoid constant overshooting. Optionally one might be able to disable ang velocity governor independently.

As it is now, it gets tiresome after 5-6 mins chasing a target (I know not the typical time for a dogfight, just testing).

Edit:
How about displaying angular velocity magnitude and limit info, analogous to the linear one?

[Deus Siddis]

I've tested the llama(without cargo) yesterday a bit. ... Maybe not more then 2 secs from max negative ang velocity to max positive (full rotation reversal), to avoid constant overshooting.

I guess that wouldn't be a bad value for the llama for starters.

As it is now, it gets tiresome after 5-6 mins chasing a target (I know not the typical time for a dogfight, just testing).

I don't know that this balance can fix that issue. It is the job of SPEC to both make travel quick and allow you to snatch your prey out of SPEC travel and hold them there. But adjusting it be good at both of those things seems to be a difficult.

How about displaying angular velocity magnitude and limit info, analogous to the linear one?

It's an option, but I think trying to get the game to work without any new HUD features is the first step.

For small ships at least. For gigantic ships like the Ox that turn like a snail, such a guide might be necessary.

[IansterGuy]

Maybe not more then 2 secs from max negative ang velocity to max positive (full rotation reversal), to avoid constant overshooting. Optionally one might be able to disable ang velocity governor independently.

I think the absolute maximum angular acceleration really should depend on the limiting factor of either the sheering force due to the extended out ship mass; or 10g anywhere on the ship expected to hold passengers during manoeuvrings. Anything up to that maximum I am am okay with. The Llamba is huge though for something that is supposed to double as a combat vessel. I just imagine the meters per second cargo is being moved at inside every turn and the amount of force that exerts on anything not in the centre of mass of the ship. I think the Llama should be half the size, same with all the fighters, so to me, twice the expected turning speed is believable now, it makes sense assuming the ship would be smaller.

As it is now, it gets tiresome after 5-6 mins chasing a target (I know not the typical time for a dogfight, just testing).

I don't know that this balance can fix that issue. It is the job of SPEC to both make travel quick and allow you to snatch your prey out of SPEC travel and hold them there. But adjusting it be good at both of those things seems to be a difficult.

I think that is a separate issue, but indeed SPEC outside the should be fixed with the interdiction methods of jamming discussed in the topic here.

How about displaying angular velocity magnitude and limit info, analogous to the linear one?

It's an option, but I think trying to get the game to work without any new HUD features is the first step.

For small ships at least. For gigantic ships like the Ox that turn like a snail, such a guide might be necessary.

True but I'm working on a updated HUD proposal based on what has been discussed. I think visuals are better in this situation. I'm working on combining discussed HUD proposals with Log0's HUD proposal and with my HUD proposal in an image with all indicators set to the scenario. With indicators set to the scenario people can test what information their able easily retrieve from a single unmoving image.

[Deus Siddis]

Updated physics patch with lower llama angular governors. The llama now handles more precisely and slowly.

[IansterGuy]

I don't like the changes made just now for a couple reasons. It's too basic of a solution that replaces one problem with another. A space pilot would not allow limitations on his ship to make it easier to steer when his opponent could go without those limitations, and further more, would take advantage of the predictable turning rate. It makes the ships feel sluggish and it goes back to insulting the players intelligence by saying "ships can only turn this fast for your safety".

I think the governor for maximum spin speed AKA the maximum angular velocity should be as fast as the limiting factor of either ship hull, equipment, or passengers can take. So the smaller the ship the faster it can spin. Governors I thought where to make it believable to assist in what some people call immersion not to make it easy to master.

It is up the the player to learn to fly the ship and not spin around missing everything like they don't have a care in the world. I think this just shows how realistic this is that you must steer with a time delay just like large passenger air plane pilots must. Being a passenger plane simulator fan this set-up now is insanely easy for me to steer, I am sure most people will get bored of this and frustrated when they can't get a single shot at their enemy who can now just stay behind them the hole time. It is much better with an angular velocity governor so hight that no one hits it unless they are spinning around for fun.

Predictive flying I'm pretty sure will make this game more addicting to most players interested in this game, because they are probably playing it for the Semi-Newtonian physics like me. If the player requires help to learn, I suggest giving him tools not rules nor limitations. It already does work without any HUD assistance, so any that is given would be bonus.

[log0]

@IanisterGuy are you using a joystick? Maybe this is the actual problem.

With a mouse(as I've tested it) people would expect the vessel to go in the direction the target reticle is pointing at(with delay of course due to inertia). The problem with a high ang velocity limit(relative to ang acceleration) is, that the controller has a really hard time to match the desired flight direction, resulting in what I've called constant overshooting. The vessel never goes where you actually want it to. It forces you to correct the flight direction all the time, which I personally found tiring after a few minutes maneuvering.

I am not sure whether there is a way to fix the mouse controller to somehow account for that. Thus the (call it lame) proposal to lower ang vel limit relative to ang acceleration but allow to disable it. It is analogous to the linear velocity governor, where you could also argue, that it is insulting to the player being constrained to 150m/s in maneuvering mode.