Tsuki

Ok I think I found the source of my problems i was using "-force-d3d11-no-singlethreaded". Without it it seems to be working fine. Or at least I was not able to reproduce it again in 2 tries. However while trying to get a clean log of this problem, I stumbled on another problem, I built something, than when I wanted to move the stake I accidentaly droped it and it exploded, I placed another stake and at that point the UI gliched and log started to spam errors. Here is the ksp.log and output_log: logs EDIT: managed to reproduce the problem with finalize build and sinking into the ground: logs EDIT2: with some more investigation, I found I can reliably reproduce the first problem (and avoid it). Whenever I enter VAB and than go back to vessel the error will show up, but if I go to the vessel directly after starting KSP it will work ok. So if I want to play normally I have to restart KSP each time I use VAB. So my gues is it is not EL fault, but something else, I will investigate more (try to remove some other mods).

This are the two NREs i get when I create the vessel. Any ideas? EXC 06:58:38.757] NullReferenceException UnityEngine.Transform.TransformDirection (Vector3 direction) ActiveJoint.getControlOrt (Vector3 refAxis, PartSpaceMode mode) ActiveJoint.applyCoordsUpdate () ActiveJoint.onPartPack (.Part p) EventData`1[Part].Fire (.Part data) Part.Pack () Vessel.GoOnRails () FlightGlobals.setActiveVessel (.Vessel v, Boolean force) FlightGlobals.SetActiveVessel (.Vessel v) ShipConstruction.AssembleForLaunch (.ShipConstruct ship, System.String landedAt, System.String flagURL, .Game sceneState, .VesselCrewManifest crewManifest) ExLP.ExBuildControl.BuildAndLaunchCraft () ExLP.ExBuildWindow.FinalizeButton () ExLP.ExBuildWindow.WindowGUI (Int32 windowID) UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [LOG 06:58:38.775] Tac.LifeSupportModule[FFDB329C][2721.17]: OnStart: PreLaunch, Landed [EXC 06:58:38.776] NullReferenceException: Object reference not set to an instance of an object ExLP.ExWorkshop.Update () and is it related to vessel spawining inside the ground? And another problem, after building the base the GUI does not uptade and the button "Finalize build" remains there so there is no way form me starting an new one and I can keep placing the built vessel

I got an exploding issue. When i try to finalize the build (using stakes) it places the thing correctly, but after few moments it teleports below ground and explodes. Any ideas? And yes it looks like there are some NPEs

Would you be so kind to maybe provide your servo script? I did some kOS programming long ago, and I really want to start fiddle with the kOS+IR and an example of the a servo scrip would help greatly.

Yap I did that, but a different texture would be nice and I suck at this So an officiall kas container would be nice

Would it be possible to make KAS containers "storable" on the rover? science crates are all good and fine, but having a kas container on a field assembled rover would be awesome.

Question about aerodynamic failures, I like the feature however how do i go about to make wings more robust? Struts do not seam to help much, and i cannot pull much more than few Gs, i mean some RL planes can pull way more than 10Gs before breaking.

Did i read right on the last update... about FARAPI!? now I really might try to implement that glide slope prediction..... Time to start learning more about the math of aerodynamics, @ferram4 got any good starting point literature?

Or hide the whole lander inside the fairing like they did it RL:

I know it was discussed before but it sill one of my biggest problems with FAR is spot landing. I did get fairly good results with practicing and repeating specific reentry procedures and I find it very satisfactory to land un-powered craft on the landing strip by only doing one single reentry burn in orbit. But... it would be great to have some computational assist I did some thinking (however I am very inexperienced in the actual math involved) and wouldn't it be possible to calculate a landing spot/elipse using current AoA and the crafts drag/lift coefficients, reentry angle and speed. The calculation should update often, to display the landing location as it would be if all those variables stayed the same as they were at the moment of the calculation. It would help a great deal in knowing how are your inputs changing the spot of landing. Maybe such calculations are to expensive to do every frame, but maybe a lower update cycle would provide just enough time to calculate it and still being useful. EDIT: for more clearance, what i am suggesting is some kind of: where will an unrpowered glider land if it keeps the current AoA if it is less than stall AoA. for angles above stall aoa, we could consider it an invalid solution, or just simplify the prediction to use some kind of average drag the craft is producing at the moment. So some kind of glide slope indication.

not for me

Proot please fix the download link, as its broken atm.

Yeah mega link seems dead, would anyone be so kind to provide a mirror?

Suggestion: a way to implement an UDP listner, so it will be possible to send commands to kOS from outside. (or enlighten me please if there is a workaround to achieve the same, like reading external files ormsth) I am asking this to be able to write a custom/extended control scheme independent from the KSP one. So i am able to implement flybywire, complex commands executed by a press of a switch/key, etc. EDIT: i noticed a plugin can register custom function calls with kOS so i might go and do such extension myself.

Altho i might install the rescaled kerbin in near future, it would be nice to have just rescaled heat shock wave(or does the heatMultiplier already do that?), as the whole kerbin rescaled means also bigger lifters, which atm I am not really comfortable with (ksp does not handle them well). I know I can make it manageable with some other mods but since this is a separate mod, it would be nice to be able to tweak that.

The thing is that in .22 I never used any heatshield and when I unlocked the lander can( which should not be capable to withstand reentry), I only used that and never had any problem with heat, and IMO that should not be possible. and yea I know i could increase heatMultiplier, any advice about a good number. Hack i even did some scary aerobraking, coming into(engines first) high atmo at 4km/s it was all bright and fiery but no part got destroyed and i am quite sure that there were parts exposed to heat beside the engines. And yes i am sure my DRE installation is actually working, as if i do a totally absurd reentry everything still goes boom not only from g forces but heat also

John FX and AngelLestat it seems our point of disagreement seems to be in where the primary focus of increased performance should be. My main argument is based on the fact that launch vehicles as it is now do not need major performance boost, because you can get stuff into orbit fairly easy. Lifters are usually quite simple in part count (no need for any the small gizmos like rcs, lader, lights etc not counting struts as this is another KSP silliness and there's no a great mod to decrease them) , and even if it lags a bit, you lose the biggest part of the lifter in less than a minute never to be seen again. Also if you are not planing to construct stations/bases with the payloads you are lifting, but just fly anywhere around kerbol system, you can in fact design very compact and streamlined vehicles with small part count. Unless you are trying to design a craft based on how it looks and not usability... but than people will always find designs that bring the game to a crawl no matter how good the performance it is. And you can still go for mods if you are on for the looks. Now... what I think it should be fixed is the ability for us to build stations and bases, as we got docking ports, and were promised planetary resources, so the incentive to build such structures is getting bigger and bigger. And unless you go into a silly amount of streamlining the station/bases (ex: fueling station is a free floating uncontrollable bunch of docked orange tanks with one spare dock ormsth) you will be stuck with yellow or red time counters every time. And the only correct way I see to improve our ability to build stations or bases is to improve performance based on how many parts can run smoothly (preferably scaled with computer performances). And the only "band aid" solution would be part welding or multifunctional parts, which i think we all agree is not something we want. Oh and accidentally, if they increase the part count performance, they also increase our ability to build lifters with more parts, so everything is better. EDIT: Also repeating myself: major part count performance increase will not be achieved by simple code optimization tweaks, but they need to make some quite fundamental changes, that is why they should be done as soon as possible, because the more features they add on top of the faulty physics engine, the harder will be to replace it.

Not sure if someone already mentioned it, but somehow the combination of FAR + DRE seems incredibly easy. My first thought was that I am imagining things because I grew accustomed to shallow angles of reentry but than I did some testing. For most of my landers i do not need any shielding. I do not remember that DRE and FAR were so forgiving did something change since .21? So my question is, what settings would be recommended for FAR+DRE combo to force me use shields or wings (for atmo bouncing) or do retro-burns for slower descent as I do not think is realistic to be able to survive reentry with unshielded landers (using the 1.25 lander can not pod) and all the small gizmos exposed. Only parachutes seem to need protection from direct exposure. TLDR:FAR+DRE feels too easy, could anyone recommend good settings for that combo?

Angel you are avoiding the main argument how procedural parts is only a band-aid that at best can only improve performance on specific ships, mainly when trying to stack up fuel tanks or wings. And for both of this 2 problems there are existing mods that help you with that (procedural wings, stretchy tanks, modular fuels, and KW rocketry for bigger parts) not to mention you can have smarter lifter designs. However no procedural parts will help you with reducing parts count for space stations or planetary bases, because on such structures you usually need many docking ports, lights, rcs solar panels, landing struts and other small parts that you cannot simply replace with one procedural part. There are mods that try to cover this by making multifunctional parts but this takes away the creativity. And if you are building a station or a base you usually want to visit it with other crafts, like SSTOs for refueling, or similar, and those crafts needs their own set of parts which just adds to the part count when being close enough. So no procedural parts won't solve the main issue, that KSP as it is for now is only good for making a ship, sending it somewhere, and come back (or having fun horribly killing kerbals....). As soon as you try to go into station building or planetary bases, you will hit the wall of bad physics performance. Also, about RAM usage, i do not really mind, as RAM is cheap now-days, so really not of much importance (except that current x86 builds have a limit of only 4GB). But no (reasonable)computer upgrade will fix the physics performance.... EDIT: Angel just now i saw your signature, you've build a nice station, now tell me how many parts could procedural parts reduce.... Not to mention that your station is kindof minimalistic, but you still get yellow counter

A bit noncontributing post, but still: I can still very well remember how one of my first SSTOs could only fly backwards at reentry, and at that time I decided not to fix the problem, but to improve the flight characteristics in backward, resulting in perfect landings on the KSC landing strip... in reverse. And by landing in reverse I accidentally solved one of my main issue with SSTO re-usability... i would not need to turn it around for takeoff

I mentioned it was Rawbots (a really small team) that switched to bullet in Unity. As for "waiting for unity to get better physics" it was said multiple times by unity devs, that they are conservative in this type of change as the main selling point of unity is its cross platforming(think mobiles) and backwards compatibility. And is most unlikely that there will be any big change in Unity any time soon. And KSP's needs are quite specific and a bit different than the kind of games Unity aims to support. So there is probably only 2 possible options... Squad does major a physics overhaul by themselves (yes a 4-6month cycle...) and get away from the hellish physX from unity, or does nothing but small optimizations (yes those are done in Beta). Sadly they will probably opt for the later, and KSP will never be epic as it could be..

Tuareg speaking of skyrim: http://www.youtube.com/watch?v=O4wFtwtL6dc those 4000 cabbages lags less than 1000parts in KSP, and skyrim was not meant for rigid body spam, while for KSP is essential and can't handle 1/2 the amount. Or this: it has more than 1k and runs perfectly smooth(compared to ksp @ 400parts), despite most of them being in contact, and being pushed around with fusrodah

Wrong... 5thHorseman, your anecdotes makes sense only if you mean optimization before all the frills. Perfectly it would be optimize engine first before starting to add features, but sadly these days in development is features before everything else. And IMO KSP at the moment already has all the main features it needs (and what it does not have is, and can be covered with mods), but at this point what it really lacks is better performance. Its getting to a point where new features are becoming useless because of bad performance. We got docking, but we cant make space stations without major lags, there is talk about stock planetary resource system (you can use kethane mod at the moment) but you cannot make a decent planetary base without lags. In any direction KSP wants to expand (with features) it will hit the wall of max 300parts without lags. As it is for now, KSP only works well for building simple go to (and maybe return) ships. One exception is science and career mode(with parts cost eventually), as it actually forces you to minimize and gives additional meaning to "go-to ships". Also the more features you add the harder it becomes to replace/optimize the underlying engine.

Also on the note about procedural parts, what parts would you make procedural? Lets say fuel tanks, struts, beams, wings, etc.. so yeah mostly structural stuff. But when you look at an average ship, they have all those tiny parts, like rcs, ladders, landing struts, docking ports, science stuff etc that can't be really "procedural" unless you have complete blocks in 1 part that has it all. (but that would utterly destroy the creativity in this game), or another option is parts welding which I suggested long time ago, and there is a mod for that, as it only simplifies the damage simulation, but not creativity. Also as it is now, the game allows decent performance for simple space ships that are able to go land and return to any planet/moon in game without lag. But when you get into space stations, or bases, and when you make or 3rd or 4th dock the game gets unplayable, so again not something that procedural parts will help alot with. Also since there are 3 great procedural MODs already why bothers the DEVs to make it into stock, since not much change there. I would very much prefer they would focus on actual performance boost, than porting mods into stock. TLDR: procedural parts would not improve much as it would only help you reduce part count (depending what are you building) for 10-5%.

AngelLestat although I do agree with you that having stock procedural parts would be nice, there are mods that provide this and making it stock would not change much. However increasing base game performance (mostly physics engine) would mean a whole other level of awesomeness, as the ships having few parts are dull in terms of their looks and how they "disassemble" when there is a structural failure, not to mention it takes that LEGO feeling out of the game.