MOARdV

It's been a couple of years since I used this mod. From what I remember, I needed to autostrut the Zenit side-booster fuel tanks to the main fuel tank (using Autostrut to Grandparent). To avoid all of the torque effects of the RD-170 engines on the side-boosters, I used Autostrut to Root on the nose cone for the side booster. This seemed to take care of the twisting that the side boosters wanted to do during ascent. Of course, this was a few KSP versions ago, so who knows if it still works. FWIW, I typically autostrut each fuel tank to the root part, boosters tanks to their grandparent part (so they strut through the decoupler to the tank that the decoupler attaches to), and booster nose cones to root to eliminate the twisting that the boosters otherwise will do. I haven't needed KJR to launch anything up to N-1 or Saturn V sized when using autostrut.

I'll second that. The mesh and texture work on these look incredible. I'd love to have some better-than-stockalike modular MIR components, and I think this art refresh pushes the Tantares MIR into that range.

That looks like a shader issue with the text renderer code in RasterPropMonitor. You might check on the RPM (adopted) thread to see if @JonnyOThan knows about it.

There's a link in my sig for "how to get help". Specifically, I need to see the ksp.log file from a game session that hangs. That may provide a clue as to why the game is hanging. I have barely touched 1.9.x - I think I spent enough time to verify that the game loads and MAS more-or-less works. There's at least one known issue in 1.9 on Windows: cameras don't work quite right because Squad changed their flight camera setup, and I haven't had the motivation to hack a work-around into the code.

Oooooh. And here I've been trying to figure out how I could make a sort-of R-7 using BDB. For reasons. And, bonus, this uses my two favorite US LVs. Maybe it's time to go try doing horrible things to first-stage vessels...

Does editorOpenOffset also control the direction the fairings go when they deploy? EDIT: Derp, you just said deploy direction is based on CoM. Sorry. Let me go revisit those values first. EDIT 2: Yes, changing the CoM from X direction to Z direction fixes that element. Thank you for the info.

Could I get some suggestions on what I need to do differently when retrofitting SAF to an existing fairing? I'm messing with the very old DECQ Angara mod, which had separate fairing parts. (KSP version 1.8.1, SAF version 1.7.2) I've got this in the config (showing MODEL and the SAF nodes only): The CONE transform is the first named transform that's unique between the two models, FWIW. The shielding center/radius and the CoM value for the CONE are copy-pasted from an existing working fairing. In the VAB, the fairings appear on the 'front' and 'back' of the adapter, not on the sides (even if I remove the rotation field from the fairing's MODEL node), but when I Open them in the VAB or deploy them in flight, they fling off to the sides. The KW Rocketry fairings appear on the sides, and eject to the sides, so I assume it's something peculiar with the Angara fairings. What should I do to get the fairings to appear on the sides, not the front/back?

I found it tricky to get them to dock as well. Like @Pappystein said, it's probably a collider on the Dragon pod that's interfering. I used a BDB 1.25 to 0.9375 structural adapter on the space station to move the passive docking port away from the surface, and that helps. There was also one occasion where I rolled the Dragon slightly (just tapped roll) after retracting the docking ring, and that helped as well. But, if you're using Dragon, I'd suggest using a narrow structural adapter on the space station so the passive dock doesn't have anything from the space station near it. FWIW, with any other spacecraft, I have no trouble with the CADS docking ports.

It looks like it. I didn't really account for text-mode graphics when I wrote the text renderer - I figured people would use an IMAGE node to represent the graphics they needed (which is why the MFD directory has so many textures). If you can point me at the Unifont, and it's got a compatible license, I can include it in an updated MAS release (if nothing else, I can kick out a point release to include that an a couple of 1.8.x update leftovers, since I still haven't moved to 1.9.x in my dev environment).

I hadn't considered it, to be honest. I figured the fonts already there were fairly thorough (the Liberation Sans font has unicode support - I've used it to display Cyrillic characters), although the fixed-width limitations on the MFD will skew characters. Since I need to update the asset bundle loader anyway, I will see if there's an easy way for me to support additional fonts from other asset bundles.

I think the problem may be in your script - you've got a local variable named 'SUP_TimerButtonPushed', and a function with the same name. The function replaces the boolean that was named SUP_TimerButtonPushed, so when you say 'if SUP_TimerButtonPushed then', Lua thinks you're referring to the function. I think renaming the local variable to something like SUP_TimerButtonPushedState will solve the issue. In case you weren't aware, the ASET Clock/Timer is in core MAS (MAS_ASET_ClockTimer in GameData/MOARdV/MAS_ASET/ASET_ClockTimer/ASET_ClockTimer.cfg).

The SetPersistentBlended call is as expensive as GetPersistentAsNumber until it has to start updating the value. Then it's as expensive as the Get call plus a Set call, basically (plus the tiny bit of maths involved in blending). In the grand scheme of things, I suspect an active MFD with text and graphics is more expensive than this would be. EDIT: Maybe I should answer that for someone who's not spent too much time bouncing around in my source code. Both the "set" and the "get" are more expensive than a lot of the MAS functions, but they are still pretty streamlined. The "Flight" page in MAS MFD2, for example, will be require more CPU cycles to update. For any command pod or reasonable flight deck, I'd think that the adjustable seats would be no big deal, as far as introducing lag.

