• Content Count

  • Joined

  • Last visited

Community Reputation

2,050 Excellent

About MOARdV

  • Rank
    IVA Scientist

Recent Profile Visitors

9,505 profile views
  1. You'll want to install Unity and the KSP PartTools extensions to Unity, and configure the PartTools. There are instructions on the forum for how to get those tools set up. Once you've done that, you can open an existing IVA, and use PartTools to select props from a list and spawn them. It's not really difficult to do, but it can be tedious - especially when you're first starting, or trying to figure out which of the hundreds of props is the one you need. One tip for placing the first few props - select an existing prop, go to its Transform window in the Inspector, click the gear icon and choose Copy Component. Then, once you spawn a prop you want to use, do the same thing, but select Paste Component Values. That places the new prop where the existing prop is, so you don't have to move and rotate the prop to get it positioned about right.
  2. To install it on a stock light, you're going to need to use a MM patch to remove the existing light module from the light, and to add ModuleNavLight to it. It is going to take some effort to configure it correctly, since AviationLights adds lights to the root gameObject on the part. You'll need to use LightOffset and LightRotation to position the AL where the stock light was, and probably need SpotAngle to change it from an omni light to a directional light. There are some other mods already out there that give you control over existing lights similar to what AL does - one of those might be a better choice when working with an existing light.
  3. You would need to edit the prop's config file - the file is in GameData/ASET/ASET_Avionics/ModernPack/ASET_HUD/ASET_HUD.cfg Search for "EASPEED" in that file, you should see labelText = <color=#3cff60> <=0:000=>$&$EASPEED Change EASPEED to SURFSPEED, and you'll have surface speed in m/s. There isn't a separate true airspeed, since the airmass on Kerbin has no velocity relative to the surface. Other speed options are at the RPM wiki here.
  4. That would primarily a question for BDArmory. I don't use the mod, so I won't be building support for it into MAS. MAS supports the RPM interfaces for displaying pages on MFDs, so if BDArmory has RPM compatibility, it'd be able to display through MAS.
  5. The "imaginary unit" is Equivalent Airspeed - the altitude at sea level that causes the same dynamic pressure as the current true airspeed and altitude. Wikipedia has a couple of examples for why you'd care about it (stall prediction being one reason).
  6. @Bottle Rocketeer 500 - okay, sorry, I misunderstood. Something like that *should* be possible with MAS today, with a creative application of Lua scripting and the MAS navigation system, as long as you're looking for prompting ("Climb to Flight Level 15, Turn Left to heading 300"). MAS isn't able to fly the route for you, but it should be able to tell you what to do. I think the only excuse I have for not making a sample is that I don't have a lot of navigation waypoints to work with. I've included a lot of radio navigation sites that @alexustas created, and I've added the Kerbin Deep Space Relays, but that's all the MAS database knows about. Okay, the other excuse is that I am not good at that "space plane" thing in KSP, so my normal flight path is "go up, tip over, circularize", not "speed up horizontally, pitch up a little bit, don't smash the back of your plane on the runway, go fly somewhere". So flight path planning isn't as important. MAS should have a patch for Hullcam compatibility -- but, as far as I know, there isn't a Mk3-9 IVA using MAS. From the props I see (Near Future Props plus some RPM props), that looks like it's a RasterPropMonitor IVA, which isn't something that MAS is going to control. If I remember correctly, HullCam manages compatibility with RPM (it's been a few years since I worked with HullCam / RPM interoperability). Well, considering MAS sneaks in to other mods to be compatible with them, I figured I wasn't the only one. Kidding aside, kOS / MAS interop may be a good candidate for core MAS. It may be time (when I have the spare time to play around with KSP again) to look at making the kOS / MAS interface a thing. There are a few things I wanted to do in MAS that probably would work better as kOS. But I realistically won't be able to work on that any time soon, since Real Life and other hobbies have kept me quite busy lately.
  7. A Flight Management System is more of a prop or collection of props, not really a feature (as I would define 'feature', at least - part of the DLL). The IFMS MFDs I'm working on do integrate some flight management features, although they are focused on KSP rocket flight management, not space plane. alexustas showed off a MAS FMS on his YouTube channel last year, but he's been very busy lately with Real Life. MAS also has an extensive set of navigation features that can simulate radio navigation systems and compute a variety of informations, such as heading to reach a specific location on the planet, distance to a location (both slant direction and distance along the surface). Other than alexustas, I don't know if anyone has used them extensively. Probably what would make the most sense from a MAS perspective is a soft dependency, similar to the way MAS interacts with FAR, MJ, RealChute, KER, etc. That would allow MAS to talk directly to the kOS interface, which provides a great deal more flexibility. I suppose at some point I could take a look at kOS again and see how well suited it is for that sort of interaction.
  8. Switches, etc, are in the realm of possibility. I need to update the MAS Action Group feature to make it more robust - once that's done, a lot of functionality could be supported through switches with that code. There's no reason a second instance of the rack-mounted prop can't be used as a kOS core / mini-display. They are rack-mounted units, after all. Maybe (at worst) a reskin of it to change the logo? As for graphics - MAS can do a lot graphically (display texture / images, draw lines, draw closed polygons), but it also supports the old RPM interface of passing another module/DLL a render texture that it can draw on. Although it may make more sense to couple kOS more tightly, so more types of information can be passed back and forth.
  9. 1. Not entirely. There are currently three varieties of MFD in MAS - MFD1, which is supposed to be a Soyuz-styled MFD, which I haven't maintained in forever; MFD2, which is more-or-less complete; and the IFMS series, which is complete for launch / landing / maneuver, but still needs rendezvous / docking and some information pages. The IFMS will be my development MFD going forward, since its letting me validate some multi-monitor designs (the "kOS" terminal with the keyboard is for planning / configuration, the conventional MFD is for data reporting and task-specific control). However, I've been working on some non-KSP stuff lately, so I haven't finished the IFMS design. 2. No and not currently. There is a monitor called the "kOS Terminal", since alexustas designed it for RPM with the expectation of kOS support that never happened. The monitor is fully functional - all of the buttons send events. I've never used kOS, and at the time I was looking into it, I had some unpleasant exchanges with one of the kOS team members, so I decided it wasn't worth my time. 3. MAS is designed to interact with other mods. For some of them (commonly used, with stable interfaces), I've built support into MAS. MAS can also use the same interfaces that RPM uses - the other mod needs to provide a couple of methods with specific signatures that MAS can call, and then MAS can send them button events and display text on a screen. If that's what you mean by integrating, then it shouldn't be too painful. If you mean letting another mod control MAS, it's not designed for that - it accepts collider events from props, and it can trigger events based on conditions of variables and functions it uses. I could probably extend MAS to call public functions in other mods without a lot of difficulty. I can go into more detail if you want to give me an idea of what you're looking at doing.
  10. Avionics Systems v0.97.0 is now available. It has been tested against 1.6.0 and 1.7.0. This release includes fixes for some potential (and actual) NREs, as well as a patch to replace the map of Kerbin on the Globus instrument with a map of Gael when GPP is installed (map courtesy of @snakeru). @Micro753 - If you're able to add the props, you're most of the way there. To save the IVA config is not obvious - you have to click on the root of the IVA in your Hierarchy window (not the top-most item, but the item that has the IVA model's name): Then, the Inspector tab should look similar to this. That last section is where you save. The Space Name is the name of the IVA space. Config Name is the name of the .cfg file that's created. Dir URL is the folder where you want the config file to be saved. To save your work so you can continue later, you want to Save Scene (or Save Scene As...).
  11. Is there any other context around that error statement? By itself, I see nothing in the variable that would be a problem. Yes. "autoRepeat" means "While this variable is true, call 'event' every single FixedUpdate, not just when the variable becomes true." You would use this, for instance, to repeatedly update something while the conditions in 'variable' are met. If "autoRepeat" is false, if means "call 'event' as soon as the variable becomes true. If it becomes false, call 'exitEvent' (if it exists). If the variable becomes true again, call 'event'", et cetera.
  12. Short answer: yes. Long answer: This is an overview of how MAS variable updating works. There are 5 kinds of "variables": Lua Script - these are actual Lua functions. These update every FixedUpdate by default. There's a control on the MAS configuration window (accessible from the Space Centre view) to reduce that frequency. Lua scripts are s-l-o-w. My measurements show they take 10x - 15x longer to process, so you want to avoid using them for variables any time you can. Save Lua variable for complex things. (EDIT: Or as the action for colliders or TRIGGER_EVENT actions) Native MAS functions - these are MAS functions like 'fc.GetApoapsis()'. These are updated every FixedUpdate, but they are also very fast. Dependent MAS functions - these are MAS functions, and mathematical operators like 'and' whose output is affected only by the inputs. As long as no input is changed, the dependent function does not update. Every FixedUpdate, MAS will ask the dependent function, "did any of your inputs change?", and skip it if the function says "no". Persistent Variable Queries ('fc.GetPersistent()' and 'fc.GetPersistentAsNumber()') - these go one step farther, and they only update when they're told their persistent variable changed, so when MAS asks them if they need updated, they always say "no". Constant Variables - they're technically variables, but they're never queries, and they never update. MAS uses a parser to disassemble the 'variable' field to figure out whether MAS can handle it directly, or if it needs Lua to handle the variable. In your example variable, there are 9 variables involved in the computation. four of them are constants ("aaa", "bbb", "5" and "0"). Two are persistent variables, and the rest are dependent variables. The only variables that change on their own are the two persistents, so the only time that variable gets evaluated (or partially evaluated) is when a persistent changes. The evaluation of compound statements stops as soon as MAS finds a result that is unchanged. For instance, if persistent "aaa" is 4, and it changes to 3, MAS will reevaluate fc.GetPersistent("aaa") < 5, and it will discover that the result did not change (aaa is still less than 5), so it won't worry about recomputing whether the result of the "and" has changed. As for the side question: Yes, if your Lua script is only checking some values to see if they're in range, and using that knowledge to update another variable, a TRIGGER_EVENT will be much more efficient. By the way, the parser is only semi-smart: as long as you use the same ordering of variables in your conditions, MAS won't generate new variables to handle each case. For instance, mathematically, 'fc.Apoapsis() * 0.001' and '0.001 * fc.Apoapsis()' have the same value, but MAS will create two variables (and do the multiplication twice). If you use the same order every time, MAS will create only one variable who will broadcast its results to all interested parties. - so, 'variable = fc.Apoapsis() * 0.001' and 'variable = (fc.Apoapsis() * 0.001) < 5' will both use the results of 'fc.Apoapsis() * 0.001' - it does not get computed twice for the two variables.
  13. Hi MOARdV

    Dont know if you have seen this or not, but I asked if it could be used in conjunction with writing scripts for MAS props...

    If you think it might be useful to you, I guess maybe PM the devs about it.


    1. MOARdV


      Yeah, I did see that.  They're using MoonSharp, IIRC, so their Lua stuff would be compatible with mine.  I don't know off the top of my head how well the two mods would mesh. I'd have to spend time playing around with what they have, and peeking at their source, to see if their script editing could work with MAS scripts.

  14. It looks like you have the correct model name for the 6-mark switch. It looks like the names for the labels are Pos_1_TextObj, Pos_2_TextObj, etc through Pos_6_TextObj (I get these from the JSILabel entries in ASET/ASET_Props/Control/SwitchRotary/6_pos/RES_DISP_ModeSelector.cfg). I don't think I've used the 6-pos rotary switch, so I don't have any other guidance to suggest yet. MAS is a little stricter about module definitions compared to RPM. Certain modules need to be explicitly added to parts / props / IVAs in order for MAS to initialize and function correctly. For this particular case, I really ought to change the message to make it clearer in-game that it's something missing from the config file.
  15. Ironically, I removed that functionality just a couple of months ago... Actually, it was not exactly like you are asking. It was a part module that would add options to trigger a MAS function from the part action window (right-click part menu). The reason I removed it is that MAS functionality is switched off in part when the player is not in IVA view, so it would be possible to trigger a function that doesn't work, or it doesn't work correctly. I could add something to MAS that allows a custom option like you show in the screen shot mock-up, but it will have the same restrictions as the previous module - it may not work if the player is not in IVA mode. It also requires adding part modules to the IVA's part (not the IVA itself, or a prop), but you already have to do that for the MASFlightComputer module anyway, so that's not a big problem.