Starwaster

Forgive me for mixing references but.... It's the chain I go get and beat you with until you understand who's in ruttin' command here!

What I do about that is I stage the engines before engaging the autopilot. When it engages it brings them up slowly and then I release the clamps. (or, with Ferram's latest mod I've been letting them sit on the pad clampless more and more)

Galane's answer may have contained unnecessary information but aside from that, he told the other person correctly what to do (uncheck the option to limit to terminal velocity). The issue isn't that MJ is not deactivating something that the end user chose to deactivate. The issue is that at some point 'Limit to terminal velocity' was enabled and never disabled. When enabled, it is active regardless of the autopilot state. You can click the autopilot button all you want it; it's not meant to affect the other options which operate even if you are on manual control. Again, unless explicitly disabled again. Additionally, when you make changes to MJ settings they are saved globally. Again, by design. So the original poster might have originally enabled the terminal velocity limit on another rocket. It carries over.

No, there are five lights.

Eve isn't Kerbin. What gets off the ground on Kerbin might not be powerful enough for Eve. The gravity there is higher. You should always design your rockets around their intended usage. Likewise, what gets off Kerbin would definitely make it off Duna, but by designing it with Duna in mind you can trim some mass from it. That's the name of the game when it comes to rocket science.

No. Don't think so, it would need some config files written up for it; Not sure if anyone who contributes uses that parts pack.

It sounds like you are in Career Mode and have not unlocked it yet. Either that or your settings file is messed up. Does it work in Sandbox?

Note the aerospike engines. You get a lot better Isp in atmosphere. In fact (on Kerbin at least) sea level Isp is almost as good as vacuum Isp.

What, is that sarcasm? That is how MJ is designed. Throttle limiters are NOT the same as the auto pilot. Limit to terminal velocity is a throttle limiter. You have it engaged, that's obvious from your picture. It is SUPPOSED to possible for it to be engaged separately from the autopilot. (The box to the left of it is lit white showing it to be engaged. Click it to disengage and it will turn dark)

No my 'issue' is a little more complex than that but at least re-read the second sentence because it sums up a part of it more accurately than your interpretation.

That post wasn't sufficient. It doesn't change that a small group decided on changes that most were not privvy to because most don't frequent the venue where this was all discussed. This is something you need to proceed very cautiously on. This is development, not maintenance and I'm sorry if this sounds harsh but you should have expected the level of push-back that you got. It was predictable.

very nice. I have a question (largely aimed at Nathan) and I'm not sure that I'll be asking the right one... Is it possible to add flag decal support here? It requires two things. One is the flag decal module added to the PART. That's trivial and can be done with ModuleManager or direct PART editing. The second part is where I'm unsure. The mesh needs a second UV map? Or a separate properly UV map? Not sure which exactly. I think the latter. The mesh name is used by the the FlagDecal module to display the flag. It's really nifty but hardly any parts coming out use it. And no stock parts at all.

ok thats what I thought. I downloaded RPA 1.2 lite but it doesnt display thrust and my head is spinning and my browser has about 20 tabs open to assorted rocketry and NTR pages and equations and I just drew a complete blank

My head is spinning right now from too much maths. Please correct me if I'm wrong but if I know the Isp and the mass flow rate then can I determine thrust just from those? I forget. Also is mass flux the same as mass flow rate?

There's some quote on Project Rho's website... something about how fluorine stops being gentle and cuddly above a certain temperature....

You may be right but I've been calling them bubble searches for almost 20 years now. *shrug*

argh you ninja'ed me. I use Notepad++ Use it and you won't regret it. This is how I found the missing } First, because I had that problem myself once I suspected it could be an issue here so I just searched first for the { then for the } and Notepad++ told me how many of each it found. Then I selected the first half (making sure to end my selection BEFORE it included the beginning of another part so I was only selecting complete PARTs) and searched again. When I still got a mismatched number of braces I knew it was in the first half. So I selected the first quarter and searched again until I narrowed it down. That's what programmers call a bubble search. Only they're meant to be done by programs and not people, but meh, the concept works for the meat just as well as the silicon. Narrowing it down within the part I just did by going down the line properly indenting with tabs. Notepad++ has a special way of connecting braces when you indent with tabs that makes it graphically obvious where the missing brace is. (the connecting line ended in a place that had no brace)

You definitely have a problem in engines.cfg and I have seen mismatched braces break the game. The problem is in the liquidEngine3 part. You need to insert another } between line 1637 and 1638 (it's easier to see with proper indentation) I had to search the document bubble search style to locate that.

Nah I just tested it; tried to break the game that way and it loaded ok. I also found a problem in his engines.cfg There's 1,262 { but only 1,261 } That WILL break loading for sure. (the first one with the RESOURCE being all inline I'm not sure breaks loading, it might just break parsing. I forget what happens if you do that) Anyway I'm not sure where the missing } is gm537, where possible make a new config file instead of editing the existing ones. I can sort of see why you did it with the engines.cfg, looks like you rewrote large parts of it but the resource declaration could have been in a single file by themselves. For instance, the corrected RESOURCE node that I pasted in could have been in their own file, and it makes it easier for others to troubleshoot your stuff.

Don't do this. RESOURCE_DEFINITION{ name = DiFluorine density = 0.00753 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP} RESOURCE_DEFINITION{ name = Lithium density = 0.00256 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP} Do this. RESOURCE_DEFINITION { name = DiFluorine density = 0.00753 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP } RESOURCE_DEFINITION { name = Lithium density = 0.00256 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP } Not sure if there's any other issues I'm still looking at the files. <snipped the part about the line breaks in front of the first bracket, just tried it out and it didn't seem to break anything> Edit #2: BTW, breaks / returns between the full node (that is between the final brace and the next node) are OK.

I think you should provide some snippets demonstrating what you tried to do . And what do you mean the loader got stuck? Did the game actually fail to run, is that what you mean? Edit: Wait, I see that you posted some config files....

I'm not seeing how replacing the DLL file itself is prevented by program design. That's what's being talked about.

What mods are distributing actual modified ModuleManager.dll files?

I'm finding the current implementation simple enough. Even testing your 1.4.x would require me to copy your dll to too many folders and then deciding where to move too many other config files from where they're currently at. Too much work to move from a system that just works. Too much needless complication to solve a problem that's trivial at best. Non-existent at worst. But the thing is, after all the objections raised, you still say you don't understand then where do we possibly go from here?

Uploaded new definition files and probe science files. Probes get their own sample collection now which they analyze and transmit the results back to Kerbin. I don't think they can collect samples in quite the same way as Kerbals; the container module is for Kerbals on EVA... That is to say, the container module is for Kerbals to store samples while on EVA... the EVA aspect can be turned off but I'm not sure what effect that has on the probes if I were to try to attach the container to them. (A Kerbal should be able to store samples on the probe but can the probe store samples on itself?)