Bluebottle

Two bugs found. Bug 1: The .cfg parser chokes on commented "mesh" statements. These are present in some of the Near Future Construction parts. For example: Removing the "//mesh" line made the KSPBlender parser work again. With that line in the file, no "trusslrg-hollow-1" parts could be imported by the script. Bug 2: The part database builder will count backup .cfg files from some text editors as valid .cfg files and load a part twice, which means that none of those parts will be imported into Blender. I had several .cfg~ files (note the tilde character) lying around in my GameData, which normally cause no problems whatsoever, but KSPBlender considers them valid and loads them. You need to delete such files, at least on Linux.

Thank you. That could be very useful.Did you ever try offsetting the model meshes? That's what I do with my new compound .mu files, since it allows me to match the new model to the old attachment nodes (from a normal weldment) and get rid of all the old models. Then I can just drop the new part in to an existing ship with a save-game edit. @Alewx do you have any opinion on which are positioned more accurately in a weldment: the attachment nodes or the model meshes?

I've found that this fix is actually incorrect. It's a band-aid over the real problem: somewhere along the line, the textures are being vertically flipped during the import. I've yet to find out whether it's happening in the .mu importer or KSPBlender, or maybe in Blender itself. The biggest issue is that exporting back to Unity requires either all the textures to be vertically-flipped, or you have to manually flip the UVs and offset them back down onto the UV square, to emulate the effect of a flipped texture. edit: it's actually just DDS handling. All DDS textures have to be flipped, for 'reasons'. What's annoying is that the Unity editor doesn't demand this and displays DDSs "properly", while the game needs them to be flipped.

Sure. The source/algorithm/parser would be useful too, mainly because I run Linux and could implement it natively, but I could run the executable in a virtual machine.

Just used this today in 1.0.5 and it still works. Very useful. Whack-a-kerbal is a crapshoot and the Depart utility didn't work with my saves, so this was the last hope. Thanks.

Thanks for the texture tip, I hadn't seen that syntax before, or maybe I just didn't notice its significance. Yes, I've had times where moving a part or adding one would incur a 5-10 second delay, every time. Annoying. Removing attachment nodes en-masse didn't make any objective difference. About the colliders, I was referring to doing it at (effectively) compile time, but those mods you reference are obviously doing it at runtime, which would be a better way. On the other hand, their problem domains are more strictly defined, and they're not attempting any kind of optimisation, AFAICT. FreeIVA's colliders are added manually, according to everything I can find in their thread. KKS would modify the shape of a collider but without removing anything from its mesh. So, optimising the colliders would really be a shape-recognition problem which makes it similar to computer vision. A plugin would have to project a welded part's colliders and recognise sub-shapes that approximate boxes or spheres. Particle-swarms might be useful. At the most basic level, this problem is quite similar to captcha bots and OCR tech, but in three dimensions, although with only two shapes to approximate for. Not for the faint of heart. Or, of course, it could be done with some kind of manually-created metadata that replaces the colliders at runtime, which is the FreeIVA method (again AFAICT). But each and every player would have to create a unique collider mesh to go with each and every welded part they want to improve performance for. That's what I've been doing, just not at runtime.

Yes, I make a new .mu. That requires doubling up the textures too, because my welded parts often contain parts from many different mods and I don't know how to use textures from other locations in GameData, or whether that's even possible. RAM usage therefore goes up. Also, I had to flip some textures - not sure if that's a GIMP import problem for DDS files or a KSPBlender plugin problem, probably the latter. Colliders are quite straightforward. For long trusses you can make a bounding box in Blender and use that for a collider (by removing the mesh renderer from the bounding box in Unity, but keeping a collider). For individual parts sticking out of a truss (e.g. a fuel tank), I just use Unity to create a box collider around that one mesh. edit: Creating new colliders automatically would likely be impossible. It would first require huge amounts of time to get Taniwha's Python exporter working again, then you'd have to automate/script the Blender process, and on top of that create an amazing algorithm to identity the largest box-like shapes in the collection of meshes. One thing should be clear: my method is for lifting the FPS at the expense of everything else. The resulting colliders can be terrible to work with when surface-mounting other parts in the VAB or SPH. I make cylindrical tanks use box colliders. But I don't care if the truss is just hanging around at the back of a huge station and no kerbal or ship ever goes near it. edit: Welding a part with the Ubio plugin is still very useful. It provides a set of attachment nodes which usually just have to be offset in a consistent manner because the CoM of the part never stays the same. At least I've never figured out how to keep the CoM of the UbioZur-welded part. I also re-use the UbioZur config file, and effectively just swap out the model and node sections, for the most part.

