koksny

But it's not working with PF, someone need to fork it (or explain how to do it).

Exactly figured what's causing it to happen: When you use "Grab" function in KAS, you are actually decoupling one ship into two (What is left, and kerbal + detached part). To do it, KAS uses the same method that's used everywhere in game (like, in decouplers) - part.decouple(). It's part of code (function) wrote by Squad, and out of range of moders (You actualy can't modify it without KSP source code) that's likely to rely on some either function or variabe value that acts different in Unity 64 win player. And the suspect is (most probably) either convex mesh colliding into something or force vector being applied as negative, etc. So we pretty much know what's the problem, there is just so much you can do about it without looking directly into KSP code. And to add insult to injury, it seems that the issue sometimes, randomly doesn't appear (as, decouplers work in x64 around 5% time). It's something that really doesn't help while debugging without knowing exact source code of function. Tl;dr, we're looking at workaround involving not using decouple() function, or hotfix from Squad. This, or Majiir (or other moder) is coding god, and can fix it "somehow". Last option would be best, because it would actually make ProceduralFairings and stock decouplers possible to fix too.

It's more case of "If it's bug in Unity, abandon all hope until Unity 5", and not underestimating modders. There is really not much anyone except Squad can do if it's the case. All we can hope is for Majiir to get some workaround code, so he can split vessels without using decouple() function. Don't get me wrong, i reall wish to see KAS working in x64, it's just the case - if Squad can't do it, modders probably can't too (And no, dont bring multiplayer, multiplayer wasn't dependant on Unity team fixing their code). EDIT: Also there is possibility of turning off physisc collision on parts involved with KAS whatsover, but afaik (and i tried forking it myself) best you can do is make kerbal being swinged by force vector, instead of grabbed part.

Yeah, it's just message from compatibility checker, works fine in game. For everyone using now KAS, just play x64 until you need to run KAS utility and start x86. Better than nothing, before Unity/KSP patch.

Afaik, so far there was no reports of new bugs in 32bit (x86). So, yes, KAS for 0.23.5 works fine in 0.24 x86/32 bit.

So it looks more and more like issue with Unity Win x64 player, not the game. Doubting even more we will ever get a fix. Also, to people who demands x64 compatibility - for christ sake, just make yourself second GameData folder in KSP, slap there ActiveTextureManagment as addition to all other mods and in emergency situation that needs KAS - change the name of folder to GameData and run x86. I really, Really, REALLY doubt we will see this problem fixed any time soon. If it's some convex mesh collision detection borked under Unity... yeah, good luck, some of these bugs are still in Unity after years.

What is the point if grabbing doesn't work? Every part manipulation involving decoupling in x64 version will effect in best case swinging your kerbal hundreds meters away, worst case - explosion. At this point i wouldn't really mind just x86 compatible 0.24 release. Just slap big, red letters on front page "NOT WORKING WITH 64 BIT" and, well, done for now. Problem is, solving this kind of issue can take aswell all the time to 0.25. There is no point in holding back 0.24 KAS release if only for x86. I don't doubt in Majiir skills, i just think that if Squad wasn't able to squelch that bug before release, postponing mods release because of it doesn't make sense. But of course it would be great to get this issue solved, i'm pretty sure ProceduralFairings doesn't work now for same reasons. (not tested, but was the case in 0.23.5 x64)

I highly doubt any modder can solve issues showing up on x64/x86 differences, there is not much platform dependant stuff you can mess up on mod code. And tbh, i don't believe it's related to game itself, it can by Unity related problem for all we know. Either Squad is going to notice the issue and fix it (At some point), or we just have to get used to keep x86/x64 installation, and for few mods making problems - just start x86 to perform things like linking stuff with KAS. None the less, it's impossible for Majiir to fix problem with decouple() (or other physics calulations done behinde the scene, ftr) itself. Looks like KAS for x64 isn't going to happen in 0.24.

You can use old build, it pretty much works, except it doesn't in x64 player (Same problems as in 0.23.5 x64 hack, grabbing doesnt work, things explode on decoupling, etc).

No, that's the Release Candidate. Scratchpad - "QA Builds and Staging Area". First it's on experimental (dev), now it's QA.

Dont quote me on this, but as far as i know - this is bug related to Unity 4.3.3, fixed in Unity 4.5, not with Kerbal itself, so it's probably "fixed" already. Although, would be nice to get confirm from Squad (Or at least word that they know about this bug).

No, they do not, try setting up very simple test craft with probe core, decoupler and small part connected to decoupler. After decoupling (via staging or manually) there will be force applied but with wrong force vector, resulting with (depending on vessel) either explosion or no visible force applied. Whole decouple() function is atm glitched in x64, working maybe 5% times (And rendering mods like PF or KAS pretty much unusable). If they would there wouldn't be few pages of this thread looking for decouple() hotfix.

