Tiron

Is that why it was rolling 'into' my turn sometimes trying to turn on Duna? It wasn't a huge problem if so. I managed to correct it out by backing out of the turn and in some cases accelerating the roll to go all the way around. Didn't come near being a major issue. Have a picture to go with:

@Ferram4 Okay, I just flew my SSTO to orbit for the first time with the outer wings flipped to 1 tick anhedral instead of 1 tick dihedral. It's still a bit unstable when trying to keep the nose up, and I still have to make constant adjustments, but it is GREATLY improved. The adjustments are small, relatively minor ones, instead of battling fiercely just to keep it holding on course and from rolling to one side or the other. That was the smoothest ascent I've flown with the thing. And I'm getting used to the change in profile rather quickly. I don't know what to say. 'Thank you' seems poor and inadequate.

Yeah. Part of the Ravenspear heritage though. I flipped the plane version to one tick of Anhedral, and it does actually seem improved a fair bit. It still does it a bit, but it's not near so strong or as easily induced. Looks a bit funny to my eyes though. And the rudders are TVPP Delta Deluxe Ms, which are a bit stronger than the regular size delta-deluxes, and set to 30 degree max deflect. They're actually stronger than you'd think.

At the moment, I've only got three of my planes updated to the current version, and they're all variants of the same design. They're a mix of different sets of mod parts (B9 Fuselages, TVPP NTBI wings and control surfaces, stock and TVPP resized stock winglets and rudders, multiwheels landing gear, and aviation lights just for fun), with the same basic planform as my old, stock Ravenspear Mk3 derivatives(with one slight exception.) This is the SSTO version: It uses SABRE-S intakes and SABRE-S engines from B9. There's also a plane version of that one without all the orbit-specific stuff (Reaction Wheel, RCS, Monoprop tanks, Solar Panels, and some of the navlights) which is a tiny bit shorter and somewhat lighter (especially with the tanks not filled, which they don't need to be anywhere near for any reasonable flight plan.) The plane version uses stock Turbojets and TVPP cone intakes. There's also an experimental derivative with TVPP ramjets, which has the tail replaced with a bicoupler with a pair of B9 turbojets, larger canards, and the wings moved all the way back (making it a tailless, slightly swept delta.) All three have one tick of dihedral on the outer wings. All three do a lot of sideslipping and rolling when in a hypersonic cruise at altitude. I had no idea the dihedral was making it worse.

If you go to the craft load dialog in the SPH on a save with stock craft enabled, it'll be greyed out with a notification that it has invalid/not unlocked parts, and won't even let you TRY to load it. It'll spam up the console with a list of the missing parts. Other than that, you shouldn't notice a thing. And Anhedral reduces that wing rocking at high AoA? ...*goes to flip the wings on his planes* >.>

Works on mine, although it loses the ability to back out to the mod menu. Which is fine because you can just push MOD.

Well every time I tried to use control surfaces as airbrakes they looked stupid and did essentially nothing.

@Ferram4 Yeah, I tend to just do what I've heard you say you do... Manual PCM. That said, I deorbited, transitioned to hypersonic flight, realized I was over the ocean past the space center heading away, did about a 220 degree turn starting at mach 5.5 at 26km or so (ended up at mach 2.2 at 13km by the time I finished turning), descended and landed without any significant problems. I did get 'high dynamic pressure' warning during a fair portion of the descent to the space center, and my Multiwheels Flat-4 Monoprop engine (contained entirely within the fuselage!) broke off without damaging anything else, but it's for taxiing and I'm out of monoprop anyway. I am kinda curious as to why that of all things broke off first, (not being terribly aerodynamic probably contributed, but it shouldn't've been taking any substantial force I wouldn't've thought?) and may try to find a way to keep that from happening again. If anything, the deployed B9 speedbrakes should've broken off rather than the engine.

@Ferram I haven't really had that much trouble with it so far, other than when I deliberately *tried* to break things. I'm still testing deorbit: aerobraking has gone fine...multiple times. I'm trying to do a space-shuttle-style high AoA black-side-down entry, and it keeps pushing the PE up and not slowing down enough. It's coming down on this pass for sure, though. The biggest problems I have is that your answer to the problems is 'use the DCA', and I avoid using the flight aids at all (they tend not to work well with the SAS or Mechjeb, and I don't like it when things interfere with me controlling the plane anyway.) I *might* use it, if it was a set-it-and-forget-it thing that I didn't have to mess with all the time (I have ADHD, remembering to turn stuff on or off is a BIG problem for me.) Unfortunately, the 'help' guide for configuring it is singularly uninformative and I gather the default settings can cause overly weak controls at high altitude (and all my designs are high altitude hypersonics, one of which already has terrible pitch control.) But honestly? If it takes a lot of time or work to get things set in a way that makes stuff work, I'll just downgrade or edit the .cfg values to make it not be a problem. And as for the Mark1-2 pod problems...could the reduced transonic/supersonic drag have changed its deorbit profile enough that you can't come down in one pass if you're using DReC, maybe?

There's an ejection and eva parachute mod too: http://forum.kerbalspaceprogram.com/threads/25305-0-23-Vanguard-Technologies-EVA-parachutes-23!-Sry-4-not-fixing-earlier-%28Dec-30%29 I'm testing Aerobraking and de-orbit myself right now. I'm at 600km coming from Duna, set for an aerobrake pass before full deorbit, I have a suspicion that half the plane's going to get torn off, if it doesn't burn up (I don't think burning will be a problem with this PE based on prior testing of DReC). You can tweak the thrust on the SRBs in the VAB, which may help with that (it makes them burn longer too). There's a .cfg file in FAR that specifies the strength values for the aero stress, or some such. I may tone it down a bit. I might also add that I *did* get a plane to tear itself apart in 0.23.5 using either FAR 0.13 or 0.13.1, not sure. Specifically, the FAR Thunderbird design that comes with it. In a high-G pullout, it went completely to pieces (F3 indicated max-Gs in the 20s).

Except that said option doesn't work. Toggle it, and stuff still falls apart just as easily. Unless there was a super-stealth update with zero indication of it since yesterday. I'm also a bit worried about what this change is going to do to an aerobraking or de-orbiting spaceplane. Gonna test it in a sec (I gotta edit my testing sandbox save first.)

It works without it...but you can't get the big map, or get a map outside of IVA, without some sort of scansat part.

So got talking about this mod on IRC, and made a short demonstration video where I play 'clip the flagpole' to show off the ejection module. Enjoy! (Ideally in 1080p.)

No problem. Other than those two problems, I found it to be very shiny and awesome. And honestly, the SCANsat thing is...moderately annoying at worst. You just get some text on top of the map, which otherwise works perfectly.

Seconded. 'Download Forum size' gave me a corrupted .png.

VV uses the 'back' button in order to go up to the previous menu level/rehide the menu if already on top level. With your MFD installed, the back button takes it out of VV and back to the 'Mod Select' page. And when you go back in to VV, it remembers where you were in the menu, so you can't even use that to bypass! I'm also finding that the Scansat page says 'Plugin not installed' and continues to show the mod menu...even though it then goes ahead and loads the map underneath it, which other than the text on top of it works fine (switching maps, zooming both work too.)

Oh and Mechjeb is now up to 2.0.9-86, so I've lost the accurate TWR again. Did you get Sarbian the code to include it in the main branch eventually or am I just gonna have to suck it up?

Oh, I should probably mention... Bac9 and Taverius rebalanced the Sabres, they increased the Isp and decreased the thrust in rocket mode, and increased the thrust but decreased the Isp in Air-Breathing mode. They're now more powerful in air-breathing mode than in rocket mode. I don't know what this actually does to performance since I'm running realfuels, but yeah.

I've encountered an odd sort of issue using FAR on Rockets. There seems to be some malfunction in the roll control scheme when fitted to a rocket. Using 8-way symmetry really brings it to the fore, but it occurs in some variation or other no matter if the fins are placed individually, the location of the root part is changed, fins are exchanged for canards, or even if only four fins are used. Basically, fins on one side of the rocket are reacting very incorrectly to roll commands. With 8-way, five of the fins correctly twist in the same direction. Three exhibit erroneous behavior, and it seems to be linked to the pitch axis: it's the three fins that are on the 'up' side of the pitch axis that respond incorrectly. Two of them barely move at all; in fact unless you watch closely it looks like they haven't moved, it's such an infinitesimally small movement. Not only that, but the movement is along the pitch axis, in the same direction, instead of being a twist around the center. The third fin, the 'top center' one, moves to full extension like the five that respond correctly, but in the opposite direction. That is, along the same direction on the yaw axis as the 'bottom center' fin. Pitch and yaw seem to work fine, however. It does seem to affect flight characteristics, because my attempts at spin stabilization on a ballistic rocket (just for fun) have all resulted in partially stabilized tumbling, worsening as the air thickens and easing as it thins. They're called 'Stabilators' but are basically the same thing. Smaller versions were just added in R4.

Because KSP is a 32 bit program and can't address more than 4GB of Memory, period. Seriously, they need to force people to understand this before they're allowed to use more than 4GB of memory on a computer. I'm getting tired of hearing people say 'but how could I be out of memory I have X GB'. Like a '64 bit license' that you're only allowed to use 32 bit without it. It's a basic, fundamental limitation of the architecture. And before you ask, no, they can't release a 64 bit version because Unity's 64 bit versions for OSX and Windows are not stable. Linux already has a 64 bit version, but if you didn't realize that KSP was 32 bit and limited to 4GB Linux is probably not something you should be trying, frankly.

The magnetic attraction the ports have doesn't work very well on a body's surface: they don't like to lock on until they're *perfectly* aligned, which makes docking two objects that are both on the ground VERY difficult. One way I've found to solve it was to use KAS: my rover Carrier SSTO design uses a pair of KAS winches and the Rover's Reaction Wheels to pull the rover's docking port upward into the plane's docking port. It's actually quite reliable, presumably because the rover's free to swing around on the cables, and thus the magnets have a chance to correct any misalignment without having to fight friction between the rover and the ground.

Releasing the source is a Squad Requirement to post it on the forums or Spaceport. Note that making the source available is not the same thing as 'Open Source'. 'Open Source' implies that the rights to modify and redistribute are included. Fact is though, there's two different, unrelated things and you can do one without the other. He's not hardly the only modder that released the source to satisfy Squad's requirements but reserved all rights.

As he says, it's been known to freak out a little bit if you're scanning during a launch, something about all the stuff at KSC staying in the scan-path I think. I thought X4R1 didn't do that, though...you using 3.3.4?

The only reason I've yet seen for mapsat to crash a system is that its memory usage put you over the limit, which generally requires that you have a lot of PARTS installed. It's textures that eat memory for breakfest, and Mapsat's a prime offender in this regard because it loads THIRTY 2048x1024 textures every time you use it. Just plugins without a lot of parts don't use very much memory (Mapsat, FAR and Modular Fuel Systems, for example.) At least some of the optimizations he did didn't make it into 0.22. It looks like the load-time improvements did (holy crap, dude.) The optimizations he did to core to improve performance with 'high numbers of parts' did not. I didn't really have any specific reason to suspect that he'd improved the memory usage for textures, I was just hoping he had, and it doesn't look like he did. That said, the problem with the memory usage, so far as I can tell, is not the AMOUNT that's being used, it's the fact that almost all of it is cache that isn't getting used. Simply having things cached isn't in and of itself harmful: actually, it can speed up loading substantially because the stuff is already there. The problem is that you're supposed to be able to dump cached items if you need the memory for something else, and KSP doesn't seem to do that. Most of it only seems to get used during scene transitions. Honestly, probably the best solution for the problem would be to set it up so that it CAN dump the cache when it needs to. The memory usage would still be just as high, but it wouldn't crash if you hit the limit: It'd dump enough stuff to stay under the limit and keep going. It could slow down load times when it had to do that, because it'd have to pull stuff off the hard drive again. Based on mapsat's usage though, it looks like for textures what it's PROBABLY caching is all the intermediate steps in getting the texture converted into DXT format and sent to the vidcard. If that's true, it's an especially pointless bit of cache, since it shouldn't need to re-covert it unless the texture changed in the meantime, and you'd have to do a manual database reload to do that anyway. They should, theoretically, be able to just dump the original file and what looks like two uncompressed copies as soon as they're done using them, and just keep the DXT. Presuming I'm right that it's keeping the original file, two uncompressed copies, and the DXT cached (the only way I could think of to get the filesizes up to the amount of memory the maps use), dumping everything but the DXT (the only thing the vidcard can use anyway) would reduce mapsat's memory usage by about 540MB.

The fact that it has a (2) on the end of it suggests there's at least one other copy of the archive in the same location, possibly two other copies. Or were, anyway. Is it possible you stopped the download after you realized you had already gotten it, and thus it's incomplete? If so one of the other copies may be complete.