selfish_meme

You could replace the bulk of the midsection fuselage with a fairing, I also think all the hump could be empty mk2 tanks.

They won't be such a burden in 1.1 because even though their movement needs to be calculated each part tree can be in a different thread, You could break this problem up into many threads, but once you dock and create one craft, and the part tree is recalculated that all must be in a single thread and then you lose performance. If however you could break the problem into three threads by keeping the part trees separate your performance would not suffer as much. You would not be able to say, tow a cart this way, the simulation would be too sloppy, I would suggest the connection severs if any large movement happens and then they are all separate again, otherwise you would have springy rope type behaviour.

That is not wrong, but it is also synthetic vs real world. I don't think it's a card issue, the log shows something going wrong, maybe it's the beta EVE, I have run SVE in the past without the FPS hit.

I think you are mistaken about my card http://gpuboss.com/gpus/GeForce-GTX-960-vs-GeForce-GTX-570

GTX 570, my normal in game FPS is 60 FPS with my anti-aliasing settings, EVE drops it by 5, scatterer by a further 12, but SVE drops it by 20 by itself, without scatterer. I imagine scatterrer should be more expensive to run?

I did it with a new install, module manager and stock bug fixes was the only things installed

I understand but you implied my reported bad FPS was because of the texture size.

I just did some testing on a new install with Just SVE UR and MR, no scatterer or Kopernicus installed Linux 64bit, OpenGL, nvidia no difference in FPS between the two packs, both at about 20FPS lower than without SVE at all, got rid of Kopernicus stuff and citylights, about 1 FPS better I didn't know what else to do so I looked at the log, interesting stuff there, I'll put it at the bottom. Stock EVE 1.05-4 only drops the framerate by about 5 FPS, if it was a texture size thing, which does not really seem reasonable, that's a load time issue, then the SVE MR pack should have a better FPS than the SVE UR pack, but it does not. Something is wrong in the settings. This might give you a clue, it does not happen with stock EVE [LOG 22:25:21.494] CloudsManager: Unable to parse config node: OBJECT { name = Kerbin-MainClouds body = Kerbin altitude = 4000 detailSpeed = 0,6,0 speed = 0,20,0 settings { _Color = 255,255,255,250 _DetailScale = 2 _DetailDist = 0.0000003 _DistFade = 0.0003 _DistFadeVert = 0.000008 _MainTex { value = StockVisualEnhancements/EVE/Atmosphere/Textures/kerbin1 } _DetailTex { value = StockVisualEnhancements/EVE/Atmosphere/Textures/DetailLow } } layer2D { shadowMaterial { _ShadowFactor = 0.60 } macroCloudMaterial { _DetailDist = 2E-06 _FalloffPow = 5 _FalloffScale = 10 _MinLight = 1 } } layerVolume { maxTranslation = 0,100,0 size = 4000,2 area = 20000,4 rotationSpeed = 0.0002 particleMaterial { _TopTex = StockVisualEnhancements/EVE/Atmosphere/Textures/particle/1 _LeftTex = StockVisualEnhancements/EVE/Atmosphere/Textures/particle/2 _FrontTex = StockVisualEnhancements/EVE/Atmosphere/Textures/particle/3 _LightScatter = 0.55 _MinLight = 0.5 _InvFade = 0.004 } } } [LOG 22:25:21.495] EVEManager: Issue loading CloudsManager! Error: UnityEngine.UnityException: Unable to apply node! ---> System.InvalidOperationException: Operation is not valid due to the current state of the object at System.Linq.Enumerable.Last[Light] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Last[Light] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0 at Atmosphere.Clouds2D.Reassign (Layer layer, UnityEngine.Transform parent, Single scale) [0x00000] in <filename unknown>:0 at Atmosphere.Clouds2D.set_Scaled (Boolean value) [0x00000] in <filename unknown>:0 at Atmosphere.Clouds2D.Apply (.CelestialBody celestialBody, UnityEngine.Transform scaledCelestialTransform, Atmosphere.CloudsMaterial cloudsMaterial, Single radius, Layer layer) [0x00000] in <filename unknown>:0 at Atmosphere.CloudsPQS.Apply (System.String body, Atmosphere.CloudsMaterial cloudsMaterial, Atmosphere.Clouds2D layer2D, Atmosphere.CloudsVolume layerVolume, Single altitude, Vector3d speed, Vector3d detailSpeed, Vector3 offset, Matrix4x4 rotationAxis, Boolean killBodyRotation) [0x00000] in <filename unknown>:0 at Atmosphere.CloudsObject.Apply () [0x00000] in <filename unknown>:0 at Atmosphere.CloudsManager.ApplyConfigNode (.ConfigNode node) [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Setup () [0x00000] in <filename unknown>:0 at EVEManager.GlobalEVEManager.Setup (Boolean late) [0x00000] in <filename unknown>:0 [LOG 22:25:21.495] AtmosphereManager: Loading... [LOG 22:25:21.495] AtmosphereManager: Cleaning Atmosphere!

