|
Post by AtomHeartDragon on Feb 11, 2018 10:58:06 GMT
That doesn't seem to be a bug, just a minor data presentation issue - if you look at celestial bodies you'll notice that it also happens for Venus. Both rotate retrograde, so the only issue is in how it's presented to the user - it probably shouldn't be expressed in seconds for negative values either.
My solution would be to stick an abs() in there just before the data is converted to human readable units of time for display - should sweep both the negative and unit issue.
|
|
|
Post by AtomHeartDragon on Feb 11, 2018 10:37:45 GMT
pause, launch, back to orbital view; blast launchers do not have this problem IIRC I had a problem with core 15x Striker tube when it turned my ship into glowing slag (as in "nukes going off" rather than just launcher exploding) when used under fire. Anyway, the problem is mostly when the AI tries to use launchers in combat, not player, although I wouldn't object to being able to just use modules and experiment with them - this is the whole point of this game, is it not? Plus orbital missile spam is kind of boring.
|
|
|
Post by AtomHeartDragon on Feb 11, 2018 10:29:52 GMT
Ok, it seems that the only difference that counts is a single VS multiple tube launcher - single tubes work just fine, multitubes either refuse to fire or destroy themselves and their payloads (despite working just fine when fired manually). Multiple launchers (single or multi) seem to collide their projectiles (as expected), while my only attempt at multiple launchers launching different projectiles at the same time has crashed the game on leaving the launch bay. Also, given that ship with sideways electrical launchers starts performing wild gyrations when broadsiding (presumably trying to aim launch bays at the target despite it not being how they are supposed to work), the proposed setup (spinal gun plus dropped froward launchers) doesn't seem practical so far.
|
|
|
Post by AtomHeartDragon on Feb 11, 2018 10:20:43 GMT
I question the wisdom of armouring a spaceship with something that, on one hand, melts in 505K and, on the other, autocatalytically dusts itself when cooled to temperatures not far from the freezing point of water (depending on impurities and how bad do you want it to get how fast). No, I wouldn't build crew modules out of potassium either. I don't know if the game models the fact that melted armor tends to disperse slightly more safely than a more temperature resistant material, but the added hardness of tin and general extra density tends to make it work out decently well for a whipple shield compared to other alternatives, like Aluminium. We don't have to deal with the armor freezing to a point where it falls apart either, so I think it works out great if you ignore the fact that lasers will ruin everything, but that's the case for almost all whipple shielding. It still has just some 200 degrees stability range. Go into battle around Mercury and it will likely have melted off before even seeing enemy lasers, go to outer planets and it will have dusted itself off the hull before you get there. Aluminium doesn't do this kinds of shenanigans and is nice, cheap, common and has RL precedents. Does anyone know how does magnesium fare, BTW? Also, has anyone tested most effective thicknesses and spacings (either vacuum or vacuum++) for different materials?
|
|
|
Post by AtomHeartDragon on Feb 10, 2018 16:50:52 GMT
They are cheap and light, but in my opinion Tin is slightly more viable. It's less likely to bend while you're outside putting the new sheet into place, though you might need to deal with the implication of it being slightly more "spally". I question the wisdom of armouring a spaceship with something that, on one hand, melts in 505K and, on the other, autocatalytically dusts itself when cooled to temperatures not far from the freezing point of water (depending on impurities and how bad do you want it to get how fast). No, I wouldn't build crew modules out of potassium either.
|
|
|
Post by AtomHeartDragon on Feb 10, 2018 16:30:31 GMT
The cost of non-cylindrical ships should in fact be less (in most cases) regardless of armour manufacture and repair techniques. The thing about spaceships is that they aren't just hulls wrapped around given volumes. They are hulls wrapped around discrete components. If you have, for example, a hex cluster of 7 fuel remass tanks, then there is a more economic way of armouring it than making a cylinder around it and calling it a day - making a hexagonal prism with rounded corners so that flats are tangential to the individual tanks and corners reflect curvature of the tanks themselves. True, but the game currently doesn't support rounded polygonal shapes. But it would be interesting (though I'd probably stick to cilinders). For hex cluster of 7 cylindrical components circumferences are respectively 18.93 radii of individual components (optimal hexagon), 18.84 radii (circle) and 18.28 radii (hex with rounded corners). Even with no rounded corners the kind of hexagon like in our example would (assuming negligible thickness of armour) only require less than 100.5% armour required by cylinder (so only slightly less efficiency), OTOH requiring just over 95% of effort required by cylinder to completely dodge projectile (in optimal direction - flat to flat, and you should always be able to afford that given that you dodge away from stuff, not in specific directions) and presenting better slope for hits near centerline when aligned ridge-on. With rounded corners it requires slightly over 97% armour (making it more efficient) while retaining dodge advantage. Given that the game already generates exact armour mesh for ships, an algorithm trying to sort of stretchwrap the stack and surrounding modules isntead of assuming circular or predefined polygonal crossection would be worth it. As a bonus it would yield more interesting looking ships.
|
|
|
Post by AtomHeartDragon on Feb 10, 2018 12:31:33 GMT
The cost of non-cylindrical ships should in fact be less (in most cases) regardless of armour manufacture and repair techniques.
The thing about spaceships is that they aren't just hulls wrapped around given volumes. They are hulls wrapped around discrete components.
If you have, for example, a hex cluster of 7 fuel remass tanks, then there is a more economic way of armouring it than making a cylinder around it and calling it a day - making a hexagonal prism with rounded corners so that flats are tangential to the individual tanks and corners reflect curvature of the tanks themselves.
|
|
|
Post by AtomHeartDragon on Feb 10, 2018 6:57:24 GMT
I started experimenting with mating spinal mounted railgun with two stage launchers - sideways launcher dropping a MRLS consisting of a remote and blast tube(s), with optional RCS plus aim assist gun (firing detonating blanks to not clutter launch trajectory with bullets) combo. This seems like it could be effective as spinal railguns can easily be made long ranged, launchers can be assigned arbitrary engagement range, blast launchers can easily (if mass inefficiently) reach decent velocities greatly increasing guided munitions' ranges and sideways->forward two stage launch should mesh perfectly with spinal mount and allow mounting even on skiff sized tinyships (unlike, say, missile turrets). I've also had some preliminary successes with similar two stage launchers (albeit single tubed and with bigger both launch velocities) on my test rig. Unfortunately, while the launchers I am testing currently seem to perform admirably while manually controlled (they can quite reliably release their entire payload on desired trajectory without going into a spin, even without RCS), they don't seem to launch on their own. Engagement range is set to beyond current range and target types are checked. What could be the problem? The only differences between my test setup and current one is that the launchers tend to lag behind manoeuvring ships (while my test platform was pretty much sitting still and launching since it doesn't have any long range fixed armaments - it's mainly intended for testing payload guns and some drones) and may in fact cause some mild jinking when manually forced to launch, so maybe they consider allies to be in their line of fire? What workarounds could I use? I am thinking of complementing the remote with the right fuse and dumbfire rockets to help them clear the ship OR putting RCS on launching ship to help it aim its spinal mount without accelerating. Edit:Tactical geometry would support "allies in the line of fire" hypothesis - at first I thought it would only delay firing, but with MRLS moving away at constant, slow rate and launching ship constantly accelerating due to its use of gimballed thrusters that can't help, but add some forward component to velocity with each manoeuvre, the geometry can only deteriorate until the fleets start passing each other by. So it seems that dumbfire boosters it'll be, unless I can reduce the forward acceleration enough (using RCS) for the MRLS to clear the launching ship and fire before it jinks in its way (without breaking fine manoeuvrability needed to fire spinal railguns) - with typical sideways launching speeds it seems hopeless, though. Either way will cost me - either engine and fuel weight added to each MRLS or having to cut crew req uirements enough to squeeze in some more reactorfolk.
|
|
|
Post by AtomHeartDragon on Feb 9, 2018 18:01:36 GMT
The same radiation, with the same spectrum, at the same intensity and incidence angle causes the same armour to ablate at wildly different rates depending on how many lasers it is emitted from - sounds like a bug to me.
A possible solution would be to account for effects of all sources of laser irradiation before performing ablation calculations for given tick. I don't know the details of the code and algorithms, but the game might already be doing something roughly similar where accounting for different sources of gravity?
|
|
|
Post by AtomHeartDragon on Feb 7, 2018 20:55:04 GMT
This one is bad. Siloship in Vesta Overkill tends to spectacularly blow itself apart more often than not.
|
|
|
Post by AtomHeartDragon on Feb 7, 2018 20:49:25 GMT
Between ships (half covertly) missing crucial modules like radiators, engines and powerplants, core stuff happily mixing with workshop items in common namespace, like one huge, deeply dysfunctional family (whose family tree contains cycles), no version viability tracking and component designs happily overwriting each other in one big free-for-all, so that what you put into your missile one day as a long, skinny 10kg fluorine tank, will return to haunt you as a stubby, bloated one the next day, happily propagating across your dependency tree and adorning your most cherished designs with red exclamation marks while turning them into bloated monstrosities, the Workshop is pretty much unusable in its current state. What is really needed: - Tracking each single item, down to individual modules by workshop ID and uniquely identifying it by one
- Keeping track of the game version the ship or module was built with
- Keeping track of external dependencies and enforcing them
- Allowing quick deletion from within the game
- Separation of core stuff from workshop stuff just like the core stuff is already separated from user designs
Any workarounds and user side remedies I could apply are welcome as well.
|
|