Gaius

Better yet, use "\s+" to match one or more of any whitespace character.

It's making no attempt to turn anything off merely if a vessel is no longer controlled. You're right, that would be an extraordinarily bad idea that would interfere with many useful things people do with MechJeb... but that's not what it's doing or trying to do. If you can do that, that would work. Does KSP/Unity send some last notification to a vessel's parts/addons before packing it away into another's structure?

It's already in there. I use the following code in my "generic" launch script: if stage:solidfuel > 0 { when stage:solidfuel = 0 then { print "SRB separation.". stage. }. }.

Yup. Didn't happen first time I undocked, I undocked a few times before it happened -- I presume its triggered by an undocking which, in previous versions, caused the undocked craft to immediate start doing something because Smart A.S.S. was still on and set some way. But yes, at one point I hit undock and MechJeb just disappeared entirely, all windows and even the side menu tab. Only way I could figure out to get it back was to edit the global settings file and reenable the menu module. Not sure if I needed to restart but I did. Possibly I could have gotten away with quitting to the main menu, editing, and going back? Anyhow, I've dropped back to the previous version for now. I'm always fiddling with the setup of my stations, so I do an ungodly number of undockings in a typical session...

Probably be a while until you read this, but I just thought I'd mention, having seen it in action... ...this is probably overkill. Leaving Smart A.S.S. open, but switching it to "OFF", was more or less what I was thinking when I mentioned the problem of undocking ships smashing into things. Disabling all modules, including the side-menu (MechJebModuleMenu) so that it appears MechJeb has been uninstalled, is a bit on the extreme side. Quick question for the peanut gallery: is there some way to get MechJeb back in-game if MechJebModuleMenu is disabled? I got it back by hand-editing the mechjeb_settings_global.cfg file to change "enabled" from "False" to "True" in MechJebModuleMenu, but that's a bit cumbersome...

No problem here, definitely says 0.5 on bootup.

w00t! A big thank you, and enjoy your trip!

It's confusing, tbh. You may or may not have to adjust node positions, depending on what else you changed and how you did it. In theory, rescaleFactor adjusts node positions proportionally. In practice, it kinda depends on what other numbers you may have fiddled with. I think that if the only thing you changed was rescaleFactor, and the model's scale isn't weird, monkeying with the node position numbers shouldn't be necessary, they are scaled with the rescaleFactor, in theory -- it used to work that way but I'm not sure that it still does. I do know that now, if you changed any of the other scale numbers... the interaction gets weird. Particularly if you monkeyed with the MODEL scale numbers. In one particular resize I did, I had to modify the scale numbers by 0.5 to cause a rescaleFactor of 2 to place the nodes in the intended position using their original numbers -- this is because the model was rescaled by the square of rescaleFactor, whereas the node numbers are simply multipled by the rescaleFactor, when I was monkeying with the MODEL scale. Or maybe they were interacting with both. Still not exactly sure, if you don't monkey with the MODEL scale -- I'm not honestly sure what it does -- could work the same way, but I've never tried it; I'm always playing with the MODEL. It's weird, but the point is, you don't have to modify the node numbers if you play with scale and rescaleFactor in such a way that the numbers balance out. Whether that's easier or harder than just adjusting the node numbers depends...

There are two kinds of bad programmers, those who use GOTO (or whatever passes for it in the language in question) when they shouldn't, and those who refuse to use GOTO when they should. The latter tend to be more annoying, because at least the former will admit they're doing it wrong; the latter are more dangerous because they often refuse to admit that they have some very bad coding habits they need to work on. Trying to correct them is like questioning anyone's religious beliefs -- those who truly believe GOTO is the Devil will not listen to any reasoned arguments on the subject, it's heresy. The dogma must be upheld at any cost... in the idealized world they live in, exceptions simply don't exist. Those who admit to exceptions are salvageable -- they're okay with GOTO statements as long as you spell it "THROW"...

Right. They don't need an oxidizer because they don't actually "burn" their fuel, they just heat it and expell it. It's not really "fuel" at all, it's reaction mass. That said, hydrogen is commonly used for this, and it's also commonly used as liquid fuel in many bipropellant rockets, so the case could be made for simply using liquid fuel tanks for the nuclear engines in-game. But they didn't do that. This is nice, in that we can use all the game's normal tanks this way, but a better solution would be to use the right "fuel" for the engine, and make tanks configurable -- you pick what you want to put in the tank in the VAB. Haven't you ever wanted a big orange tank full of monopropellant? No? Well, anyway, that'd be the ideal solution. Maybe we'll get that someday down the road...

