Squelch

http://youtu.be/FCARADb9asE

This is filling out quite nicely now. Well done to you both and all of the other submitters on what should be the first recommended addon to load.

I really must spend more time reading the forums. For some reason i've been doing it the hard way, and attempting to search for those little tidbits. Thanks for the work you've done here. Excellent resource.

What a fantastic achievement hitting the mark on the first touchdown, and all credit to the team for doing this. The failure of the cold jet and the harpoons is a shame, and I've been trying to find details of the methods of propulsion they both employ. Does anyone have a source of information on the specifics of the systems? The length of inactive time in such a harsh environment must be a factor here. Whatever the outcome, there is great science and lessons being learned despite what some quarters of the press are hinting at as failure. Once the passive science is done, I hope that they come up with something that could reposition the lander using the drill torque and other instruments to make a controlled jump. The landing legs are capable of doing this, but only two look to be in ground contact. The boom could possibly be used to nudge or even act as a counter mass for righting the lander if it does topple. Images this evening will hopefully reveal the landers true position. Anyway, Philae is still functioning, and has touched down, so I'm sure that great minds are working on this phenomenal opportunity. It's still exciting times.

The expectation of a "regular" dirty snowball probably shaped the decisions back then. The revelation that the surface may be rocky must have the ice harpoon and anchor drill designers worried. It will be an incredible feat if they pull it off. Perhaps a lasso should have been included to snag a boulder too? Velcro is very good too apparently... Exciting times, even more so with the new technical challenges.

Here is the proposed timeline of the landing, and details on where the results are available straight from the horse's mouth http://blogs.esa.int/rosetta/2014/11/07/landing-operations-the-most-critical-moments-you-should-watch-for/ http://blogs.esa.int/rosetta/2014/11/07/rosetta-and-philae-landing-timeline/ I've set time aside for this, and will be watching with baited breath. Will Philae be able to attach itself, or will it bounce?

Respectfully, that is a contradiction itself. A parts pack will give the option to those that want it, but won't take away the option of loading due to limited memory on some machines. If the only argument is about the looks, then please also consider the function. The parts need to work in unison with everything else, so if the meshes and attachment points conflict, what should be changed? every other part to suit a legacy part, or simply deprecate the old part? First make it work, then make it pretty.

I see that ESA have made a call for media interest in the landing site announcement planned for the 15th. My personal take is that it has been not as straightforward as originally expected. The "duck" or "dumbbell" shape was totally unexpected, and brings a whole set of interesting problems. How's the gravity well going to affect a stable orbit for relay? Temperature and sunlight exposure need to be reconciled, and those images certainly leave food for thought. That map, and the VIRTIS measurements don't make it clear how much variance those potential sites have considering Philae has minimal temp management. Will it survive? I find it so exciting that this is happening, but with celebrity stories taking the headlines, how can the press make this utterly mind blowing event more appealing?

Madness! Utter inspirational madness! I'm loving your work.

That's an interesting rapid disassembly you have there. Did that happen while you were recording, or did you record to show it? I've seen something similar once, and attributed it to heavy background task load. Ordinarily, I don't stress my system too much, but on that occasion there was lots going on, so I suspect that your capture software may not have helped. Something to check for if it happens with only KSP and required tasks, is the physics tick slider. Found under Settings => General => System => Max Physics Delta-Time per Frame Have you manually adjusted it? I'm not certain, but I beleive it gets automatically set according to your machine spec, so setting the tick duration lower could feasibly cause undamped oscillation. IR probably adds extra stress the physics engine, and any other machine load will exaggerate it further. Try decreasing the number of ticks - increasing the duration - to see if that helps.

If the surface is as soft and powdery as they suspect, then even a very low gravity would keep a boulder in proximity and make an impression. I'm sure I can see points along those tracks that have a telltale fan shaped erosion pattern. That said, it may just be tricks of the light, and as new mapping comes in things will be clearer - if you'll excuse the pun?

