MOARdV

Members
  • Content count

    1,703
  • Joined

  • Last visited

Community Reputation

1,546 Excellent

About MOARdV

  • Rank
    Rocket Scientist

Recent Profile Visitors

6,466 profile views
  1. RPM (and MAS) are only aware of the stock ModuleParachute and RealChute's RealChuteModule. Provided the right methods and fields are exposed in public fields in the SSTU parachute module, MAS could become aware of it as well. I've stopped developing features for RPM, so I won't be retrofitting support to it. The logic for switching engines is a little convoluted. If an engine is enabled and it can be shut down, it will be shut down. If an engine is disabled, and it allows restart, and it is part of the current stage (according to the stage counter on the KSP UI), then you can switch it on. If the engine isn't part of the current stage, it won't switch.
  2. [WIP] Real IVAs for BDB

    Apology first, this is going to be a long-winded tutorial. I'll try to clean this up and put it on the MAS wiki later. The switches in the ASET props pack are all RPM controls. There aren't any official ASET MAS controls - all ASET MAS props are part of the MAS distribution, prefixed with "MAS_" in the prop name. You'll have to make new prop configs for the switches that are missing. I have very few mechanical switches converted to MAS, and alexustas does not have any MAS-enabled props released to the public. The first post in the ASET Props Pack has links to the ASET Modular Push Buttons manual and the ASET Modular Toggle Switch manual. If you don't already have those two PDF files, go get them. They'll make customization of props *vastly* easier. Next, since you're mostly needing toggle switches, browse to GameData/MOARdV/MAS_ASET/Switch_Toggle_Modular. These are all of the toggle switches I've configured for MAS (not a lot, since I'm currently working in a modern IVA design with few mechanical switches). Copy any one of those to your own props working directory. For the sake of illustration, grab MAS_toggle_IMP_Power.cfg and open it in your favorite text editor. A quick tour of the MAS prop config: At the top is the name. That'll change, obviously, to reflect what the switch does. The next few entries are MODEL nodes. Refer to the ASET Modular Toggle Switch Manual, and you'll see what each of these components are, and what options you have for changing them. These control a) how the model looks, and b) which parts you can click on. In this prop's case, you have the TgglBase, which is used on every prop. The TggleBase includes the transforms for adding labels to the switch, as described in the manual. Next, there is TgglLever_Type_5, which is a conventional toggle switch. For an Apollo-style toggle, you may want to use Type 1 or Type 3. After the lever, there's TggleBase_Bcklt_12, which is a simple rounded square border. There are several options here, depending on whether you use a guard on the switch or not (the IMP Power switch does not, but the manual shows you toggle guards, and MAS_toggle_Abort uses a guard). Lastly, there's the collider model, TgglCollider_SNGL. You can select between 1, 2, or 3 colliders, depending on the action the switch will perform. For an action group toggle, for instance, a single collider is sufficient. This prop does not use a switch cover, but the abort switch does. All of these switch component options may seem overwhelming, but remember that you don't have to customize every single switch's model. If you get a particular combination you like, you can copy the config, change the name, label, and actions, and that's it. Maybe 1-2 minutes per prop once the basic style is done. Anyway, let's assume we're making the Action Group 1 toggle. In your copy of the file, change the name to something like MAS_toggle_AG1 (and change the file name so it is easier to find). Beneath the MODEL nodes is a single MODULE, the MASComponent. This module is the guts of a MAS prop. In this particular IVA, it consists of four subcomponents. Some props may have more, some fewer. The COLLIDER_EVENT determines what happens when the prop is clicked. Since this prop has a single collider (per the MODEL node), there is only one COLLIDER_EVENT. The name in the "collider" section corresponds with the one collider named in the manual for the single collider prop. Right now, its onClick function is a little bit complicated, but you can ignore that for now. Change the onClick to "onClick = fc.ToggleActionGroup(1)". This means every time the switch is clicked on, it will toggle AG 1. Beneath the COLLDER_EVENT is a ROTATION node. This node rotates part of the prop. The "transform" that it rotates is the controlled transform for that lever style. You will want to change the variable to "variable = fc.GetActionGroup(1)", so the switch position updates when the action group is toggled. The range / blend / cycleRate entries here are used so that the switch doesn't instantly flip on and off, so it looks a little more realistic. The TEXT_LABEL has a lot of fields in it. As it is configured now, it works well for the IVAs I build. You may want to tweak some of those, like font size and transformOffset. The down side to TEXT_LABEL is that it is not visible in Unity - you will have to launch KSP and enter IVA to see how it looks. At the very bottom of this node is the text - you'll probably want to change it to "text = AG1". If you wanted a label on the bottom of the switch, you would add another TEXT_LABEL node, changing the transform and anchor, and possibly transformOffset. The "variable" entry and "blend" do a couple of things - first, the blend allows the brightness of the text label to change smoothly like it is connected to a dimmer switch (which is exactly what the prop MAS_swRotary_InstrumentLight is). Second, fc.Conditioned() allows MAS to cut off the value when there is no power on the vessel, or randomly when g-forces exceed a limit. Those details are configured in the MASFlightComputer. The active color is the emissive color of the text when the backlight is fully active. The passive color is the diffuse color of the text when the backlight is off. Last is the COLOR_SHIFT. This node controls the other illuminated portions of the prop - the border and the illuminated cap on the toggle switch. Once more, this prop uses fc.Conditioned() to cut off the backlight under some circumstances. The passiveColor in this case is the emissive color of the prop when it is "off". So, wall of text... The upside is, once you've made it through all of that to configure the AG 1 switch, all you have to do to make the AG 2 switch is copy the file, change the name of the file, change the "name" field at the top of the new config file, and change the number in ToggleActionGroup, GetActionGroup, and the text field of the TEXT_LABEL, and you've finished AG 2. And, once the AG switches are done, it may be a little easier to figure out how to make other switches.
  3. Yes, it looks like that slipped through my update. Finding where that was defined and changing 'realchute' to 'parachute' will fix it temporarily - it's going to be updated again, though, in v14.0. No, MAS does not look at keyboard inputs. Considering there are typically a few hundred props in a fully-populated IVA, the keymapping would be a serious challenge to implement.
  4. To be honest, I don't know. My "normal" installs of KSP do not have RPM, and I haven't used it for anything more than a cursory check prior to releasing updates for about two years now, since I started MAS. I would not expect RPM to affect performance in the VAB, since it shouldn't be doing anything. Then again, there have been a number of changes in KSP between 1.3.1 and 1.4.x.
  5. [WIP] Real IVAs for BDB

    ASET Props has all of the models you will probably need for developing Apollo-era control panels. His modular toggle switches have many, many configuration options, but I think I've only converted a few specialized switches for MAS. Fortunately, once you have the template put together for a style of switch, it's a fairly simple (but tedious) task of duplicating it for other switches. It's one case where I really should automate the process with a script or a simple program. MAS supports Lua scripting, so if you can write Lua script, you can write a lot of complexity into the controls. You could set up your controls so certain switches have to be on in order for the controls to do anything - the MRK IVA in MAS demonstrates this with a few instrument systems (the Apollo-style FDAI in seat 2, the Soyuz-style Globus in the center column, the clock system on the left panel, etc). You could conceivably make the controls more complex than that even. One issue I ran into with the IVA for the BDB Apollo when I looked at it a year or so ago was that the seats were way too high relative to the instrument panel. That severely limited the usefulness of the panel, since a lot of instruments had to be placed way below eye level, making them hard to read. Since the IVA was a public domain model, I was able to shift the seats downwards some, so it helped. Please feel free to PM me with any questions you have related to MAS, prop configuration, and so forth.
  6. This is actually a little different than I reported. I retested the "camera aimed up has no sky" portion, and it turns out that's not true. On launch, the atmosphere is missing as previously mentioned, but if I go to the space center and return, it's restored, and I can pan the camera clear to the horizon and still see sky. It looks like the atmosphere layer is generated for maybe the hemisphere that the camera is facing at Start(), but it's unaware that the camera transform was updated. I found an AtmosphereFromGround object, but it's completely undocumented.
  7. You may use them at the same time. I know alexustas has both installed for some of the IVA development he's been doing, and I used both during the early stages of MAS development.
  8. I've found that the cameras I add to parts don't render the atmosphere under certain conditions. When I launch a craft (from the VAB or the Space Center scene), and I enter IVA and switch on external cameras (shortly after sunrise), I see this: If I return to the Space Center and return to the craft and look at the cameras, I see this: So, it self-corrects. The second issue is that the skybox seems to be missing overhead. If I take one of the cameras and tilt it upwards, I eventually find the edge of the sky: Likewise, if I put a cameras on the top of the craft aimed straight up, the sky is black. I don't have Scatterer or EVE installed - the closest I have to a visual mod in this case is Distant Object Enhancement, and just to double-check, I removed that DLL as well. I create the cameras here, copying the existing flight cameras. This code worked in 1.3.x, and I'm not sure what I need to do differently to work around it. One thing I'm doing is that all of the cameras write into the same render texture, but this same behavior has been used in MAS and RPM for several years. EDIT: Changed from "skybox" to "atmosphere", since it's the atmosphere not rendering at the surface.
  9. That may be the info that I was missing. I'll test it out and see what happens. Thanks for digging it up.
  10. AL 4.0.4 is now live on GitHub. Fixed the flash-after-warp bug @MikeO89 reported. Thank you for the bug report. EDIT: The original release did not have an updated .version file. It's now been updated. Thanks to GitHub user MaximeBrean who reported it.
  11. No, that's a bug. I knew exactly what it was as soon as you described it. I'll see about a fix in the next day or so.
  12. I've adjusted the version file to indicate 1.4.2 compatibility. As for the MFD problem -- I've spent a fair amount of time bashing my head against the keyboard, and I have not found a workaround for the problem. It appears that something in the update to Unity 2017.1.3 is affecting the y-inversion that Unity used to apply for DX9 and DX11 to account for DirectX's left handed coordinate system. The problem seems to affect the lower-level calls that RPM uses, since text is not affected. Since I'm not a Unity expert, I don't know what secret knob I can turn to tell Unity to fix this for me, and I don't have the time and inclination to rewrite all of the affected code in RPM to modernize it to the code paths I use in MAS. As a workaround, -force-glcore appears to fix the problem on Windows machines. I assume the problem isn't happening on Linux and Mac, since using OpenGL on Windows doesn't exhibit the problem. If someone else has the time to dig into the problem, or someone who knows more about Unity knows of something I can do to fix this without rewriting lots of code, I'd appreciate it.
  13. ... And AL 4.0.3 is now up.
  14. ...And AL 4.0.2 is now available. Fixed the problem with emissives not updating correctly in flight, and added a toggle switch to tweakable spot lights (the configurable aviation light) that can switch between spot and point lights. ... and I just realized that I didn't extend that toggle to work for symmetry parts, so I guess 4.0.3 will be out very shortly.
  15. Not bugs, but by intent. To expand: The previous versions of Aviation Lights would create two point lights per aviation light part, one as the main illumination, the other to emulate scatter. However, instead of using two point lights, I consolidated it to a single light. I also added the capability to limit the light projection to a spotlight, which the configurable aviation light uses - mainly because I got tired of navigation markers illuminating most of the craft. The lens portion of that part has an emissive layer which should toggle as the light flashes in the VAB (at least, that was working on my local computer when I released 4.0.0). To reinstate 360 degree lighting, you can use a module manager patch along the lines of this: @PART[light_aviation] { @MODULE[ModuleNavLight] { %SpotAngle = 0 } } (provided I didn't type that up incorrectly), or, of course, you can use the MM patch that was included in the release to un-hide the old parts, assuming you didn't want the extra configuration options. I'm not sure if the Unity spotlight allows a cone larger than 180 degrees - it's been a few weeks since I skimmed their documentation. It might be possible to allow the spotlight cone to be adjusted as well. I will have to look into it.