Indeed. I often wish MechJeb would jettison my fairings at >69k. Sometimes I'm not really paying attention (or am literally afk), and if I come back with the ship in orbit and the fairings still on, ejecting at that point creates debris that needs cleaning, whereas ejecting on time usually leaves it sub-orbital so it just takes care of itself. Don't know if that requires a full blown stacking commands functionality, perhaps just a checkbox that says "Stage as leaving atmosphere" or something like that. Obviously you'd want to leave it off if your vehicle doesn't have fairings to eject... A bigger nifty, though, would be to get the delta-V calcs for stages correct. Often my "stage dV" displays as 0 when I clearly have plenty, and the stage before you eject fairings is one that's dV display is always broken... not a BIG deal, but annoying. The bigger deal is rockets that display 0 dV on their last stage or two. Bad enough when you're building the rocket and you can't see what kind of dV the probe at the end will have once it's on that stage, but worse when in-flight it just can't figure out your dV, and there's no apparent reason why it would be confused, there's no more stages to consider or anything, it's just a probe with a fuel tank and an engine. Straying further off-topic with my gripe list, there's one big one that I'd kill to see fixed before anything else: stop my bloody ships from spinning around and smacking the space station the moment I hit "undock". At one time, I could have sworn, MechJeb's Smart A.S.S. would simply default to "off" for any ship that undocked, but there was a serious regression in behavior some months ago, and now a newly undocked ship, which you're not in control of, will have its onboard MechJeb suddenly engage in violent maneuvers the moment it undocks as it tries to do whatever it thinks it ought to be doing, and there's simply no way to switch to the ship quick enough to stop it from smashing itself against the side of the station sometimes. I notice this doesn't happen if I quicksave and then reload the game before undocking, but if I've been repeatedly docking and undocking during the same session (as I was the other day as I reconfigured an assembled-in-orbit station), undocking a previous docked craft causes its Jeb to run wild. It appears to have its settings something like what they were when it docked, but often they make no sense anymore, like it's trying to align to a target, except you now have a different target than you did when you docked, and it decides it needs to point in a completely different direction RIGHT NOW. Other times I swear it's getting confused about which ship it is -- it'll adopt some Smart A.S.S. setting that I'm pretty sure a completely different ship had that docked previously. In any case, it doesn't help that my station tugs are designed with enough torque to manhandle heavy station components, so when they're undocking with nothing in tow, they can spin around with incredible speed and force. After a few explosions, broken pieces, and craft nearly kicked out of orbit, I just got into the save/reload habit before each undocking, but it's a pain... if I had to pick just one thing to get fixed, it would be that. Gripes aside, I do love this mod. As complex as it is and as much as it does, obviously it's going to have some rough spots, but overall it's an insanely great piece of work. Gotta love it...

Yeah, there seems to be a bug in the parser. The first three statements work fine, but the fourth causes an error. set pitch to 20. set pitch to -20. set pitch to 20 - (altitude / 1000). set pitch to -20 - (altitude / 1000). Unrecognized term: ''. // But this works: set pitch to (-20) - (altitude / 1000). // But this does not: set x to (-y). Unrecognized term: ''. Go figure...

These work like the stock LV-N engine, using the regular LFO mixture for fuel. That's wrong, but until Squad makes the game actually do NTRs right, it's probably best to just stay compatible with stock... What I don't understand is, why didn't Squad just make the LV-N use liquid fuel alone? Using the same fuel as a jet engine isn't realistic either, but it's less unrealistic than requiring that same liquid fuel and an oxidizer on an engine that doesn't actually "burn" its fuel.

yw... sorry I couldn't be of more help. The symptoms you describe were exactly the ones I was experiencing before I noticed the file structure as I'd installed the mod was wrong, with some parts loading fine and only those particular parts failing to load, so I figured it must be the same issue. Have you checked the error log? That often gives clues as to why some parts won't load -- it will say something along the lines of "failed to compile part" for each one that doesn't load. Clip out the dozen or so lines around the error and post it here, maybe we can figure out what's happening...

It's the end of the UNTIL statement where you used an unrecognized operator. There's currently no "<=" or ">=" operators in kOS, you need to rework the logic using only "<" or ">". I also have no problems with external editors. I prefer "joe", but you can use your evil editor if you prefer... Incidentially, open a terminal and just type: print 1>2. (notice the output) print 1<2. (notice the output) print 1>=2. (notice the error -- look familiar? I suspect your problem has nothing to do with the external editor, it's just the lack of support for that operator)

I had that happen the first time I installed it. If you're like me, you saw the .zip contained a folder named after the mod, as per 0.20+ style, so naturally you dropped that folder in GameData. That won't work. The .zip actually cannot be directly unpacked into your KSP folder like most mods, because inside that mod-named folder is a GameData folder, and inside the GameData folder is yet another mod-named folder, and the pathnames in the config files assume the top-level folder inside the archive does not exist. Dig the deeper mod-named folder out and put it in GameData and it'll work. Alternately, if you're using an unzip program that lets you drill down and selectively unpack a subfolder inside a .zip, you can just go down a level and unpack from there. You just can't unpack the archive as it's currently structured and have it work correctly (without further file management), since the top-level folder shouldn't exist at all (it's at the level that KSP_win should be at, if you were packing from that level... which you shouldn't, since it's named differently on different OS versions of KSP). tl;dr: Go into your GameData folder, and into your RLA Stockalike 0.6, and you'll find yet another GameData folder, and inside that, yet another RLA_stockalike folder. Pop that folder up two levels, delete the gratuitous RLA Stockalike folder, and all will be fine.