I'm intrigued by what looks like tracks on the plain in this image. My first thought was they were formed by boulders or concentrations of ice that while outgassing, rolled around on the surface, and I still can't get that out of my head.

I made that mistake the first time i attached an extendatron to a command pod which is the root part. Simply make sure that you rotate the extendatron through 180 before attaching and everything will work and look fine.

I agree on the structural point, but those trusses can also be used to house other parts. I've picked up the habit of placing battery packs and instruments in such positions. A bit cheaty using clipping I know, but I hate to see wasted space. This really only applies to spaceborne craft where the only consideration is inertia. A ground based vehicle looks incongruous built such a way.

Of course. The preference is entirely yours to make, and there are many a debate on the merits or otherwise of the various alternatives. I just thought I'd throw those suggestions into the mix with no preference of my own. OMS could be used as a framework for a mission editor/generator, and could be particularly suited to setting challenges. Either an easily read and edited format, or the ability to create a third party editor would be a boon.

YAML or JSON might be better alternatives to XML. They retain validation, but are much easier to edit for the average user with a high signal to noise ratio to boot. This looks interesting, and I'll be following your efforts.

The ideal situation would be for the user to be able to enter exact values directly into the text field which is a fairly common method when combined with spin buttons and sliders. There are many places throughout KSP where this would be desirable.

That's great to hear, and welcome back - if I'm allowed to say that being so new and all. The ideas I'm working on cross the boundaries of code and modeling, so it's kind of inbetween. I love the rework theme, and believe they should be de facto. However, one part of the idea involves some compound parts to keep the loaded part count down, and the other is the ability to add a servo to more than one control group. Plus something else completely out in space and possibly not doable. It's all experimental right now, and I have much to learn. Fixing problems is a good way to familiarise myself with how things work of course.

I've found the issue, and managed to fix it locally. I can prepare a pull request if you are accepting contributions? Otherwise the fix is simple and can be explained easily.

Will do, thanks. In more general terms, and the reason for my attention to the GUI, are contributions welcome on the expansion of some of the parts functionality? I have some ideas that I'm working on, and compliment the work being done here.

I have found the problem and applied a simple fix for the horizontal scaling of the control GUI in my local copy. I'm not entirely sure if this thread is the place for this, but are contributions accepted? If so, I can prepare a pull request for sirkut. I don't want to unnecessarily clog the main thread.

