|
Post by jtyotjotjipaefvj on Jul 12, 2018 2:20:27 GMT
PTFE doesn't "melt" in the traditional sense as the molten material is so viscous that it doesn't visibly flow like other molten materials, which makes it really handy as an outer anti-laser layer. That's not simulated in any way whatsoever though. Not even melting is. Heating the material to its melting point is enough to destroy it, which results in extremely inaccurate performance in most cases. I suppose it might be a good approximation of ablation at low intensities, but it makes no sense for gigawatt beams.
|
|
|
Post by jtyotjotjipaefvj on Jul 10, 2018 14:19:31 GMT
It seems the level editor automatically sets the first planet you add as the main body, and it can't be changed anywhere. This is fine for missions taking place around a single planet, but makes interplanetary missions almost impossible, since planetary orbits around Sol don't render properly, and orbits can't be projected to the sun's reference frame. Adding a dropdown menu to allow selecting main body would fix this. Or is there even any benefit to not having the main body as the local sun?
It can be worked around by setting main body manually in UserLevels.txt but it needs to be set every time you adjust the level in the editor, which is not very convenient.
|
|
|
Post by jtyotjotjipaefvj on Jul 10, 2018 11:20:19 GMT
You don't need fixed point calculations specifically, you can go with bare ints as long as you can live with arbitrary units you pick to avoid overflows on one side and cover your range of expected values on the other. What you've done there is you've just described fixed point numbers. Adding and subtraction will work fine on native integer operations, but things get hairy once you need anything more complicated. There's no hardware trigonometry or square root operators for integers so you'll have to make your own software implementation, which will be extremely slow by comparison.
|
|
|
Post by jtyotjotjipaefvj on Jul 9, 2018 23:47:47 GMT
A few patches ago, PTFE and nitrile rubber were superseded by PE (polyethylene) for anti-laser armor. It has the good efficiencies for both mass and credits, while not being the best at either. Here's a more detailed data sheet based on the game's laser damage model. The table on the left is relevant to your interests, the one on the right is for a mod that removes laser ablation cap. For ballistic protection things are not that simple and it doesn't seem like there's a single simple formula that would apply for most cases. Here are some recommendations for what works against hypervelocity projectiles (a 50 km/s railgun design I happened to have.) Monolithic plate: It doesn't seem like material choice for the main plate matters all that much, as long as the material is reasonably strong and doesn't shatter too badly on penetration. For a similar mass, it seems all these "good" materials work almost equally well. Good materials I've found include Beta Titanium, Vanadium Chromium Steel and Titanium. I've also experimented with plate materials that are nuke-resistant, which would work nicely as a multipurpose material. Zirconium Carbide seems to be one good candidate for this. 3-5 mm depending on material density seems to be a decent amount, lasting around 10 seconds against a dozen max firerate guns hitting a single small spot. Increasing it to 1-2 cm increases survivability further. Spall liner: The bulk plate should be backed by some ductile material like spider silk or nitrile rubber. Just a few millimeters seems like enough for a spall liner, and increasing it does not seem to help much. Whipple shield: A whipple shield stuffed with Graphite Aerogel is absolutely mandatory. No other combination of armor layouts comes even close to the low mass / high protection provided by a whipple stuffed by a meter or more of graphogel. Any less than a meter, and your performance will drop dramatically. Past that and it seems you'll hit diminishing returns. The whipple shield material doesn't seem to matter terribly much, but it should be something that does not generate huge plasma cones on hit. I've found just a few millimeters of Aluminum to be sufficient here. I also noticed that you can replace your whipple shield with 1-2 cm of PE for a combined whipple shield and anti-laser layer, which is very nice for keeping your armor layout simple. I haven't found any use in adding spacers anywhere, but there's so many possibilities I can't really rule that out either. At least I can say for certain that a meter of graphogel works far better than a meter of spacing behind a whipple shield.
|
|
|
Post by jtyotjotjipaefvj on Jul 9, 2018 20:13:17 GMT
I've used AE modules for nearly a year and this is the first time I have any issues with them. I suspect it has something to do with the new separation between core and mod modules. I'm not sure about [AE] modules, but I have definitely seen workshop blueprints missing vital modules, often depending on other mods, their order of installation, phase of the moon and CMB fluctuations. My use case is quite different though. These are designs I made yesterday and they no longer work correctly even though I've made no changes in the last four months to the only mod I have installed.
|
|
|
Post by jtyotjotjipaefvj on Jul 9, 2018 20:10:29 GMT
I meant 64b ints. Why trade valuable precision for ability to handle stuff on microscopic scales (close to the origin) or galactic scales (far away) if neither interests us? Because fixed point math will be significantly slower than floating points, since there's no hardware implementation of them in the CPU. There also doesn't seem to be too many ready-made implementations (because what madman would want to use them?) so you'd have to implement a whole bunch of math algorithms yourself. Already the orbits can get quite laggy in gas giant systems, I don't want to suffer even worse just to get some more precision, when the worst issues can be worked around quite easily.
|
|
|
Post by jtyotjotjipaefvj on Jul 9, 2018 19:40:50 GMT
same precision everywhere Math happening close to the simulation origin will still be more precise thanks to how floating point numbers work. Also, numerically integrating the orbit will mean accumulating errors the further you go. Are you even sure the orbit simulation doesn't already use 64-bit floats? It wouldn't be a major change to do it so I'd imagine it already runs on double precision.
|
|
|
Post by jtyotjotjipaefvj on Jul 9, 2018 19:36:50 GMT
I've used AE modules for nearly a year and this is the first time I have any issues with them. I suspect it has something to do with the new separation between core and mod modules.
|
|
|
Post by jtyotjotjipaefvj on Jul 9, 2018 11:12:58 GMT
I keep running into issues with ship designs containing references to the AE module package. I get no error messages or crashes, but any ship containing references to mod modules loads with the mod modules missing. Creating a copy of the mod module and using that instead of the original seems to work correctly though. I was able to work around this issue by cut-pasting the entire AE module collection into my UserDesigns, after which everything seems to load correctly. Here's an example ship which appears in UserDesigns correctly, but when loaded is missing the reactor and its radiators. Replacing the reactor with a stock one makes it load correctly. CraftBlueprint Dart Drone Modules Aggressive Remote Control 1 0 null 0 0 10.0 MW 4mm Internal Railgun 1 25.904 null 0 0 88mm Turreted 3 - Cannon 2 3.0277 null 0 0 [AE] 100 kN Methane NTR 2 1 0 null 0 0 200 kg Methane Tank 2 9.7414 null 0 4 600 kg Methane Tank 2 11.032 null 0 3 200 kg Methane Tank 2 18.75 null 0 7 200 kg Methane Tank 2 14.544 null 0 8 600 kg Methane Tank 2 4.8982 null 0 1 600 kg Methane Tank 2 4.509 null 0 6 600 kg Methane Tank 2 17.497 null 0 5 [AE] 10.1 MW Reactor 2 21.461 null 0 0 6x1 Boron Nitride Radiator 2 0.24011 [AE] 10.1 MW Reactor 1.5708 0 6x1 Boron Nitride Radiator 2 1.4803 [AE] 10.1 MW Reactor 1.5708 0 Armor Shape Dodecagonal Concave true AspectRatio 2.32 ArmorLayers Spider Silk 0.001 0 0 1 1 0 Beta Titanium 0.001 0 0 1 1 0 Graphite Aerogel 0.05 0 0 1 1 0 Polyethylene 0.002 0 0 1 1 0
I'll attach my UserDesigns as well as the AE modules package so you can test this for yourself. UserDesigns.txt (42.08 KB) Apophys Electrics Standard Modules v1.5.txt (87.39 KB)
|
|
|
Post by jtyotjotjipaefvj on Jul 8, 2018 18:08:32 GMT
Number of ships (including missiles and drones) also contributes heavily to lag. In a 1v1 situation you can have close to a hundred thousand rounds flying before the lag gets too bad.
|
|
|
Post by jtyotjotjipaefvj on Jul 8, 2018 17:18:28 GMT
Lag from long-range railguns can be solved by getting rid of the payload. You can have a dozen of these going at max range and you won't get too bad lag. I'm including the design view so you can copy a bunch of weight saving concepts, mainly the aerogel barrel armor and vcs-vcs projectile and rail combination that seems to result in a very light barrel when not using a payload. Note also the wafer-thin momentum wheels. With coilguns, I like to use heavier projectiles since they work far better than railguns. The capacitor version is capable of shooting targets on its own, whereas the other one is meant as a final guidance stage for the rounds, and all energy will come from the firing drone's engines. When hitting a gunship at 5 km/s, both rounds will go straight through the armor on both sides.
|
|
|
Post by jtyotjotjipaefvj on Jul 8, 2018 12:32:52 GMT
Orbit accuracy decreases the further you go from the last maneuver. You can fix this by adding a miniscule course adjustment just before the intercept.
|
|
|
Post by jtyotjotjipaefvj on Jul 3, 2018 19:26:54 GMT
]Confirmed, it's the case with railguns as well - have one that takes 2ms to fire, but reloads faster. You don't really get any benefit in that case. Guns operate at 30 Hz frequency, anything inbetween is skipped. Your gun will fire only 30 rounds per second despite the massive reload speed.
|
|
|
Post by jtyotjotjipaefvj on Jul 3, 2018 17:55:43 GMT
The questionable capacitor efficiency when staging still happens in the latest version. I also noticed that coilgun firing time is not taken into account at all, which can lead to coilguns that have over 100% actual efficiency, despite what's claimed by the weapon info screen. If the firing time is longer than one simulation tick, you can use a loader that's faster to get free energy out of your coilgun. For example this gun fires 8.2 kJ rounds at 15 rounds per second, dictated by the loader speed, producing 125 kW of kinetic energy output while only draining 10 kW power. Rate of fire should be limited by firing time as well, not just loader and capacitor. I haven't tested this for railguns but I assume same thing happens there as well.
|
|
|
Post by jtyotjotjipaefvj on Jul 3, 2018 9:24:47 GMT
But for gameplay reasons I guess we'll have to live with it until armor transparency, reflectivity, and active cooling are added. Armor transparency and reflectivity are already modeled. It doesn't account for beams passing through plates to other layers, nor interreflection between armor surfaces, but otherwise it seemed to be modeled correctly.
|
|