Sorry to be back again. Would it be possible to edit the beginning of the locked 1.6.x RPM thread's OP (the NOTE: section of the OP) to point people at the new thread? I should have done that before asking for the lock. So, edit the OP here: to direct people to here: Or, if there's some way to temporarily give me permissions to make that edit, or whatever's most convenient.

That's a clever way to work around the limited panel space! 1-seat IVAs are always tricky to pack everything you need into them. As for getting the position - you would probably need to use something like fc.SetPersistentBlended() (here) as the variable controlling the seat position. That would let you query the position via the persistent variable. To try to demonstrate, since it's a little convoluted: --SEAT POSITION SWITCH COLLIDER_EVENT: onClick = fc.TogglePersistent("GoalVerticalPosition") --SEAT POSITION VERTICAL TRANSLATION: variable = fc.SetPersistentBlended("VerticalPosition", fc.GetPersistentAsNumber("GoalVerticalPosition"), 0.25) "GoalVerticalPosition" tells you which position the seat is moving to. "VerticalPosition" tells you where it's at currently (the 0.25 in the blended means it will take 4 seconds to change positions - that's where you control how quickly it moves). If fc.Abs(fc.GetPersistentAsNumber("GoalVerticalPosition") - fc.GetPersistentAsNumber("VerticalPosition")) is small (<0.001, for instance), the seat is done moving. You'd do the same thing with a HorizontalPosition and GoalHorizontalPosition,. Since you're only going to have a couple of SetPersistentBlended calls in the IVA, it won't be too expensive (processing time) to use. Using two variables also lets you deduce which direction the seat is moving, if you wanted indicator lights for that.

It looks like I never upgraded the start/end translation to accept variables, so they're currently vec3 instead of three variable digits. It looks like the ASET props that wanted to use two translations used two transforms, as well.

Please lock my RasterPropMonitor thread.

Since @JonnyOThan has taken over maintenance and development of RasterPropMonitor (thank you, once again), I'm going to have this thread locked to avoid future confusion. Please check in at the link in the post directly above this one for current editions of RasterPropMonitor.

The Mk1 stock command pod already has a MAS Mercury-ish IVA. I have not looked at the BDB Mercury IVA to see how its panels are set up, but the Gemini IVA model is really unappealing. FASA has a much nicer model to work with, but the panels are set too far in front of the crew positions, and the model can't be rescaled to fit BDB's Gemini pod. I'm lucky if I can use Blender to create a cube (to say nothing of exporting to Unity, and then getting it into KSP), so I am the wrong person to create a new IVA model for either the BDB Mercury or Gemini. Which is a pity, because Gemini is still my favorite of the three. So, regrettably, there's no plans for replacing them. If I had a good IVA model to start with, that'd be a different story. Thank you! It's not quite perfect, but I am really happy with how it turned out, and (once you get the hang of it) it's fun to fly, too.

You'll need the Unity editor (which is free), and you need the Squad's Part Tools to load/save the IVA configs from here

KSP 1.9 made changes to the camera system for the Windows version of the game (but not Linux or Mac). When I have time to get a KSP 1.9 development environment configured and I can get some testers to verify that Mac and Linux work, I will look at it.

Nice! Nothing funky in the log (I'm supposed to be working right now, so I shouldn't fire up the game to check )? I suppose that if I need to get a release out, I ought to think of some other feature to tack on while I'm at it. There was a request to make the light's spotlight cone tweakable. Would that be of interest? Maybe support axis groups with that, as well?

He is a steely-eyed missile man, for sure.

Unfortunately, no, there isn't. That would have required a level of planning way beyond what I had at the start. That, and I was using my own design aesthetic for a lot of the common things (action groups, etc) instead of alexustas's aesthetic. By the time I realized that I desperately needed to organize the props better, and provide some documentation, there were over a hundred props in the MAS collection. Once I *did* start getting organized, and I started converting props that were more straightforward, I tried to use the ASET name with "MAS_" prepended to it. (eg, ASET_ALTIMETER_Adv -> MAS_ASET_ALTIMETER_Adv). Documenting the props is one of the two big (and boring) components of what MAS needs right now, along with the conversion of the rest of the ASET props. If I can ever find adequate motivation to slog through it, I will. And that'll allow for a MM config that can magically convert RPM IVAs to MAS IVAs.

Every launch vehicle I build uses Aviation Lights configured as red beacon / double flash for "Warning Lights" on the first stage. Because I decided Kerbals would not clear the airspace around a launch site, and (somehow) aircraft in the area would notice lights on a launch vehicle *before* they notice the rocket blasting through their flight path.

Ah, cool! I will download it and rotate it back into my flight planning.