Tiron

Hey... I'm playing again. Using MFT, again. And it seems like it *really* doesn't like the FL-C1000 from Making History (Size1p5_Tank_05). The little 4 units of solid fuel *really* seems to throw it off. I'm constantly getting empty solidfuel, the solid fuel storage changed to 540 units (the size of the base LF tank), or even an extra oxidizer or fuel tank added in place of the solid fuel. it's... vexing, because I love the little things. No idea what the problemo is.

The way it acts I'm about half tempted to think it's getting stuck in a loop trying to parse the staging, but obviously I can't be sure. The game hangs, there's a bit of an increase in memory usage. Not exactly 'explosive leak' level, but enough to indicate it's *trying* to do something and apparently spinning its wheels.

Not sure but I don't think so? It only does it with Stagerecovery 1.9.1.2 installed. with 1.9.1.1 it doesn't seem to care *where* the parent part is.

Unfortunately, I don't have the broken version anymore... but I may have figured out another aspect of the problem just now. The root part for the lander was the engine attached to the plate, because it had to be to attach it to the rocket properly. I just re-added the plate to the lander for bottom cover purposes, and when trying to re-root it to the engine on the plate it's freezing up. Doing further experimentation now. Update: Yep, that's it. It's throwing a hang reliably with the EP-18 and EP-25 (haven't gotten to the others, as it's a slow process to test) if the plate's parent is attached to any but the 'top' node. Even just attaching it that way *without* a re-root causes an instant hang. Loading a craft set up that way, hang. Re-root it that way, hang.

Separate Craft File. Which didn't have any problems loading. I'd combined it with the rocket via the 'merge' function on the loading tool, and the combined craft had loading problems. Fixed now.

Immediately after updating to 1.9.1.2, I'm getting a game hang trying to load a rocket I was working on... that used a stock engine plate. Uninstalling or reverting to 1.9.1.1 both fix it. Gonna fiddle around with it some more, will report back. Update 1: Removing plate didn't fix it. Only other craft I had which used a (different) plate no problems. Going through stage-by-stage to try to isolate the problem. Update 2: Problem traced to merged-in lander containing artifact EP-18 (Forgot to remove it after opting to only use one engine). Original lander file loaded no problem. After Re-merging a new, plateless lander, loads perfectly. Other craft with EP-18 had zero problems loading, so I'm confused as heck.

Just a note to the people of the present viewing this old, old thread: The Pancakes don't work anymore. The stock aerodynamic model was VERY different at the time. I'll also mention something I didn't at the time: I had the entire fuselage of the Valkyrie behind the cargo bay welded together to reduce flopping and lag, which is why only the nose flexes when the nosegear hits. I'm pretty sure it would've taken the hit anyway but there would've been a lot more bending. We didn't have KJR at the time, and the stock joints were even floppier than they are now, so welding was the only way.

I came up with a fix for the LV-T45's bottom node, that makes it line up properly with the bottom of the nozzle. Quick modulemanager patch, just throw it in a .cfg file (it's also set to not do anything if Ven's isn't installed): @PART[liquidEngine2]:NEEDS[VenStockRevamp]:AFTER[VenStockRevamp] { @node_stack_bottom = 0.0, -8.1, 0.0, 0.0, -1.0, 0.0 }

It was the dumbest thing. Taniwha's script for making the .version files left the build field blank on release builds, and AVC's parsing apparently can't handle null fields. AVC actually *does* pick up the version file, and adds it to the count of mods installed, but can't parse the 'version' construct because of the null field, and thus it doesn't show up in the list. the file in question is: ..\Kerbal Space Program\GameData\ExtraplanetaryLaunchpads\Plugins\EL.version The problem is in line 5: "VERSION":{"MAJOR":5,"MINOR":4,"PATCH":0,"BUILD":}, You can fix it in about 5 seconds on an existing install of 5.4 by opening the file with notepad++ and changing it to either "VERSION":{"MAJOR":5,"MINOR":4,"PATCH":0}, or "VERSION":{"MAJOR":5,"MINOR":4,"PATCH":0,"BUILD":0}, Taniwha's modified his script so from the next version onward it'll automatically do the latter, and should work.

I'm wondering what it does if you land at KSC, but not KSC. ...You know, like here: (Single Stage Round Trip to Duna that didn't have enough fuel to make it to the runway after Aerobraking.) There's a launchpad and everything (don't recall if it had launchpad biome, but it did have KSC biome.)

I agree with the last part of the statement, although I'm unsure how much the fact you weren't around had to do with it Mostly me whining and Taverius pointing out there was an empty wiki that would be perfect for such things, and then awesome people jumping all over it.

Mechjeb plugin also has the same problem with the obt and tgt submenus...and the same solution. Comment out line 825 (as opposed to 862 for VV.) It's exactly the same setup as the VV one, but in the 'pluginSmartASS' page instead of the 'pluginVesselView' page.

