Tiron

Yeah, I've seen the option, but when it gets like that it doesn't show up, all you get on right click is 'toggle info'. No idea if the AG works because it wasn't set up, may try it here in a sec. Yeah, well, the idea was 'no auto parameters at all', pre or full either one. The radio buttons list it as altitude or pressure 'predeployment' which is why I called it that. I was more referring to the fact that there's no way to NOT set either an altitude or pressure trigger. Well the staging turned to not be part of the problem, just a minor irritant that's mostly obviated by a recent fix to aviationlights. Although an option to take stuff out of staging entirely would be vunderful, some of the time anyway. Probably not, but isn't things going horribly wrong half the fun?

Just downloaded this today, after hearing tons about it on IRC, mainly because drag chutes (plane landing speeds and stopping distances is a problem I'm working on at the mo'). It's very good, there's just some niggling...things. Most of which are of the 'just bugs me' variety. For starters, I keep setting the drag chute off on takeoff. If I pull up too soon and my 'lazy Tiron' protective tailwheel (also useful for rough terrain landings) touches after the main gear get off the ground, it activates the chute. Turning on 'must go down to deploy' mostly stops it. Except it leaves the chute in an 'armed' state that can't be cancelled, with that obnoxious 'waiting for negative vertical speed' display in the middle of the screen until it's deployed. Then there's the forced 'pre-deployment' options. There's no way to disable them, or even to fake disabling them by setting them to unreachable/redundant parameters. Mostly just an annoyance, except that when it gets stuck in 'armed' state from the tailwheel, it actually uses them to deploy the chute(at an altitude no lower than 10m, because it won't let you set it any lower than that.) The hybrid of staging/action group/right-click/automatic deployment is a bit...odd, sometimes. Especially for a drag chute on a plane. Having 'stages' on a plane just feels wrong somehow, and it's something I've worked to avoid (and have even used the 'stage' AG to activate certain features on some of my birds as a result of my success in doing so.) Some sort of way to get the chutes out of staging entirely and rely on action groups/automatics would be useful for drag chutes in particular, and I can imagine some niche roles for aborts/emergency use as well. Spin chutes, say. Or maybe using chutes to try to pull burning SRBs away from the capsule (if attached radially, they tend to curve inward because of the radial decoupler hanging off the side. I've yet to have one where they'd go right at the capsule, but I've had some where they'd come close enough to be a problem...and did have one clip a capsule once, destroying one of the radial chutes and the top mounted docking port.) In a related vein, an emergency 'I don't care what your parameters are, activate anyway' button could be useful in some situations, too (drag chute as impromptu spin chute comes to mind.)

I'm still gonna be doing my own RPM compiles because Mechjeb Dev Version, at least for the moment. I might look at trying again to get Mechjeb itself to compile, since its version numbers are already hardcoded and it's just the stupid buildbot messing things up. But yeah, same thing with the RPM SCANsat display...mostly. There are two problems with it that I've seen: It's slower than heck to render, almost as slow as the full bigmap. It's nigh-useless near the poles, because the RPM map apparently uses either the rectangular or the kavrayskiy projections all the time (I strongly suspect but cannot prove it's using rectangular), with no way I've found to change it. It leads to hugely distorted output in the polar regions and pretty much entirely loses directional alignment. When I tried to use the zoom-in function on the bigmap instead it seemed to be doing something similar (albeit with MUCH faster rendering but a much smaller window), so I almost wonder if the RPM version isn't calling the function for that little zoom window.

Actually, KAC itself has two methods it can use to calculate a transfer, which yield different times: Formula and Model. You toggle them with a radio button on the 'transfer alarm' page. Mechjeb's transfers generally seem to end up close to one or the other of them, but which isn't consistent. I'm guessing that each method in KAC varies in accuracy and particularly efficiency, and that Mechjeb's using a more sophisticated and detailed method that's both more accurate and more relevant. Mechjeb's also accounts for the ejection angle you need and thus where your craft will be in its orbit when the window arrives, to some extent or another, which I'm pretty sure KAC's alarms don't do at all. KAC seems to just note when the planets are in the right position relative to each other. Back before the fix that made mechjeb always find the first transfer window, I twice tried to use KAC's alarms to execute the burn manually out of sheer frustration. One time it worked okay-ish. The other it sent me in the exact opposite direction from where I needed to go. I was on point of re-downloading protractor for the first time since before Mechjeb 2 came out when the fix went in on the dev version.