Cute as a duck? Indeed it is.

I was just doing that, or rather, was looking in the config to get the name of the part so I could add the modifications to my ModuleManager config file, when I noticed to my horror that the "name" parameter (not "title", the human-readable string) has spaces in it. Alas, this breaks compatibility with ModuleManager and apparently other mods. The internal object names aren't meant to be human-readable, and should really follow Unity object naming conventions. Alas, fixing that would break existing flights and craft files, so, gah... well, just letting you know.

Correct me if I'm wrong, but isn't the main problem with ISA MapSat is that it loads every single map texture it has into memory? The mod seems to work fine when I first start using it, and make my first map of Kerbin, but the longer I keep using it, and the more planets I map, the worse the performance gets. Last time I was using the dev build, I had mapsats around Kerbin, working fine, Mun, working fine, Minmus, working fine, Moho, starting to drag, and Duna, um, oh dear... and I was forced to uninstall the mod and go back to 3.3.4 to stop my game from crashing constantly. Sure, any mapping mod has to have a big texture around for the body being mapped, but it doesn't need a huge texture around for every single body in the universe at all times. Also, were you switching probes while checking for memory leaks? I never had any problems with MapSat gradually consuming more and more memory while I just left it running, mapping a body. It did that without problems just fine. It was just when I was switching back and forth from mission to mission that things would start going south and eventually lock the system or drag FPS so low it was essentially useless... if MapSat wasn't leaking memory on mission switches, I'm not sure what else might have been, but I suppose it could be some other mod, and the increased memory use of MapSat just aggravated the issue that was actually caused by something else leaking memory.

Okay, the old numbers were OP, but this seems also wrong, except in the other direction. The stock PB-NUK generates 0.75 E/s with a mass of 0.08, yielding a power/mass ratio of 9.375. If power per kg was just kept even, a 3.2 ton generator would yield 30 E/s, and a 6 ton generator would get 56.25. But realistically, efficiency should improve slightly as generators get larger (compare the watts per kg ratio of a SNAP-19 vs. a BES-5 Buk, for example). It should never go down, or you'd just wrap a number of PB-NUKs together in a larger package instead (indeed, some larger batteries in real life are just arrays of smaller batteries if you open the case and look inside). I'd recommend something along the lines of: G60M: 20 E/s, 2.0 tons (6.7% better power/mass ratio than the PB-NUK). G120XL: 80 E/s, 7.5 tons (13.7% better power/mass ratio than PB-NUK). This way, you get higher power per kg efficiency with the larger units, but within reason. Also, IIRC, the G120XL is like double the radius of the G60M? If the height is equal, it should be roughly four times heavier (double the radius of a cylinder increases the volume by four), but I think it's not quite as tall? Anyway, maybe they have different densities/more empty space/padding in one or the other, that's not too important, but yeah, something like these numbers would be a lot more realistic.

What would be really cool is a fairing side with CORE Anvil textures that works with the Procedural Fairings mod. Would really just need the one side-piece, and I think it'd just be a matter of making the texture and a config file that references it, everything else needed is in that mod already.

BTW, I think this goes pretty well with the CORE Anvil V rocket. They're both bright white and... rivety... is that a word? It is now! [table=width: 500] [tr] [td][/td] [td][/td] [/tr] [/table]

Is there some way (or could some way be added) to set how aggressively the computer tries to turn the ship? I have a rocket that if I tell it to roll over to -60 at 8km, it's literally clear of the atmosphere before it finishes the turn. Using manual control or MechJeb, it turns to whatever angle I want in seconds rather than minutes, so I know the rocket's capable of turning much more quickly, the kOS computer just doesn't want to turn it. Also, there does seem to be an issue with one of my rockets where it appears kOS is trying to turn it based on the orientation of the root part rather than the orientation of the active ("control from here") module, or the kOS module itself. This is problematic, as the root of this particular assembly is a rover that for various reasons is packed sideways under the fairings.

Nice! One suggestion: one of the flight statistics it would be nice to have is ATTITUDE (not to be confused with ALTITUDE), a vector describing the ship's current attitude, allowing you to make relative adjustments, e.g. LOCK STEERING TO ATTITUDE + R(0.1, 0, 0) or something like that...

Now we need engines that sound like a Recognizer.