Because decouplers dont work in x64.

Ok, can trash all that manual-clicking theory. Just got proper decoupling under staging. It's random.

As default, 3m decoupler has PhysicsSignificance = FULL, that might have tainted your results, right clicking doesn't work then.

I have been working on the decouple force in x64 version for quite few days, here are my conclusions for now: Issue is related to decouple() function itself. There doesn't seem to be any clear way of debugging it, but i have checked values on input on both x64 and x86 - to no success. And i disagree with statement that's issue with force - i'm pretty sure force is calculated correctly, what's wrong is force vector. I found the issue while playing with KAS. It uses decouple() function on grabbing things. While force (and amount) seem to be applied correctly, the vector is wrong, resulting in smashing things up. Resulting in decoupling having no force (because direction of this force is null or negative). Could you please elaborate on that? I have tried to get any sort of workaround with PhysicsSignificance but to no avail, it doesn't seem to make any difference. The reason why it's not working in ProceduralFairings might be because the PhysicsSignificance = NONE/FULL is hardcoded into mod dll. For anyone also cracking on this problem, there are two links that might me related to the issue: http://bugs.kerbalspaceprogram.com/issues/2412 http://forum.unity3d.com/threads/hybridobbcollider-crash-issue-in-x64-standalone-player.224486/ Any help on topic would be greatly appreciated, especially if anyone knows what is inside decouple() and how to modify it. EDIT: There is brilliant finding few pages back: With PhysicsSignificance = NONE and manually clicking the decouple action from RMB menu - it works. There is different method/function being called when manually activating decoupler from RMB menu. Where's the difference? This thing may be the key to hotfix. EDIT2: Triggering decoupling from Action Group also works. EDIT3: Can confirm earlier testings, it doesn't work 100% times, still better than staged decoupling. EDIT4: Nope, it's all totatlly random, can decouple with staging too. Sometimes.

