koksny

RemoteTech DOES work with CactEye (as default) slim probe, there is however mistake in config: If author can fix the MODUKE into MODULE (K lettter instead of L, if You still cant see it), and add the missing MODULE[ModuleSPU] dozens of posts about incompatibility with RT should be gone.

OpenGL doesn't render any shadows and has much less memory footprint (around 1,5GB in full res) DX11 is just better performing default renderer, but ATM will still not help due to DDS textures Also in case of OpenGL, remember to set up your AntiAliasing forced from driver software (Build in setting doesnt work with OpenGL), and disable crew in VAB/SPH, for some reason (probably due to problem with shadows rendering) they tend to lag really much. Up to 20-30fps more without them. Seriously speaking the game is now unplayable under DirectX without reducing texture quality, i'm astonished everyone is ignoring the memory issues. Memory leak when showing temperature indicators, memory leaks when changing scenes, basically any craft over 300 parts leads straight up to CTD.

In meanwhile you can play Kerbal with "-force-opengl", it still works (albeit without shadows). Stock with ATM runs at around 1,5GB ram.

Unfortunately it does not, it just prevents crashing (while disabling in-game shadows).

It's also worth mentioning that the 4GB ram-limit problem might origin from things like shaders. I don't know did anybody else noticed, but - Linux x64 is rock solid, even on same Unity build. What is the difference? Well, for starters Linux players are using OpenGL KSP version. And guess what - i have yet to crash in OpenGL KSP 0.24 (Win x64). Maybe the problem is in DirectX (or some dx shader) implementation? Or is it just the fact that OpenGL does not produce shadows under Windows therfor giving more ram (vram?) for in-game usage? So, did anyone crashed under Win x64 while playing with OpenGL? Is it the origin of problems? Is it enough of workaround for most of x64 crashes? (Also is there any way to get shadows working under OpenGL?)

Fine, i agree that just looked very messy (when i was writing that post there was only narration of one side available, with "Blocked SSL certificate" story, etc...) and unprofessional, but point pretty much stands, without any mirror it just asks for whatever-they-might-be problems to happen and FASA is just totally unobtainable. And don't get me wrong, i'm all for open-source, clarity, etc. but i still believe GitHub uptime is much more likely to be higher than community driven, non-profit niche site. So, yeah, i don't ask anyone to sell his soul and unborn children to Curse, it would be just nice to havy any other source of this mod. Like, you know, every other mod has.

Well as we saw today, everything Kerbalstuff needs to get down is lack of consensus between two people, besides, one mirror is always fine idea, even when there are just technical and not ideological difficulties.

Can we get a mirror of FASA/Launch Towers on some real site, like Curse/Dropbox/Github?

I'm getting exceptions making game sometimes crash/lag/dissappear HUD after staging one craft into two vessels, both with RT processors. Is it known bug? It seems like it's similar case to vessel duplication bug, except it doesn't duplicate craft now, just throws a lot of exceptions in log. Bug reproduction is same as to vessel duplication in last version (before 0.24 support)

Well it works now fine with DRE, the "Compute Mesh Inertia" message seems harmless and it just indicates you still have somewhere in the model file a collider without depth. Maybe it's because your models are hollow? No idea.

Can confirm, everything works fine with DRE, great work, so much appreciated. One minor issue - Dragon V2 still spams "[Error]: Actor::updateMassFromShapes: Compute mesh inertia tensor failed for one of the actor's mesh shapes! Please change mesh geometry or supply a tensor manually!" in log while in VAB. It's not problematic, but it happens. You should probably deal with it somehow before 0.25 release.

As i wrote page earlier, config for DRE is not enough - part has no working physical collider (the mesh error in log), resulting in burning parts attached to capsule (like docking port and nose cone for example). We need to wait until Laz makes it compatible with DRE, no way around it. It does, however, works nicely with FAR (since FAR calculates shape itself).