I think a lot of this is to do with the colliders. For example, Nertea's NFT construction parts have quite detailed mesh colliders and the physics load from them will still be there with a welded part. I've been playing around with importing an unwelded part (i.e. before welding it using Ubio) as an entire craft into Blender, then bringing the whole thing back in through Unity, and redoing the colliders with simple box and sphere ones. That way, you can replace all the individual colliders of each part with one collider that covers them all. I call it "ultra-welding". It does work, and increases performance a lot, but it's quite labor-intensive, especially with the materials and the attachment nodes.

You run FAR, right? What values does FlightIntegrator give you for the 'analytic temperature' (IIRC)? They'll be in the log file. It used to be an issue with any part that had a ModuleCoreHeat but it was fixed in FAR a couple of months ago. Could be something else that interferes with the FI though.

As it says right in the readme.txt, the kspdir.txt contains the full directory path where your KSP.exe lives.

Are you using any parts that aren't plain structural parts (e.g. stock wings)?

Yep, all problems fixed. Thanks for the update.

It also affects the Github repository as well: both locations have a 22 byte zip file.

Thanks for the mod. Yet another that Should Be Stock! And now, the bug report. At least it looks like a BBT bug. A kerbal on EVA spews these NREs in the log, as long as they are not in the landed state. I've left the Final Frontier message in there because it shows when the NRE stops: when the kerbal lands. If the kerbal uses their jetpack, the NREs start again. No surprises there. [ERR 22:49:07.351] [BetterBurnTime] (NullReferenceException) Object reference not set to an instance of an object: at BetterBurnTime.ImpactTracker.CalculateVesselHeight (.Vessel vessel, .Part& lowestPart) [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.GetVesselHeight (.Part& currentLowestPart) [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.CalculateTimeToImpact (.Vessel vessel, System.String& verb, System.Double& impactSpeed) [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.Recalculate () [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.LateUpdate () [0x00000] in <filename unknown>:0 [ERR 22:49:07.450] [BetterBurnTime] (NullReferenceException) Object reference not set to an instance of an object: at BetterBurnTime.ImpactTracker.CalculateVesselHeight (.Vessel vessel, .Part& lowestPart) [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.GetVesselHeight (.Part& currentLowestPart) [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.CalculateTimeToImpact (.Vessel vessel, System.String& verb, System.Double& impactSpeed) [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.Recalculate () [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.LateUpdate () [0x00000] in <filename unknown>:0 [ERR 22:49:07.523] [BetterBurnTime] (NullReferenceException) Object reference not set to an instance of an object: at BetterBurnTime.ImpactTracker.CalculateVesselHeight (.Vessel vessel, .Part& lowestPart) [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.GetVesselHeight (.Part& currentLowestPart) [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.CalculateTimeToImpact (.Vessel vessel, System.String& verb, System.Double& impactSpeed) [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.Recalculate () [0x00000] in <filename unknown>:0 at BetterBurnTime.ImpactTracker.LateUpdate () [0x00000] in <filename unknown>:0 [LOG 22:49:15.435] FF: ribbon achievement (vessel state): [LOG 22:49:15.435] + name: First Mun Surface EVA [LOG 22:49:15.435] + code: G1:Mun [LOG 22:49:15.435] + previous vessel state: [LOG 22:49:15.435] - Timestamp: 5982045.56775724 [LOG 22:49:15.435] - Origin: [LOG 22:49:15.435] - Vessel name: kerbalEVA (Phoayne Kerman) [LOG 22:49:15.435] - Vessel type: EVA [LOG 22:49:15.435] - Situation: LANDED [LOG 22:49:15.435] - altitude: 585.650262520794 [LOG 22:49:15.435] - speed: 0.840291798114777 [LOG 22:49:15.435] - geeForce: 0.153467908364258 [LOG 22:49:15.435] - geeForce_immediate: 2.11929301057188E-05 [LOG 22:49:15.435] - GetTotalMass: 0.094 [LOG 22:49:15.435] - MachNumber: Infinity [LOG 22:49:15.435] - MainBody: Mun [LOG 22:49:15.435] - IsLanded: False [LOG 22:49:15.435] - IsSplashed: False [LOG 22:49:15.435] - IsLandedOrSplashed: False [LOG 22:49:15.435] - IsEVA: True [LOG 22:49:15.435] - IsLaunch: False [LOG 22:49:15.435] - IsPrelaunch: False [LOG 22:49:15.435] - OnSurface: False [LOG 22:49:15.435] - IsInAtmosphere: False [LOG 22:49:15.435] - HasFlagPlanted: False [LOG 22:49:15.435] - InOrbit: False [LOG 22:49:15.435] - Situation: SUB_ORBITAL [LOG 22:49:15.435] - HasMovedOnSurface: False [LOG 22:49:15.435] + current vessel state: [LOG 22:49:15.435] - Timestamp: 5982058.68775695 [LOG 22:49:15.435] - Origin: [LOG 22:49:15.435] - Vessel name: kerbalEVA (Phoayne Kerman) [LOG 22:49:15.435] - Vessel type: EVA [LOG 22:49:15.435] - Situation: LANDED [LOG 22:49:15.435] - altitude: 585.650262520794 [LOG 22:49:15.435] - speed: 0.840291798114777 [LOG 22:49:15.435] - geeForce: 0.153467908364258 [LOG 22:49:15.435] - geeForce_immediate: 2.11929301057188E-05 [LOG 22:49:15.435] - GetTotalMass: 0.094 [LOG 22:49:15.435] - MachNumber: Infinity [LOG 22:49:15.435] - MainBody: Mun [LOG 22:49:15.435] - IsLanded: True [LOG 22:49:15.435] - IsSplashed: False [LOG 22:49:15.435] - IsLandedOrSplashed: True [LOG 22:49:15.435] - IsEVA: True [LOG 22:49:15.435] - IsLaunch: False [LOG 22:49:15.435] - IsPrelaunch: False [LOG 22:49:15.435] - OnSurface: True [LOG 22:49:15.435] - IsInAtmosphere: False [LOG 22:49:15.435] - HasFlagPlanted: False [LOG 22:49:15.435] - InOrbit: False [LOG 22:49:15.435] - Situation: LANDED [LOG 22:49:15.435] - HasMovedOnSurface: False [LOG 22:49:15.435] + - end - It looks like BBT is trying to calculate the lowest part for a kerbal... which they don't have because they're only one part? edit: forgot the versions. Linux KSP v1.0.5.1028, BBT v1.3.4 via CKAN.

