shimmy00

A perhaps minor nitpick, but some screens there show "km" as "KM" and "m" as "M". That's actually not right either - the SI unit system standard says those symbols must always be lowercase, i.e. "km" and "m". That matters even more because the next step is "Mm" (and then "Gm" and "Tm" and so on), and "MM" could be read either either "Mm" or "mm", and those are literally and exactly a billion times different from each other. Also and technically, "M" typically stands for "molar concentration unit", though obviously that has no meaning here. This is a regression from the KSP1 UI where, except for the altimeter which showed "k" as "K", the proper SI capitalization conventions were followed. It was also a bit hard to tell that the "AP" and "PE" readings were actually in hundreds of thousands (of meters), too, as that comma looked close enough to a period to fool me and I was wondering "why the heck is the orbit so low?!" for a while there. FWIW, SI also has an answer for that: you don't use commas to separate thousands, but spaces - thin spaces, actually, so the two groups of three digits should be only slightly separated from each other and more separated from the unit symbol. Of course, "in real life" everyone sloppily ignores this, but technically, that's the correct way to write any metric measurement.

I would tint it differently, so it looks more like the pastel colors seen of a typical real-life galaxy, i.e. also more like the colors in the original game. Should be easy to mod, though, as others have pointed out Nonetheless, definitely looks more realistic insofar as the details go - the KSP1 background looks kinda cheaply airbrushed, though still far from shabby. Though of course, in its favor, we could also explain that in-universe as an abundance of the green material that forms Jool. But still, I like the KSP1 colors better I suppose.

Thanks. Okay, never heard of that before, but if it works with that, that'll be great!

Hmmm ... when they say this is to be "released to PC first", does that include Linux on PC, or is it only Microsoft that they're supporting?

ADD 2: Despite my post I made in another area about how that I was going to be leaving this forum ... well, things didn't actually quite end up working out that way and I was actually still able to do some work on these mods. If you want to try it out, you can get a GitHub of it here: https://github.com/shimmyshai00/Cochrane but as I said the artwork is still very crude and one part (the warp field generator) has no texture at all, so I'm not going to call this a "release", just something to test with. If anyone wants to contribute improved artwork, they are free to do so.

Thanks!

