Fiontar

Sorry that this bug report is for 4.0, rather than 4.1, I'm not updating again until after release looks settled. I still thought it might be worth checking on, if it wasn't already fixed with 4.1: Using warp with extractors/ converters. Converting to Karbonite only seems to scale properly for me up to 5X game speed. After that point, there are no gains in karbonite conversion rates in real time, even though game time is passing at the expected rate and rock is also being mined at the proper rate. My thought was that this may be related to the very small buffer allowed for molten and enriched rock. I tried editing those values in the configs. Editing the configs seemed to have no impact on already deployed parts, so I edited the save file to match the new .cfgs. I was able to double the buffer, (max. amounts of Molten Rock and Enriched Rock), but not beyond that point, no matter what the numbers were set to in the .cfgs or the save file. So, two issues. Please ensure that conversion rates per real time second properly scale with game time warp beyond 5x. Also, are some of the values in the .cfgs for jaw/converters etc... hard capped in the .dll? If so, could you loosen those caps for those that wish to tweak the numbers? ^TIA

When I say things starting acting weird when changing between the VAB and launch pad, this is an example of what I mean. Not long after the persistent save was corrupted. I had a lot of similar, though less severe issues, in previous days and with another save. I'm running 32 bit OpenGL WIndows 8.1

If I get a chance, I'll reinstall the mod and see if I can catch the bug for you. It does seem to be related to the mod in some way, though. With it installed, I wasn't just having problems with an occasional corrupted save, but other times after a mission recovery I'd get weird behavior trying to switch into or out of the VAB, trying to launch from VAB, etc... Since I uninstalled it, no issues like that at all. I'm wondering if it might be related to when/how it writes to the persistent save file? I have no idea how the game handles data related to a flight that you revert out of. If no one else is having this issue, it's likely a mod conflict, I am running a ton of them. Sorry for not jumping right back into troubleshooting this. Lost a lot of play time having to start a fresh save and I'm trying to get some relaxing/fun/productive play time in for a bit before going into troubleshooting mode again. (It took a lot of mod swapping to narrow the issue down to this one).

I'm finding that with this mod, sometimes if I recover a flight after stages have already "landed", my save becomes corrupted. It may be an incompatibility with another mod, I run about 63 addons. When I say corrupted, I mean sometimes the ship will disappear, sometimes it will end up in null space, with no location. This last time, my entire Kerbal Space Center disappeared. If I have time, I'll try to figure out what it might be conflicting with.

Any chance you can make this mod compatible with DMagic Orbital Science? http://forum.kerbalspaceprogram.com/threads/64972-DMagic-Orbital-Science-New-Science-Parts-V0-4-%281-11-14%29 Full compatibility with missions that use some of the science unique to the mod would be great. However, immediate to near term, I really most want to see Fine Print recognize the Universal Storage analogues to the stock science parts included in DMagic Orbital Science as fulfilling Fine Print mission requirements. I really prefer the clean footprint of a Universal Storage Octocore slotted with science equipment vs. stock science parts. Adding this compatibility would be very much appreciated.

Yes, thanks for the fix! (Now let me hide away version 0.3, just in case....) I did make a couple fun craft that wouldn't have worked otherwise, but I didn't actually complete anything with them, had a little fun then reverted.

Well, there is a serious bug in this add-on. That no one else seems to have found it makes me wonder if it isn't due to some conflict with another mod. (I run with around 63 mods). With version .3 installed, all my rockets consume fuel at about 1/1000th, or less, the normal rate, while providing normal thrust. For most rockets, it looks like they are consuming no fuel at all. I had to pair small tanks with large engines to see the numbers move at all during a flight. Neat if you want "god mode", but I don't really get how that came out of a contract window mod! Here is a snapshot of my GameData Directory. I don't have time today to try to troubleshoot which mod it might be conflicting with. C:\Program Files (x86)\Steam\SteamApps\common\Kerbal Space Program\GameData\ 000_Toolbar\ B9_Aerospace\ BahaSP\ CommunityResourcePack\ CrossFeedEnabler\ CustomBiomes\ DavonTCsystemsMod\ Diazo\ DistantObject\ DMagic Orbital Science\ Engineer\ ExsurgentEngineering\ FinePrint\ Firespitter\ Goodspeed\ HGR\ KAS\ KerbalJointReinforcement\ Kerbaltek\ KineTechAnimation\ Klockheed_Martian_Special\ KSPScienceLibrary\ KSPX\ LazTek\ MagicSmokeIndustries\ MechJeb2\ ModsByTal\ MunarWheel\ NASAmission\ NearFutureConstruction\ NearFutureElectrical\ NearFuturePropulsion\ NearFutureSolar\ NohArksPnP\ nothke_DROMOMAN\ NovaPunch2\ OLDD\ OpenResourceSystem\ PartCatalog\ ProbiTronics\ ProceduralFairings\ RemoteTech2\ ResGen\ ResourceConverter\ Romfarer\ SCANsat\ ScienceAlert\ SelectRoot\ ShipManifest\ SPD\ Sphaera\ Squad\ StageRecovery\ StationScience\ Tantares\ TarsierSpaceTech\ TextureReplacer\ ThrottleControlledAvionics\ TweakScale\ UmbraSpaceIndustries\ US_Core\ US_KAS\ WaylandCorp\ WorldCup2014\ XanderTek\ ModuleManager.2.2.1.dll toolbar-settings.dat

