Synthesis

Ah, okay, the connection with the physics model went over my head--sorry about that. Exposure, you're using the in-game generated fairing models, right?

I know this may not be up to stupid_chris, but has anyone had any luck getting around the issue of parachutes refusing to deploy under/next to/in close proximity/not-so-close proximity to fairings? I've been looking through issues with Sumghai's SDHI service module escape option system (the parachutes rely on RealChute), and the parachutes flat-out refuse to deploy after they're uncovered (even if I stick a separator in between the parachute-docking port and the fairing itself). That breaks the escape option, naturally, and possibly the ability to actually use the default reentry parachutes (since they're on the same), so no bringing a crew back as such. Has anyone been able to get around the error?

Just wanted to add, yes, the new model fixes the collision issue in the VAB. Hurrah! Back to experimenting with the parachute. I missed an obvious issue myself: so, with this fairing bug, forget abort stages, I wonder if the SDHI docking parachute might not function on return (even if you discarded the fairing hours/days earlier). Has anyone gone that far? EDIT: Yeah, so, idiot that I am, it never occurred to me to check the RealChute end of this--apparently, RealChutes having problems deploying with/near/within visual range of a fairing of some sort is actually not uncommon, according to the RC thread (not sure if that's being worked on). In my case, I may just replace it with a default go-to parachute within the CFG as a temporary fix.

Indeed, you can sort of "weasel" your way around the attachment zone. I'm trying to figure out the parachute fairing issue through CFG editing, just because I really want that abort option.

Sure, sorry I didn't get to this sooner--hopefully these illustrate the issues. Objects that have a larger mounting base, like large batteries, just "hover" entirely.

So, I tried the new MU file, and while the collision model does seem different, it's still having some glitches towards the middle of the cylinder (so there's a "sweet spot" for top and bottom third of the cylinder respectively). Just thought you might want to know, I'm sure these sort of things can take time, and some areas are beyond your control for now.

I understand your reasoning behind the fixed parachute values--though I think as of 1.0 it's glitching in the other regard. I've set up a "escape from surface" test a few times where I test the escape tower from the launch pad. The parachute just doesn't want to deploy, either manually or by action group, even after you meet the criteria (negative velocity, etc.) because of the fairings. In which case, then yes, probably a 1.0-related glitch. I don't want to sound ungrateful or anything, but bringing it to your attention if you were not aware of it. I'll try out your most recent release this evening and report my findings in the area of parts attachments.

So, I've been trying to get a working abort stage together with the assembled service module--and I'm running into some obstacles. Currently, even if you have Realchute installed, you can't edit the docking ring parachute in the action menu--which is a problem, since you can't set it to automatically deploy earlier. That, in turn is a problem because if you just try and deploy it normally, the pod can be lifted by the escape tower effectively, but when you try and deploy the chute, you get the message "Can't deploy, parachute is in fairing" even though the fairing is already clear.

No kidding? I hadn't noticed...then again, in 0.90, I used my craft files from 0.25, so I guess that would explain. Some sort of collision problem I guess--hardly devastating, you can skirt around it by mounting smaller parts in that area.

Gave the unfinished release a try--so far, working very fine, except it seems mounting parts on the service module under the ring is a little sensitive (move to far in either direction, and your parts will stick "outside" where the fairing would be, even if there is visible space. Of course, it is unfinished, so I don't mind in the least--just wanted to report that, very excited to see this completed. I'm pretty sure this is the last 0.90 "must-have" mod I'm waiting to get updated to 1.02.

Fortunately for you, I had the exact same issue--here's the fix.

Kyle, Winston, great to see a formal update! Time to install!

That completely did it, thank you very much!

Sorry--it hangs on loading, I believe in the middle of Module Manager applying patches. I checked for the obvious (missing brackets) but haven't seen anything yet.

Has anyone using KW Rocketry started using Deadly Reentry for 1.02? It seems like the two don't agree somehow--at it happens, older versions of KW Rocketry also seem to disagree with the new DR as well (they didn't conflict with DR for 0.90, when it wasn't functional). I know it's not up to anyone to fix the incompatibility, but I can't quite figure out what's causing the issue myself. Maybe someone's having better luck.

No, it's definitely something from KW Rocketry (both old and new versions). No idea what though, the pre-1.00 version didn't cause incompatibility (but that was just there for the parts).

So, is anyone getting hang-ups on loading, amid module manager patching? I used the error correction patch, but now I can't complete loading (with or without DDS files supplied by Insane Plumber). Not sure what could be causing it, I know removing DR fixes the issue though. Guess I'll look for incompatibilities. EDIT: I'll be damned, it was ol' K&W Rocketry. Guess something about it and DR at the same time upsets Module Manager--it happens either with 0.90-compatible KW Rocketry and the up-patched version. Naturally, this isn't your problem Starwaster, but I want to share it in case anyone else runs these two mods together (especially if they've got it working somehow).

Great to hear you're close to a breakthrough Starwaster--though I've managed to play 1.0 without DR (just the functioning parts), and I'm eager to get a working DR mod up again, I don't mind waiting for you to get it right.

Has anyone had luck getting antialiasing to work under OpenGL?

Hmm, good balancing! I just removed the values weeks ago...could I trouble you to share your CFG for both engines?

So, I was slightly mistake in my diagnosis--but I'm getting the same thing. As it happens, DirectX vs. OpenGL doesn't seem to matter. I'm using the stock red and yellow "stripes" flag (not the transparent default flag that reads "Kerbal Space Program"), and I get a red box instead. I guess the info window just takes a pixel from the corner of the flag and displays that? What flag are you using, Sal?

So, here's a strange bug that seems to have been around since 0.90, at least for me (with unmodded installations). In the tracking center, bringing up info on a flagsite doesn't display the flag, but a blank box. This doesn't appear to be effected by any mods (and I'm only using stock flags). Was the flag supposed to be displayed?

Once the updated hits, I'll be able to switch my career to 1.00 (and 1.02) proper! Can't wait, godspeed Starwaster!

Interesting--when it doesn't work, what happens? Does it hang on the end of loading? That's what happened for me. As an experiment, I tried setting it to a lower resolution (1680x1050), setting it to be windowed in normal DirectX, then tried running through OpenGL--the window briefly was at the correct size, then reverted to a different resolution (it always goes to that size in my case), and then hung in the same place (checking the last asset before the spinning planet load screen). Weird. Looks like this new Unity version will not run OpenGL on my system, bummer. EDIT: Okay, I played around with the settings a bit more, and I got OpenGL working, hurrah! Let's see if it keeps up after I restart though.

It may be me failing to understand, but this doesn't seemed solved by not going into fullscreen (though no matter what your settings are, at least in my case, it starts loading in windowed mode--then hangs.).