Yes, everything looks fine now with my test save. KAS pipes are functioning again too! Many thanks for the quick fix.

Sure, no problem.

OK, I've reproduced it: [LOG 02:39:24.878] AGX Flight Update Error 7h10 System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 Possibly-relevant information: the NREs are produced by a save that has a kerbal on EVA as the focused vessel, in a scene on the Mun where I have a problem with KAS and I'm unable to undock my shuttle from the Mun base (the KAS pipe disappears but the base and the shuttle remain technically docked, although with separate physics). The NREs continue in any scene from that save, though. I don't know if the impossibility of undocking is related. It's a KAS bug because it remains even when AGE is uninstalled: probably a corrupt save. Still, it's an edge case. Let me know if you need more info. edit: actually, I'm getting the NREs whenever I focus on an EVA'd kerbal, even in older saves. edit 2: OK, this is getting odd. I've noticed that an EVA'd kernal still retains the action groups of the vessel they just left, and can indeed use them. I don't think I ever saw this before. Stock actions like landing gear don't work in this circumstance. Screenshot:

Hi, I've been getting NRE spam since the 1.35 update: [LOG 21:05:41.412] AGX Flight Update Error 7h System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 [LOG 21:05:41.453] AGX Flight Update Error 7h System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 [LOG 21:05:41.492] AGX Flight Update Error 7h System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 [LOG 21:05:41.541] AGX Flight Update Error 7h System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 [LOG 21:05:41.581] AGX Flight Update Error 7h System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 [LOG 21:05:41.638] AGX Flight Update Error 7h System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 [LOG 21:05:41.678] AGX Flight Update Error 7h System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 [LOG 21:05:41.721] AGX Flight Update Error 7h System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 This happens in any scene with a vessel, and never ends. Re-installing 1.34 didn't stop the NREs, so I've had to uninstall for now. 1.34 worked fine except for the group names issue when docking, so I guess 1.35 changed the way the data was stored and now I can't go back?

