Tiron

If you transmit something after extending them, they retract again when they're done transmitting. He was looking for a way to stop that and just leave them open.

Far as I can tell, there's no way to lock them in place. best you can do is put them on an action group and re-extend them when you're done transmitting. No, the external seats don't work like pods for data storage. They act like you're still on EVA: you can take surface samples and EVA reports without even leaving the chair, and if the rover has a transmitter, you can transmit them directly, too.

First, there is such a thing as 'Fake Difficulty'. In general, Fake Difficulty consists of things that make a task in a game difficult that aren't actually related to the difficulty of the task. Bad camera controls, lack of information, lack of feedback... a few examples. Sometimes developers add them on purpose, in order to extend gameplay time or make a task more difficult that they're either unwilling or unable to make legitimately difficult. KSP has a few of these, almost entirely because it's incomplete. The high drag losses are an example. They're caused EXCLUSIVELY by the invalid and ridiculously unrealistic placeholder drag model the game uses. My original, stock aero, hypersonic transport plane had a top speed that increased from 1600 m/s to over 1900 m/s, and a maximum altitude for full throttle that increased from 23000m to over 26000m as it burned off fuel, because the fuel tanks have lower drag when empty than they do when full. This means that, for example, you could vastly reduce your drag losses by using the realfuels subbranch of modular fuels to switch to Liquid Hydrogen fueled rockets, which is absurd. The sad thing is that, unrealistic as it is, it doesn't really substantially increase the difficulty. You just need a slightly bigger rocket, and the primary limitation on building bigger rockets is the single-threaded physics limiting the ability of your system to run a high part count. It also vastly reduces the effort required to design an effective rocket, increasing the utility of things like Asparagus Staging and making Pancake rockets viable. As for the SRB thing...the lander can is really really light, and the SRBs have a really, really high TWR. Also, 'Flat Front increases drag' isn't universally true: At high enough speeds it can actually REDUCE drag. Many rockets these days use a device consisting of a small disk on a spike sticking out the front of the rocket. It reduces the overall drag by creating a sort of wake that encompasses almost the entire rocket. It's a principle similar to supercavitation, and also similar to the blunt-body method of designing re-entry vehicles. The lander can on top of SRBs would realistically do something similar, although not as efficiently as using a smaller surface further out in front: the lander can would have enourmous drag on the face of it, but everything behind the front face would be within the low-pressure wake and have very low drag, once it got up to speed. To a point, anyway. It's also possible that it was a bug in FAR that got fixed in the meantime. I'll have to try this myself when I get back to Kerbin.

FAR's actually a crapshoot, difficulty wise. Yes, it cuts delta V to orbit by about a quarter. It also makes design and piloting much, much harder. Screw up either, and your rocket is going to end up with the wrong end pointing towards space, just from aerodynamic forces. You can literally end up with a completely intact rocket that's flying backwards because you gravity turned too hard. Or a really bad, inefficient trajectory, because you didn't get turned enough. I've had a lot of problems with that in 0.22, because my rocket designs so far have had really high thrust and speed, and thus really high aerodynamic forces that limit their ability to pull a gravity turn. Planes are an order of magnitude more difficult than rockets because stalling suddenly matters, going supersonic actually changes how your plane develops lift, any amount of stalling can put you in a spin that is completely unrecoverable... There is one thing you don't see mentioned as often too, but it comes up: the changes in the drag modeling work both ways. FAR makes it possible to go much, much faster at low altitude. For example, if you're coming in to Kerbin from the Mun on a really steep trajectory, it's entirely possible to hit the ground still doing well over 1000 m/s. It's also entirely possible that your design won't ALLOW you to keep it in a high drag orientation: Planes for example, if designed to be stable, will correct themselves to fly nose-first once the drag gets high enough. This makes re-entry somewhat more challenging, because you have to make sure that you can actually get slowed down enough by the greatly reduced drag. Pair it with deadly re-entry and you could have some serious problems, re-entry wise.

Yeah. As I said, it reduced the per-engine fuel consumption by about 0.15 per second. Which is...not much. The plan was to see how bad the delta-v loss was after adjusting the fuel allotments but that's on hold, at the moment.

This is probably caused mostly by changes to the CoM. I've got a manually welded B9 body that I made, before the plugin came out. The modifications to the CoM changed the handling slightly, but in particular, FAR really, really hates the 'CoM offset' .cfg specification. My first attempt used it, and resulted in the plane's performance not conforming to the statics. Having set the origin to the CoM instead of using an offset it works almost the same, but because of the lack of CoM shifting as fuel drains the empty performance isn't quite the same. Just a limitation of the welding itself, not really a compatibility problem.

