TheOrqwithVagrant

OS: Linux (Fedora 30) HW: Ryzen7 1700X, 32G RAM, NVidia GTX 1080 ti Keylogger: Definitely not

Having a very minor but also quite weird issue with the latest (at least I only just now noticed it) - thrust warp won't happen if I go to warp in map view. No error messaage, throttle gauge stays in place, but no accelleration occurs. I start warping in vessel view, it works fine, and continues to work fine when i switch back to map view. Super minor, easy workaround, but... odd. I have a frazillion mods and a campaign save that's been going since 1.3.1 or arounds, so I'm *far* from sure this is actually KSPIe's 'fault', mostly posting it in case someone else runs into it and haven't 'noticed' the easy workaround

Flex-o-Tubes no longer 'dock' vessels into one - is this how they're supposed to work now? Are they basically just a mechanical 'tether' between different vessels now in their 'new' incarnation? Interestingly, my 'old school' flexotubes visually disappeared, but the base I built with them still behave as one big base. The 'new' base has visual tubes, but they don't 'join' the base together.

Done all that, has never once worked. FWIV, the save file edit is easy enough. I remember at one point, I thought I had this tracked down to IsEnabled existing in the save file in a capitalized and non-capitalized form (isEnabled and IsEnabled). 'Restart' from EVA did change one of those in the save file, but I'd end up with isEnabled = false IsEnabled = True and the reactor remained offline until I removed the ' = false' one. I don't use fission reactors all that much anymore in my campaign (fusion reactors power on and off just fine) so it's been a while since I had to deal with this.

Yeah I keep forgetting about this - I can't remember ever successfully re-starting a fission reactor once it's been shut down. There's supposed to be a fairly long 'cooldown' period before you can re-start, but I've never been able to make a reactor restart no matter how long a wait i've given it.

