|
Post by AtomHeartDragon on Feb 16, 2018 11:36:02 GMT
I do love GOG and what they're trying to do, but wouldn't the GOG client itself eventually do the same thing Steam has already done? Given that their main selling point is letting you "own" your games - so no DRM, client stays strictly optional, you can revert to any prior version if you want, etc. - unlikely. Then why do games still sell when cracked or sold without DRM to begin with? If compensating creators for their good work doesn't appeal to you, then the best reason to buy games is ensuring more such games will be made in the future (either by the same people, copycats wanting to replicate the success, or new devs inspired by the original). All DRM accomplishes is treating paying customers as thieves by default, creating countless technical and security issues, and helping really good games get lost in time. Conversely lack of DRM avoids screwing anyone over, helps keep programming simple, solid and less likely to break stuff or get broken and helps ensure game's longevity. Let's just say that if CoADE was on GOG I would have gotten it about a year earlier, as I never personally buy stuff through Steam and only occasionally buy games on Steam if they are available in boxed version.
|
|
|
Post by AtomHeartDragon on Feb 16, 2018 11:05:01 GMT
Space Engine looks absolutely spectacular and allows toggling procedurally generated stuff with decent degree of granularity, so I can't recommend it enough for space mapping needs. It does have some screw ups in ported catalogue data, but they are relatively far in between.
E:D is a bit of a sore spot for me, ever since the announcement of it being always online and dropping strictly Newtonian flight physics for some nebulous thing they call "fun". Now, if I shared this definition of "fun", I wouldn't be posting on this forum, would I?
OTOH now ancient sequels to the original Elite - Frontier: Elite 2 and Frontier: First Encounters were really impressive even over a decade afterwards (fully Newtonian albeit approximated to two bodies and without much respect for Tsiolkovsky, full scale planetary systems, curvilinear 3D vector graphics with extreme level of detail, sourced coloured lighting and unlimited rendering distance within system, procedurally generated galaxy, could run on 286/Amiga/Atari and fit on a single floppy).
|
|
|
Post by AtomHeartDragon on Feb 16, 2018 10:10:29 GMT
I really liked how you keep staying to standard strength level without going overboard in stuff. Well, I'm lazy, so I try to do the best with stuff I got or tweak it if I have some particular itch to scratch. I also think that excessive optimization exposes dubiously physical corner cases or would hit engineering issues IRL, plus it kind of misses the point - I think everyone agrees that an Empire States Building sized railgun supplied with adequate power supply would be freaking awesome, but so what? What does it tell us? Well, it did tell us that sandcasters are good, but that's a bit of a case of wanting your railgun to be a laser. OTOH how to build and lay out your vessel so it works is actually interesting because it has to solve more problems and weigh more trade-offs than just flinging stuff as fast as possible and has more interesting solution space (and you can get some spiffy looking ships with only minimal functionality concessions - often good form follows function). I'm not disparaging module design, especially given that many here have skills in it I can only wish I had, but I think it's kind of tangential to the main point of this game. Especially given that originally it got included because different module types weren't easily characterized and it wasn't obvious, for example, what a good and reasonable space railgun would look like, so the best way to parametrize was to dump whole numerical simulation on the issue and let players sort it out (which is awesome in its own right and certainly makes an unique selling point for the game - it certainly did contribute to me buying it), but it's really just the badge of legitimacy and a way to extend the available arsenal, the real fun starts once you have everything you need and can start building and engineering around particular problems. Since so far we can't aim blast launchers, you either need to sync it with something that will get aimed (conventional gun, most of the time as it has similar performance characteristics and can be made small and not energy demanding) - sync exit velocity and put engagement range slightly below gun's expected firing range, put it on a dumb payload with some assumptions regarding how it hits the target (which may vary depending on the intercept) and fire it point-blank, launch guided projectiles in the approximate direction (for bigger ships you don't want to face enemy with 'splody array of blast tubes you can use side launched blast tube launch containers and nose forward orientation) or just scatter projectiles around in an effective pattern (there are some examples way beyond my league in the screenshot thread). Actually only slightly more than RTGs need. On Thunderbolt there is one extra aluminium panel over immediate cooling needs, and that's for Hellfire level of power generation (my Stinger replacement duplicated the original's powerplant). There is also just enough silicon carbide ones to cool at least one RTG if aluminium ones get flashed off, which seems to make sense to me given that Hellfire seems to be meant to be a tankier (armour thickness, radiator size, material and double redundancy), shootier (4x firepower) alternative to Stinger. Well, in this vein I also made something tankier and shootier than my Stinger replacements. On Firestorm there is one more than I would be able to get away with if I used the more effective pattern I used on Dragonclaw, but I decided to not tweak it further. Since I use vanilla power generation and vanilla RTGs run rather cool, and since I had to replace Hellfire's costly RTG with much cheaper, but also much cooler bunch of 3.5kW ones used on Stinger to meet the cost requirement, the radiator demands boomed. Yes, I could use less numerous radiators if I made custom ones, but since the crew requirements aren't sanely calculated for drones and radiators should probably scale crew requirements with total area first and individual panel mass * the number of hinges second, why bother? This way it at least looks like something made from standardized components and reasonably meant to replace commonplace military hardware. What IS really wasteful on this drone is the RCS, which got only added to satisfy turnabout time demands without rolling an entirely new engine. Without it it would be a bit more sluggish, but wouldn't eat delta v nearly half as fast - as it is losing all the delta v (and not from tank punctures either) is what tends to get it killed - even when soloing a gunship.
|
|
|
Post by AtomHeartDragon on Feb 15, 2018 22:16:27 GMT
what's wrong with Alkali or Alkaline? theirs nothing to react with in space They have crap mechanical properties, crap thermal properties and they only have nothing to react with if you put them on the outside of the hull - which is actually fine by me if you just want to paint your ships with weird stuff - I'm not judging. Other than that? Radiators run coolant inside and it's already somewhat cheesy with sane and structurally materials that you can have kilometres of them without it limiting your manoeuvrability. Making them of something you can bend by looking at it hard enough is just adding insult to injury. Habitats have air and people moving inside. Injectors inject fluids, under pressure and often violently reactive, into infernos commonly known as rocket engines. Sure, they may be coated, but none of those applications is suitable for something that scratches and bends easily and then catches fire (because coating broke when it bent or scratches). Yay for habitat you could put your hand through if you are not careful and then, before it vents to space it catches reactive metal fire. I'm not even going to think about trying to put, say, fluorine into stuff because this thing is mental enough in contact with normal materials, and getting a scratch in your passivated steel or something tank housing it can still give you the same kind fun alkali metals try to give you with nearly everything.. Don't get me wrong, I have nothing against first and second group elements. They are exemplary metals. Some of the best meals I ate used sodium chloride! You can make nukes with lithium, sodium is great for putting into reactors and if that's not enough for you, you can always use NaK (which isn't in game, figures). But they shouldn't even be modelled as structural materials because you just can't build sane stuff out of them. Hell, *tin* is already not a sane spaceship material, and it doesn't do any of the scary stuff alkali metals do. What's next, metastable metallic hydrogen for structural applications? I know, let's make armour out of it - you won't get any spalling, ever.
|
|
|
Post by AtomHeartDragon on Feb 15, 2018 15:32:14 GMT
In the vein of my recent Dragonclaw and Firestorm I present Thunderbolt - heavy assault USCV (drone): It comes equipped with modified 33mm cannons also used on other two drones, as well as modified 60mm cannons typically used as warship CIWS further altered for drone use. Additionally, it mounts blast launched payloads used by the other two drones, except in greater numbers. All weapons have been tuned to share ballistic characteristics allowing any combination of them to be fired without reorienting the craft. To facilitate cost reduction main armour layer has been replaced with denser, but much cheaper amorphous carbon, expensive RTG used on hellfire has been swapped for five much cheaper RTGs used on Stingers, which, due to their widespread use, should ease the logistics considerably, although it came at a cost of having to mount much larger radiator surface - in the form of aluminium radiators also used on Stingers and the other two drones. Another change that should ease the logistics has been move from Hellfire's MethLOx based propulsion stack, to modified Stinger's Methane-Fluorine propulsion. To satisfy listed requirements and provide measure of redundancy four such engines are used, alongside an array of much smaller fixed vernier motors - together they allow craft to surpass Hellfire's manoeuvrability as well as giving it ability to roll which is rare in such small craft (granted, given spinal armament and limited delta-v rolling is only of situational utility). Because of craft's relatively large size and cost it's design feature some nods towards survivability, in spite of it being a semi-disposable drone. A number of Hellfire style SiC radiators have been provided in addition to new aluminium one to grant craft limited flash resistance - the area provided can effectively cool a single RTG and allow opportunity to continue firing single mounted weapon of choice. In addition four main engines (alone providing considerable measure of redundancy) for which fuel has been spread into multiple tanks arranged into mixed symmetry groups to minimize delta-v loss in the event of penetration. Control system have been made doubly redundant while ammo and power generation has been spread apart and moved to areas where penetration is statistically less likely. Craft's front features ballistic cap backed by generous 5.7cm of nitrile rubber. Armament also provides a measure of redundancy with four cannons of each type (on board powerplant provides enough power to fire any five weapons at the same time). The result is a relatively modest (with the exception of cost) improvement over Hellfire's characteristics that can however do one thing Hellfire cannot: Quite reliably solo a Gunship. Yes, this drone too conforms to my self imposed challenge of trying to do things with vanilla power generation if possible. As for the radiators, my menu is cluttered enough as it is.
|
|
|
Post by AtomHeartDragon on Feb 15, 2018 6:53:57 GMT
Asymmetry allows the enemy to pincer you between two attacks That depends on the asymmetry. For typical dedicated broadsiders - absolutely, but it's also the case for dedicated nose forward ships, especially those relying on extremely directional armour or weapon scheme. For asymmetry merely serving to break-up exploitable patterns, nah. Manoeuvrability is presumably also going to be a huge game changer against pincer attacks. In any case, we can't test it in game as it doesn't allow multiple intercepts.
|
|
|
Post by AtomHeartDragon on Feb 14, 2018 10:05:10 GMT
Apart from asymmetry allowing task-specific sides on a ship (dedicated broadsiders are a special case of that), symmetry is also a gift to your enemy - with a symmetrically laid out ship, when a stream of hypervelocity sand carves a deep gash in your whipple shield and threatens your turret, performing a barbecue roll simply exposes another turret in the ring, allowing the enemy to quickly sandblast the entire ring without retargetting (and retargetting tends to take time before retargetted projectiles start arriving). With lower symmetries, asymmetrical layouts or ring symmetry not matching hull symmetry rotating component out of the way does just that.
Asymmetrical layouts are also nice for ships that are generally nose on, but may occasionally broadside.
As for mass distribution management - that's what gimbals are for.
|
|
|
Post by AtomHeartDragon on Feb 14, 2018 9:43:39 GMT
Huh, firing folded radiator projectile. ...I think i can get some ideas out of that because that actually interesting. Overall, quite a good design without going too ridiculous in OPness. Not my own idea sadly. I took it from a KKV using small, dummy RTG and four long (about twice as long as mine), thin osmium radiators as main means of dealing damage. My own work originally started as a quest to find a way to reliably inject nukes into ships - a heavy projectile dropping a nuke behind just before impact. Since I couldn't get it to work (blast launch, no matter how gentle, tended to throw the nuke's trajectory off enough to not let it follow) I started experimenting with compound nuke/rod/flak projectiles that fired thin rods into the target, dropped nuke/flak behind and detonated flak/nuke in projectile's body (the effect is quite similar no matter which you drop behind). This turned out to be surprisingly effective - can't determine if it's because of cycles of flashing, penetration and flak blasting making short work of armour, nukes shining down the holes, or even rare lucky nuke actually detonating inside, but it already tended to leave empty, incandescent hulls with some punctures and whipples flashed off. Folded radiator projectile was added later to maximize the area of hull damage after attempting to penetrate it with rods and really made the added mass worth it. Now it leaves incandescent, de-whippled, empty hulls that are also cut to ribbons - for when you absolutely, positively need something dead. Afterwards it turned out that just the folded rod itself also makes for an excellent, cannon- or blast-launched munition and can be more useful when you want a lighter solution or don't actually want to kill everyone and destroy everything on the target ship. The drone itself is just a better Stinger (thinner armour but better everything and handles lasing somewhat more gracefully) with some extra blast launcher(s) bolted on the front - I try to stick to vanilla power generation because it's more fun than throwing gigawatts at the problem until it vaporizes, plus some aspects of reactor mechanics are somewhat sketchy (subcritical fuel without reflector actually doing anything?). I once put two reactors (0.5 or 1GW each, I don't remember) I found on the workshop that happened to match both length and required radiator area in place of my five 60MW vanilla ones on my heaviest ship but it quickly lost sense to me - maybe if I wanted to terraform Ganymede I could put a bunch of such ships in orbit around it to melt the ice with radiated heat? Also, thanks. BTW: What is a good standardized measuring stick to pit your ships against? I'm using gunship, but obviously you can do better than that - except without making it clear to others what are you talking about. I also suck at armour.
|
|
|
Post by AtomHeartDragon on Feb 13, 2018 13:23:38 GMT
Payload details for the above (works really well when fired high ROF out of conventional cannon as well):
|
|
|
Post by AtomHeartDragon on Feb 13, 2018 13:14:51 GMT
I hereby present Firestorm and Dragonclaw: Both are similar to Stinger, with substantial part commonality, similar dimensions, capability to reuse existing fuel supply chain and ability to handle all the mission profiles available to Stingers, but around twice the available cannon firepower and additional blast launched payload weapon systems (tuned to match cannons' characteristics) for heavy, decapitating anti-capital strikes. Firestorm's payload is a complex, multi-part weapon combining a number of different kinetic weapons and a miniature nuclear charge and is best suited for completely obliterating resilient targets (unless the target is significantly better armoured than stock gunship there is really no point targetting subsystems because this increases the odds of some portion of enemy vessel remaining serviceable afterwards). Dragonclaw uses large number of single function kinetic payloads and is better suited for precise surgical strikes (like cutting off offending vessel aft section housing engines and power generation - at least I think that's what "surgery" means) or when you don't want to spam clusters of nukes (for example for political reasons). Basically, two variants consisting of Stinger's original propulsion stack, duplicated Stinger powerplant, doubly redundant remote control and two slightly modified Stinger's cannons (improved accuracy, exit velocity, heavier projectile and separate ammo bin), with lightened, somewhat showoff shell of armour stuck on top of it. It's somewhat lighter, cheaper, shootier, has better delta v, is less liable to be sent into a deathspin when its gun gets lasered off, less liable to be cored and... a flight of five should be fully capable of penetrating stock Gunship's laser screen, closing into firing range (no need to ignore range and you don't want to waste payloads) and literally cutting it into ribbons (single drone's payload should be sufficient for that, but a single drone is likely to get lasered to death before getting close), which is something you can't do with similar number of Stingers. Most of the flight are likely to be reusable afterwards too, even though some only as impromptu KKVs (at least without extensive repairs). Disclosure:This started as a simple excuse to stick my payload based (originally cannon fired) weapon system on a Stinger and evolved into improving survivability a bit by removing obvious points of failure - my heart isn't really into drones (presumably because many are chemically propelled). I also suck at armour design, and admit to have gone polygonal for purely cosmetic reasons here (usually I at least have the legitimate excuse of it being needed for roll thrusters), although it might make shooting the nozzle off a bit trickier. Credit also goes to the authors of 94.9t Mini-Nuke (Nitrogylcerin-Nitrocellulose) - although I *can* easily adapt to something less compact, and Space Sword KKDRM ( samchiu2000) - which provided working principle behind primary kinetic weapon used by Dragonclaw drone and used as late, but very worthwhile addition to Dragon's Breath payload used by Firestorm. Disclaimer:Names, tracer colours and armour configurations presented are liable to change without prior notice.
|
|
|
Post by AtomHeartDragon on Feb 13, 2018 11:42:26 GMT
I think that many challenges would be quite interesting with added limitations of only stock power generation (stock only NTRs would be a bit of an overkill, because there are too few to fill all the interesting niches) and no insane material use (like any alkali or alkaline earth metals save for magnesium, beryllium and possibly lithium for anything remotely structural).
Constraining available resources (power and power density in this example) does wonders for creativity.
|
|
|
Post by AtomHeartDragon on Feb 13, 2018 9:03:34 GMT
I can't get my guns to preferentially target explosive modules on the Cutter and Siloship which would allow taking them out of action quickly and not be bothered by lasers and streams of 60mm rounds.
Instead they seem to focus on the fleet carrier (which is the biggest target in enemy fleet) and any drones it launches.
|
|
|
Post by AtomHeartDragon on Feb 13, 2018 8:57:18 GMT
We don't have those, sadly, so I'm trying to work around. Indeed. What does not make sense is that ship rotates to make the launcher face enemy which means: - Missile launched is no longer nose forward, making it easier to destroy and take extra time and delta v to rotate towards the target
- Ship is no longer nose forward making it more susceptible to enemy fire and possibly throwing off any nose mounted weapons.
- The launch bay, possibly backed by a missile can, possibly even full of monoprop is now in full view of the enemy who can take potshots at it
|
|
|
Post by AtomHeartDragon on Feb 11, 2018 14:52:39 GMT
Tanks try to be cylinders. Narrow cylinders have proportionally smaller flat surfaces (the end caps) which are the part of the cylinder which needs to be the thickest (though thickness is probably homogeneous). Having purposefully bulbous end caps (domes) would lighten tanks, as the end caps wouldn't need to be so thick. Or allowing a wire/wires connecting the end caps to each other would similarly help. I am still not seeing it. In-game tanks are pill shaped and from geometry it would be obvious that the closer the tank to a sphere the more efficient it is at storing its contents (barring further considerations such as wanting to then pack those tanks in a big armoured sodacan, but those don't affect tank's own mass ratio), so the closer to the spherical, the better mass ration. Unless it's something to do with slosh baffles and water hammers, elongated=effective is plain wrong. Either way warrants some detailed explanations and investigation of how things are calculated in game and why.
|
|
|
Post by AtomHeartDragon on Feb 11, 2018 12:24:44 GMT
As a workaround for the lack of side mounted forward facing blast launchers I was trying to devise a two stage system where a simple munition consisting of blast launcher, remote and, optionally either a dumbfire motor (with fuse) to avoid being overtaken by the launching ship or RCS cluster + aim-assist gun (with ballistics tuned to the launcher and self-destructing projectiles) to self-stabilize and actually aim the launchers, all wrapped in a mostly cosmetic hull would be electrically launched at the target already within range of blast launchers (to ensure immediate launch). This setup seems to work reasonably well for projectiles containing a single 1x launcher, but causes problems otherwise: - n x m launchers either don't fire on their own or destroy themselves and missiles immediately upon firing (they do seem to work fine when manually triggered, though)
- multiple identical launchers cause immediate collisions between projectiles (not unexpected, but it would still be nice to have some safeguards allowing for clustering launchers together)
- variety pack of several different launchers (all offset from the axis) - crash immediately after electrical launch:
1x
Assertion at z:\documents\code\utilities\utilities\core\Darray.h(53): Size > 0 Error: EXCEPTION_BREAKPOINT 0 0x750f322c DebugBreak Line Info Error 487 1 0x003cc738 <lambda_8a366f813bf63f6f50382e32e08dbabe>::operator() z:\documents\code\cde\cde\logistic\crafts\craftblueprints.cpp(3014) 2 0x003cc414 CraftBlueprint::Instantiate z:\documents\code\cde\cde\logistic\crafts\craftblueprints.cpp(3009) 3 0x00636ebf SpacecraftComponent::SpacecraftComponent z:\documents\code\cde\cde\tactical\components\spacecraft.cpp(61) 4 0x00618a7a Body::BuildBody z:\documents\code\cde\cde\tactical\body.cpp(26) 5 0x004ce906 LauncherSubCompartment::LaunchOnce z:\documents\code\cde\cde\logistic\modules\weaponmodules\launchersubcompartment.cpp(72) 6 0x004ce058 LauncherSubCompartment::RunActions z:\documents\code\cde\cde\logistic\modules\weaponmodules\launchersubcompartment.cpp(23) 7 0x0049d676 BlastLauncherCompartment::RunActions z:\documents\code\cde\cde\logistic\modules\weaponmodules\blastlaunchermodules.cpp(409) 8 0x006381d4 SpacecraftComponent::Tick z:\documents\code\cde\cde\tactical\components\spacecraft.cpp(134) 9 0x0061cd37 Body::Tick z:\documents\code\cde\cde\tactical\body.cpp(302) 10 0x0035aad2 util::Darray<util::SharedPtr<UIWidget> >::Add z:\documents\code\utilities\utilities\core\darray.inl(282) 11 0x600000b9 Function Error 126 Line Info Error 126
2x Assertion at z:\documents\code\utilities\utilities\core\Darray.h(53): Size > 0 Error: EXCEPTION_BREAKPOINT 0 0x750f322c DebugBreak Line Info Error 487 1 0x012bc738 <lambda_8a366f813bf63f6f50382e32e08dbabe>::operator() z:\documents\code\cde\cde\logistic\crafts\craftblueprints.cpp(3014) 2 0x012bc414 CraftBlueprint::Instantiate z:\documents\code\cde\cde\logistic\crafts\craftblueprints.cpp(3009) 3 0x01526ebf SpacecraftComponent::SpacecraftComponent z:\documents\code\cde\cde\tactical\components\spacecraft.cpp(61) 4 0x01508a7a Body::BuildBody z:\documents\code\cde\cde\tactical\body.cpp(26) 5 0x013be906 LauncherSubCompartment::LaunchOnce z:\documents\code\cde\cde\logistic\modules\weaponmodules\launchersubcompartment.cpp(72) 6 0x013be058 LauncherSubCompartment::RunActions z:\documents\code\cde\cde\logistic\modules\weaponmodules\launchersubcompartment.cpp(23) 7 0x0138d676 BlastLauncherCompartment::RunActions z:\documents\code\cde\cde\logistic\modules\weaponmodules\blastlaunchermodules.cpp(409) 8 0x015281d4 SpacecraftComponent::Tick z:\documents\code\cde\cde\tactical\components\spacecraft.cpp(134) 9 0x0150cd37 Body::Tick z:\documents\code\cde\cde\tactical\body.cpp(302) 10 0x0124aad2 util::Darray<util::SharedPtr<UIWidget> >::Add z:\documents\code\utilities\utilities\core\darray.inl(282) 11 0x015e2cba ActorHandler::GetAllAliveActors z:\documents\code\engine\infrastructure\manager.cpp(156) 12 0x11111111 Function Error 126 Line Info Error 126 13 0x01563919 TacticalManager::Tick z:\documents\code\cde\cde\tactical\tacticalmanager.cpp(149) 14 0x015dc2f4 GameManager::Tick z:\documents\code\engine\infrastructure\gameplay.cpp(271) 15 0x011fc4d5 main z:\documents\code\cde\cde\common\main.cpp(83) 16 0x016adc27 __scrt_common_main_seh f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(283) 17 0x756b337a BaseThreadInitThunk Line Info Error 487 18 0x774692e2 RtlInitializeExceptionChain Line Info Error 487 19 0x774692b5 RtlInitializeExceptionChain Line Info Error 487
Interestingly, blast tubes seem to work correctly when packed onto meatier drones - I have two stinger-based bomber drones (and no launch platform for them as of yet) that in addition to forward firing cannons use blast launchers (tuned for same ballistic performance so that they can be aimed using main guns) and seem to be quite effective - a single one dropping its payload typically cuts stock gunship to ribbons.
Additionally the way the AI treat the launchers is questionable:
- Electrical sideways launchers, which are clearly intended to just drop projectiles at negligible launch velocity and have them boost under own power tend to be aimed directly at target when broadsiding.
- Blast launchers which can fire volleys of projectiles at considerable velocities (often exceeding conventional cannons) are not aimed at all.
It seems pretty clear to me that this logic should be reversed - electrical launch should be direction agnostic, while blast launch should use proper targetting solution (although blast aiming should have lower priority than gun aiming and fire blindly when overridden to allow sideways blast launches when fighting head on).
This might be a slight issue for all the cluster munition designers out there, but working around it with a tiny forward needle blast launcher with marginally better engagement range seems like a much better prospect than trying to aim every single blast tube that needs to be aimed with complex setup involving ballistically tuned aim-assist guns, ammo bins, generators, radiators and issues with guns shooting freshly launched munitions right in the nozzle.
Alternatively (and optimally) launchers could get a field telling them whether or not they need to be aimed and if they should still attempt launch when they can't.
|
|