Could that be my problem then, since I use FAR? I mean, the Sabre-M is a seriously big engine (640/860 kN depending on mode), although this is a FRACTION of what the real one it's based on is actually supposed to do (maybe that's why it's -M instead of -L?). The 1960/2940 kN it's supposed to be capable of would be SERIOUSLY overpowered, if it didn't just flat out break things. My 'problem' is mainly that the fuel consumption roughly QUADRUPLED going from MFS 1.3 to MFSc 1a. I'm sorry I wasn't clearer about this, but I pulled those numbers by changing the ratios in the .cfg file with everything else being v1a standard. The original MFS used 13/87 as the LH2/IA ratio on the Sabres, and changing it to the 37.7/62.3 from v1a (roughly tripling the LH2 side of the ratio) quadruples the fuel use, with all else being equal. Honestly, my personal suspicion is it's one of those cases where so much else about the engine varies from reality that it's hard to use any of the 'realistic' numbers, especially given the fact the entire game's scaled down. I am curious as to where you got that '23 to 1' number from, because when I was poking around their site they listed a fuel/air ratio of 0.08 (or roughly 1 LH2 per 12.5 air). They don't specify how they arrived at that, but when talking about the LACE further up the same paper they mention the stoichiometric ratio being 0.029, which according to some other stuff I found is actually a rounded-off version of the stoichiometric ratio for hydrogen/air by mass. From what I can tell from the paper, it uses more fuel than air because they use up some of the LH2 cooling the intake air and powering the turbocompressor for it, although less than a LACE did. And it sounds like they shove that excess hydrogen into the outer part of the engine and burn it in that outer-ring bit, which is supposed to be some kind of weird pseudo-ramjet or something. Or somesuch. I'm just a computer tech, I'm learning this crap as I go. Edit: Ooo. One thing is certainly much better in v2. The folders are much cleaner! I only had to remove one 'source' folder, it took like maybe 10-20% as long to get it installed as a result. Kudos! Edit2: Fuel use on Sabre-M now about 2.09/s in air-breathing mode with v2 setup. let me just quickly pull FAR out and try it to see what that does... Edit3: Not a bloody thing. I really think it's just the ratio change. :|

He said it was based on the 2.0.9-80 dev version, which includes all the changes from Sarbian's temporary fork, which has been shut down due to r4m0n's return.

If you do it right, it's pretty easy to get the Camera to clip through the ground. Doesn't mean they're easy to FIND. Even the X4R1 version of Mapsat has a limit to the resolution. It'll get you close, but there's a whole area that'll look like you're right on top of the dot, and it can be anywhere in that area. Depending on how far down it is and the structure of the surface where they're at, they can be hard to spot even with the camera clipped through the ground. If it's say, just under the surface on the very steep side of a mountain outcropping, it's going to be hard to spot. If it's just under the surface at the fairly flattish bottom of a depression, it's not too bad. If it's about 10-50 meters down, particularly if it's under flattish terrain, it's pretty easy. Too far down and it gets hard to spot at all just because of zoom issues.

Okay, so I poked at things a bit and quantified the actual numbers involved. In air breathing mode: With the original MFS 1.3 ratios, the Sabre-M burns ~0.6 LH2 per second. With new MFS v1a ratios, the Sabre-M burns ~2.35 LH2 per second. 391.7% of the original value. Which is funny, because the ratio only increased by 290% (37.7 versus 13) The original, LF/LOX version of my Valkyrie SSTO had 920 units of LF to get up to speed and altitude, and retained around 2000 m/s delta-v on reaching orbit. The original switch to LH2/LOX reduced that value quite significantly: The lower weight allowed a more aggressive, more efficient ascent profile, but the reduction in total Delta-V more than made up for it. Adding an extra fuel tank got the delta-V almost back up to the original value, and was still quite lightweight compared to its original design weight. It also needed only about 600 units of LH2 to climb to speed and altitude. Really more like 500, but I tend to be a bit conservative. With the new version it blows through that 600 unit allocation at right about 10000 meters. I estimate the the LH2 requirement to maximize speed and altitude to be at minimum 1750 units, and probably more on the order of 2000. The total volume available for fuel is 22,410 after adding the extra tank.