Unfortunately i have no clue how to get to decouple() code. What i did was painfull debugging of variables being used (in KAS an ProceduralFairings) before calling decouple(), hoping to catch any difference, but to no success. And since i believe decouple() is part of CSharp Assembly, i dont really know how to proceed. Dump the bytecode from memory? It makes reverse engineering this code almost nonsense - we will probably get 0.24 before it's done. Also there is possibility it's bug related to Unity 4.3 ( http://forum.unity3d.com/threads/hybridobbcollider-crash-issue-in-x64-standalone-player.224486/ ), fixed in Unity 4.5. Can't check it for obvious reasons.

First and foremost, i dont think there is problem with PF/KAS or any other mod. I thought this is the case before discovering general decouple() incompatibility. And that's clearly on the Squad side to fix. But. What i'm looking into is making some kind of hotfix for it. A mod for the "64-bit-KSP-that-is-totally-not-a-hack" that would deal with the issue before Squad does (Like, most of the mods do already in other fields), since i'm not only one using 64 bit "hack". By no means i'm expecting mod authors to do anything - just hoping to get other people with same problem look here and maybe get some workaround ideas. I just don't want to wait passively until Squad or someone else fixes it (If ever at all), and since i don't see other people working on it, i'm desperate enough to try working on fix myself hoping it will help other 64 bit users. Is there any way to debug closer what's happening there? Or just straight code some decouple() replacement? Or is it just out of reach without changing source code itself?

But neither files are being modified to run 64bit player, i wasn't really speaking about libs needed to compile solution or run the game, but sure, you are right - that lib actualy contains game code, my bad, have overlooked it since every Unity game contains it too. Point stands - no "hacking" involved, and no code is being tampered to address 64bit. And as i said, i'm not expecting any modder to support 64bit (hell, i dont expect them to support even x86, these are mods after all), just hoping for someone also using x64 player and mods with decoupling incompatibility to maybe stumble upon this thread and help with forking hotfix.

To be honest there is no KSP code in any dll. File you are talking about is 64 bit Mono library (the only actual dll being replaced), and afaik, Mono is already pretty much platform independent, with 64 bit lib just allowing to address all memory, but function and codewise - it's same lib. I believe right now you can get any Unity player game (like, i dont know, Blizzards Hearthstone for example), copy Hearthstone.exe, change the name of Hearthstone.exe to KSP.exe (so player will know where to look for assets and actual data, since KSP_Data folder could be also just renamed to Hearthstone_Data without changing .exe name) and there you have fully working KSP. Since the version that unified part modules, all game data and assets are being kept in, well, KSP_Data folder. Only "real KSP" data in KSP (duh) is contained in level, mainData and .assets files, and also in GameData files (for parts and plugins). And all the dll libraries contained in Managed are universal, not bound in any specific way to KSP only. So, just as i said before - making a 64 bit "hack" would require some asset repacking and modification, or bytecode injection via some memory managing software (Like game "trainers", or other soft directly overriding memory). That's not the case. It's really like getting HTML5 game working on 64 bit browser, and that is the reason why it works so well so far.

Just to prove a point - it does not. Executable itself is a player, there is no "32 bit ksp executable", you can replace it with any Unity player. And the only DLL involved is 64 bit Mono. Any sort of hack would require modification of game files, this method doesn't. And it is, kind of, intended. The fact that it works on Windows is probably leftover from the nix versions. But as i said, i'm not a dev so i can't prove here anything, but in same time i'm fairly confident there are ways to override API functions. Maybe there is possible some rough replacement for decoupling code, maybe it is case of some simple modificiations, one way or the other, i'm at least hoping for someone smarter than me to try cracking the problem before calling it unadressable (if thats a word). I mean, come on, i'm not calling for multiplayer or fluid dynamics, it's case of some slight model hitbox collision miscalculation. It's probably some position value getting wild with precision, and it's the only thing standing between me, and thousands parts stations working without crashes and with decent fps. There just has to be way.

It's kind of misleading imo to call 64 bit Unity player a "hack", you probably wouldn't call a 64 bit web browser a "hack". Besides, fact is that except this one case there are no incompatibilities between 64/86, in wide variety of mods (Like highly physics/math precision dependent FAR/IR) If there is in fact some dependency in code that relies on floating point, 64/86 integer precision, it's not like it is not causing problems already. As you can see on bugtracker, there are in fact some stack overflows problems with decouplers right now, leading to game crashing on Mac/Nix (with exception handler keeping it from crashing on Win). So even if it's "not supported hack", i believe it can at least be used as feedback to backtrack x86 problems. And really, playing the game on 64 bit player is just so much smoother and faster that i'm not going to give up so much FPS performance just to get back into x86 texture-reduction-mods hell. And i hope modding community will soon help with supporting "unofficial" x64 player, just as now there are modders modding "unofficial" mods. I literally believe it's just case of waiting before everyone using mods like KW/B9 will get into x64, because it's just so good. (And the "hack" is really pasting two files. Truly a hack.) Also i'm not coming here just expecting to get a fix - it's in fact a matter of 2 days looking in code for this little pesky bug. And i'm not a dev at all. Just hoping that with this knowledge someone with experience in C# can at least find an ugly hotfix. Or at least tell me where to look for code of decouple()/ModuleDecoupler.

Right now ProceduralFairings mod is not behaving correct in KSP 64 bit. There is some difference in how .decouple() function is being handled between 64 and 32 bit client, resulting in force on fairings not being applied correctly (looks like force just doesn't have correct direction applied, instead it just explodes in attachment node point). It all results in fairings being just detached from ship, but either no force is applied, or it's applied to vessel instead, changing torque/power in VAB does not impacts decoupling behaviour. Any chance for some fix? Or way of generally fixing problem with .decouple() in 64? Exactly same problem renders Kerbal Attachment System unusable atm. EDIT: Can it be related to http://bugs.kerbalspaceprogram.com/issues/2412 ?

After quite long debugging i have found out the issue causing incompatibility with 64 bit version, and explosions/big velocities on grabbing part with KAS. And in fact Majiir was totally correct, the issue is not related to KAS code in any way. There seems to be difference in how .decouple() works in 64/86. Basically, it looks like in 64 the direction vector of force after decoupling is null (or some other wonky number), following with force being applied to both parts in attachment node point. Following with explosion because of collisions. Most important fact is - same problem shows up, for example, in ProceduralFairings, because of also using the .decouple() function. So now the question is - can we modify the .decouple()? Replace it with some custom function? Or is it just so deep in Unity we are screwed? EDIT: Can it be related to http://bugs.kerbalspaceprogram.com/issues/2412 ?

So after some testing, i can further confirm that problem is only related to event handling decoupling part from original vessel and attaching it to Kerbal. When part is grabbed, a lot of force is being applied to vessel itself, what leads to structural failure between Kerbal and part connected to him. Also its worth noting that the part is not being attached to Kerbal correctly - it's state is set as grabbed, but it's just treated as new vessel (debris). After "ungrabbing" it and grabbing again (not from vessel but from ground) no problem shows up and everything works. So there is either different method in code for grabbing stuff from ground/vessel, or it's just case of collision boxes being miscalculated (What leads to no problem when grabbing stuff from ground). I did logged same situation on both 86 and 64 clients, but it's really not adding much, just the difference with Structural Failure being logged in 64 version. I have also succesfully achieved modyfing the code to the point where after grabbing force is being applied to Kerbal, not into vessel. It obviously cuts off explosion, but slinging someone in orbit is also a bit counterproductive. Any hints? I believe it's possible to backtrack the problem with more log messages injected into code, but maybe someone with more experience have some brilliant idea before i will start painfully spawning DebugError in every function related to EVA?