acatalepsy
Junior Member
Not Currently In Space
Posts: 97 
|
Post by acatalepsy on Sept 27, 2016 2:33:07 GMT
I think we need to have a conversation about how range and accuracy is calculated in this game. Within the stock ships, range is fairly limited, by design. This is good for the game; it means that there's a balance between weapons, and deciding how to intercept a given target matters. If we all had infinite range death guns, the game would be a lot more boring. Introducing your infinite range death gun. Credit for this one goes to open_sketchbook on SV.  This one is mine; it's small enough to fit several on a single ship or even a large sized drone.  Yes, that muzzle velocity is 9.95 Megameters per second - or nine thousand, nine hundred and fifty kilometers per second. Yes, that will destroy almost any ship instantly from ranges of over six hundred kilometers. Similar experimentation will get you similar results with coilguns and railguns - if you make a small projectile, or simply optimize for speed of projectile and range, you will very quickly find yourself with a ship that will murder anything stock for cheap. You can even mount some of these artillery pieces on (reasonably sized) drones for less than 200 kw - in case you thought there was a downside to all this juicy firepower, there isn't. I think this is, for lack of a better word, a problem. I don't know if I'd consider combat solved in the very first weekend, but certainly it's been broken. The ideas presented in the game for how to fight are at-best irrelevant to how the combat paradigm works under the game's own rules. The combat speeds being what they are, weapons of this range, accuracy, and power render all attempt at maneuver irrelevant; when speeds are on the order of at-most a few kilometers per second (and usually much slower), someone with a gun that fires accurately at hundreds of kilometers more will win. If both sides have the same weapon, then the contest becomes a pure gun duel, without the complexities of missile/point defense engagements, or even the effect of different relative velocities and arrangements of ships. A buffet of options is reduced to one decent but bland flavor. One thing to ask is what the rules regarding accuracy are, and if they are not too simple, or otherwise broken by crafty players taking advantage of a weakness in the rules that would not be viable in the real world. At the ranges we're talking about, should other things that the physical characteristics of the weapon be determining accuracy? Might there be a patch to rebalance precisely this kind of thing? |
|
|
|
Post by qswitched on Sept 27, 2016 4:16:05 GMT
Muzzle velocities that high even with that low of mass are almost certainly incorrect. This is indicative of an incorrect physical limit, or a physical limit that was missed during implementation. Once the flood of bugs dies down, I'll take a closer look at this. Thanks for catching it though!
|
|
|
|
Post by jakjakman on Sept 27, 2016 5:03:22 GMT
Only 1 MW to power that thing? No way. Can't have more energy come out of the barrel than you feed the thing with.
This is also true for the stock 286mm coilgun. It shoots 10kg projectiles at 5.2 km/s, at a rate of 7.7 per second. So the kinetic energy is coming out the barrel a rate of 1.04 Gigawatts, yet it only requires 13 MW for power.
|
|
|
|
Post by beta on Sept 27, 2016 5:42:02 GMT
|
|
|
|
Post by aetreus on Sept 27, 2016 6:17:38 GMT
It's something to do with loader power consumption and rate of fire. Looking at coilguns when they have very rapid rates of fire(which is the opposite case as these super-guns), their velocity changes very little with changes in fire rate. For the super-guns, it's the reverse, small changes in fire rate mean very big changes in velocity. My guess would be that there's two errors somewhere to do with figuring out stored power for firing and that's resulting in behavior which seems correct in general behavior but is off when it gets towards edge cases.
|
|
|
|
Post by beta on Sept 27, 2016 6:21:41 GMT
Yeah, I would agree it is to do with the loader power. Increasing it by even 10 watts drops muzzle velocity a LOT.
|
|
|
|
Post by jonatanhedborg on Sept 27, 2016 8:02:55 GMT
As jakjakman mentioned, this violates some pretty basic laws of physics  The second one generates ~1 500x more kinetic energy than it consumes in electricity, and the first one ~28 850 000x (before relativistic effects). |
|
|
|
Post by qswitched on Sept 27, 2016 11:21:20 GMT
So after some digging, it turns out these particular weapons are min-maxed to take advantages in the numerical integrator's inherent inaccuracy. Because coilguns apply highly nonlinear force, exacerbating it can cause the integrator to approximate the acceleration very badly. Reducing the integration timesteps by a factor of 100x reduces that particular coilgun's exit velocity down to about 2 km/s. Making even finer timesteps would reduce the exit velocity further to it's more accurate state.
Such is life with a numerical integrator. Coilgun force equations are too complex to solve, and must be approximated in this way (as are railgun equations).
Unfortunately, increasing the simulation accuracy to fix the issue causes performance to plummet until things are unusable. I'll likely just have to clamp the values in these cases to the kinetic energy.
|
|
|
|
Post by beta on Sept 27, 2016 11:48:34 GMT
To be expected with such an open ended design interface. I'm actually surprised it took so long to "break" the game in that manner. Now for lasers ...  |
|
|
|
Post by Crazy Tom on Sept 27, 2016 12:02:46 GMT
Unfortunately, increasing the simulation accuracy to fix the issue causes performance to plummet until things are unusable. I'll likely just have to clamp the values in these cases to the kinetic energy. I've been thinking about this, and I was wondering if you needed to do the integration each time the gun fires? Couldn't the gun be simulated once when it's designed and use the values generated during testing in gameplay? |
|
|
|
Post by jakjakman on Sept 27, 2016 12:33:10 GMT
So after some digging, it turns out these particular weapons are min-maxed to take advantages in the numerical integrator's inherent inaccuracy. Because coilguns apply highly nonlinear force, exacerbating it can cause the integrator to approximate the acceleration very badly. Reducing the integration timesteps by a factor of 100x reduces that particular coilgun's exit velocity down to about 2 km/s. Making even finer timesteps would reduce the exit velocity further to it's more accurate state. Such is life with a numerical integrator. Coilgun force equations are too complex to solve, and must be approximated in this way (as are railgun equations). Unfortunately, increasing the simulation accuracy to fix the issue causes performance to plummet until things are unusable. I'll likely just have to clamp the values in these cases to the kinetic energy. Makes sense! Thanks for taking the time to look into this for us. Brings me back to the days of my numerical methods class |
|
acatalepsy
Junior Member
Not Currently In Space
Posts: 97
|
Post by acatalepsy on Sept 27, 2016 13:06:05 GMT
I've been thinking about this, and I was wondering if you needed to do the integration each time the gun fires? Couldn't the gun be simulated once when it's designed and use the values generated during testing in gameplay? Presumably it is, but it's also recalculated every time to change something in the designer. If it started taking minutes every time you dragged a slider, that would be pretty unbearable. Unfortunately, increasing the simulation accuracy to fix the issue causes performance to plummet until things are unusable. I'll likely just have to clamp the values in these cases to the kinetic energy. This is still pretty unsatisfying, at least as far as it means that it means that coilgun and railgun design would still likely revolve around breaking the numerical integration to yield perfectly efficient linear accelerators. Or do you mean doing some kind of clamping in the intermediate steps? Gotta agree with jakjakman here: this takes me back. So many matricies - I can't help but feel there's a solution here that maintains the physical approximation. |
|
|
|
Post by Crazy Tom on Sept 27, 2016 13:47:28 GMT
I've been thinking about this, and I was wondering if you needed to do the integration each time the gun fires? Couldn't the gun be simulated once when it's designed and use the values generated during testing in gameplay? Presumably it is, but it's also recalculated every time to change something in the designer. If it started taking minutes every time you dragged a slider, that would be pretty unbearable. Not necessarily. First, there could be a 'Validate Design' button that you click once you've made the changes you want so that it didn't recalculate each time. Second, while you're in the module editor, the game isn't simulating anything else, so it might be the case that even with a smaller time step for the integrator, real-time simulation wouldn't slow the game. I prefer the second option, but it would come down to how much time would be needed to simulate the results each time. |
|
acatalepsy
Junior Member
Not Currently In Space
Posts: 97
|
Post by acatalepsy on Sept 27, 2016 14:12:16 GMT
Not necessarily. First, there could be a 'Validate Design' button that you click once you've made the changes you want so that it didn't recalculate each time. Second, while you're in the module editor, the game isn't simulating anything else, so it might be the case that even with a smaller time step for the integrator, real-time simulation wouldn't slow the game. I prefer the second option, but it would come down to how much time would be needed to simulate the results each time. I mean that I think it's already done this way - the calculation of weapon properties is done only in the designer. But I can see how decreasing the size time step in the designer would rapidly become a problem; even while doing nothing else, it could absolutely grind to a halt. There are various options for how to do detailed integration while still maintaining usability, but all of them require sacrificing some amount of clarity and usability IMO. My preferred solution would be to keep the "cheap" estimation, then run a detailed integration in the background after changes have been made (and have a spinning icon or something to let the user know that this was happening), then update with the 'real' result, but how workable that is only one person can say for sure. I think in general you'd want to try to detect and compensate for boundary conditions, but anyone who had done simulation and modeling can tell you what kind of rabbit hole that can turn out to be. |
|
|
|
Post by quarkster on Sept 27, 2016 14:37:36 GMT
So after some digging, it turns out these particular weapons are min-maxed to take advantages in the numerical integrator's inherent inaccuracy. Because coilguns apply highly nonlinear force, exacerbating it can cause the integrator to approximate the acceleration very badly. Reducing the integration timesteps by a factor of 100x reduces that particular coilgun's exit velocity down to about 2 km/s. Making even finer timesteps would reduce the exit velocity further to it's more accurate state. Such is life with a numerical integrator. Coilgun force equations are too complex to solve, and must be approximated in this way (as are railgun equations). Unfortunately, increasing the simulation accuracy to fix the issue causes performance to plummet until things are unusable. I'll likely just have to clamp the values in these cases to the kinetic energy. This is happening with Runge-Kutta methods? You may want to look into how those are being implemented, as you should be dynamically adjusting your time-step size to suit the needs of the problem. |
|
The second one generates ~1 500x more kinetic energy than it consumes in electricity, and the first one ~28 850 000x (before relativistic effects). 