I just checked too, and cannot replicate. These lines show you have an older version of KSPAPI. [COLOR=#333333][FONT=Consolas]Platform assembly: C:\program files (x86)\steam\steamapps\common\kerbal space program\ksp_Data\Managed\Boo.Lang.dll (this message is harmless)[/FONT][/COLOR][UIPartActionsExtendedRegistration] Elected unopposed version= 1.6.0.0 at C:\program files (x86)\steam\steamapps\common\kerbal space program\GameData\KSPAPIExtensions.dll Platform assembly: C:\program files (x86)\steam\steamapps\common\kerbal space program\ksp_Data\Managed\Mono.Security.dll (this message is harmless) [CompatibilityChecker] Running checker version 3 from 'KSPAPIExtensions'

I'm sorry that I've only just read that edit while reviewing the thread. That is pretty much exactly what I'd done after I had the initial problem, and I saw there was something funky - see my first post here, and the update. I just read the tail end of the KSPAPIExtensions thread and noted that I'd seen the versioning issue mentioned there while chasing this problem. There is also an updated version 1.6.1 of KSPAPI so on a whim, I installed it while removing the 1.6.0 existing versions. It works! There hasn't been anything to indicate an issue with KSPAPI, and blame, if any, has been pointed in this direction. I'm determined to try and understand how TS became a casualty, and in such an odd way too. I equally sorry for the wild goose chase and grateful for your patience.

Results from the last two test files. The first one worked first time, but failed after a second attempt. In all, one failure out of five. The crash was different in that I could at least place the part, and then it CTD'd as shown in the log. ------------------- initializing editor mode... ------------------ editor started Untitled Space Craft - Untitled Space Craft [KAE] Registering field prefabs for version 1.6.0.0 (latest) trussPiece3x(Clone) added to ship - part count: 2 Crash!!! ... ========== OUTPUTING STACK TRACE ================== (0x0000000103C00000) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x00000000641DE82E) (Mono JIT code): (filename not available): EditorLogic:attachPart (Part,EditorLogic/) + 0x21e (00000000641DE610 00000000641DE83C) [0000000003A74D48 - Unity Root Domain] + 0x0 (0x000000006419ABB1) (Mono JIT code): (filename not available): EditorLogic:UpdatePartMode () + 0xec1 (0000000064199CF0 000000006419AFAF) [0000000003A74D48 - Unity Root Domain] + 0x0 (0x00000000641996CE) (Mono JIT code): (filename not available): EditorLogic:Update () + 0x7e (0000000064199650 000000006419973A) [0000000003A74D48 - Unity Root Domain] + 0x0 (0x00000000040472DB) (Mono JIT code): (filename not available): (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) + 0x6b (0000000004047270 000000000404734A) [0000000003A74D48 - Unity Root Domain] + 0x0 (0x000007FEDA6436CA) (mono): (filename not available): mono_set_defaults + 0x2b8e (0x3EBA63203E2CA091) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x00000000FFFFFFFF) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x0000000003A74D48) ((module-name not available)): (filename not available): (function-name not available) + 0x0 ========== END OF STACKTRACE =========== **** Crash! **** The second file shows similar results for two consecutive runs, but I haven't run it multiple times yet. ------------------- initializing editor mode... ------------------ editor started Untitled Space Craft - Untitled Space Craft [KAE] Registering field prefabs for version 1.6.0.0 (latest) trussPiece3x(Clone) added to ship - part count: 2 stage count is: 0 Crash!!! ... ========== OUTPUTING STACK TRACE ================== (0x0000000103AD0000) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x0000000076D398F5) (Mono JIT code): (filename not available): EditorLogic:UpdatePartMode () + 0x515 (0000000076D393E0 0000000076D3A69F) [0000000003934D48 - Unity Root Domain] + 0x0 (0x0000000076D38DBE) (Mono JIT code): (filename not available): EditorLogic:Update () + 0x7e (0000000076D38D40 0000000076D38E2A) [0000000003934D48 - Unity Root Domain] + 0x0 (0x0000000003F172DB) (Mono JIT code): (filename not available): (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) + 0x6b (0000000003F17270 0000000003F1734A) [0000000003934D48 - Unity Root Domain] + 0x0 (0x000007FED3FC36CA) (mono): (filename not available): mono_set_defaults + 0x2b8e (0x00000000FFFFFFFF) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x0000000003934D48) ((module-name not available)): (filename not available): (function-name not available) + 0x0 ========== END OF STACKTRACE =========== **** Crash! **** I'll try a couple more times, and then try with MFT again. Whatever it is, it just moves that bit further along at every attempted fix. I've seen the MuMech.Toggle spamming Smurfalot's log in the IR thread.

It does seem counter intuitive, but it is 100% reproducible. I only have the necessary addons installed for IR to function. Isn't linq associated with xml? Not a problem on the chasing of this out. It's a learning exercise for me, and should hopefully squad a bug for everyone. @sirkut - I'm at a loss as to what it might be. With so few mods, there are only so many variables, and I can recreate the problem or make it go away at will. TweakScale without MFT causes a CTD Add MFT, CTD ceases. Remove TS and MFT, and the CTD's cease. The only other factors are Toolbar, IR, KAE, and MM I have only one copy of the latest revisions for all of those, and without any one of them, my intentions for IR are stymied. I just spotted a new file to test...