NoMrBond

We need to keep in mind that as impressive as the Gangbeasts demo is, it isn't really representative for KSP because even with PhysX 3.3 while each collection (joined bodies) can have its own thread, a single collection still can't have multiple threads so 4 bodies of 150 parts each will perform a lot better than a single body with 600 parts. That's not to say the PhysX 2.8.4 to 3.3 upgrade that's occurring from Unity 4 to 5 won't offer benefits from the threading (a ship next to a station, or a rover next to a base could each have independent threads for example) and from moving from x87 only to also supporting SIMD acceleration (plus the new MTJS in Unity 5 itself). The drop mesh and hinge bridge examples from Pierre Terdiman's blog seem the closest in terms for representing what KSP will be doing with the physics system.

As Motokid600 says though, upgrading the underlying engine to Unity 5 could take a considerable amount of time (or not) Given HarvesteR's prior post on what they ran into when upgrading KSP from Unity 3 to 4 though, we can hope for smooth sailing but we should not expect it.

That migrated versions of KSP on U5 would max out any computer they tried to run it on, and it would crash in short order.

It's happening [Edit] By which I mean Unity 5 has out the wingwong

I would have thought you could do this via the control panel but I had a look on my wifes computer and there isn't a disable option (only force 2-16) Maybe it's controlled by the ingame render quality slider in the graphics panel, I think someone said setting this to 'fastest' worked?

Sounds like the OpenGL issue for which the solution (for most people) has been to completely disable anisotropic filtering for KSP

Nothing I've seen as yet, still working through the changes myself It may be as simple as adding and additional argument to their MODULE{name = ModuleEnginesFX ... } in the config EngineType = LiquidFuel to anything LANTR (i.e. using LF/O) and EngineType = Nuclear to anything NTR (LF only) Not something I can check right now unfortunately

You can also set up an Empty Game Object (EGO) in your model then called the EGO in your config using the NODE{} system, the node will be oriented in the EGO's Z+ direction

Unfortunately working out the new thrust values is a lot more faffing about than flipping the sign for the Y stack vector :\

Changing the sign on the 5th number on the node_stack_bottom line should fix it (it will probably need to be made negative)

I think it was for assembling SRB's, so you could dunk a 'fuel plug' extension directly on top of an SRB and it would give it more fuel (i.e. SRB extenders which only worked when stacked)

That part is in progress, there were a lot of changes for 1.0 so I'm afraid I don't have an ETA right now MOARdv has also released updated versions of the URMP and EE plugins for 1.0.x.

That's glorious Did you have any luck with fixing the camera in regards to replacing the stock water, or has that remained stubbornly jump up and flood the worldish? Best of luck with settling into your new job in any case, do you have a paypal or patreon etc for donations and such?

First run through where it's compressing the textures is a lot of work If using 100% is running your CPU up to 100'C though that sounds like your cooling isn't right, also the i7 should throttle itself before hitting 80'C

What happens if you manually edit your settings into the two configs in the PlanetShine\Config\ directory?

I get the feeling it is more like; Behaviour is unexpected > tune existing simulation params to approximate desired solution > start coding simulation changes/extensions required to correctly implement solution So what we're seeing is the best interim approximation of the intended solution possible until the necessary code is in place to offer the desired solution

That looks exactly like what I was getting back on page 33 with OpenGL Nothing I tried got rid of the blue/black/pink lines or pink boxes for me unfortuantely, but Blackrack did make a few suggestions regarding the issue though which may work for you

DX11+ATM are basically my minimums to make the game not out-of-memory crash during load/scene given the CPU mirroring bugs in Unity's DX9 implementation OpenGL + ATM saves way more memory but OpenGL is unpredictable both visually and performance wise Another option is L.O.D., but the last fork/release I can find is SpaceTigers v3.5 fork for 0.90, which people are stating crashes with 1.0 because it was never designed to handle the now stock DDS textures, and also isn't compatible with TR

I'm using Scatterer 0.014 with ATM v5 and I haven't seen any trouble there, what problems are you experiencing?

Enough time to investigate the rings I was seeing under DX11 Not sure why, but the sizes (mesh/layer depth?) must be very slightly different DX9 vs DX11, setting the atmosphereGlobalScale variable in the settings to 999 fixes it.

Let us know if there is any donkeywork which we can free you from to enable this work

At a guess, don't fuel feed into the centre stack so it remains full, it should be significantly depleted at LRB separation? Sorry if this isn't what's happening, just trying to think of why TWR drops out after LRB sep and it sounds like too much sustainer fuel remaining

Remember to state what license you're distributing under in your opening post too, I'm assuming same GNU GPL?

In blender rotate your part x = 90, apply rotation (rotation x/y/z: should all become zero), then rotate part x = -90, part should then appear with the same orientation in game as it does in blender Basically you always want rotation x = -90 for the root part of your hierarchy for going into .blend > Unity > Export to KSP

0.90 was on 4.5.5, I haven't checked what Unity version 1.0 shipped on, it could be 4.6.4? The ksp.exe has the Unity version embedded in it though, just right-click>properties and look at the version number in the details tab