This is because the relevant 'if' statement that tests for matches with "position=" also matches things like RealHeat's "...Decomposition=". I fixed it by adding a whitespace check to that match, which means that line 118 in part_dict.py simply needs a "\b" added: if "\bposition =" in line and not(got_pos):

Ahh, sorry. I forgot to copy the log when I restarted KSP to recover the kerbals . Since I run a continuous "tail -f" on the log file in a terminal, I can only provide you with everything after 01:56:09 (the 100,000-line limit in my terminal means everything was truncated before that time) but that's five mins after they were killed off. Would that still be useful? Probably not. The vessel was 6 days and 2 hours out from Kerbin when I noticed the problem, so it's altitude would have been 30-40 million metres, and I guess KSP could have given it the wrong altitude. The camera kept flipping around between the orbital and suborbital perspectives despite a periapsis of ~24,600. Thanks for the quick reply! No pressure whatsoever for a fix. I'm sure everyone would prefer that you kept your power dry for the apocalypse that will be 1.1. edit: I've got a dated-saves mod installed too, so I'll try to go back and reproduce it from the last save before the problem. Maybe it'll work. edit 2: Having gone back to that old save and time-accelerated past when I had the problem, I'm unable to reproduce it. Who knows, it could have been a section of code that isn't thread-safe or the like.

You could try editing the welded part cfg and just removing everything apart from resources. And just to be sure, what are you using as your root part? I remember the nose cone floating off a spaceplane because I had reassigned some landing gear non-physics part as the root part (!). Happens to the best of us, even the Manley himself. That's awesome about the pivot parameter. Do you know of any other modules with similar tweaks available?

Been using this mod for a long time, but just had my first instance of kerbals being killed off by it today. I had a shuttle vessel returning from Minmus. It had previously undocked from a base there (KAS hose) and was firmly within the Kerbin SOI. All was well with four kerbals on board. When I later went back to it to alter its inclination, all the kerbals were missing. I found they were listed as KIA in the astronaut complex but Final Frontier had no record of them being killed. I didn't suffer any reputation decrease either. SR handed me a ghost ship... [LOG 01:01:42.841] [SR] Determined cutoff altitude to be 27200 [LOG 01:06:45.396] [SR] Added vessel KSS Eos v1.0 (8ddd4623-7df6-4c24-8d8b-edd320a639c4) to watchlist. [LOG 01:06:45.411] [SR] Added vessel KSS Tyche v1.0 (0a292d34-f937-4f83-aae8-180dced4fc11) to watchlist. [LOG 01:06:57.959] [SR] Vessel KSS Tyche v1.0 (0a292d34-f937-4f83-aae8-180dced4fc11) is about to be destroyed. Pre-recovering Kerbals. [LOG 01:06:57.960] [SR] Pre-recovered Verdi Kerman [LOG 01:06:57.960] [SR] Pre-recovered Wehrlan Kerman [LOG 01:06:57.960] [SR] Pre-recovered Madise Kerman [LOG 01:06:57.960] [SR] Pre-recovered Edrey Kerman Those are all the SR messages until they were killed. No more log messages from SR for 17 minutes after that, just regarding the normal operation of other vessels. I only discovered the issue after a 3 hour, 40 minute session: there was no in-game notification from SR and the vessel itself was still there, unharmed and fully functional. There is a happy ending: I've been able to revive the crew with ShipManifest and then edit the savefile to restore their experience and put them back into the vessel. Linux v1.0.5.1028 64-bit, SR v1.6.3 via CKAN. Edit: the kerbals were killed by the mechanism below. Probably nothing unusual here. FF didn't notice though (I think it does normally list any killed kerbal in their mission log, but then again, I'm not in the habit of murdering them). [WRN 01:07:01.867] [ProtoCrewMember Warning]: Crewmember Edrey Kerman found assigned but no vessels reference him. Edrey Kerman set as missing. [LOG 01:51:28.338] Crewmember Edrey Kerman has been missing for too long! He must be dead by now. [LOG 01:51:28.339] [00:00:00]: Edrey Kerman was killed.

I'm not familiar with those parts, what part modules do they use? Whenever I've had parts just float away it was because I was getting too audacious with part modules.

I'd love to know what that tweak was: I'm using them for landing pad strobes and could do with better visibility.

As Fury1SOG said, root part rotation can cause problems. I've found that that applies even to the SPH as a whole. For me, welding in the VAB has a higher likelihood of success, especially with any compound parts like the EL RocketPart hexcan packs. You also have to watch out for parts that are already rescaled in their .cfg's.