Lisias

Reading the posts, I came to an analogy: Do you remember Potential Energy? The energy a body has, given a situation? For example, a 1Kg mass rock hung at 10 meters high has way less Potential Energy than the same rock hung at 100 meters. Think on Delta-V as "Potential Velocity". Given my mass and the fuel I have on the tanks, how much velocity I can get from where I am?

As far as I know, it's "irradiated", not exactly "transferred" as we are used to see here, under an atmosphere.

I was thinking on collateral effects - something that should not have a autoStrutMode set , even to off. However, I just used EEX to autostrut everything to Grandparent, and the texture flickering persisted - while the parts didn't trembled. So, yeah. EEX appears to be unrelated, and I'm facing something new. I will post a video by night, I found more people talking about it and this will be interesting to fix. — EDIT — It's not related to the altitude. It's related about acceleration and speed. I got the quivering/flickering effect on high atmosphere by doing a low slope ascent. The magical speed appears to be ~1600m/s (+/- 100), and only under >2G acceleration. This is going to be interesting!

I'm on it. However, my vessels are quivering when they are near the Karman Line, and I never saw that before. The parts "flickers" and "tremble", and it appears to affect the face's normals on rendering. I'm trying to figure out if my change is related, if it's a colateral effect from Kerbal Joint Reinforcement, or it's something new and completely unrelated with this!

I came to this: if (GUILayout.Button("No Autostruts")) { RefreshParts(); foreach (Part p in parts) { if (!doNotMessWithAutoStrutModes.Contains(p.autoStrutMode)) try { p.autoStrutMode = Part.AutoStrutMode.Grandparent; p.ToggleAutoStrut(); } catch(Exception e) { p.autoStrutMode = Part.AutoStrutMode.Off; Debug.LogException(e); } } OSDMessage("Autostruts turned OFF for all current Parts in Vessel (except forced)."); } The exception is being raised by p.ToogleAutoStrut(). So, if anything goes wrong, the p.autoStrutMode will have a improper value, and this is what will be saved to file - perpetuating the error. This way we would have the Exception logged for eventual analysis, and we will also ensure a safe value on the Twekable. User should save the vessel right now (preferably with a new name), and then reload it. Just to be on the safe side.

