|
Post by qswitched on Sept 27, 2016 16:21:16 GMT
Runge-Kutta methods are used, and the time step is adaptive. I'll keep noodling ways to get better performance out of it.
|
|
|
Post by argonbalt on Sept 27, 2016 18:53:01 GMT
Now wait a second and here me out, but could we, maybe in some sort of Easter egg, YOU GOT GOLD ON ALL MISSIONS type deal, just maybe, keep the superguns? or perhaps someone could include it as an option-able mod. I mean i agree that in the base game things should probably be fixed, but i can't help but fell a little attached to the Paris(space)guns. Like i don't know include(as a bonus or something) a Chogokin material to preserve some of these gloriously insane exit velocities?
|
|
|
Post by qswitched on Sept 27, 2016 20:07:40 GMT
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? Actually, I found I can get pretty reasonable performance compromise by redo-ing the integration at higher and higher precisions if it detects the equation is screwing up the approximation at the current precision. Additionally, I discovered some a large glaring flaw in weapon stress. As one might expect, the long, thin shape of the weapon shatters very easily when fired, and that stress was lower than it should've been when the shape is very long. I was wondering why all the designs were shaped like toothpicks and yet seemed to withstand stress quite easily. That will also be fixed in the next update. I look forward to seeing how the guns get broken next
|
|
acatalepsy
Junior Member
Not Currently In Space
Posts: 97
|
Post by acatalepsy on Sept 27, 2016 20:19:23 GMT
I look forward to seeing how the guns get broken next I'd be more worried about the armor-penetrating, ship-killing 100km death ray lasers. More when I get home and have time to test it for myself rather than hearing second-hand.
|
|
|
Post by blothorn on Oct 2, 2016 3:42:56 GMT
|
|
joker
New Member
Posts: 8
|
Post by joker on Oct 2, 2016 4:37:29 GMT
Yeah, current gun efficiency is totally insane. How could it spit tons of metal in one second?
|
|
tuna
New Member
Posts: 33
|
Post by tuna on Oct 2, 2016 7:21:20 GMT
Rather than capping the max velocity, maybe just have a hard cap on fire rate, so that total fire rate is max(current computation, coilgun_module_power/kinetic_energy_of_a_single_shot). No more superguns that output more power than they should, no more complexity in implementation.
|
|
|
Post by peridot on Oct 6, 2016 18:03:49 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. Indeed, there are robust adaptive integrator codes out there that can produce accurate results for a huge range of problems. The better ones - typically ancient but well-tested open-source FORTRAN codes - can also detect when they've hit their limits, so that the game could simply outlaw anything that breaks the integrator. Or let people minmaxing wait for their results. One could even have an impressive-sounding "please wait for electromagnetic simulation" dialog box. I believe VODE and LSODE should be robust in this way - pretty bulletproof solution-wise, and with a good enough interface for the game to fail gracefully. FORTRAN, of course. If you're in C++, Boost provides several good adaptive integrators (including some high-order symplectic ones for the orbits). There should be C implementations floating around too, with permissive licenses. But yes, integrators robust enough to handle scientific problems are quite possibly not robust enough to handle players determined to push them to the breaking point.
|
|
|
Post by captinjoehenry on Oct 6, 2016 20:32:30 GMT
Another thing that seems to break is that the rate of fire has no real impact on energy use other than to power the loader . Also Zirconium Copper for coil guns seems to break stuff. I have made a coil gun that uses less than a megawatt of power to through about 10 100kg slugs down range at around 18km/s. It does have a 100mw loader and like 200+mw reaction wheels (oh god why do I need to use these for my 1,000 ton + super gun turrets!).
|
|
|
Post by JagerIV on Oct 6, 2016 23:18:37 GMT
Yeah, each individual shot not requiring power would be a serious problem: I've only been messing with conventional weapons (which already seem to have, strange issues regarding rate of fire having nearly no impact on anything), but if that the case with energy weapons, that's an even bigger issue.
Especially since it might suggest you're ignoring a potentially large source of mass: capacitors. A 1 gigawatt generator produces that over a second. A 1 gigawatt laser runs through that in, what, 1/1000 of a second? Though there I seem to be mixing joules with Watts, a dangerous thing. Let me rephrase that then. A 1 billion joule laser could deposit that over a 1/1000 of a second. That means the capacitors would need to store at least a full secound's generator output. And if you wanted to fire more than once a secound, you need some massive capacitors/batteries to store several shots.
Any weapon which relies on large power draws should have this issue.
|
|
|
Post by JagerIV on Oct 7, 2016 0:06:11 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. Just as a question: does it only reduce performance in the ship design window, or does it produce it in gameplay? Because if this kind of calculation matters in gameplay, this seems to suggest something very flawed in the optimization and logic being used to run the game.
|
|
|
Post by n2maniac on Oct 17, 2016 2:24:47 GMT
After tweaking with coilguns and railguns, I was starting to wonder if BackEMF was assumed 0% in every case, causing efficient designs to break 100% efficiency. If so, I would recommend adding projectile kinetic energy to the power requirements for each shot leaving the barrel (which will significantly increase power requirements for the high hypervelocity death rays I made).
Then I see this thread. Good to know there are more out there breaking things like I am.
|
|