The cluster is not made to be detachable and it also needs a small bay to have enough depth, but thats OK its a good place to put radiators and panels. Its an SSTA that gets to Kerbin orbit with 3200ms of dV, its on KerbalX, called the KSS Voyager its also VTOL capable on moons and rough terrain off Kerbin. Plus it can refuel itself. Only carries itself and 4 Kerbals though. i only just figured out how efficient the ramp is drag and weight wise, this won't work to anywhere near the efficiency without it.

aeroFXVelocityExponent = 3.5 aeroFXDensityExponent1 = 0.5 In physics.cfg, I think I chose 4.0 and 1.0 instead, I can't check ATM

That didn't take you long

There is a Fairing Texture Switcher mod, I've been using it bit lately, you could also use Texture Replacer I think.

If you do, let me know and I will add them to the download pack for people

No need to apologise you can do whatever you like, I might not advocate other people doing it though. What I would do is find the configs for the procedural parts and move them in to their own config file without the stock parts, then they would not conflict.

Yes, plus they come in ridiculously early, I actually adjusted them to come in much later, over Mach 4, so now if I have flames something is going to blow up soon

You probably don't have module manager installed, or you are trying to paint a part that has no config yet. It might work but you now have multiple configs for the same part and you might be overwriting masks that I have fixed. I reorganised it for a reason. YMMV.

Hehe Great minds and all I see what you mean about loading and unloading, I remember I had one solution where I put the port on the front and a port on the floor, I had a second set of legs on the rover that lifted it over the floor port, when it docked in front I would raise the legs and it would dock on the floor

This is true, but how well does it need to be simulated, maybe the docking joint could run it's own little thread and just pass values to the two other threads. It would probably be sloppy as heck and the joint would react slowly, but I would sacrifice this for having a great station and a nice craft docked for transfer in orbit.

hmmm it looks like the cargo bay and ramp nukes are pretty much solely responsible for this crafts good performance, building a beefier back end for landing on negates the huge resources in space of the current model, even a fairing is heavier and less slick than moving bay and ramp, go figure. I think the way forwards is to have a better ascent profile on Duna to preserve oxidiser. I am thinking the outermost 4 rapiers get disabled and the nukes turned on a lot earlier, say at 10-15km, theres not much atmosphere and we only need 800ms. I am still looking at improving the pitch speed to make tail to front landing easier.

I love the Thunderbirds, this is excellent

I would like to see a few of these mods or facsimiles of made stock KER (or at least a dV, TWR readout per planet, no planet and stage) Editor Extensions No Offset Limits RCS Build Aid Hullcam VDS Camera Tools VesselMover Some type of Transfer Window Planner that creates manoeuvre nodes My more unlikely wishlist Scatterer

That's just it though, currently it doesn't matter the more parts and vessels in physics range the worse your game runs because the physics thread is single threaded, in 1.1 it is going to be multi threaded, so each vessel will have its own thread. So having lots of ships in physics range won't lag the game like it currently does. However start docking those vessels together and you will be pushing it all into one thread again and the lag will start. I am just proposing some thought goes into a docking method that does not require actually creating one craft from two docked craft, and that they maintain there own separate physics thread.

It clips through because it is the same craft, you need to hold it with a strut which will disappear when you undock, and once undocked it won't clip through the floor

I have somehow made it look a whole lot tougher, plus added more oxidiser and 8 Kerbal passenger capacity, vertical landing orientation and faster pitching. May possibly be draggier