Okay. Based on my first test flight, total Delta-V loss (After reaching orbit) on the Valkyrie from old MFS 1.3 to new MFS 1a is a little over 27%. This is attributable to the massively, wildly, insanely higher fuel consumption on the Sabre-Ms in air breathing mode. In MFS 1.3, it took about 500 units (Though I gave it 600) of LH2 to get up to speed and altitude. In 1a, I was at 1550 units and still slightly underspeed when I cut it off and went for orbit anyway. Additionally, a mission in progress prior to switching versions lost an engine on takeoff and had to emergency abort back to KSC as a result. This flight, in new version 1 (not 1a, yet), was barely able to make it back to KSC on well over 8000(I think close to 9000, actually) units of LH2. In part because it spent a lot of time, and fuel, wallowing at low altitude due to the difficulty it had in climbing with asymmetric thrust(including one flat spin I had to pull it out of, and several more that I barely averted). I have screenshots demonstrating total fuel consumption of 7358 units of LH2 to fly back to KSC and land, a total, direct distance of ~385 KM. With course deviation, planetary curvature, and landing approach etc it was probably closer to 450 or 500km actually covered. Note that when I started the flight with old MFS 1.3, I only gave it 10000 units of fuel. My first screenshot shows it climbing through 9900 m with 8238 units of fuel and a TWR of 1.89. I'm pretty sure I had at LEAST 8700 units on the ground, and I think I had a fair bit more than that. The flight to get there was more efficient than the flight back, but still. I flew out there, circled around, found a landing spot, and landed, on something like 12% of the fuel it took to fly back, using a very excessive two engines on the way out and one on the way back. That's 'switch back to the old version' worthy right there, so I hope to god that's a bug or miscalculation of some sort. And could you explain how '23 to 1' (95.833:4.1667) turns into 62.3:37.7? Even accounting for the different densities (Which I would've thought the original ratio already did) that seems extreme, especially since air has less oxygen in it than LOX. As for that, I've noticed two other, much more minor issues. Configuring a fuel tank for a Sabre has gone from 'mildly annoying' to 'fair pain in the butt'. They don't show up as options on the autofill, and before the easy answer was to just attach a radial engine to the thing, reconfigure it to LH2 and LOX, and then use that to set the ratios. Now, none of the radial engines and what seems to be very few of the inline engines are able to be reconfigured to LH2/LOX, so sticking something on temporarily just to get the autofill to work has gotten a whole lot harder. Second, just like the old version, the archive is a mess, with a .git folder, two source folders, and THREE copies of the DLL, plus Mac OS '.ds_store' files scattered all throughout the stuff in gamedata. On most mods, that kind of stuff is put in a separate top-level folder, usually called 'source', so that you can install just the gamedata bits and not be mucking up your game with a bunch of crap it can't use. The current setup makes that a bit of a chore, because most of the subfolders have at LEAST one extraneous bit.

I got just the folder. Although it's a body, not an engine (bunch of LFO tanks, an SAS, and a tail welded together), so it's really a fuel tank. Already got the config set up though, just wanted to know if I could split it out.