As has been stated many, many, many times...because of the way it works, Squad weirdness, and the recent changes to mechjeb's buildbot, RPM's mechjeb integration doesn't work with Mechjeb's Dev builds unless RPM is specifically compiled with the version you're trying to use (and then ONLY that version). Someone over in the mechjeb thread was doing compiles of RPM for the dev versions as they came out, but last I checked he wasn't doing SCANsatRPM with it, which means it breaks the SCANsat integration... I've just been compiling RPM myself for awhile now.

He's not talking about making the failures themselves happen randomly, just about making *how* they happen more random. So that pulling the same, too-hard maneuver will result in slightly different failure patterns. What causes the failures and when would be consistent and predictable, the exact nature of the failure itself would not. Big difference.

The actual shape of the blades is a pair of isosceles trapezoids that share the larger of the parallel sides. It starts with a narrow part that attaches to the hub, expands outward for a short distance, and then tapers very slightly down to the blunt blade tip. The taper is fairly slight from the wide point out to the tip (less so from the wide point to the hub, the hub connection looks like it's about the same size as the tip but the wide-to-hub section is MUCH shorter.) When it folds up, all it does is flatten their pitch(0 collective, basically,) flip them back into a 'V' shape, and collapse the hub. (There's some complications involving what happens if it's spinning already when you want to fold it, but that's a bit out-of-scope at the moment.) So if my understanding of what you said is correct, it's pretty darn close to *being* a pair of oblique wings in wing mode. Of course, I also got the impression that it doesn't really matter, as it sounds from what you said like the nonsideattach bit simplifies things in a way that would prevent it from modeling that anyway. So here's a question: if the wing module can handle oblique wings, would it be possible to 'fake' movable wing support by attaching the FAR wing module to just the wing part of the model? I realize it can't do this now, and you'd probably have to (somehow) be able to set a fake!origin for the wing module to work right (no idea how you'd do that, that sounds like it could be somewhat difficult to find the right co-ords). I really don't know what I'm talking about, I'll freely admit, but that occurred to me just now based on your explanation...

I've been having a rather spirited discussion with Ferram about the possibility of FAR-izing the Wing Rotor, over in the FAR thread. A couple of things have become abundantly clear: FAR can't do things like variable sweep, at all. If you attach a FAR module to a variable sweep wing it's going to have the same lift properties at all times, at best. FAR can't handle sweep in the case where both left and right wings are part of the same part. It can do a straight wing that goes both ways, but not a swept one (because for sweep, it presumes that it's starting at one end and sweeping towards the other. It can't start in the center and sweep in both directions.) Also: If you put a non-FAR lift component into a FAR installation, the CoL indicator gets screwed up. It'll show *only* the Non-FAR lift. Also, FSliftSurface is set to turn itself off if FAR is installed, so that might be the source of the 'there's no lift waaaa' issue. Which has me wondering if the wing-rotor was even generating lift at ALL... or if it was just the king of all drag surfaces for nothing.

I'm hardly an expert on the subject, you'd probably want to ask Mihara, because everything I know I learned from reading his thread. Trick being, I gather that it only applies in cases where one plugin is trying to call functions from another. It's not a problem within any particular mod, just when one mod tries to use parts of another. He said something in one of the posts about being able to use 'reflection' to get around it, which I'd guess is normally what gets used. Problem is, for RPM purposes, SCANSat/Mechjeb *itself* would have to be set up in some specific way in order to use it. If they were, it'd work without the secondary plugins, a-la Vesselview (which has a specific version just for RPM.) Basically, RPM has a problem with it because Mihara's using a dirty, dirty hack to hook into a couple of mods that weren't really designed to be hooked into at all.

