• Content Count

  • Joined

  • Last visited

Community Reputation

2,217 Excellent

About MOARdV

  • Rank
    IVA Scientist

Recent Profile Visitors

13,691 profile views
  1. 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.
  2. 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...
  3. 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.
  4. 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?
  5. 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.
  6. 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).
  7. 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.
  8. 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).
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Please lock my RasterPropMonitor thread.
  14. 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.
  15. 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.