Can't wait to see it. I got a lot of work to do on the planes still. The Delta-Deluxe replacement in the pre-alpha stuff works pretty well with it, the R8 replacement not so much (those being the two the planes were using...with NTBI wings from Taverio's Pizza and Aerospace, it matched pretty good. Not so much with Pwings, especially the B9 Pwings.)

Ah. Nice. I'm having to re-wing my principal (space)plane design (all four variants, whimper) because of a FAR problem with part of my wing arrangement, and the winglets I've got on it don't really match...

The heck stabilators are you using there and where do you get them?

()@% ()@*%)( @()%() @%() I figured it out. It's not anything with the actual layout of the plane, but purely how I built the inner wings, to get the shape I wanted. At the time, pwings couldn't handle a shape like that(without looking REALLY stupid anyway), so I built it out of a bunch of wing pieces. Five of TVPP's NTBI wings, to be exact. Four 2x1 wings, turned sideways, plus a 2.5x2 tailfin, also turned sideways. Something about the 2x1 wing panels being turned sideways induces a HUGE amount of N-Beta. And that's it, so far as I can tell. Time to try Pwings again I guess...sigh. This is going to be a LOT of work.

Actually if you hover over it, it tells you. Up to a point anyway. Just...not so much on the 'how to fix it' front.

RPM also doesn't give a crap if you've got a SCANsat part on the ship or not (I think it's supposed to check maybe from looking at the code, it's clearly not working if it is), but only gives you a rectangular, zoomable map (I really wish it had some way to change it to polar or something, it's almost useless for polar navigation because it gets so distorted that not only do the shapes on the map have little meaning, but so do general directions!) It actually makes sense that the multispectral does still return something if there's no biome, for both gameplay and realistic reasons. Gameplay wise...most planets don't have 'biomes' set up yet, but probably will eventually. It'd also give an even bigger incentive than there already is to install that mod that adds biomes to the other worlds. Realistically speaking, almost regardless of what is meant by 'multispectral', *some* kind of result is going to get returned. (RADAR not as much, and probably less usefully even if there was something in the two cases it generates a static map.)

I've mapped the entire System except for the Sun...although only with the low-res and the biome maps, as I haven't unlocked the SAR yet. It's the first time I've mapped everything at all though, and it's entirely thanks to being able to map at high warp. I'll admit that my description was unclear, there are two forms of 'static' you can get, which are very easy to tell apart by looking at them but somewhat harder to describe. The first is the 'out of power' type, which results in animated static that sort-of follows the scanlines and only appears on the small map. You can still kinda see the map through it at parts, because it kinda clears out right behind the scanline for a few moments? Or somesuch. The second type is the 'nothing to display' type, which you get from biome mapping anything that isn't Kerbin or its Muns, or from Altitude-mapping something with no ground (Jool and the Sun). It's...well, I want to say 'Static' but let's go with 'fixed'. It's clearly randomly generated, as it changes when the map gets redrawn, but it isn't animated. It stays fixed until you do something that causes the map to redraw. It basically looks like a screenshot of what you get out of an old analog TV that's been tuned to a channel that isn't there: random black-and-white dots. It's still helpful because it lets you see where you've scanned so far. The multispectral will let you turn the scans in for science even when all it can do is a static "map", but the radar will not. I've yet to manage to 'map' the Sun effectively, as I've yet to figure out a way to circularize at a low enough altitude. (Mechjeb wants 26 THOUSAND m/s to do it. Or was it 28? Whatever.)

To be honest, it's not the 'aerospace engineer' version we really need. We need the quick-and-dirty rules of thumb, shortcuts, and 'if this then do that' type stuff. It's like so many things in this game: knowing the 'What' is more important than knowing the 'Why', because there's umpty billion tricks and tools to figure out the 'Why' for you. The 'fly to the Mun' trick is a good example of this: Burn Prograde shortly after the Mun rises in front of you. You don't need to know WHY it works to use it. Even when you get into more advanced interplanetary transfers, you don't need to have a clue about any of the math or reasons behind a Hohmann transfer(or even that it's CALLED that for that matter), all you need to know is that you need to burn at the right Ejection Angle when your Target is at a particular Phase angle, and what the two angles are (which there's at least four ways to get that I know of.) FAR seems to already *have* the tools, it's just lacking in explanations for how to turn the data they spit out into useful design information. Edit: A good example in that thing someone posted up above: "Zδe is assumed to be correct for a standard tailplane design, so for canard designs it will be wrong." All my current planes have at least one thing showing up red, and they all use Canards, so I'm betting that's probably it. (no it's not, it's white.) Edit2: I'm also having a problem with one of my planes...I went to tweak a couple things slightly and...doing so breaks the simulations entirely. Works fine until I change something, and then boom, sims seem to just crash. Console's full of 'NaN' errors. Edit3: Okay, having read through that thing Thorfinn posted and looked at the stats on all four variants of my plane (which have some pretty large variances in how they're built), the problem seems to be coming from a large, very negative N-beta. I also just discovered you can hover over the individual stats to get a directed explanation of what they are and what they should be. Which is...somewhat more helpful. Still doesn't tell me how to fix it (something ferram said about a 'strong vertical tail', on the other hand...) Edit4: or not...changing the rudders isn't doing a bloody thing to it. It sticks on about -12.8 basically no matter what I do to it. Odd.

I can't add things to it if I don't understand the things in the first place, which is kinda the point. That said, if someone that DID understand it would add some stuff, it could be extremely helpful. Edit: I'll mention also that the instability of my designs is EXTREMELY minor. The SAS damps what little of it is there most of the time, and the only time it really gets to be an issue is when I'm trying to pull the nose up to gain some altitude after it's dropped a bit too low while I'm in a mach 4.9+ cruise at 20km+. It'll either yaw off, roll off, or both(generally in the form of one and then the other). I can correct it, but it takes a fair amount of fiddling. Once I've got the correction in it's stable enough that the SAS will hold it, although it tends to let the nose drop a bit below where I left it (which I can usually compensate for by setting it higher than I want it.) It's good enough that I can alt-tab out and only check on it every few minutes to make a correction once it's established. Changing the wings from one tick of dihedral to one tick of anhedral (fairly minimal change, and still looks good) reduced it a bit.

Okay, this I have to comment on. First off, for minor instability, the SAS still helps quite a bit. Second, it's a lot more useful than the flight aids, which I've never managed to get to do anything but interfere with the controls while still not really being effective. Third, there isn't a useful guide I've ever found as to how to use a fair portion of the stuff FAR provides. It took some effort to be able to figure out how to interpret just the static analysis, and it's literally the only thing I use in the VAB because the data+stability derivatives and simulation tabs I have no idea how to set up, and even if I did get it set up right, the results are just meaningless numbers to me. I've glanced at the explanations for what they are, and could probably figure out what the numbers mean if I really wanted to, but I didn't see a thing that indicated that I'd gain any understanding of how to do anything with them other than interpret them. Matter of fact, for the data+stability derivatives tab's help, the longitudinal and lateral motion tabs... I honestly don't know why 3/4ths of the stuff in those help tabs is even there. It's a lot of stuff about different aerodynamic motion modes (most of which I've heard of), but no indication at all of how that relates to the data. Only about a quarter of each of those tabs actually mentions anything that's included in the data itself, and that's just a key, with no indication of how to apply it. Explanations of Dutch Roll, the Spiral mode, Short Period Motion, and Phugoids are well and good, but not really all that helpful when trying to figure out which of the derivatives relates to the problem in question, let alone how to fix it. It's a lot of general information, when what's needed is specific information. What types of things cause problems with particular things, how to correct common problems, what numbers to plug in to the various fields in order to get useful results. The way most of it's set up presumes that the person using it already understands aerodynamics at a fairly advanced level. And if, like the majority of people you don't know squat about aerodynamics (or even if you know a small bit coming in), there's nothing to help you learn enough of it to be able to actually USE most of it. You seem to spend a lot of time diagnosing problems with individual people's planes: most of this thread seems to be composed of such. Hell, that tip about the anhedral helped my planes a fair bit. There's probably a bunch more stupid things like that I could do to make them less annoying to fly ('annoying' is the extent of it. They're a TINY bit unstable, not enough to cause crashes unless I do something really stupid, but enough to require some regular tweaking to keep them at a reasonably steady altitude and heading.) But I have no idea what they are, because there's no ready way for me to learn it. Other than pestering someone to death, which I don't really want to do.

Unless he changed it and I didn't notice, they'll still scan, it'll just come up as static. Which isn't entirely useless, as you can still get science for it. There's a mod that adds biomes to planets that don't have them though.

Shouldn't need to in future, with the changes to the dev version numbering specifically to fix that problem. As soon as Mihara updates it with the TargetOrbit change I was talking about, it should work without any effort with all future dev versions (until they do another change like that anyway.) I did get a fixed, drop-in replacement for the MJRPM built and working, since I apparently put the fix in correctly.

There's two downloads. One is just the .dll, one is the complete package, with the parts and whatnot. You only need one of them. The complete package (the zip) includes all the files just like the normal install package, the other is just the mechjeb2.dll itself. In theory, if you've already got it installed you should usually only need to replace the .dll, which is why there's a separate download with just the dll. Trick being, that presumes there haven't been any changes to the rest of it (which to be fair, there rarely are.) If there were changes to any of the rest, you wouldn't get them by just installing the .dll.