I added an exemption for FSliftSurface as I mentioned previously, and it didn't particularly change anything so far as I can tell. I'm pretty sure the lift surface *itself* is the source of the drag, because when I say 'enormous' I mean it. I'm not talking 'FAR wing panel turned perpendicular to the airflow' or 'giant cylinder', I'm talking stock-level drag. As in 'similar to the OP B9 Airbrakes I use'. One time I started a shallow descent from about 25km at about mach 4.5, engines off, and was down to about 300 m/s by 14km. *Without* using the brakes like I normally do. (FYI: if there's a way to port those brakes over to FAR I'd love to hear it, because I mostly use them for the for the look. I'm guessing the answer is 'no' or you would've done it in the default .cfgs. I will admit I kinda like using them to pull out of a spin, though. ;P ) I didn't really, but given that you made it quite clear an accurate one wasn't possible, and I discovered it wasn't behaving accurately to begin with, I'm willing to settle. It just got frustrating that every time I asked something, your explanation seemed to suggest some way it *could* work, if less accurately. Sorry if I got a bit snippy. Sometimes, one just has to suck up the limitations and deal with it. There's a reason 'workaround' is a word. I'd prefer not to, but some semblance of accuracy is better than none at all. Trying to figure out how to do a high Mach STOL is giving me headaches. The coaxial-contrarotating twin rotor (think 'KA-50') that the same pack comes with works fine. The amount of drag is insignificant and it's even slightly more powerful than the wing-rotor. But carting a rotor along (especially a twin-rotor) at Mach 5 is just too absurd for me to accept. Every time I look at it, my brain goes '*snerk* yeah, right.' That actually makes a lot of sense, from a computing standpoint. It's just not obvious, or more importantly, intuitive. There's no real way to tell what the shortcuts and limitations are, though once mentioned it's fairly obvious they have to be there (non-idealized drag equations are just INSANE.)

First off, it's not mine. It's made by a guy named PolecatEZ. I'm just not averse to modifying things. Second, so far as I can tell, it's not actually using FAR in the slightest: the drag's coming from Firespitter, which I can hack away with Firespitters drag multiplier if I really have to. This goes double since I added FSliftSurface to the 'modules to ignore' list in FAR. I just prefer doing things properly to using dirty hacks, if it's possible, and I'm trying to figure out if I can modify my own personal copy of the part to work something like approximately correctly. Working a bit unrealistically in FAR would be better than working extremely unrealistically in Firespitter, from my perspective. And I've Gathered FAR doesn't really reference the models like most people think it should (IE: Parts inside other parts still have drag, even though 'stuff in front lowers drag of stuff behind' is supposed to be one of the things FAR does.) That being the case just makes the possibility of the slightly-less-dirty hack I have in mind MORE likely rather than less. It doesn't have a FAR module AT ALL. It's using EXCLUSIVELY firespitter. It has a single wing, unrelated to the rotor system, which is static and active at all times. The visual of it folding into a wing is purely cosmetic and has nothing to do with the operation behind the scenes. Is it possible to attach a static FAR wing, which would necessarily also be active at all times (this is not a change from current), to this thing at all, under any conditions or requirements whatsoever or not?

From reading Mihara's stuff on the subject, it's actually Squad's fault. Something in the way their plugin loading setup is arranged makes it so that directly calling functions from another .dll only works if it's the exact right version of the .dll, otherwise it doesn't allow it. He's got a couple posts on the subject, talking mostly with Sarbian after a change to Mechjeb's buildbot broke compability with the dev mechjebs. Here's one Another Given what happened with the Mechjeb Dev version and the nature of it, it seems like the pluginloader's going off the version number on the .dll for the purposes of enforcing this. Basically what happened was this: Mechjeb's version numbers are hard-coded in the code itself, and are only changed when a release is pulled. All the mechjeb dev-builds since version 2.2.1.0 was released (225/226-242 at the moment) if you pull the code down and compile it yourself, will show up as version 2.2.1.0. They also have an automated build bot set up, which every time there's a commit to the project automatically compiles the new version and hosts it for people to download. At some point here recently they changed how it does so: instead of just compiling it straight up, it now automatically appends the commit # onto the last digit of the version number. So instead of it coming out at 2.2.1.0 like it would if you compiled it yourself, the one the buildbot spits out comes out as 2.2.1.242 (or whatever.) Judging by the forum posts, before that change to the buildbot, the dev versions of mechjeb worked with RPM without any modification. You could just drop them in and they'd work...apparently because they had the same version number as the last release. I've seen people mentioning a specific commit where the change took place and the compatibility broke. My understanding is that dropping the version numbering on the .dll wouldn't fix it in and of itself: the new one would still register as 'different', but if the version number didn't change after that, and the functions that were being hooked into didn't either, each subsequent version after that would continue to work after it'd been recompiled once. In fact, if my understanding is correct, you could make your versions of scansat work as a drop-in on the unmodified RPM simply by setting it up in such a way that your .dlls always came out with a version number of 1.0.5.32015, the version of the release that RPM's been compiled with. It's not great practice, and it'd remove the ability to tell what version you had by checking the plugin... but it should allow it to work without having to rebuild RPM constantly.