Problem is…. Here too. CC is not crashing at the moment on that very same craft it was crashing some hours ago! I spent some time trying to figure out why, and I think I realized the reason: my last debugging session messed up my save game, and all my accepted contracts were deleted. So I have no contracts running right know. I remember that one of that contracts demanded a flight to be completed without breaking a single part (I was stuck on exactly that one, my planes have that weird tendency to hug the grass), so it make sense that CC would monitor the Joints! A broken joint would invalidate the contract - even if the part is not destroyed. I also remember failing a bunch of contracts about landing a aircraft without breaking parts (all at the same time!) when two boosters collided after separation while kicking a rocket out of this world, so the Contract's checking happens all the time for every active contract. I don't know, yet, how to mangle the savegames so I will pursue a CC contract with that criteria in order to check the thesis. However, the following exception is being raised, apparently once for each offending part, when launching the vessel setting all the parts to AutoStrut Grandparent (probably all of them, but I didn't tested every single case) on the previous EEX: [EXC 00:33:15.856] NullReferenceException: Object reference not set to an instance of an object PartJoint.SetupJoint (Vector3 jointPos, Vector3 jointOrt, Vector3 jointOrt2, Int32 size) PartJoint.create (.Part child, .Part parent, UnityEngine.Transform nodeSpace, Vector3 nodePos, Vector3 nodeOrt, Vector3 nodeOrt2, Int32 nodeSize, AttachModes mode, Boolean rigid) PartJoint.Create (.Part owner, .Part parent, .AttachNode nodeToParent, .AttachNode nodeFromParent, AttachModes mode) Part.SecureAutoStrut (.Part anchor) Part+<SecureAutoStruts>c__Iterator3.MoveNext () UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) So the issue with non-autostrutable parts being autostrutted is still reproducible on the previous EEX, what confirms the fix on the new one. As soon as I manage to get a Contract failing with that exception above, I'll try that try-catch stunt to recover mangled vessels.

Find a ladder or solar panel on the vessel, put "autostrutMode = GrandParent" on it. Or wait a couple hours, I'm on it. — POST - EDIT — Make it 3 or 4, my KSP just crashed on my face.

It will break on Contract Configurator (see my post above). You wil need to do something like this: RefreshParts(); foreach (Part p in parts) { try { if (!doNotMessWithAutoStrutModes.Contains(p.autoStrutMode)) { p.autoStrutMode = Part.AutoStrutMode.Grandparent; p.ToggleAutoStrut(); // blah blah blah blha } } catch (Exception as e) { Debug.Log("Oh my God, they killed Kenny!!!"); } To prevent that the breakage of some other mods interrupts the process. Replicate in all other commands.

Thinking is a very healthy habit. I should do that more frequently. Yeah. That's exactly it. Moreover, the Contract Configurator exception almost certainly is also due that! I'm prone to conclude that something changed on KSP 1.4.4 . The behaviour in question is novelty, but this savegame and this vessel were "in production" since the 1.4.3 era and they were working fine (including the Contract Configurator). — POST - EDIT -- Ladders, Struts and Solar Panels are not AutoStruttable.

And, yeah. I still have problems even with the fix from 4x4cheesecake. But, and it's almost for sure, it's something related to another mod stomping on EEX's feet. I'm monitoring the Ship's .craft directly now. There're something preventing the EEX to disable all the autotruts - some of them are still on Grandparent. I wonder if it would not worth to "try catch" the inner loop to be able to narrow down the parts being affected. Since EEX is a Editing time plugin, some performance penalty are acceptable in order to help debugging and trouble-shooting. Anyway, by hand or by luck, I will narrow down the exact part that triggers the problem. I will follow up later. — POST - EDIT -- By the way, I disabled by hand all the autostruts on the vessel file, and now I'm getting: [LOG 20:00:59.483] [Blimp MEDEVAC - 2]: ground contact! - error. Moving Vessel up 998.942m [LOG 20:00:59.485] Unpacking Blimp MEDEVAC - 2 [CUT] [LOG 19:59:55.319] [UIMasterController]: HideUI [ERR 19:59:55.672] Triggers on concave MeshColliders are not supported [CUT] [ERR 20:01:03.867] Non-convex MeshCollider with non-kinematic Rigidbody is no longer supported in Unity 5. If you want to use a non-convex mesh either make the Rigidbody kinematic or remove the Rigidbody component. Scene hierarchy path "HL.AirshipEnvelope/model/node_collider", Mesh asset path "" Mesh name "X_001-mesh" This vessel worked fine last time I used her on a Mission. But reading the .craft file, it appears to be happened on the KSP 1.4.3 times, when I started this Career…

The "Non-convex MesshCollider" is on Unity. Recently (or sort of) they deprecated colliders with a non-convex shape. So a lot of mods that used to work fine with such colliders, ceased to do so. It's interesting that even a few stock ones still have this "problem". Since such colliders are not supported anymore by Unity, I wonder how collisions are being handed on such parts, and how it affects the auto-struts (if affects it at all).

Hey, things changed here. The EEX Exception is not more, but now another one took his place: [ERR 17:43:43.336] Exception handling event onPartJointBreak in class VesselNotDestroyed:System.NullReferenceException: Object reference not set to an instance of an object at ContractConfigurator.Parameters.VesselNotDestroyed.OnPartJointBreak (.PartJoint p, Single breakForce) [0x00000] in <filename unknown>:0 at EventData`2[PartJoint,System.Single].Fire (.PartJoint data0, Single data1) [0x00000] in <filename unknown>:0 [EXC 17:43:43.337] NullReferenceException: Object reference not set to an instance of an object ContractConfigurator.Parameters.VesselNotDestroyed.OnPartJointBreak (.PartJoint p, Single breakForce) EventData`2[PartJoint,System.Single].Fire (.PartJoint data0, Single data1) UnityEngine.Debug:LogException(Exception) EventData`2:Fire(PartJoint, Single) PartJoint:DestroyJoint() Part:ReleaseAutoStruts() Part:UpdateAutoStrut() Part:ToggleAutoStrut() EditorExtensionsRedux.EditorExtensions:MenuContent(Int32) UnityEngine.GUI:CallWindowDelegate(WindowFunction, Int32, Int32, GUISkin, Int32, Single, Single, GUIStyle) This appears to be something to be dealt on Contract Configurator now. The "ground contact", "Physics.ClosestPoint" and "Non-convex MeshCollider" issues are still there. So it's not related with EEX for sure.

I'm experiencing it too. KSP 1.4.5, EEX 3.3.19.5 (without EERNoOffsetLimits.zip). And a lot of mods. It appears to have a issue from the NRE for each part of the vessel - I find a lot of the following on my KSP.log. [EXC 10:06:34.345] NullReferenceException: Object reference not set to an instance of an object KSP.UI.Screens.EditorActionGroups.ConstructGroupActionList () KSP.UI.Screens.EditorActionGroups.ConstructGroupList () KSP.UI.Screens.EditorActionGroups.ClearSelection (Boolean reconstruct) ClickThroughFix.CBTMonitor.Update () I think I managed to make a correlation with another problem I have - until now, the two vessels that have this problem on the editor, also "jumps up" when launching, one just a few centimeters, other, 1000 meters! [LOG 11:00:50.545] [Bimotor PAX Carrier Short Range]: ground contact! - error. Moving Vessel down -0.452m [CUT] [LOG 11:03:26.785] [Blimp MEDEVAC]: ground contact! - error. Moving Vessel up 998.868m I'm reluctant on pinpoint EEX as the source of the problem. I just don't remember a single KSP installment of mine that doesn't had it, and this "jumping" issue is new to me (I just realized the NRE recently, but I can't say if it was there before). Worst, the jumping vessels didn't jumped at all when I created them and for some time after, so it's something that happened between last time I used them and now. So this can be something else stomping on EEX's feet (but, granted, can be EEX stomping on someone else's feet - and just know the "right feet" were available!). I don't have the slightest idea if the following is related or not, but I have also the following anomalies on the offending logs: (lots and lots of this:) [WRN 11:03:26.751] Physics.ClosestPoint can only be used with a BoxCollider, SphereCollider, CapsuleCollider and a convex MeshCollider. [CUT] (lots and lots of this:) [ERR 11:04:53.070] Non-convex MeshCollider with non-kinematic Rigidbody is no longer supported in Unity 5. If you want to use a non-convex mesh either make the Rigidbody kinematic or remove the Rigidbody component. Scene hierarchy path "HL.AirshipEnvelope/model/node_collider", Mesh asset path "" Mesh name "X_001-mesh"

I was making a joke, and the extensive use of emoticons should had be enough. But, since you want an argument, let's go! I used to drive smal truck with 2 tons cargo. I used to drive 4 tons tractors on the mud. I used to drive medium performance cars in not the safest speed I was expected to drive. And in all these vehicles, lessening up the friction on the steering wheels is suicide. In once situation, we were experimenting on different tires on the trucks in order to optimize our funding (aka - saving money!), and we had the bad idea of using a tire of harder rubber on the front wheels (the same we used on the rear wheels). Hard rubber are… harder. But there's also less friction for the same given weight. Not so bright idea. With a full load, the rear wheels got way more friction than the front wheels, and this leaded to a ridiculous situation: on a U turn, with the truck stoped and every single other traffic rule being obeyed, I turned the steering wheel all to left, engage the first gear and hit the gas pedal (the diesel pedal, to tell you the true). The damned vehicle just gone straight ahead, virtually ignoring the steering. I had way more friction on the rear wheels than o the front, and by accelerating a bit more than the minimal, the front wheels couldn't steer the car anymore! After math? I drove back home at 10 mph and we never more did anything that could remotely lessened the front wheel's friction. That would had killed me on the field. In every single situation decreasing friction on the steering wheels is a very bad idea. Aquaplaning a 2 tons gross mass vehicle because you were using sand tires over a curve where a water plumbing had blown is not funny. Not even at 40Km/s (27 or 28mph). Interesting enough… I could reproduce these situations on KSP (obviously, respecting the limitations of the game engine - there's no aquaplaning on the game). The rule of thumb is simple: you don't want to lessen your friction on the steering wheels. You need it to… steer (!) the rover! If you flip over your rover, you are too fast for the height of the center of mass - there's a reason fast cars runs scratching their bellies on the ground. If you are breaking your wheels on turning, you have too much weight on them. You need bigger wheels, or lighter vehicles. If you lessen up the front wheels friction, you are loosing authority on turns and risk doing a involuntary doughnut when breaking. You never design an vehicle with more friction on the rear wheels than on front!

As a "survivor" of an aquaplaning (managed to regain control of the car before damage was done - my seat, however, didn't made it…. ), I strongly disagree.

IF you bought (or plan to buy, it works for every published version once you have the license) KSP from Steam, you can download the V0.17 using steam://nav/console (once you install Steam, of course). It's a somewhat convoluted process (search the steamdb for the desired appid/depotid/manifestid; type the long command line; wait for the download to end; copy and paste the path the console prints on the screen when done). The "hardest" part is to match the manifest date with the one from the wiki so you can infer the version. Again, you must have a valid license for KSP from Steam, you will not be able to download anything you are not authorized to. — POST - EDIT — As stated below by @4x4cheesecake, the oldest KSP version available on Steam is 0.22. I'm sorry for the mistake, I need to properly file and maintain my KSP collection.

Never mind. I'm grumpy, after all. He will survive. On tubes. Honestly, I wish he does well by himself - because I don't intend to ever move a finger on his behalf again.

Yep. People always understand the world by using themselves as reference. It's a drag, but it's how people are. And exactly how I suppose to know I should not open it without opening it? It was my personal account, it is intended to be used for chitty-chat.

Thanks! About 230 parts the Carrier, what gives me 25 parts to be used on the payload. This can be trimmed, however - the "second floor" radial engines are easily detached, as well every juno that is not a joint pivot. Some of the wings can go away. as well some elevons. A curiosity that took me some weeks to figure out. Since the payload (and not the Carrier) is, technically, the main vessel, use the radial decopuler on the payload. The decoupler assumes that the atached vessel is a booster or something like that, and the crossfeed behaves this way. So we need to attach the Carrier as it was the "booster". — POST - EDIT -- Tacked down some glitches on the design, and took a new screenshot on the "Second Maiden Flight" Last shoot of the week - I lengthen the Carrier and this make her way less prepense to juggle by entire airstrip. She is somwhat heavier now, but with all that thrust? Not a problem. Simple, I should had thought it before.

And for today, I'm reviving some old ideas that I never used on a mission and that, now that I had to replay a lot of missions, can be of use. This is my QuadraPlane Platform for Airborne Launching - since I do not have technology to build a high altitude plane that could take-off, go really high, fly to a mission area and then go back to KSC, I'm building a X-15 style approach: a Carrier ferry the craft to the mission area, launch the thing and that's it. Landing the mission craft can be a challenge, as some missions doesn't have an airstrip near - but with Kerbin Side and Contract Manager installed together, there're some nice opportunities for a low-tech but high-performance solution like this. So… This is the Report for the maiden test-flight! (note: yeah… there's a terrible typo o the screenshots! ) ------ Carrier and X-3. Engines ignition. The Carrier is way over-engineered as it was originally built for a way heavier rockets on later missions. Since I had to rollback some missions, I choose to "tech down" some crafts. The SCANsat radar is being use to map Kerbin - I have no Tech enough for satellite surveying yet, so I do what I can on planes in the mean time. Open Cockpit view while pre-flight check and taking-off: This monster juggle a lot on the airstrip, I still have some work to do in order to safely take off - right now, it's a nightmare! But once I manage to get the wheels off the ground, the huge amount of thrust make her easy to climb! She maneuver as a 2nd World War fighter! Since this is still a test flight, I don't need to fly the all the way to the target. So I commenced the pre-launch checks - I'm prone to forget action groups and tweakables when merging the crafts - and yeah, I forgot some. I got some very nice internal views during these checks: Eager to capture some very nice pictures, I choose to try a launch with internal view: That was my error. I forgot to activate the AutoPilot, the Carrier started a slightly descent and I didn't noticed. When I launched the X-3, I also did a mistake on the staging of the engines: the first X-3 stage fired up in the same time the radial decoypler's charges blew. So the X-3 had thrust at launch, that created acceleration and lift. And I mentioned that the Carrier were on a descent? SO… Yeah. Tragedy. The X-3's wing-mounted engines hammered the Carrier belly and blew magnificently while the X-3 scratched her way under the Carrier and hit the Carrier's huge tail elevators. ripping them off. And since I also forgot to activate the auto-screenshots on crashings (I'm using Automated Screenshot together the Historian), I don't have screenshots from this fantastic event neither. Yeah, I'm hearing your thoughts. I agree!

Uneducated people are terrible. A country full of them is a disaster. An economical disaster of Communist proportions. A <insert-your-favorite-non-forum-rules-compliant-offense-here> of a (now no more) friend of mine called me two weeks ago offering a contract. I took it, despite that feeling in my guts telling that friendship and business doesn't match. Ok, the guy was to send me some information about the job last week. I received nothing. (sigh) Yesterday, another friend of mine got a problem with his wife, and asked me for some advices (I have my share of bad decisions on the matter, I know preciselly what not to do) and I fired up my personal Skype account to talk to the guy. And there it was - that (no more at this time) friend of mine sent me professional and classified data on personal channel that I explicitly told him is not secure (used on shared computers) neither professionally monitored. And, with a 36 hours later timestamp, a complain about my "unprofessional behaviour". (sigh) People here send classified commercial information on Facebook, on WhatsApp, on everything, but not on my professional, secured, paid, professional e-mail - this last one is used for PPT presentations with kittens, jokes and every kind of chitty-chat ever created under the Sun. I loose a job and a "friend". I'm pretty liquided about the job but, frankly, not that much about the "friend". People unable to follow a simple instruction as using a commercial email/skype account for COMMERCIAL STUFF is not someone you can rely on, on my experience. Now on fire-fight mode. A 30 years "friend" can do a lot of damage to your network. Damn.

Use negative angles of attack. Lift in KSP is greatly simplified - the shape of surface is meaningless, so there's no difference on flipping the wing upside-down as we would do on reallife. What I do is tilt down the wing's front border. This creates "negative lift".

The 32 bits addressing space is just a problem due a 32Bits DLL "infiltrated" on the 64Bits distribution. I run KSP on MacOS and Linux, and I don't have a problem with 10 to 15G RAM processes - other than Unity, obviously.

Frankly? Knowing what I know from Unity, this would not be a (new) issue. Dynamic Loading Assets would reduce the initial memory footprint (and the initial loading time) by a mile , but would also make the memory problems worse. Try to imagine the pathetic Unity's GC handling, also, many megabytes of binary assets being loaded and unloaded on demand on playing time... SystemD had bitten me on the SAS more than once. This thing manages to be worse than Unity's GC, and you are a happy man if you didn't had to figure it out by yourself.

Not only Mono, but Java and any other Garbage Collector based runtime - including C++ ones. To make GC work on Real Time systems, you need to satisfy a lot of constraints and demandings that, usually, renders manual memory management easier to implement. Only now, after what… 20, 25 years? Java has a somewhat usable Real Time kind of friendly GC (G1GC). But frankly… Who wants to do business with Oracle? Now take all this investment and try to figure out if isn't cheaper to just teach the !#$##!@# developer to handle memory and apply best practices and static tests when writing Real Time applications. A call to such OS function will be, always, more expensive than just allocating something from your heap. It will incurs on a context change to the privileged ring, a search on the memory tables for a suitable memory block (and sometimes repacking the free memory to build such block by "force"), mapping it into the Process Descriptor tables, zeroing it for security reasons and some more details I don't remember right now. It is a very expensive call. But yes... It's way more expensive not to do it. It's plain appalling that someone that calls itself "Professional Developer" just ignore this simple fact. "We don't aim to serve games with such long lifespan" it would be an acceptable answer. Ok, it's a low quality and cheap Engine for casual, 15 to 30 minutes session, small games. It would be a honest answer. But this "The O.S. does it wrong, we know better" approach? Really? It's due an abomination called WinSXS. Every time a program is installed, a "snapshot" of every DLL it uses is recorded by its installer. So, if another program or system update happens, this program still uses its own well known "copy" of the DLLs. With time and updates, you end up with almost a private copy of almost entire O.S. for every program you have. As an emergencial hack to keep things working while a proper solution is worked out, it's acceptable. Unfortunately, Microsoft have a notion of "temporary" that appears to be incompatible with Reason. You too? Another Follower of the Sacred Way of a SystemD-less System? Stuttering can be delayed by using MemGraph. You "pre-allocated" some memory ahead before it's really needed, so it would take sometime before the GC is needed - that stuttering is essentially the GarbageCollector freezing everything in order to reclaim unused memory. However, you do that too much, when finally the GC kicks in there're so many garbage to be collected that the freeze takes too much, and something else on the Engine blows up due the freeze. The GC must halt every other thread in order to do its thing. It's a limitation of the technology - threaded GC's are some of the harder problems to be cracked on this trade. About the 12+ hours gaming sessions - there's a unspoken true: some of us (me included) don't only mod the game, but we mod the mods themselves. We profile, detect and fix the performance/memory leaking problems for ourselves. It's the reason some old school players are still using 1.3.1 or even 1.2.2 - the effort to redo all that work is too much for the benefits they will get in exchange. You can count about 1.000 to 5.000 lines of code rewritten and months and months of work. Not for the faint of heart.