http://answers.unity3d.com/questions/14497/actorupdatemassfromshape-error.html From what i understand collider now is a planar object, instead of, for example, cube/cylinder. And since you are probably using right now some shape similiar to model (and not plane), i guess some setting in Unity is off the mark? EDIT: Ah, and also this: http://forum.unity3d.com/threads/compute-mesh-inertia-tensor-failed.47271/ You can't use mesh as collider for rigid objects (and i guess parts in KSP are rigid). So it must be some primitive instead. I guess thats the problem, you are using just simplified geometry mesh as collider? EDIT2: And if i'm at this - could you include config files for TAC/DRE compatibility? And for TAC so it supports 7 crew pods.

Are you going to make Dragon v2 compatible with Deadly Reentry any time soon? Right now it's possible to include heat shield module by config editing, but parts attached to the top of Dragon v2 (so docking port and nosecone) explode on reentry because (most likely) of issue with model collision convex-mesh. If i understand correctly it's also reason for your Dragon V2 sinking underground if not landed properly, so it would also kind of help non-DRE users.

What if mesh creator is offline from quite some time, can i fix it somehow myself? For example by editing the mu file in some 3ds max? I'm quite experienced in 3d modelling, just never touched Unity files. Is it some case of just including in .mu file a second, simpler dummy-helper model for physisc calculations? (Or just something like deflector?) The error from log: And also it shows in VAB, not in flight. Related? EDIT: So it looks like Laztek used open mesh collider instead of convex mesh collider. Any quick how-to change it? Or link to related tutorial/wiki? EDIT2: After lil reasearch i found that .mu files are compiled. Well, so much of Dragon capsule for DRE users.

Could anyone help me with working out some fix for Laztek Dragon v2 pod? It works fine with heatshield module added in config, however, part attached to top of the command pod (decoupler, nose cone) just heats and explodes on reentry no matter what, like it's not shielded at all. I guess it's because the pod is hollow inside. Is it possible to fix it by some config edition, or should i change the model somehow? Also there is a lot of convex-mesh issues in log, if i remember correctly. Help?

I'm having now exact problem to the point of not using the trunk anymore - could you share changed code? Or just describe what's happening there?

Works like charm, amazing fix, thank you very much. Now could you go to Blizzard HQ and fix their servers so Naxx will work? Seriously tho - great work for upkeeping this mod and doing it so fast.

We should basically dedicate 0.24 to you and Sarbian for fixing 64bit physics, insane. Thank you so much, going to test it asap.

Really happy to hear it, you guys are doing what Squad should, fighting with bugs that shouldn't be there since last version in first place. Kudos to you.

I'll be happy to provide you with any additonal information you would need. Although, there is nothing unusual in logs, so can't really be more specific. I'll double check on Kerbin to exclude possible new mod incompatibility, but i really doubt it, it just looks like the violence of decoupling/grabing rises with distance from Kerbin. Also didn't had any problems with containers, grabing, etc on Kerbin itself/orbit. Little fact, it looks like when grabing some parts the part shows on Kerbal, gets back to ship, and hits Kerbal again. And Kerbal goes "poof", after the impact, sort of. EDIT: Yup, everything fine on launchpad while grabbing solar panels, and everything goes full kraken in Minmus orbit while grabbing same panels.

I can confirm, last fix from JeffersonFlight (on page 168, but version before too) seems to be little bit glitched when using Grab in places other than Kerbin/Kerbin orbit. Trying to grab any part on Minmus orbit results in explosion/crash/swinging Kerbal far away (works fine otherwise). Any help? Some force value tuning? Or is it just floating point and precision issue? Problem obviously under x64.

You are right, strange, i was almost sure clamps worked fine in x64. I will test it without this fix again.

Can we get exception for Stability Enhancers in next hotfix patch to MM config? Or can someone tell me how to do exception in config file (Do i have to use some "!", etc?). Because right now in v0.2 using engines and stability enhancers in same stage doesn't work.

No, it does not. We need to fork Fixed Decoupler into this: I have tried adding a loop with frame count, but it didn't work. Any help from some actual coder? EDIT: Also atm using Fixed Decoupler messes with launch stability enhancers, might be good idea to make exception to them.