Unfortunately, I'm not sure what the shape of the actual liftsrf is because invisible. I'm not sure it matters, because I gather FAR assumes that the lift in question is applying to the entire model anyway. Firespitter lets you designate, which is probably why the wing-rotor thing has has a separate component for the lift in the first place. Which is why the CoL of the part doesn't change when it changes shape, or when the rotor's flipped on (rotor = thrust, not lift.) It *might* be possible to fake it as a non-swept wing, I have no idea.

I hope by 'different sweep' you mean 'in opposite directions'. It isn't actually a movable wing, doesn't have variable positioning or sweep or anything. In fact, it appears that the model has an invisible, static 'liftsrf' component that functions as the lift generating portion, completely independently of the visible rotor. In short, it *looks* like a rotor that turns into a wing, but functionally it's a folding rotor that has a built-in static wing attached to it(which happens to be invisible so it can pretend to turn into a wing). I'll try flagging it as a greeble maybe, see what that does, but I'm pretty sure the drag's mostly coming from the fact it's using firespitter's lift system. When I turn on aeroforces display it doesn't show any, so I don't think it's interacting with FAR at all. Edit: I exempted FSliftSurface, that's the only thing that I have which is using it anyway.

The Rotor's complicated as heck because it has to do entirely different things based on which mode it's in (which is why it's actually not doing different things in each mode.) I would think Variable Sweep would be more easily achieved, however. You would think, at least. Not automagically, I suspect, as Firespitter and FAR use completely different setups for defining wing lift...

Actually, FSliftsurface contains code to shut itself off if FAR is detected, but apparently, due to the fact that there's no FAR module anywhere that applies to it/the sheer weirdness of it, it's using it anyway. I was afraid of that. It's already *got* 'something else' set up, namely firespitter, and I'm honestly not at all sure it actually *is* 'turning the lift off' when it switches into Rotor Mode as it is (at the very least, during the transition, there isn't a *hint* of instability, even when the wings are out of position). Somehow he managed to get the lift oriented correctly with FS though: it's centered a bit behind the rotor shaft when they're folded, which is what you'd expect from a wing swept like that, I'm pretty sure. The mod it's from is technically in Pre-Alpha, and I myself am at this point merely experimenting with it (which is why it's on a plane even though that makes NO sense at all.) It occurred to me how a helicopter would be nice for landing to collect science/visit anomalies, but also that helicopters and Tilt-Rotors are...not exactly fast. Patience is not exactly my strongest suit, so when I saw something that could 1.) Give STOL/STOVL/VTOL capability 2.) Still be absurdly fast 3.) Not have useless parts hanging off in one flight mode or the other, I said 'Okay, I'm trying that.' The Drag is just TREMENDOUS, though. There's a workaround for that(FSliftmodule has a 'drag multiplier'), but I figured I'd see if it could be done properly before I went there. Now I gotta decide if I wanna try to modify it to fit in better or just try to do a more traditional VTOL. (The plane in question turns out to be very well balanced, far better than I expected, but I don't know where the heck I'd stick VTOL engines on it.) Edit: Preliminary testing suggests that it probably does just have the lift from the 'wing' mode active at all times, and the switch is just cosmetic (other than it being unable to generate thrust while folded). Switching into 'rotor' mode in the VAB doesn't change the CoL, and it also doesn't seem to have any effect in flight. I'm still working on testing it with the rotor engine active, as the rotor uses the throttle, and thus for such a test I really need to have the throttle cut. Edit2: Got a decent glide test. Lift characteristics don't seem to change based on what mode it's in. Given that it's (apparently) already acting as a combination of a static wing and a rotor, is there a way to make the static wing part at least FAR compatible or is it still a 'nonono' because of it being two wings instead of one.

Okay monsieur Ferram, here's a dumb question. I've been experimenting with a very alpha part from a B9 expansion pack. It's a helicopter rotor that folds into a cute little V-Shaped wing. Using firespitter, natch. The question is, it's using FSLiftSurface (firespitter) for the wing mode, and I can't tell if it's working with FAR or not. It completely overrides the CoL in the VAB and it's not showing aero forces(yes I turned them on) or a 'stalled' gauge in flight. It also seems to produce an absolutely ENORMOUS amount of drag. And I'm not getting much in the way of illumination from reading the docs, unfortunately. I just slapped it on my science plane to play with it, the sheer unrealism of which does bug me a bit so I may design a new vehicle if I decide to use it. Edit: I talked to Snjo and what he said (I'm not sure he understood exactly what the part actually was) implied that the FSLiftSurface is supposed to turn itself off if it detects FAR...but since there's no FAR module in there, it might not be. He also said something about how adding one would make the lift 'static', which so far as I can tell it already is, at least when it's in 'wing' mode and not 'rotor' mode. If I add a FAR wing module to it, how bad is it gonna blow up on the rotor mode? And here's a short vid of the thing in action:

Had one a bit ago in testing: both got ragdolled in the chairs, both were debris when they got out. Not sure how it happened that time.

Oh, mayhaps. I was extremely tired when I wrote that. I thought you were saying it took a pre-rendered image and revealed it. It may have had a corruption problem in 0.23 (which would've been version X4R2 I believe.) But I wouldn't know, as I quit playing the middle of 0.22 and only started playing again maybe a month ago. And have been using SCANSat in lieu of Mapsat since I got back.

There's no cross-dependency that I've seen, but RPM has the same problem with the SSRPM and MJRPM plugins that they have with the SS and MJ Plugins themselves: if they're a different version than the main RPM plugin, it can't use them. That's why I said you have to do all three: every time I compile them myself, even using the 'release' source, I get a different version number than the master release. If I try to just compile one of the plugins and drop it in, it doesn't work. It needs all three recompiled so they all have matching version numbers. Like I said, if you somehow got the thing to spit out your recompiled .dll with the same version number as the master, my understanding is that it'd work as a drop-in replacement without doing the other two. I just have no idea how to do that. As far as I can tell, it's the version *number* that causes the problem, not the file being different. So in theory, you could also fix it by just having all the new SCANSat.dlls have the same version number as the one that works, as long as the function didn't change enough to break it. (but that has its own problems) I've also been having out of memory crashes lately, and I'm not entirely sure why. It happens on scene changes, but only after I've loaded a flight in, generally. I don't know if it's SCANSat or what, because I started using V6R1, RPM 17, and MJ 238 all at the same time, and that's the most recent change I've made. I also picked up IR recently and already had a ton of other plugins and parts (Including a modified EVE, which I've suspected as well.) Edit: It actually didn't. It actually used a group of scan 'probe' lines to query the terrain maps and created the texture on the fly with the results. As a result, he actually set it up such that it could support not only changed terrain maps but entirely new planets without requiring an update, starting with X4R1. The problem it had with the terrain changes in 0.21 was that it has a file called hilo.dat which stores the maximum and minimum height values for each body, used exclusively to set the color scale on the maps. He'd set it up to automatically rebuild it if it found a new planet, but forgot to have it check if the existing planets had changed. So the pre-made hilo.dat it came with was outdated, and resulted in weirdly colored maps due to using the wrong scale. The trick, which I discovered, was to delete the hilo.dat file entirely to force the thing to rebuild it. He'd done his best to keep it from rebuilding if it didn't need to, due to the fact that rebuilding it was a slow process which made the game seem to hang during loading. He just forgot to include a check for that particular case. Presumably he fixed it in X4R2, since I told him about it on IRC. The problem with this system is that the map you made was stored purely in the .png it made with the scan results. (There was also an option to spit out a .csv with the raw data alongside, but it wasn't fully re-implemented last I heard.) This meant that even if Hilo.dat was updated when the terrain changed, your stored maps weren't. Which could result in the slightly comedic situation of not only the map being wrong, but the legend for the color scale being different than the one the map was made with. Re-scans overwrite the sections of the stored map you scan, allowing you to fix it without dumping your old data (which is what I'm doing in that image I linked above, except I only had a couple orbits worth of 'bad scale' map done when I figured out how to fix it.)

I think I might have got at least a partial bead on what causes this, today. I was out doing preliminary testing on a modified rover design at my usual spot: out in all the pipes and junk by the launchpad, using Rollkage mk2s. A couple times in flip-testing, the Kerbals riding in it got ragdolled, still locked in the command chairs. In this state they were able to do EVA reports and surface samples but not to get out of the chair. I was a bit confused by this so I started trying to do more specific testing, to find out how it was happening. What I found was this: when it's sitting perfectly on the top, the ground clips into the rollkage just a bit. If it hits just right, it's able to clip through far enough that it JUST hits the top of their heads, which seems to be able to ragdoll them without detaching them at least some of the time. On the attempt where I finally saw what was happing, Hanzor got detached, Kenzor got ragdolled but was still in the chair. When I switched to Hanzor(who was working fine), Kenzor immediately popped out of the chair and ended up standing on top of it...now flagged as Debris. It's pretty suggestive that this 'ragdolled but still in the chair' state is causing the 'flagged as debris' problem when they subsequently get detached, at least some of the time. It seems like there's some particular set of conditions, or maybe just an intermediate level of force, that ragdolls them but doesn't detach them. I suspect that most rover designs aren't able to manage that just perfect level of almost-protection where they can get hit just hard enough to induce it without taking a subsequent, harder hit that detaches them entirely. It's only one data point, so it's not conclusive, obviously, but it is interesting.

It's some problem with a 'module that will not be named' bug or somesuch? I forget. Something about the way KSP works when one plugin calls functions from another one. Apparently, it only works with the specific version of the plugin you compiled yours with. But from what I read, it's linked to the version *number*. Apparently, the dev versions of mechjeb used to be drop-in replacements until the buildbot started auto-incrementing the version numbers. The problem is, this applies to the RPM plugins too. I have no idea why, but when I build them myself I get a slightly different build number than the official release, even if I build from the official release's source. This prevents just rebuilding say, SCANSatRPM.dll and dropping it in. You have to build all three RPM plugins to get them to work with each other. It's not hard: the source comes with .csproj files for the three dlls and a .sln for the overall set. When I try to compile it, I get 10 build errors: something something.Orbit.something commands to mechjeb that come up with an error along the lines of 'mechjeb doesn't have an 'Orbit' thing, wtf you talking about'. Changing '<x>.Orbit.<y>' in those lines to '<x>.orbit.<y>' leads to a successful build. No idea why. Other than that, all it takes is making sure it can find the three KSP .dlls it needs, plus the versions of SCANSat and Mechjeb you want it to work with. If you could figure out some way to get the SCANSatRPM.dll to build by itself with the same version number as the official release, it might work as a drop-in, though...that's the impression I get, anyway. Otherwise, every time the version number on the SCANSat.dll changes, it'll break compat until the whole thing is recompiled. Or some such garbage. There's some way to integrate into RPM directly without going through a special plugin, which Vesselview does. No idea what it is, but I gather it doesn't have any of these problems, so that might ultimately be easier than custom-rebuilding RPM each time MJ or SS updates.

Absurdly simple. At first I was trying to figure out how to get Dev Mechjeb to compile (the version number as specified in the files isn't changed with each new commit, the automated buildbot does it, so if you build it yourself it'll have the same version number as the last release), but RPM was much easier to get it to go... MUCH easier. New dev mechjeb came out and I decided to try V6r1 scansat at the same time. Works a charm. I should really put the dependencies where they're supposed to go so I don't have to reset them every time I update RPM, but meh.

Actually... You just have to compile RPM yourself with the references updated to the newer version of the .dlls. And at least in my case, ten of the 'Orbit'-s changed into 'orbit'-s (I get fits over missing reference if they're capitalized, I have no idea why.)

@Ferram4: well what you were saying about it being nastier in KSP, it wasn't 'unconsciously' correctable, unless maybe you could feel it when it was incipient and fix it or something. So far it's only manifested while trying to turn as hard as possible over an extended period on Duna, and it wasn't a huge problem then. @Sauron: He's right. Having CoM behind CoL creates extreme instability, which is what you're seeing on der graph there. Having the two lined up also creates a fair amount of instability. You want CoM ahead of CoL, but barely (the closer it is, the more maneuverable you'll be.) My experience with the 'falling out from Mach Tuck' issue was that it generally seemed to primarily be the result of not having enough lift for the weight of the plane. At least on the stuff I design. @jstnj: If it is in fact said Access Violation, try using Active Texture Management if you're not already. The 'basic' version has dropped my memory usage considerably, without any reduction in quality that I've noticed.