Yeah, trick being both my SSTOs being SSTOs use Sabres, so LH2 and LOX, not LF/OX. at least, not since I started using the original modular fuels a few days ago. The initial switch cut the delta-v by quite a bit, but adding a fuel tank to each plane pretty much solved it. It was going from original setup with LF/OX to Modular Fuels setup with LH2/LOX that cut my delta-v, not your update (though I haven't checked it yet.) Also, since I need to add a .cfg entry for my welded body on the one, can I put them in my own .cfg file that won't get overwritten by updates? In other words, is it set to read any .cfg file in there, or just the ones that came with it?

Well, Sabres. The one's not so easy to add tanks to because they're welded, it was too flopsy without it (it's still a bit flopsy WITH it, frankly.) I'd already added an extra tank to both of my spaceplane designs to compensate for the lost Delta-V, making up the rest with their more efficient flight profiles from the reduced weight. I'm going to have to check them both to make sure that with all the changes they still work and have acceptable amounts of delta-V. I've also got to recreate the cfgs for the welded body of the one, because I just deleted them without making a note of the values. Bleh. Can I add them to a new .cfg file I can stick in there, or do I have to put them in one of the existing ones?

Oh. Well w/e that's easy then, but I still have to see how messed up the Delta-V is again.

Uweeehehehehe. Okay, it's not confusing now. Although if Sabres are now Configurable, I'm going to have to fiddle with my planes...again...I added a fuel tank to both of them to accomodate the fact the LH2/LOX has a lower Density

Yeah, I was a little whiny, sorry about that. I get that way when I'm frustrated. Glad to help, though. Took a bit to track down, the first couple times I looked at it I didn't notice the Sabre S had the @ on the ratio and the Sabre M didn't. But then I don't really know modulemanager syntax so I didn't even know until then what the @ meant. Fixing it DID help my plane quite a bit, I managed to get roughly the same Delta-V to orbit after having added another fuel tank, and suspect I could improve it more by optimizing my flight path better. Fixing the LOX ratio gave it about another 600-800 m/s or so. Not as much as I'd hoped but still quite helpful.

If you're not getting the compass (Circle Drawing Tool type) icon in the lower left corner, in my experience this is usually caused by incorrect installation. If you're using the one off spaceport, well, it was designed for like Version 0.18 or so, so it's going to take some work to fix, and I've no idea what all. The X4R1 Version is linked in this blog post: http://forum.kerbalspaceprogram.com/entries/414-0-20-Dev-build-of-Mapsat-4-available-and-blog-update To get this one working, you need to remove all old ISA Mapsat parts. In particular anything lurking in Parts or Plugins in KSP root related to mapsat needs to be removed, or it will probably exhibit the problem you two guys are having. You then need to put the 'Innsewerants Space Agency' folder from the zip into Gamedata. If you put the parts and plugins folders from it directly into the folders in KSP root, you'll have the 'no icon' bug once more. Also, while you're at it, go into 'Innsewerants Space Agency\Plugins\PluginData\ISA_MapSat' and DELETE the Hilo.dat file. According to Innsewerants you can do this even if 'update hilo.dat' is not checked and it will work fine. I was the one that originally came up with the 'delete hilo.dat' method and specified that you should turn the update on first out of an abundance of caution. IS says it's not neccessary, though: that just has it check for new planets and update if there are. The next time you load a ship with a mapsat part, the game will appear to hang on the loading screen for some time while it checks the planets and rebuilds hilo.dat. How long depends on your system, I'm told it can be up to several minutes, so be patient. This is strictly a one-time thing: even if you have 'update hilo.dat' checked, it won't do this again unless you re-delete hilo.dat (or if you have update checked, automatically when a new planet is added.) The bit about cleaning artifacts.dat is only neccessary once you've started scanning, and uses a batch file that was posted some ways back, I've linked it several times for people but don't have the link handy. The X4R1 version tends to put a lot of duplicate entries in for anomalies, that can cause severe lag or crashing when you enable the anomalies display for a planet with a lot of duplicate entries. The batch file cleans the dupes out and eliminates that. Edit: And yes, the X4R1 version uses ~700MB of Memory, maybe a bit less. ~600MB of that is the very large map textures, apparently due to a general problem KSP has with texture memory usage. My testing shows that it's invariant, and the size is consistent with every step involved in getting the compressed map textures loaded into VRAM is being cached for no particularly good reason(Which seems to be support by some testing I've done). There's an included, very small, png file that's used for blank maps, but planets being scanned or not scanned doesn't seem to vary the usage (which is extremely wrong given that very small blank texture.) That ~700MB is constant, so long as you've loaded a ship with a mapsat part on it. The map textures aren't loaded if you haven't loaded a ship that has a mapsat part on it yet, so the memory use is about 600MB lower if you haven't used Mapsat yet this session. This is the cause of most people's complaints that trying to use mapsat crashes them: They install mods up to their memory limit, but inadvertently base that on not having the map textures loaded. When they go to use mapsat, the extra memory used by the maps crashes the game, and they end up blaming Mapsat for it basically because Mapsat's doing the right thing and not hogging up memory unnecessarily all the time (As much as KSP will let it, its memory usage for textures really is terrible). 3.3.4 has much smaller, less detailed (and less useful) maps, and so uses much less memory. Personally, I'm just hoping Mu's optimization package helps the texture memory usage in 0.22 and this won't be an issue anymore.

Ugh, this is confusing...I just started trying to use this the other day. I see it hasn't been updated in quite some time, and there's like at least 2 or 3 people that appear to have forks going, with Nathan saying he was going to make a new post 'soon' several days ago. Trying to figure out what to use, not having read most of the thread (and not going to, there's too much for someone just jumping in), is just confusing, so I haven't used any of it thus far. Now I find that possibly part of the reason the Delta-Vs on my spaceplanes is ruined so badly despite the much better performance (using a lot less on ascent) is that the burn ratio on the Sabres doesn't conform to what's in the config files. They're burning 40% LH2 and 60% LOX. I have no idea why, google doesn't come up with anything useful. There doesn't seem to be any good 'starting point' for someone just starting to use this mod to find information on the various fixes for it at all. I'm strongly tempted to just uninstall it, and maybe check back in three months or so, see if things are more usefully collected at that point. Edit: Okay. Only the Sabre-Ms are jacked up. They've taken every change from the B9 Modular Engines.cfg EXCEPT the fuel ratios. Thrust changes, thrust curve, fuel types...yeah. But it's ignoring the ratio. the Sabre-S works fine. The hell? Edit2: Okay, found the cause, just not the why. In the debug menu part listing, it's got TWO "ratio = " under 'LiquidOxygen'. The Oxidizer's original 1.1, and the LOX's 0.27. The 1.1 comes first so presumably it's using that. No idea why as yet, the .cfgs for it and the Sabre-S (which works) appear to be identical, at least that part... Edit3: Found it. Missing @ on the ratio in the .cfg file.

He's been quite active on IRC, and he's been pushing dev builds out as well, starting to incorporate the changes in this branch too. He's pushed out six dev builds since Sarbian got back, and it looks like almost entirely changes that are in Testbed.

Used to be the only way to land, pretty much. Landing Legs were added after the Mun was. My first few Mun landings were that way, before I bought the game. They left almost no clearance between the ground and the engines, though, as they were just BARELY long enough. Thus the gentle. Get too much flex, goodbye engines.

I've noticed that the drag in the statics is affected by parts which are completely clipped inside other parts: When I added a multiwheels engine to my plane, I discovered that it lowered the cd on the graph and improved the L/D if it was turned end-on rather than side-on, even though it's buried inside the nosecone. My similarly buried Mechjeb, ISA Mapsat GPS, and Vanguard ejection modules all show the same behavior. I turn them all end-on, even though I suspect that in flight they don't actually add any drag. Could be something similar, where it's calculating the drag like the flat end of the adapter was directly exposed to the airstream?

So far as I know, Innsewerants didn't even know about it, because he's been away from KSP doing other things. Which isn't an excuse for breaking the law and the forum/spaceport rules. Frankly, having having an 'unofficial' version competing with the official one is not a good idea anyway. It's happened before with Mapsat, and resulted in a lot of people having trouble when trying to switch back to the updated official version, which wasn't compatible with the old 'unofficial' one. In this case it also prevents the actual problem from getting fixed. Porting an old version is not in and of itself a bad thing: doing it without having the rights to do so is. The CORRECT thing is to ask Innsewerants to either release the mod under a permissive license or to give permission for you to modify it and distribute it. Barring that, the only other option is to restart from scratch. Copyright expires 70 years after the death of the author, so 'he hasn't been around for months' and 'there's no way to contact him' aren't valid excuses. There ARE ways to contact him, actually, just not through the forums. Even if it actually wasn't possible to contact him, modifying it and distributing the modifications are both illegal absent explicit permission.

If you check you'll find that it's no longer on spaceport at all. See, things that are posted on spaceport aren't checked when they're posted. The unofficial version was allowed to go up because nobody validated it to make sure that it was legal. It's been taken down now, because Squad just looked at it and discovered that it was, in fact, not legal. I'm not trolling, I'm telling you that illegally ported versions of mods are not the answer to anyone's problems.

The unofficial 3.3.4 is going to be taken down shortly because it's a copyright violation. Modifying and distributing mods with an impermissive license is illegal and not permitted by Squad. Version 4 has no major problems and works perfectly fine. The memory usage is a problem with the way KSP uses memory, and I've yet to see anyone demonstrate a way around it. Mapsat loads 30 very large textures for the maps, and in the current version of KSP textures use an absurdly high amount of memory for no particular reason. This includes the textures on parts and in the game itself, although these are generally much smaller than X4R1's maps are and as such it's not as noticeable. Basically, the game is keeping cached items from scene loading in main memory, and not releasing it even when the memory limit is reached. This includes all the intermediate steps in getting the ~2mb or less png maps converted into ~2mb DDS textures loaded into VRAM. In short, it's not that Innsewerants needs to fix X4R1, it's that Squad needs to fix the way the game uses memory for assets. ALL Assets. They may have done for 0.22, I don't know: Mu did a major optimizations package, I know that, and hopefully the problem with the memory usage got fixed in there somewhere. If that's not good enough for you, I suggest you try to do better. Yourself. Not illegally porting Innsewerant's code. Starting from Scratch. If you can do better, that'd be better for everyone. Illegally porting an inferior version of the mod doesn't help a thing. Now if you can convince Innsewerants to release Mapsat under a permissive license that allows it to be modified and distributed, or get permission to modify it, that's a different thing.