Just to finish up for those interested in the oddity of the situation: I deleted and reinstalled your mods. The station still crashed with the Karbonite Folder in the default location. Since I could access the station running in 32 bit with OpenGL, I did so. No crash. I collapsed all inflatables. Turned off all generators. Shut down anything else that was running, scan sat, additional communication antennas, etc... Reloaded the game with the problem 64bit Open GL client. The station was slow to load, but it loaded. So, I guess related to either the inflatables having been inflated or something that was running that I shut down. SO, add that to the weirdness. Just to be done with the headaches, I used Hyperedit to "land" the station, recovered the crew and cash. I'll now build a new station with all mods up to date. The station represented the most time and effort, but I'm glad to have salvaged my communications satellite network, contract progress and crew roster. All the satellites load and work with out issue, so I'm going to take the risk that the save itself is safe to build on. The station predated the parts changes to MKS. I had edited the persistent to get it working in the aftermath. Maybe that contributed to the weirdness, who knows. I'm probably one of your very very 64-bit OpenGL testers, so I'll let you know if any further weirdness occurs, but only if it isn't limited to a particular deprecated save game, but can be duplicated in a fresh save. Testing in OpenGL 64 with a very limited mod set, MKS, Karbonite, their mod dependencies, Scansat, Mechjeb, Hyperedit and one or two more "core" mods yielded no problems with a station I slapped together with all the parts recommended in the OKS tutorial. I'll see how things go with my normal mod load out. (I'm running 65 mods total in the recently rebuilt GameData folder, all of them current versions and most specific to 24.2). When the problem ended up being path related, I was hoping that might ring a bell with you as to something that changed recently that might play into that. I have no problem, though, just righting it up to some odd game save breaking confluence of mod updates. (The station was very over engineered and there were a lot of different mods represented in the construction of the station, so there was more opportunity for conflict). Thanks for acknowledging my issue and thanks for the great mods.

RoverDude, It might be as simple as the mods evolution breaking the save. Why it would break on 64bit OpenGL, become sluggish but still load on 32Bit OpenGL, while apparently nor being broken at all on Direct3D, I have no idea. I'll reinstall your latest versions in their default locations and start a new game on OpenGL 64-bit KSP. Hopefully future updates won't be save game breaking for me.

I'll back up my GameData and see if I can replicate the issue with a minimal set of mods. What I was wondering was if, while developing Karbonite, you did so from a clean GameData folder and rather than nesting Karbonite inside of the USI folder, it was in the root Gamedata folder at the time you compiled the mod in Unity? Or, that the pathing in settings in Unity were off and for some reason OpenGL is less forgiving? The station load crashed in KSP64 OpenGL, with the files in the location where the install places them, but the load times were long when loading the station in KSP32 OpenGL, even though it didn't crash. Moving Karbonite and the DLLs to the GameData root solved both issues. As to the 255 character pathing limit, my KSP is a steam installation, so it's deeper from the C: root directory than an non-Steam install, but still only about 110 characters to the deepest directory with in Karbonite. I had earlier builds of Karbonite installed with out issue, which I why I wonder if something changed in your development process when compiling the mod?

RoverDude, does this make sense to you and is it something you can fix? I'm guessing that KSP64 running OpenGL is particularly finicky about pathing of mod assets compiled by Unity. Can you confirm this and (hopefully) ensure that the pathing is friendly for 64bit OpenGL in future releases? Or, absent that, test pathing of future releases and provide alternate install directions for those using 64bit OpenGL? I spent several hours troubleshooting the issue, I'm just curious why the pathing is wrong and if it's something you can easily fix. TIA

