Search the Community

So I'm very Laggy in KSP and I wanna fix it I heard a way on Youtube, and it said using unity 5.. when I checked it, I wasn't able to find a version for the on final approach which is KSP 1.12.3... any ideas? thoughts? links? discussions?

So after looking through the archives here and finding next to no discussion of the changes that Unity 5 KSP 1.1 caused I thought I would create this thread. First change. The form factor radii appear to all have changed, F0 = 0.25, F1 = 0.5, F2 = 1, F3 = 1.5 Second change. How you import your part tools has changed. Note: like with PT 0.23 I simply created an empty template with part tools and copy it for each new part. Third change of course we are using part tools 11-2 Forth change is there are a whole bunch of new assets that I'm not to sure how to use. Before installing the New Unity I tried to mod an old part with my old Unity today and it gave me a version warning, not sure why, so now I am unable access my old project.

Ok so I'm a bit new to the whole modding thing with the new unity 5 engine and I need a bit of help. I'm having a few issues with the texture of my part, it's normal/bump/depth map thingy and how the game won't highlight the part in the editor and in flight. Here is a rundown of how I created the part. I created the original model in google sketchup, exported the dae file into Blender, exported the Blender dae and uv map, put the dae and part tools into unity, opened the uv map in photoshop, created both the texture and normal map and put them into unity, created new game object and made the model a child of it, then placed the textures into their proper slots, i kept the normal map png as a texture with alpha as transparency because otherwise the (limited as is) bumps would not appear on the model, exported the part into the game and this is the result while the model appears blank in the unity editor, the detail is all on the inside faces (material_0), although it shows in the game with the detail on the outside (refer to above gallery) but i can't find any distortions, weird eh? I am using these versions of the programs: Google Sketchup: 15.3.329, Blender: 2.76, Unity: 5.3.5f1 personal, KSP: 1.1.2.1260 Can someone help me with this? Should I rebuild the model and try making the part again? Do I need to provide anymore information?

So, I've been dealing with an instant crash issue in KSP, as reported here: http://forum.kerbalspaceprogram.com/index.php?/topic/137661-110-crashes-instantly-on-load-osx-edition/#comment-2529501 In my journey for an answer (nothing's worked yet), I came across this: http://forum.unity3d.com/threads/our-game-no-longer-runs-on-mac-osx.395699/ Very recent thread, only started 20 days ago. The error described there is exactly the error I'm getting. Apparently there's some kind of conflict with Unity 5 and OS X and, in my situation, OSX, and other Unix-based machines. The former I can confirm firsthand, the latter is more anecdotally. Unfortunately, the fix appears to be squarely in the dev side of things. I haven't found any way to do this on the user end (and I've been working at this for the last three days, there's no easy solution to it). I know this isn't technically the right place to bring this up, but I hope this gets some visibility on behalf of non-forum users that might be having the same problem/for those that might have a fix for the problem.

never mind

All right, so many of us have watched the 2015/3/24 Squadcast and seen what the current state of the game is re: multithreaded PhysX. As is known, Unity 5's PhysX 3 implementation allows for multiple physics threads. The discussions happening on this board for the past several months have been about whether there was a possibility that single vessels could be spread across threads, and the general consensus was that no, they could not. The squadcast pretty much confirmed this; single vessels are indeed individual threads, and new threads are spawned when vessels undergo separation in the flight scene. It also showed a major problem with this: complete game freeze while the (new) threads are prepared. On KasperVld's not-junk gaming laptop a 650-ish vessel was split into a rocket and launch tower, and took 45 seconds to prepare and spawn the new threads. Another significant freeze of 15 seconds was also encountered on booster separation. Further staging events (what I would call "reasonable" part counts) showed no noticeable freezes. Now, the vessel being shown is pretty excessive, and Kasp is on a laptop. But his laptop is a powerful gaming laptop, and even small freezes during gameplay are quite immersion-breaking. Especially on less-powerful older systems that many of us may have. So - we who are not the developers, how do we think they should approach fixing this, and how can they? I have three different thoughts on the matter, but I'm not really knowledgeable about multithreading, or about Unity/PhysX thread handling in particular. But here goes: Code cleanup. Don't worry guys, it'll get better. Just wait. It could be simply that the current state is running in a non-optimized manner for pre-release, and small things will be done to speed up this simulation step. I don't have high hopes for this, at least for the 1.1 release; after all, they've been workng on the Unity 5 port for nearly a year, and I'd expect low-hanging fruit to be picked by now. But one can always hope. Delay thread splitting. I'm sorry PhysX, I'm kinda busy right now. Vessels are running just fine on a single thread prior to a staging event, and from experience, we know that KSP vessels run just fine on a single thread after staging events, too. It may be possible to prevent PhysX from splitting the objects into separate threads immediately and wait until we have more time to let it happen. Figuring out when that good time is, however, is another problem. But once vessels are in space and no longer thrusting or under atmospheric forces things are much less time-sensitive and we can better afford to be inconvenienced by this. Pre-stage threads for separated vessels. I can see the future. Trust me. The problem with trying to split a single vessel across threads is that information has to be shared in two directions between threads, which is slow and cumbersome. Also, if a vessel can break up in an arbitrary manner, there is no way to predict the best way to split the parts up. However, we have an ace up our sleeve here - the staging list is well-defined. We know which parts will go to which threads beforehand. It may be possible to prepare these threads while the stage prior is active, and only have to copy the state of the appropriate part nodes to them rather than having to stop and wait while the new threads are created from scratch. We don't need to worry about two-way communication for this; the child threads are strictly slaves to the previous stage thread. Ideally we only have to do this for the next staging event if these threads can be created in the background. Now, as I stated before, I know very little about multithreading besides what's been discussed on this forum, and next to nothing about PhysX, so what I'm suggesting may be completely impossible. It's also possible that some of this is already happening and the process is just that slow. But I'd sure like to hear the thoughts of those of you more knowledgeable than me! Because while the vessels I saw in the Squadcast are excessively large and complex, the freezes are a little scary. And if there's anything that can be done to mitigate that, even if it's a little more processor intensive, it would make me very happy. TL;DR: Staging can freeze the game. Can it be fixed? I'd rather have a slowdown than a freeze.

Just a thought, since the added thermal physics has increased the overhead on the cpu. It is known the physics tree for joints cannot be split into separate threads in Unity 5, but thermal physics does not effect joint strength in ksp, except when a part blows up. Therefore in theory it should be able to run thermal physics on a separate thread, increasing the use of multiple cores, post version 1.1. Discussion please.