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 ._.

after playing around with the code (and killing a dozen Kerbals from 1400m/s collisions...) There's some strange stuff going on. Let me document this: The grab function seems to work as thus: First, it does the Align EVA Position check, which for some reason moves the part to the Kerbal's EVApack, without detaching it from craft. Apart from this, this function also drops everything the Kerbal is holding to hold onto the new part, which makes sense. If we remove everything else from the function, and using Time Control mod to slow down time 6400%, the part appears on the kerbal's back for about 1-2 frames before 'snapping' back to the craft. This exerts about the same amount of force as a 100-200KN rocket engine going off next to it (partially because Time Control makes the physics alot more accurate) Looking closely at AlignEVAPosition(), the following can be observed: Secondly, there's some code for Winches, which i ignored. Then, some collider stuff that doesn't mean anything to me (first look at mods ever, sorry) Afterwards, Detach() is called for all Grab()s. It's interesting to see that nothing happens here: but attachMode actually doesn't resolve to any of these values, when I tested it. Detach() doesn't do anything. *sadface* this part is weird. Then since i'm grabbing a pipe from a spacecraft, we run DecoupleFromAll(), which runs decouple() (if the parent still exists, which... why does the parent exist if Detach() is supposed to get rid of the parent... I don't understand. ) and also decouples every children it has, or something. It doesn't matter. i was grabbing a pipe end point. And then runs Couple( on kerbalEVAPart's root, which is the kerbal, i suppose), here, or after this, the engine throws "PartJoin, provided nodes aren't valid" error, which is a Unity error and I don't know which line throws it because the string table's tucked away somewhere else ^^; having DecoupleFromAll + Couple blows the spacecraft up, without it, a lot of force is applied but the ship will behave much more peacefully, and rarely do parts fly off/joints break. =================== Otherwise, in my commenting things out adventure: if you comment out the AlignEVAPosition call ONLY, then the part should just fall to ground but still feels as if its attached to the vehicle programmatically, and some nullexception error is thrown. I hope this analysis helps other devs a bit in figuring out the cause of the problem.

Don't hate on Apple! I can't really say anything redeeming about the high price, but you really get what you pay for in its high end products and ease of use. Here's an idea for a fix that I'm just going to throw out there, except i'm really armchair coding . What if you add a tiny invisible 'decoupler' between A KAS part and its parent, and override the "Grab" function into the "Detach" so that it activates the forceless decoupler instead, and then only when its completely loosened, do you allow 'Grab' button to appear? Or maybe sync it together so that grab auto detaches and then makes the new vessel be grabbed by the kerbal?

Would this work with Environmental Visual Enhancements or the experimental OVERHAUL?

I think there's mods that extend physics distance, and it shows that as long as you don't have a lot of crafts, you should still have reasonable performance. Of course, there's a third issue of floating point accuracy. Say you turn up physics to simulate 400KM, and have some sort of autolanding on Kerbin. I think Kerbin won't load its full meshframe until you get close to it (at least the Graphics mesh is determined by Camera position, donno about the collision mesh), so even if it touches down it explode when you get close, or fall down 30m, or even fail to collide properly with the ground, etc.

Hullo dev! I'm interested in making a model for a internal rocket/torpedo launcher (imagine in-hull missile bays for large battleships/planes, where the hatch flips open and the missile/rocket/torpedo flies out), but I am completely amateur at this, so I was wondering if I can get the model source for the cylindrical multirocket bay? Thanks

Woah, fast fix. No worries (I leave zombie code around all the time). Can you compile a new release please? I just pulled GameData folder from github and it seemed to still have the same issues, and unfortunately I can't compile C# ^^;

Using Volume Test 3. Just dropped it in and started. Was using texture compressor, then moved away the DLL file. See error during flight for a plane launching from the runway: [LOG 03:10:24.875] Clouds: Creating particle [EXC 03:10:24.876] NullReferenceException: Object reference not set to an instance of an object is repeating itself multiple (thousands) of times in my KSP log output. No clouds appear. No loading errors without the texturecompressor. (note: there was some error (something like, particle already in cache) when loading with the TextureCompressor, but I forgot to log that down. my bad ^^ First time using this mod. it's so stunning i think i'll be enjoying flying a lot more now!

Ahoy KSP enthusiasts, I've been playing for a while now, finally decided to unlurk on the forum (I'll probably end up lurking the addon and releases board anyway). I'm mostly re-creating anime and movie spaceships, so I might post some of the works on the craft exchange Cyall around, Xrave

I noticed pretty much the same thing. Bigger wings just apply so much lift to the part they're attached to, so you should always use some structs to tie down the joints. There's a transparent struct in the B9 pack you could use.