I found the fix for my problem. I don't know why this works this way, but hopefully it will be useful for RoverDude. Reminder of my problem: KSP 24.2 64-bit, OpenGL (Windows 8.1 64) Saved game with Orbital Kolinization Station, numerous OKS segments. With Karbonite Installed, loading that save = Crash when trying to load the station. If any bit of Karbonite was installed, crash. Solution: Place Karbonite Folder in GameData Root, (rather than in UmbraSpaceIndustries). Place karbonite.dll and USITools.dll in GameData Root, (rather than in UmbraSpaceIndustries). Game loads fine, station loads fine, KSP64/OpenGL. Station also loads faster in KSP32 OGL. I was also able to research and place Karbonite parts, so everything seems to be working. I'm not a programmer, but I'm guessing there is a very good reason as to why the mod and it's components only work when placed in these locations and load quicker, as a result, in the client/render combos where they didn't cause a crash previously. BTW, it's not just that they needed to be out of the USI folder, if they are anywhere but as described above, issues ensue.

I definitely get that. I think given the results I've had with OpenGL and the problems that can pop up with KSP 64, KSP 32 with OpenGL is probably going to be my platform of choice until official 64bit support is more stable. At this point though, with this issue, I'm stubbornly stumped. I've tried troubleshooting it, but it appears if any part of Karbonite is installed, my OKS centered station crashes when using KSP 64 OpenGL. I just don't get it. I tried removing bits of Karbonite and only when everything is removed does the station not crash. It's just bizarre...

I updated my previous post, including the error files for download. The space station has a full compliment of OKS modules as outlined in the tutorial. That station crashes the game, with Karbonite installed, for KSP64 OpenGL. KSP 64 D3D, KSP 32 D3D and OpenGL seem fine. It's specific to the red-headed stepchild combo of 64 and OGL. As stated in the last update to my previous thread, not a high priority, but it might signal an error in the coding of one of the dll files that gets exposed under conditions not tested for during development. Up to you s to whether it's worth trying to figure out. I'll do a little more troubleshooting to see if I can figure out what part of Karbonite is causing the issue, but after the time spent rebuilding and testing my GameData for 24.2, I'm probably going to shift focus to testing long term stability for the combination of 65 addons I have running now. As to why test for the other client/rendering methods, I'm trying to find the best solution for running a lot of mods comfortably. OpenGL has a much smaller memory footprint than D3D, (for me, it's 1.585 GB with OpenGL vs. 3.482 for D3D). 64 bit increases the memory space I can fill. 64 bit OpenGL is the most dramatic combination and though the loading time for launches or switching to orbiting craft is longer, performance, for me, has been better. 32 bit OpenGL is fine, though, since with the reduced memory footprint I have a lot more breathing room before worrying about memory issues. 64Bit D3D would also work, but performance seems more sluggish. After rebuilding my GameData carefully, I'm currently running with full size textures and no Active Texture Management, though TextureReplacer offers some modest compression of it's own. If I'm stable after a few days of play, I'll settle on a client/renderer combo and see what visual enhancements I can add and experiment with ATM a bit.