I think I'll make a write-up of my very long running 6.4x scale + OPM campaign some day, it might interest both you and others in this thread. My "SSMC" "Self-Sufficient Mining Colonizer"-class ship tends to shake out any and every bug from both KSPIe and MKS/USI - the 'lander/miner' section contains essentially full production lines for KSPIe ISRU + MKS/USI local construction. Right now, pretty much everything is working (thanks for fixing the Haber process!). There used to be nasty bug where various reactor values would end up NaN and basically nothing could bring them back online, but I haven't seen that since the last update. I battle some kind of ship-shaking Kraken a lot, but I'm sure that's a 6.4x scaling issue. There is also a heat-transfer weirdness issue where *one* compressed gas (out of four symmetrically placed ones) tank on the SSMC-class ships will overheat and explode during initial takeoff from Kerbin. Here's the SSMC "I Eat Moons And Poop Colonies" next to Ridgeview City, constructed entirely from in-situ mined resources. Ship weighs almost 4000 tons wet & 1500 tons dry - landing her is 'interesting' to say the least, but I've done it on *Kerbin* once when I had to bring the first version back for "refurb" because some things massively needed to be re-balanced (nowadays I thoroughly test new designs in Sandbox before launching them in the actual campaign...): EDIT: Some more info about the ship above. 2 Sections - the lander/miner and a detatchible orbital 'habitat' which has some propulsive capabilities of its own, but relies on beamed power from the lander section (which has enormous amounts of power) to light up its plasma nozzles. The orbital section also directly enables planetary logistics when arriving at a 'new' world. Here, since Mun already has a station, the SSMC landed with the orbital section still attached. The 'main' section - the lander/miner/factory and propulsive unit has 3 different forms of propulsion (Thermal Nozzle + Positron Reactor for high-twr burns), 4 3.75m plasma nozzles connected to Antimatter-initiated fusion reactors (the 'main' propulsion), and two 2.5m Plasma Wakefield engines ( these are astonishingly versatile - if all reactors are turned to power generation and caesium or buckyballs are provided, the wakefield engines can actually be used for takeoff and landing from most airless worlds! However - the ship does not really have enough radiators to run the wakefields at 'full power' for more than a few minutes. Oh, and there's also a 'backup' 1.25m antimatter beam-core reactor for 'emergencies' XD ...we really need a better resource display - even the Alternative Resource Panel can't adequately display the absolute TON of different raw materials and resulting product resources that a 'full and complete' ISRU & MKS/USI production line requires.

This did something bad in my install - a whole bunch of parts 'disappeared' and prevented my savegame from loading. Mostly USI life support modules, but also some rover parts, wheels, etc. EDIT: I suggest adding -iname "*.cfg" to the find args; those are the only ones where the edit should be made. Further - this *could* just be due to me using cygwin to run this - but all .cfg files ended up with unix line termination. Running unix2dos on them fixes the issue.

I just crashed one of Dres's asteroids (class C) into Dres... and instead of generating an impact, it reached 'g-limits' and just 'popped' when it hit. Neither landed bangometers nor the orbiting flashometer registered anything. I was quite disappointed. I strongly doubt this is Impact!'s fault - mostly putting this here as a 'warning' to others that their hard work to de-orbit an asteroid may not produce any useful data for this mod's science instruments.

The new disposable pads are great, but I have an issue where trying to build anything that has a Clampotron Sr causes the new 'ship' to spawn some ways away from the source vessel, rotated 90 degrees. The build also never finalizes (The pad doesn't explode), and the 'spawned' part is neither part of the original ship, nor an independent vessel - in fact, its position will lock to any EVA-ing kerbals and move around as the kerbal does, attached with an invisible strut. Finally, tearing down the build causes the universe to implode. Not a big deal, really - I just add any necessary docking ports after-the-fact with KIS - however, it took a little while for me to narrow this down to the inclusion of clampotron sr. so I'm just reporting this here in case someone else runs into the same issue.

Do we need to add Rubidium as a propellant now?

Just unlocked antimatter tech for the first time in a career playthrough - god DAMN does that positron reactor kick butt for propulsion. I wasn't prepared for quite that big a jump in performance, and the 'propulsive core' of the ship accelerated so hard it literally just shot up *through* the ship, destroying all parts above it and blowing the whole thing up quite spectacularly. Good thing it was an unmanned test launch...and that KSPIe doesn't 'model' the result of an antimatter containment breach with 'realistic' results yet... XD

Apparently the part is obsoleted, but it still works, and you can restore it to the tech tree by filling in the techRequired and category fields in the part.cfg.

Caution - SolarWindArrayCollector is missing in this release. I had two 11-million+ kerbodollar craft whisked out of existence after upgrade (savegame backed up, so no permanent damage). Be cautious when upgrading if you're using this part in your builds. I'm *guessing* this is an oversight, since removing the part isn't mentioned in the changelog. Also, the atmospheric scoops continue to be missing from the tech tree (this has been the case for a number of releases), though the parts exist and work, but it will prevent loading of ships constructed with it in career, since there's no way to research/buy the part. Not sure if this is intentional (I think the 'atmospheric processing' functionality of the refrigerator units renders the scoop somewhat obsolete?), but if not, it's easily fixed by filling in the TechRequired and Category fields in the scoops' configs. I use aerodynamicSystems/Aero, since that's where Karbonite's scoops live. As a small note, I absolutely love KSPIe, but I don't know any other mod that causes craft deletion after point upgrades to the degree that KSPIe does. It'd be nice to have some kind of warning about parts being renamed/removed.

Well yes, I know - but various 'not ready yet' configurations and combos have worked quite fine at times in the past. I'm just confirming this is not one of those times (Kopernicus certainly made it clear you should expect an apocalypse if you load your old savegames), and moreover reporting more specifically what the breakage with this particular mod combo can be expected be. Particularly since this is one of those time where the way it's 'malfunctioning' is somewhat amusing.

Just a word of warning about 1.4.4 - I had everything working fine with 6.4x scale on 1.4.3, but 1.4.4 definitely breaks things. It breaks... interestingly. The planets are still re-scaled, but not orbital distances, or speeds. I was messing around with sandbox, and trying to launch a rather experimental craft, got to 1000km and discovered I was in orbit despite only having reached a fraction of what I expected orbital velocity should be. In retrospect, the Mun did look unusually big in the sky from KSC... XD

For what it's worth, I find it hard to imagine running KSPI *without* RealFuels. The two work excellently together, and KSPI provides a partial ISRU architecture for RF. My 'perfect KSP' is 6.4x scale w. outer planets + KSPI + RealFuels + FAR (and *most* other realism mods) + MKS/USI. I can't recommend this combo enough for 'veteran' KSP players.

The virtual horizon calculation is what I was wondering if Sigma Dimensions might be screwing up - flashometer craft was definitely in view; I was looking backwards at it from the impactor all the way to impact. Distance was less than 50k. One thing pointing against this sigma/rescale is that I also can't get the flashometer to work on asteroids, where I usually just have the flashometer 'trailing' the impactor by slowing it down relative to the target once the impactor has been released. Again, distance was well under 500k, and the flashometer right behind the impact. The thing about multiple craft having the same name IS interesting - nothing shares the name of the impactors or probes, but I do have other craft with identical names in flight. I'll try fixing this to see if that makes a difference.

The flashometer isn't working in my current game. I *suspect* it might be due to sigma dimensions on a 6.4x scale (out of the many mods I run, the rescale seems most 'likely' to interfere with this). Is anyone else having trouble (or success) with the flashometer in an up-scaled system? FWIV, the bangometer works fine.

FreeThinker, that's not it. The closed cycle "nuclear lightbulb" engine now suddenly works like a *thermal nozzle*. You have to put it behind another thermal-power generator reactor to work at all, *even in zero g*. My closed-cycle gas core power ships en-route to interplanetary targets are now crippled in space Moreover, the closed-cycle nuclear ligthtbulb is *supposed to work at sea-level in 1G, even on earth*. Why this sudden nerfing?

To anyone who has ships whose reactors/engines shut down due to overheating and now won't produce thrust (despite looking like theys should) - I got this issue shortly after playing with the .6 update. I examined the save file, and found that the affected reactors all have double isEnabled entries with capitalization difrerences (IsEnabled/isEnabled)- one set to True, and a lower one to False. Removing the non-capitalized entry made things work again. I made the savegame edit after reverting to .5, just to be clear.

I'm not sure this is a 'generic' error, but there's definitely something off with CO2 production from Hydrate processing. My methane plant on Minmus is currently basically useless due to this, currently. According to resource info Hydrates are supposed to produce %25 water, %5 CO2 - after processing enough Hydrates to fill my 8000L water tanks, I had produced less than 2L of LqdCO2... Looking at Extractor.cfg, I notice CarbonDioxide, unlike Water, has 'DumpExcess' == True. I've noticed in some situations, resources don't 'make it' to tanks - I have a Moho base that thinks water storage is full and refuses to process more hydrates unless I manually transfer water from the 'buffers' to the storage tanks. Perhaps something similar is happening to CO2 - it's not 'making it' to the available tanks, and gets 'vented' even though there's available storage somewhere on the base?

I avoid part clipping as much as possible. In the case of my current explodiferous interplanetary ship, the heating has consistently started where small craft have been docked with clampotron jr.

After removing FAR, it _seemed_ to fix the issue - but in fact, it just slows the heating down. With FAR, it happens in seconds, but w/o FAR - it still happens... eventually. So I'm not so sure it's really an 'interaction', but rather that something that FAR does accelerates the overheating bug. In short; the actual BUG is in stock, and FAR just makes it a lot more obvious. A fix in FAR may actually be the wrong thing to do, if it just makes the underlying bug 'fatal' less quickly.

Actually this one is definitely from FAR - Ferram has said as much in the FAR release thread, and there's already a fix in the dev tree. EDIT: ...or not. I got the explosions _eventually_ even without FAR, so perhaps this is a stock bug that just gets 'sped up' vastly when throwing FAR in the mix...

I'm being hit by this too and with really bad timing. I have my Kerbals first interplanetary craft just leaving orbit of Minmus to meet up with the crew transfer/return ferry. A small lander 'caught up' launching from the surface of Minmus, and when it reached the main craft and docked, Infinite Heat appears to have streamed from the clampotron jr into the whole vessel, turning the expedition into an explodition. I've had minor things blow up before, but this is aggrevating - I've spent days of gaming time prepping this mission. The one item of data that I feel I might add is that once I reloaded, set 'ignore max temp', and docked, it was VERY clear that the 'source' of the heating was the point of docking - the heat quite visibly 'spread out' from there. Perhaps a clue for the bughunters... Imgur album here: http://imgur.com/a/ssr0S