Hi. While I've only been here a relatively short time compared to others, I want to say there's been some important (but not bad!) life changes that mean I will not be able to play or mod Kerbal Space Program - at all - in at least the next year or so (so hopefully KSP2 will be ready then! ). I am going to be moving to a different city, starting graduate school, and most importantly, am changing to a different kind of desktop computer that is incapable of running the KSP program. As a result, I was going to donate to you the source code for various half-baked and seed projects related to this game that I had made. In particular I have both the never-completed Cochrane warp drive mod and SmartResources resource manager source code and model files (it really needs some good texture work & I do not like working with GIMP - but the basic warp drive functionality actually works for the most part including warp at time warp, though it's feature limited and no cool FX), and a cheap Unity based project titled "OpenKSP" which is right now a very tiny stub of nothing that so far does nothing but load a certain .mu file into Unity and render it. Thought I'd just give you that stuff so anyone who wants to play with it can when I am gone. I might do something with one or more of them tomorrow but that's about it, I'll post 'em to my github, then I'm off. Thanks!

I've noticed a time warp issue with the electrical systems in the quad pack of mods consisting of this, Dynamic Battery Storage, System Heat, and Far Future Technologies in that if the NFE reactors (the SystemHeat versions) are put in with enough power draw and modest battery storage there will be power cut outs at high timewarp (10000x or more) which in one case are universally causing the FFT antimatter tanks to detonate and ruining the craft. The only workaround that seems to work is manually boosting the generation rate on the reactor, i.e. it seems to have to do with automatic throttle-down and I'm guessing electricity is transiently depleted before DBS can kick in and buffer it. Could this be fixed somehow? I am not sure where to ask this because I run all 4 mods together, but I figured this thread looks more active than the DBS one.

(rm)

It seems there is still a bug present where that, when the game tries to autosave, it results in a sudden and momentary depletion of electricity while at timewarp. This is annoying on some vessels, but downright catastrophic when something like antimatter tanks are included (i.e. vessel goes boom!). (ADD: Note this could be either this mod or it could be the related but different Near Future Electrical - I'm not sure.)

ADD: Wanted to say that not only is this not dead, I'm going to have a first test release soon! It took much longer than I anticipated because I got very sidetracked into developing an outgrowth of this mod that basically resulted from being fed up with KSP's stock glitchy resource management system, in particular that it behaves badly at timewarp - and as a result I ended up spinning off a second, System Heat-like mod project (it's part of this warp drive mod now but the aim is to make it fully separate) to revamp and replace the stock resource handling system (in particular, this new resource system does not suffer from the infamous "time warp and have the batteries run dry" problem, and also tries to provide a decent interface for background processing, all in one). More on this if you want.

Update (2022-05-11) IT GLOWS! Thumb up if you think this looks cool And I've also managed to get some ability for traveling at warp speed in time warp too. It is not yet proof good though because only goes up to 10x timewarp before it glitches and the ship blows away -- but still, that was useful enough to make a test trip to a GU star in about a couple hours of real time.

Hmm. Would be interesting to see what they came up with. Does it parse star catalogs too, or is it just a .CFG generator?

Not yet, but it's something I have planned to build, perhaps after Cochrane is at least at a working level and useful to cruise with. But yes, that's the idea - to generate .CFG from standardized astronomical data sets, though there's quite a few details to work out.

Update: Have gotten some edges filed in the code, and you can select your warp speed now. For your viewing pleasure, 3195 "G" from Kerbol, after certifying the drive to reach warp 1.5:

Damn, this is great! I'd also had the similar idea, though it was to write my own procedural planet generator algorithms and then use them to do another GU-style planet pack but more complete, particularly in regard to more thoroughly mapping the systems around our Sun at a similar 1/100 scale distance, given that GU's author seems to have taken toward the direction of making a small "galaxy" with its systems, whereas what I wanted was to feed actual astronomical data through to systematically generate all stars and all known exoplanets out to, say, 10 light years (which then shrinks to become 10 000 "T" in-game) uniform in every direction. I believe there's something like 100-150 stars in that range. I did not manage to get around to this though (though may pick it up again after seeing this.). What are you using for the procedural generation, may I ask? It's a really tricky thing I've wondered about for a long time because I remember a long time ago - before KSP existed, in fact - when I had tried to create my own planet textures for a different purpose. They are a rather difficult thing to do by hand particularly when it comes to the fact that typical graphics editors work on the presumption of a flat surface geometry only and so do not naturally produce the necessary distortion in the texture map to ensure proper scale near the poles, requiring one to guesstimate the required distortion by hand vs. being mathematically precise. (And you are really lucky by the way to be able to have other people teach you how to do KSP modding - I've had to figure all this stuff out entirely on my own, including rediscovering the various quirks of the game engine.)

UPDATE (2022-10-21): I just have managed to get a decently working implementation but artwork is still lacking. See my latest post, there's a GitHub available. This has been on my backburner for a little while mostly b/c of the awkwardness of blender, but that changed when I took recently to really trying to finish it. The idea for this mod was born after I saw another here called "TrekDrive" that introduced the concept of bringing a Star Trek-style warp drive to Kerbal Space Program, and I tried it but found it sadly to be in a rather incomplete and buggy state (although I note recently that the author thereof has posted about it and suggests they will be revisiting the mod in the future). Nonetheless, I couldn't help but think this was a really cool idea, and wanted to have a complete and working one. Moreover, I noted the author of that mod was trying to bring a set of complete Star Trek ships into the game and while I'm not at all saying that's not a good idea, I was hoping for something a bit more bare-bones and that would integrate more nicely and directly with the Kerbal vessels and parts I was used to playing with. And given I'd already been dabbling in other directions with KSP modding, I thought I'd try and roll another. Hence, I present: "Cochrane". In this take, the Star Trek-style nacelles-and-core design is employed, but it's been shrunk and modified to fit more nicely and integratedly onto a Kerbal rocket stack, as shown in this picture - note that I do not yet have texturing done on the parts shown here (you can only see the nacelles - though the default colors I find work nice enough for such a preview screenie at least, and likely suggest that the final texture will aim to produce similar colors but with proper shading and also suitably glowy bits), it's just a rough illustration so far (hence WIP). The warp core in this one accepts a 1.25m connection to the rest of the stack, and in the testing rig pictured here is sandwiched between Nertea's damn fine parts, with a LqdDeuterium tank below and Antimatter containment above. The nacelles are surface-mount so you can place them wherever you please, and are made to project a little so there's some clearance to fit a bit of a wider stack between them than just the one to which they are attached. But what I really wanted to do here was get a consistent and methodically created mechanics, both in making it polished as well as more "realistic" for suitably accommodating values of that term. In particular, just like ST and TrekDrive it uses Warp Plasma as the energy conducting medium, but it does so with more refined calculations: namely, we take that each U of WarpPlasma stands for a certain amount of actual energy in joules (here I use 1 U = 1 GJ), and we provide proper and full integration with the Community Resource Pack by using the actual density values prescribed for the LqdDeuterium and Antimatter resources to calculate how annihilation aimed at a "sensible" amount of power generation (okay: 1.21 GW to break through Warp 1) will proceed in terms of consumption and generate the right amount of WarpPlasma accordingly. There will also be thermal effects: in particular a modest amount (relative to power consumed, given that we presume the phenomenal temperature of the plasma tap of an antimatter generator should make for theoretically ultra high efficiency) of waste heat to be dumped by radiators, though in the above screenshot and as of now that mechanic is not yet implemented - the radiators you see are for the bootstrapping reactor only. I plan to use Nertea's SystemHeat for the heat management because I find it much better than the stock CoreHeat system, in particular am a big fan of the "heat loop" mechanic which makes you think about the plumbing in your vessel a bit more. Also, this mod is not meant to be stand-alone: it is only meant to provide the coils (nacelles) and warpcores - there are no antimatter or deuterium tanks or heat management facilities provided because those things are already well-provided for with other mods, I think. Finally one more screenshot from testing, showing the craft above after having flown at warp 1 for some time, at first having aimed toward the Galaxies Unbound star Surr 128, now flipped around and going back to Kerbin (That's still Kerbol there, by the way, in the distance - it would have taken much longer to reach the destination and right now the timewarp is not working when warp flight is in progress):

Uh oh ... I just tried another game (same install as before) and on reload a craft dropped from a height again. This is in OPM, no interstellar range. So the drop from height still does not appear to be fixed. Just maybe a bit?

@R-T-B I just got it. It seems to be fixed now!

True. I don't need a fix "right now" in bold though; just wanted to know if this was brought to your attention and/or to bring it if it wasn't. But also to add my observation that whatever bug seemed to be causing the unmasking was also unmasking other orbits that should be invisible too - for mods like GU this both ruins the immersion and makes the map an eyesore - in case that was not already known.

The archive file name is "Kopernicus-1.12.1-81.zip".

Thanks. Actually now I just finished reinstalling and fired up an OPM mission - it worked! No terrain bugs. However, there appears to be another bug - which I actually saw earlier and thought it was due to how I'd installed things, and that's what prompted me reinstalling so I could test that possibility - and that is that after escaping Kerbin, the Watchdog seemed to actually become visible in the map view, and not only that but also the orbits of the Galaxies Unbound stars became visible too (neither of these things should be visible!). Worse, the Watchdog not only seemed visible but was orbiting Kerbol (what?!). Hmm. Also note that I have yet to test this newest version at interstellar ranges. But given the terrain bugs were showing up at all ranges, I think it should be okay there too, but I still wanna try out an interstellar shot. (i also noticed before my reinstall, the last interstellar attempt I made had the Watchdog appearing visibly orbiting around one of the GU stars, again with hidden orbits becoming visible too and cluttering the heck out of the map. Both of these things seem perfectly correlated, btw.)

Yes. Right now I'm still experimenting. I just upgraded to the newest version - I was actually using an older build - though I had to refresh my KSP install, and will have to build and fly another mission. It seems that in the new version the bug may be fixed; but I will have to finish my testing rounds.

Um, I've just discovered that this this bug is happening when I use a much closer planet pack - Outer Planets Mod (though I do also have GU still installed, but I'm not that far out now, only 123 Gm). The height seems similar in both cases - a few meters above the ground; a noticeable >1 second of falling, landing legs can take it but not other crafts.

@R-T-B, I just finished another try again with the watchdog config installed. Now the base was not below ground, but it dropped from a height (not enough to destroy it, but quite visibly nonetheless of several meters up). Not sure though if this was due to the patch, or just due to landing at a different location on the planet.