Still troubleshooting, getting close, I think. I've completely rebuilt my gamedata folder over the lest 24 hours, testing as I go and always using the latest versions freshly downloaded. Right now, I think the problem isn't a bug in Karbonite, it's just that Karbonite adds an additional computational load when loading a complex ship/station and this is causing the graphics driver to time out. (Windows 8.1 64 bit). I've got the station loading with Karbonite using 64bit KSP and D3D, by changing the video card power management from Adaptive to Performance. The OpenGL was still timing out, but I'm applying a registry tweak that may the OpenGL time out. Reboot, reload, will take a few. I'll report back and detail the registry tweak, if it fixes the issue. Update1: Registry tweak didn't help. It will load ok in KSP 64 D3D, but not with OpenGL. I currently have texture replacer running without ATM. I'm changing texture unloading to "never" to see if that helps. Update 2: O.k., none of that helped. Further testing and it loads fine with KSP 32 OpenGL, but not KSP 64 OpenGL. Down the road it's something you might want to troubleshoot, to figure out what is causing the issue. It might be the current 64 bit client that is to blame, but I've got 65 mods currently and Karbonite is the only one with issues with KSP64 OGL. Latter, I can try to see if I can narrow the problem down with in the Karbonite install, (I did try deleting the Karbonite.dll, but I haven't tried any of the others). Here is the latest error report, if you want to take a look: https://www.dropbox.com/sh/spbe3p8fyrcx2vz/AAAf_Hp21VRb-2uokm_Iaarla I know you have a lot on your plate and a 64bit OpenGL incompatibility may be a very back burner issue, so np if it has to wait.

O.k., spoke a little too soon. I have an existing save with an OKS in orbit built when I was using a prior release of Karbonite. No parts from Karbonite installed, but there are some storage containers attached to the station. The game crashes when loading the station with Karbonite 1.0 installed. It loads fine with the mod uninstalled. Does the Karbonite mode add Karbonite storage to any of the storage containers from OKS? Could that be causing the issue? I'll try undocking and deorbiting the containers and see if that eliminates the crashes...

The latest version is now working in 64 bit KSP for me. An earlier version worked, yesterday's version did not and today's does. It is possible my download of the previous version was corrupted. I didn't try re-downloading after the crashes. In any event, glad it works today. KSP-64 using OpenGL has been working out extremely well for me so far, glad I can add this mod to the "tested and working list".

Bug Report: Toolbar 1.7.6 KSP 24.2 64bit D3D Crash when loading saved game, just as space center tries to load. No crash running KSP 32 D3D, or KSP 64 OpenGL Error log linked below: Edit: It is now working. After adding some buttons to the toolbar in the Space Center screen, while running KSP 64 OpenGL, it no longer crashes in KSP 64 D3D https://www.dropbox.com/sh/raoq4jst6xqna8n/AABGUrrYDeB7oVnO9OsJ9Y3Pa

I was having some issues with a bloated gamedata folder and 24.2, so I reinstalled the game fresh and have been slowly adding mods back in and testing them with KSP 24.2 32-bit OpenGL, 64-bit D3D and 64-bit OpenGL. I had Mechjeb, Tweakscale, Fineprint, Stage Recovery and USI Kolonization Systems installed, no problems. I added Karbonite, overwriting when asked. The game crashes reliably for me in 64-bit, both rendering methods, with Karbonite added to the mix. New career mode game, VAB, place the first SRB part, crash. Error report: https://www.dropbox.com/sh/r081vyu1m3yunep/AABuFvSWeL_wVhCZBRyfF-V4a

Same issue here, except it is effecting many of the parts in the mod. Line them up, they snap into place, but they don't stay connected. Something is completely FUBAR with the current version. At least 90% of the time, the adapter parts will not connect with normal parts. They don't even pretend to snap on, they dance around at odd angles to the connection point. Most of the Hex segments attach to normal parts with out issue, but occasionally refuse to snap on, or remain connected, to each other. I don't know if it's a 24.2 issue, or if some mistake by the author corrupted his connection nodes, but it's a mess. Did a little more testing. The adapter pieces all want to connect to normal parts at a 90 degree angle to the surface, like a coin standing on edge. If I rotate them to the proper flat on orientation, then they "dance around" and refuse to connect.

Latest Version, 32 bit, 24.2 KSP: The Basic version is saving me more memory than the Advanced version. Something is clearly not right.

Everyone is different. Initially, I was annoyed by the crazy part contract requirements, but then I realized it makes sense to test components under certain conditions not necessarily congruent with a greater mission goal. Engines do get tested strapped to concrete blocks, or to the fuselage of a larger aircraft. Current private space companies do take on contracts for things outside their greater designs for money, status and building trust with the government and corporations looking to them for possible commercial solutions. Once I got over the initial resistance, I started to enjoy designing odd test craft. Sometimes I can manage three mission completions in one flight, while there are some mission parameters I still haven't managed to crack. I don't obsess over the hard ones, I just revisit them from time to time with new ideas and tech to see if a different approach will work. I am glad, though, to know that it is possible to lessen dependance on component testing and turn focus back towards exploration, even if money becomes more tight. Like the real private space companies, I know that some very mundane commercial missions may be needed to fund my loftier goals and I'm actually o.k. with that. That said, I wouldn't mind a mod that would generate more science and exploration missions as a means of funding my space program...

2.3.0 Version, running on 32-bit 0.24 KSP. Mechjeb Bug: Selecting Land Anywhere with the landing module while flying over water, Kerbin, , distance to surface is miscalculated by an additional 1,000 meters, or so. This means no landing thrusters, resulting in catastrophic crash. Tested multiple times from a variety of orbital trajectories. Landing over land seems to work perfect, over water, disaster.

At first blush, everything appears to be working with the latest version of mechjeb and .24 x64. However, I'm having issues with the actual usage of some of the modules. In career mode x64, haven't yet tested in other situations, Ascent Guidance and Orbital info are both not functioning properly. During ascent, when I reach to portion of the orbit where you coast out of the atmosphere, orbital info shows the expected time to Ap and an Ap height of the entered orbital target altitude. However, the craft reaches an Ap lower than designated and well before the predicted time to Ap and the craft will start to lose altitude, with the Ascent Guidance still thinking you are merrily gaining altitude toward the next burn and the Orbital Info window still telling you you are one course for Ap. Could squad have changed some of the orbital physics or atmospheric drag at high altitude? Could that be throwing the mechjeb numbers off? I'll try to test in 32 bit to see if it might be a 64 bit peculiarity. Could others test these as well?

If you figured it out, why not share the solution, knowing that others might have the same issue?