Xrave

Hey guys, I'm a huge fan of the mods the community is throwing out, but frequently mods cause my game to glitch out and crash after 40 minutes or an hour of gameplay. These bugs are not easily identifiable, and crash logs are pretty obscure for normal people. Here's my idea: a script/mod inside or outside KSP that you run after each crash. It grabs the latest crash log and records it and the mods installed to database. It records the log file (and maybe even the crash exception error message), and correlates it with mods installed. It sends the record of to the aggregation server. On the aggregation server, we can use filtering to figure out which mod is causing what kind of crash, and log output of those crashes. I obviously haven't fleshed this out, but I'm wondering if there is community interest to talk about a project like this one and have a discussion about whether such a system can be technically feasible at all. Obviously, parsing KSP's log is kinda prohibitive and I'm not sure if it even logs the error when the application crashes, and from what i see, the Unity error msgs to the Mac OSX console is not saying much. -Xrave Edit: Even frequency of crash can be a indicator (say you don't install A, and you crash after ~90 minutes, and after installing A your crash frequency went up to once per 30 minutes) Although, for me personally, i think i might just be running out of memory. *hmm*

Heyo, excellent work so far, I'm confused how I can get planetary mining up? The resource frameworks are all over the place and I'm not sure where to start. So first I install EPL, then EPL->Regolith, then maybe ... Asteroid Recycling Tech (ART) for asteroid extraction? yeah? what else should I do for planetary resource mining? Karbonite? I haven't used the latest versions of it, so is Karbonite Regolith-friendly now? Or is it still just good old one-resource-for-all? [Edit] nevermind, forgot EPL has augers and extractors already. lol

@Master Tao, Thanks for the notice! I didn't know it was already there. I'll just stick to simple transfer machines then~

Ran into issues after undocking with Claw on Win x64 bit. Built a simple Robotics thing that extends a claw over to the target made of Rotatron, hinge, and a Gantry. After undocking, Robotics messes up and the actuation becomes buggy, with the Nodes no longer where they're supposed to be. Sorry that I don't have anything better of a bug report, but Im wondering if anyone else has this problem?

GUI stuff and control Key... well. there's some things like 'G' and 'H' keys, and the modules can implement their own context menus. I haven't seen this kind of clashing though. In other news, I installed Kethane and EPL plus interstellar, but it's all very wooly and unstable so I think I'll just give it up for a while before a fully patched and all the conflicts gets resolved. (Edit: more info:) like yesterday I got a spaceplane all the way to Jool (no KAS parts), and then today it crashes on vessel load. I'm doing something wrong lol

yay, so that means EL update will also come soon The good thing that came out of this is I started compiling for myself all the essential plugins XD so take your time :3

Will test parachutes when I get home from work. (wow that's a weird sentence to type)

Relax a bit guys, taniwha is apparently releasing a up-to-date dll soon, and he's damn good at delivering awesome Once again, thank you so much mod devs for making things and keeping everything updated

Oooh. I'll test that out next compile. in my version I changed Detach() so it tries to do a fixedpoint detach if it can't figure out what kind of attachment the part is employing, I don't know if that'd break anything though.

Alright. I patched the Grab Part Explosion bug with a very rudimentary, but working fix. I have no idea how to update the compatibility thing to remove the alert, but it does not impact performance afaik. If anyone could patch the compatibility warning, it'd be much appreciated Right now, if you grab something there is a .4 second delay while the game catches up to prevent the explosion. Issues: Solar panels can drop onto the ground and break, but other than that, everything is fine. Source & DLL: https://dl.dropboxusercontent.com/u/62530944/KAS-master-xrave-unofficial-hotfix.zip

Parts are not affected by the update. A recompilation of the DLL designed for 0.24.2 will pick up all the functionality, unless Kethane radically changed its resource structure. So go ahead and build the base, by the time you're mostly done, i'm sure the hotfix compatibility will be resolved.

Speculation (I haven't seen KAS or any underlying related code ): By those two discussions, it appears, than CPU does not uses floats or doubles for its operations, but uses something called FPU, which is an 80 bit floating point number. When DirectX comes into the picture, some strange things happen. It appears that when DirectX is initiating, it changes the precision of calculations on the FPU. So, when KSP detaches parts, it gives a little punch to new ships, so they move apart. Say, that punch is a little less than 1, by 0.00000001 as an example. In a 32 bit code, this number after the affection of DirectX can become 0.000000003 which is a little closer to 1. But for the 64 bit app, there are 32 bits more to carry the mistake and it can become -0.000000001 that is bigger than 1 and if we multiply it by "explosion factor" this will give us more than 1 which leads to "explode(part)". The fact that the detaching works with lower deltaT somewhat supports the idea, as the multiplications would be by smaller numbers, thus less range for error to accumulate. It can be completely wrong, as I am unfamiliar with such low level coding and this is just a hunch. Might be the case, but the current decoupling is running at breakforce=0f default, where the internal code comments something about the caller handling the decouple instead of it. I will add actual punch to the decoupling method and test how it works then. From personal testing, What I've observed so far suggests an error in the ordering of events on x64 but not x32, kinda like a race condition that causes the teleporting part (it teleports onto your back, then back to ship, then onto your back again - observed using TimeControl mod) to pull/push the spaceship. I have no idea why that's necessary... Testing so far causes unique fixes and bugs: (usually one of the following) 1. part teleports onto backpack 99% of the time unless ship kills you. ship still explodes, less violently depending on your orientation and rotation to the part. 2. part teleports onto backpack. ship does not explode. part feels zero physics and doesn't move with you, if you drop it, then nudge it, it flies away with zero drag. 3. part teleports onto backpack. ship explodes. part doesn't fully pair up with kerbal, and just drops to the ground. Part can still be dropped, but dropping it doesn't do anything. 4. part teleports onto a relative location but not on the backpack. Part moves with kerbal, does not collide. Ship explodes. 5. reattaching part to spacecraft crash. ship also explodes when you grab stuff btw. Also wish people could stop bothering Majiir. Majiir is currently busy with RL stuff and he is merely maintaining the project, meaning that this Grab segment of code probably has not been changed since KospY (the mod's original author) last committed it. Also. i don't know what's the big deal here. Pipes still work! (I think they do anyway) Just build your outposts with Piping and stuff properly planned out and you can still use that Extraplanatary Launchpad to make a base. You can still link them. You just can't 'grab' anything effectively unless you feel like a risk taker

This fix is not as simple as usual compatibility upgrade, unfortunately. I've been digging at the function for ages now and i still don't understand why the bug is occurring for the 64 bit and not the 32 bit. If I have one gripe with Majiir (and the mod's predecessor KospY)... it is that the source is written without consideration into people that may read the code later. It's not bad code , but it's not helpfully documented either ^^;

Not a lot of point sharing it right now it still imparts an annoying amount of phantom force. The fix is to make an extra Detach(AttachType.FixedJoint); here: in AttachCore... Let me just try 4 code compile cycles. I know that it doesn't exert phantom force if a entire codeblock was removed (but also breaks the Grab), i just need to figure out which of the 4 lines is doing it. Issue is found? sort of? if: this.part.transform.parent = evaNodeTransform; this.part.rigidbody.isKinematic = true; <--- this line KAS_Shared.ResetCollisionEnhancer(this.part, false); is turned on, the node becomes Kinematic and gets affected by Kerbal motion. This however also exerts force on the previous vessel for some reason. I will experiment around this area. Forgot to mention, the phantom force is only a problem with x64, I think x32 is working completely fine (unless I missed some forum posts)... anyways, after playing around with it, i still haven't found the magical combination that lets you carry the pipe around AND not impart force on the spaceship you just took it off of. Some joints need to be destroyed this day. I'll look back on it later. sorry~

Made some code changes... Managed to grab the Pipe End Point 100% of the time now, but still have a slight phantom force (enough to bounce a 1 tonne spacecraft up 10 meters)... I have no idea what's causing this phantom force ._.