Yeah, for some reason atomic bomb damage barely scales with yield, if the bombs are detonated at contact range. I think it does affect the radius of the splash damage, though.
I have a 1.38 Mt design that weighs only 164 kg, but I never use it because the effects are so underwhelming. Cluster-bombs containing several small nukes are far more effective, especially considering the cost of uranium.
Due to the nature of sliding electrical contact, a railgun necessarily vaporizes some fraction of the projectile. Pushing velocity higher requires imparting more kinetic energy per unit projectile mass, which I'm pretty sure will increase the fraction of the projectile that gets vaporized. You can't just keep trading mass for velocity, because eventually you have a "gun" that puffs plasma instead of shooting bullets.
I don't think this is solved by plasma sabots, because you're dumping lots of energy into that plasma, and the projectile is in close contact with it all throughout the acceleration.
I suspect that this limitation, or something else, would take hold even at the projectile masses and velocities we can access without editing limits.txt. I did some research into what velocities are achievable with railguns, and as far as I can tell they don't do much better than light gas guns IRL. I've found things like this, which, while similar to a railgun in principle, is not at all like the usual conception of one or what we have in game, and probably has abysmal efficiency.
As other have said in this thread, it may be more feasible to start with a particle accelerator and scale the other direction. I'd expect shielding against super-low-mass bullets might start looking a lot like shielding for resisting pulsed lasers.
It's supposed to enter combat 100 km outside laser range, boost to a high-velocity intercept, and blast out the 9 submunitions just before it crosses into laser range. The submunitions can carry more armor and have low thrust engines for better terminal homing. Counting the 1 km/s kick from the blast launcher itself, it's effectively a 2.5-stage missile.
Everything works great, up until the "blast out the submuntions" part. If they are launched under automatic control when the target ship comes within range, they immediately explode, along with the parent missiles:
But if I launch the submunitions manually, they come out smoothly:
I was able to pause after the submunitions start launching but before the explosion, but I didn't see anything amiss. Setting the submunitions to No Order did not avert the catastrophe.
Does anyone know what's going on here? Is this a bug? qswitched ?
My understanding is that IRL it's very difficult to get densification ratios better than 1/3 or so (source, ctrl-f "achievable factors range", see also, ctrl-f "extreme compression").
Mass and volume-minimized bombs take advantage of low-pressure compression mechanisms like squashing subcritical geometries (hollow, oblong, etc.) into supercritical spheres and maybe that convenient plutonium phase transition. That minimizes the amount of explosive required and the size of the lens system, but gives poor efficiency and requires a lot of fissile material per warhead.
Our ability to make ridiculously high compression ratio bombs is somewhat counteracted by the much greater critical masses (60 kg for Pu-239 in CoaDE, 10 kg IRL). It actually helps for high-yield bombs, since you can pack a lot more fissiles in before encountering criticality problems, but I've found the combat effectiveness of high-yield bombs to be very underwhelming. Several low-yield devices detonated together does more damage and is far cheaper. It also seems seems like the explosive is used as reaction mass for the bomb, so a 50 kt bomb does more damage than a 1.35 Mt bomb, at less than half the mass and way lower cost.
Hmm. Google suggests that iGPU corresponds to some kind of mobile Pentium or Celeron. Is that correct? Perhaps a "Braswell" microarchitecture CPU? I'm on Haswell desktop.
It sounds like Mint isn't using the Xorg version for its package version. The actual Xorg version number should be near the beginning of /var/log/Xorg.0.log
I'm on Fedora, with X11 1.18.4, but I'm not actually using the video-intel DDX driver. I'm using the modesetting DDX. I didn't switch to make CoaDE work, and it's been over a year so I don't remember exactly why I switched. However, you might try it.
In order to see what drivers Xorg is loading, you can run "grep -i loadmodule /var/log/Xorg.0.log". On my machine, with the modesetting driver, the output looks like this:
[ 29.267] (II) LoadModule: "glx" [ 29.297] (II) LoadModule: "modesetting" [ 29.312] (II) LoadModule: "glamoregl" [ 29.560] (II) LoadModule: "fb" [ 29.957] (II) LoadModule: "libinput" [1052474.731] (II) UnloadModule: "libinput" [1075803.657] (II) UnloadModule: "libinput" [1080019.769] (II) UnloadModule: "libinput"
Yours probably says something about xf86-video-intel.
Steps to switch to the modesetting driver follow. Before attempting this, make sure you're comfortable with logging in on a text console (ctrl+alt+F2) and undoing your changes, because if something goes wrong here it *will* prevent X from starting.
In order to use the modesetting driver you can create a file in /etc/X11/xorg.conf.d, with a name like 20-modesetting-driver.conf, with these contents:
If you already have a .conf fragment that specifies the xf86-video-intel driver, say because you were giving it configuration options, you'll need to disable it, by renaming the file so it doesn't end in .conf, or moving it into another directory. If you have a single-file xorg.conf that configures the xf86-video-intel driver, you'll need to comment that part out.
Once you've done that, restart X. Easiest way is to restart the whole machine. If it doesn't come back up with a GUI, log in on the text console and undo the changes. If it does, run that grep command again. Your Xorg.0.log should no longer mention xf86-video-intel, and the output should look something like mine.
I'm not especially confident that this will fix your problem, but it might.
Maybe the fatal error is the one about "intel_do_flush_locked failed"? I'm finding some references to programs crashing with that error. What's your GPU/distro/X version/driver version?
johndh Did you install vcrun2013 as directed in the OP? I get the openal error too, but the game still works. I think I remember having to install vcrun2013 to get past a similar crash.
Stock KSP is okay, but once you throw in Ferram Aerospace, Procedural Parts/Wings, KOS, and maybe Infernal Robotics, it becomes an amazing experimental flight simulator. There's also the whole Realism Overhaul suite of mods.
Unfortunately, I've kind of drifted away from it ever since my graphics card gave up the ghost. It's considerably less fun at 25 FPS on the iGPU.
5. Do we set limits on material compatibility? Fluorine?
8. Should things that would generally be unpleasant to the crew be allowed? Reactors 1 degree from meltdown, reactors blasting radiation everywhere except for the (temporary) shielding of 1 cm of lithium-6, paper thin crew capsule walls? Personally, I think this is not completely unrealistic, in a total war / Firefly reaper situation. Though it would be nice to know which fleets are running on the edge and which aren't.
I agree with this! And, trying the first time to make a nuclear reactor last night, how do you know how far it is from meltdown?
Set radiator temperature safety_factor kelvins over whatever you actually want. Design reactor. Reduce radiator temperature.
I didn't start out designing something to compete with the Hellfire, but the mass came very close, and it follows a similar "very high volume of fire" philosophy (though with far lighter bullets). Meet the PD-2 point defense drone:
Less than half the cost of the hellfire, and about the same mass. Details:
Engines, radiators, and propellant tanks are redundant. The reactor, alas, is not. The PD-2 is intended to take advantage of the new independent gun targeting. Because guns are only assigned to separate targets within each ship, it's best to have a lot of guns on a small number of ships.
The starting point for the design was this railgun. It has large enough muzzle velocity and low enough dispersion to be useful against missiles without ignore range, and the low rate-of-fire allows many guns to be powered from a reasonable reactor (and also keeps my computer from dying).
Kinetic point defense is actually good now. This salvo started as 100 missiles and was launched in slightly less than 2.5 seconds.
Counterlasers can be spoofed by placing fake turrets on your ship as fodder, AI doesn't prioritize lasers first so it will waste time burning down fodder turrets.
Is that new? I though the AI prioritized active lasers. I still see "Active Lasers" at the top of the list in Weapons Doctrine/Target Prioirities.
Not necessarily. There's a proof floating around somewhere that the mass ratio that maximizes kinetic energy for a given wet mass is e^2. That's approximately 7.389, and it corresponds to Δv equal to twice your engine's exhaust velocity. Though starting from the specified 5 km/s Δv in this thread, more fuel is going to be the answer for most reasonable engines.
KKVs kind of suck though, in my experience. The first one makes a small hole through the center of the radiators, and every subsequent missile goes through the same hole. They probably are a good answer to pointy ships that fight nose-on, though, since a KKV has a good chance of coring the ship if it hits from that aspect.
Mass balloons rather fast when you use a lower Isp engine to get closer to that 7.389 mass ratio with a given payload mass (flak bombs used instead of KKV penetrator to avoid making new modules):
That face-melting terminal acceleration almost makes the absurd wet mass worth it...
Er, not exactly. The e^2 result is for fixed wet mass and Isp. Total Δv is a free parameter. If instead you've fixed Δv, (5 km/s in this case), then kinetic energy is maximized by minimizing mass ratio. That means choosing a high-Isp engine, within the constraint of reasonable acceleration.
In general, you can always improve the performance of a rocket by increasing exhaust velocity, provided that doing so doesn't require violating some other constraint (initial acceleration, cost, reliability, etc.). The only possible exception is that, if you have multiple types of engines on board that have separate propellant tanks, it's best to use the low-Isp engines first. They were able to stretch the payload capacity of the space shuttle a little that way, by burning the OMS engines during ascent.
If the ship is designed with the fact that missiles all go for the geometric center of the radiators in mind, the only thing under there is going to be propellant tanks, which will be multiply redundant. Venting some of the propellant won't take the ship out of the fight, and it probably won't even keep it from limping home on MPD.