codepoet

Indeed. I know how to solve Wingnutt's problems, but I am not telling

I love this, thank you. What I like most is setting focus on a part in a lower stage and then watching the upper stage pull away into the distance from there, while the engine fairing scatter. Just be sure to get focus back to the upper stage before it moves out of range!

You can add PHP to the C-like list too. If you want to know how different syntax could be lookup up LISP.

... then they would never get home again!

source?

Oh - what is the "1.0.4 fuel drain"? I have never heard of that before!

I have come to this thread late, but here are a few thoughts on learning to write software and use various languages: * learn humility - there is always a better way to do it, there is always something you have not thought of, a bug you have not noticed or a test case you have not considered. Other folks might have written it differently, and there are always trade offs between efficiency, maintainability, portability, extensiblity, and time and money available. * when choosing a language or development platform there are several considerations: target platform, speed of execution, speed of development, development tools - debuggers etc, ability to link to other modules, language features, library features, interpreted or compiled. Again there are always trade offs. Different options have different benefits and drawbacks, and different folks would make different choices. No-one is right or wrong, but some will have more success than others. * Comment your code heavily right from the start. However, you should also be writing your code so that it is easy to understand without the comments. Make your flow control clear, name your variables thoughtfully, refactor your code so your methods/functions do easy to understand things, use the language features for the purpose they were intended, use standard design patterns, and design your code for reuse, even if you are not sure how you will reuse it. * Test as you go, at the finest granularity you can, and if possible automate testing too. * Understand your problem space. If you do not fully understand the concepts that you are working with, how can you expect to describe how to use them to the software? * If you really want to learn how to get the best out of a language (any language) then learn how to write a compiler and an interpreter. I am sure there are plenty more that others far greater than I could offer. I spent many years in the trade, but that was quite a while ago now. I am sure that there are better folks to learn how to code from than some random priest on the internet!

I have got: TestFlight.dll TestFlightAPI.dll TestFlightContracts.dll TestFlightCore.dll in the plugin directory.

I have installed this mod via CKAN on my RO game, but do not get any new GUI elements that indicate it is there to interact with (with the exception of KCT having a "disable failures" button now). The log has a line in it saying " TestFlightInterface: Could not find TestFlightInterop module" What an I missing?

CLS also come with a GUI that has a button "Alow Crew Unrestricted Transfers" to allow you to transfer wherever you want if you need to "cheat". See the CLS thread or the CLS wiki for more details.

I love it. I have made a few tweaks of my own for cost, size and techtree and submitted it as a pull request for Realism Overhaul. With any luck it will be adopted.

I have started using the Procedural structural part as tunnels in my station designs. I have started configuring it to support CLS. Is there any chance of Procedural Parts supporting CLS itself. Even better would be if the structural parts was CLS-passable depending on its width.

Thanks Sarbian. I can confirm that with the lastest RF and the latest MJ I do not experience the attitude control problem that I originally started to look into. Also, the available torque figures seem more correct when the MerlinDVac engine stops burning. I will start playing again, and say so if I run into anything else that does not seem right.

Thanks. It may well be that the fix needs to go in MJ. Either way I am happy to work on a fix myself, but I can't really do anything until you and Sarbian come to a common mind on what the various "Engine ignited" variables mean. Let me know how I can help.

I believe that from MJ's perspective the problem arises from the fact that the engine has fixed thrust (or should that be a minimum thrust other than 0) So I believe the MJ code ends up using that minimum level of thrust for some torque calculations even when the engine is "off". This is not a problem when not using RF because there is a check to see if the engine is "ignited", however when RF is installed that changes (I think). My initial thought was that it was a problem in MJ, however the MJ code does a whole bunch of other stuff in the relevant area that I do not understand so I am hesitant to point any fingers. Similarly there is more going on with RF that I know about as well. Nathan, I would be grateful if you were to have an exchange with Sarbian to decide what the best way forward is. Please let me know if I can help with more details to reproduce the problem.

I am looking into a problem with attitude control for mechjeb when using ROV and it has lead me here. Briefly the problem seems to be related to ModuleEnginesRF::EngineIgnited returning true once and engine has stopped burning due to the throttle being reduced to zero. I will start having a fiddle with the code to see if I can diagnose and fix it, but if anyone else here who knows the code can jump in and fix it faster, do please do so. I see I might end up in EngineSolver, and I know nothing about that/ I have posted mechjeb related details on the mechjeb thread. ETA I can make mechjeb behave the way I want it to by setting EngineIgnited=false in places where ModuleEnginesRF::ingnited is set to false. However that messes up the re-ignition code, so I am unsure how to proceed. It looks as if the RF code assumes that ModuleEngines::EngineIgnited has a different meaning to ModuleEnginesRF::ignited. Is this the case, and if it is, how can I get MechJeb to work out if and engine is ignited without it having to have knowledge of the ModuleEnginesRF class which would create a hard dependency?

I thought that Porkjet support was removed because porkjet was going to add it to his own project.

CLS itself does not have a transfer button (although stock does). Should this perhaps be a suggestion for Ship Manifest instead?

The cargo bay example is interesting. I am not saying this is the way forward, but consider this: Maybe a different way of doing the CLS thing is to consider that within each part there are several attachment nodes. A different way of doing all the CLS config is to provide a list of which of these attachment nodes are connected to each other. This would allow for there being two separate living spaces within a single part. This would be useful for the cargo bay, where you could have a node on the top of the part that is connected to a node inside the cargo bay that a docking port might be attached to. At the other end you have the same arrangement, but the two pairs are not connected to each other. I have no idea how exisiting parts and configs could be adapted to this new scheme or if there are other problems that would emerge (most likely), but there is a thought for you all.

Well relying of a supplier's certification has bitten SpaceX, so I can understand Musk being unwilling to continue along that path. The position this puts him in is that he wants to have struts that be can rely upon at the cheapest price. There are two approaches to this: 1) Buy them in and test them all (If he was willing to accept a failure rate then he could instead test some, but not all). 2) Make them in house (and test them as part of that process). It seems either way, if he wants to be sure the struts will not break then he needs to test them. Whether they are manufactured in-house or outsourced is a function of the costs involved.

I wonder how many such struts (or similar form the same supplier) are used in a falcon 9. If they had ~1000 on hand to test that suggests there are lots, and that means that a individual failure rate of ~0.3% would have posed quite a sizable risk to the F9 system as a whole.

When do we get to play?

That is an interesting complication - crewed pods with built in RCS might cause a bit of confusion. Obviously the best solution is for mod authors to provide a CLS config themselves. Are we going to get into a situation where we are asking mod authors to provide a CLS config to disable CLS in their part, as it is getting erroneously enabled by default? I can see that most mod authors would not be interested to do this. Also will it become harder to persuade mod author to provide CLS config if it mostly works by default, and the user can tweak the options however they want? I suppose there is nothing much wrong with this, but it does take away that aspect of "How did the mod author envisage this part would be on the inside?". These are not criticisms, just considerations. If there was a perfect solution to the problem of providing config for CLS I would have already written it myself last year!

I like this idea because it could be tied in with remote tech - so relationships between kerbals can develop in a certain way IF there is a communication link between their vessels. However such development is obviously not as intense as if they are sharing a living space.

I am not sure that adding CLS to ALL parts would be a good thing for CLS's reputation. If a load of CLS options that do not make any sense appear on parts such as RCS thruster blocks for example, then it is just going to make people think CLS is a bit daft. Having said that, I am not sure what the better solution is.