MOARdV

There were some performance optimizations in the props for ASET Consolidated 2.0.5. I've pinged them to see if they might know off-hand about it.

And I should have included you in the "Thank You". Reviva is a feature that the modded KSP IVA experience needs, and it was on the MAS to-do list for a long time (issue #248 that I opened 4 years ago, and closed last year thanks to you). Reviva is easily as important as RPM and MAS, since it allows different modders to come up with their own interpretations of the IVA experience, without the player having to choose only one of those options.

I've released MAS 1.3.7 on GitHub. This release includes Simplified Chinese and Traditional Chinese localization courtesy @ZhaoFJx, along with some important Module Manager fixes courtesy @Stone Blue. With this release, I'm formally putting MAS development on hiatus. I haven't played KSP for over a year. The work that still needs to happen to get MAS to a fully-featured release isn't something that I can spend time on, so I don't know when/if a MAS 2.0 IVA Boogaloo will happen. I'd like to thank: @Mihara for developing RPM, which transformed me from a player to a modder. @alexustas for the incredible props - without the vast collection of ASET props, I wouldn't have stayed with modding for so long. MAS would never have gone as far as it did without the feature requests and props that alexustas made (hopefully, somebody some day will get finish getting the radio navigation props working). @DeputyLOL, @theonegalen, @snakeru, and a couple of former forum members whose names don't auto-complete for submitting issues, feature requests, and feedback that helped steer MAS development over the years. @Stone Blue for feedback, suggestions, and providing support on the forum, as well as expanding the available props and fixing bugs via PRs on GitHub. @JonnyOThan for keeping RPM and the IVA experience alive. All the other players who provided feedback and bug reports for MAS as it progressed.

Now up on GitHub, MAS v1.3.6. This release has a couple of small fixes plus a large batch of props based on Vulkan's M2X props, courtesy @Stone Blue.

Since @Lisias was kind enough to adopt AL, I'll ask to have this thread locked.

I'd be happy for you to adopt it. Although I'm running out of mods for you to adopt, since you were kind enough to keep Distant Object Enhancement going also.

Here's a blast from the past. Aviation Lights 4.1.3 is now available on GitHub. This build includes a fix for the pt-br localization and an increase in maximum light range from 50m to 150m, which may help for people wanting to use these lights for landing lights. It's also been recompiled for KSP 1.12. I'm also officially putting this mod up for adoption. I haven't touched it in over a year and a half, and I don't have any ideas for what to do with it other than this last maintenance release.

Yes, that's because adding decimal support was non-trivial without custom code to manage the correct placement of the decimal, or the inclusion/exclusion of the decimal character. The data entry space accepts characters as input, and it has to convert them to a numeric value to feed to MechJeb. But it also has to convert numeric values to strings when reading values from MechJeb. At the end of the day, I decided I did not want to have to write all of the custom code required to implement those capabilities and handle edge cases. What it needs is a bespoke set of functions built in to MAS to handle all of that overhead, instead of trying to do it in Lua scripts. As for the F02 buttons, etc. They don't do anything. I left placeholders on the screen so that I would not need to position text later, but I never finished working on that MFD. I keep starting on MFDs, getting them partially working, and then run out of ideas. This is another example of that. Right now, the keyboard doesn't do anything, either. All of the keys work, but there's nothing that takes advantage of them. The original prop was intended to integrate with kOS, but RPM wasn't well-suited to support that integration. If I ever figure out how to integrate kOS and MAS, you would be able to use that keyboard to type commands into kOS (or whatever else you do with kOS - I've never used it).

It is caused by a setting. The IVA can be configured to cause instrument malfunctions in high G maneuvers. Instruments will also black out if the game is configured to simulate gLOC and the current Kerbal has passed out. Since KSP allows the player to turn off g-force limits, I could change MAS so that this effect is only enabled when the limits are enabled, but right now it would require writing an MM patch to remove the setting from IVAs.

Awesome - I'll update my documents to point at that for the "where are the IVAs" question.

I have a couple of them listed in the first post, and I think the Reviva mod lists a few more, but I have not seen any other lists. I don't think there are a lot of them, unfortunately. If I can ever finish converting ASET props to MAS, I'll have a MM patch that will convert most RPM IVAs to use MAS, but there are still about 100 props and 2 MFDs that still need converted.

Adding postprocessing effects to cameras would be done something like what you find here for the kazzelblad camera. The camera modes are described on the wiki. Follow the link on that page to Shaders to get a description of the shaders available in MAS. I've released MAS version 1.3.5 on GitHub. This is primarily a maintenance release to add more verbosity to MAS_PAGE and MAS_SUB_PAGE loading so it's possible to get a list of all of the MFD pages and sub-pages that MAS knows about. I also refactored the MAS_PAGE loader to use a cached dictionary of pages, instead of searching the KSP game database every time for every page. That should speed up the transition to the Flight scene for IVAs that contain MFDs (especially multiple MFDs, or complex MFDs).

Sorry I didn't get an update out. I got wrapped up playing Stellaris (and finally getting the "won the game" achievement after several years of getting bored before finishing the game). I'll try to get something out this week. It currently replaces some RPM screens. The MFDs are very involved to convert from RPM to MAS, since the config files are entirely different, so pretty much everything has to be converted by hand. That's the main reason why the MAS prop conversion isn't done - I got burned out trying to get hundreds of props and several MFDs coverted. There's two things going on: First, there is a patch of VDS cams that I made four years ago. It covered the cameras that existed at the time, but it was a fairly generic. Meaning most of the cameras had the very basics of "this is a camera, and it can zoom a little", but not anything else. A few had effects added to the camera. However, any cameras that were changed, or renamed, since that patch was done in 2018 will not be updated. Second, MAS treats cameras differently than RPM. In RPM, all of the camera controls are built into the MFD page (zoom, pan, tilt, and post-processing effects). In MAS, the camera controls are built into the camera part - if the camera is not intended to pan or tilt, it won't. If the camera has a fixed lens, and it can't zoom, it won't. If the camera is supposed to be an older black-and-white camera, then it'll always display noisy black-and-white images, no matter which MFD you use to view the image. However, since I don't use VDS Hullcam, it's low on my own priority list. If someone wants to update the VDS cam patch, I'll be happy to take a pull request.

I'll add some additional verbose debug output to MAS and await your results.

Yes, that's exactly the way it's supposed to work. I wonder if it's some dumb ConfigNode behavior related to the comment on the same line? I don't think I explicitly trim excess whitespace off of the beginning and end of the name, so maybe it's because of trailing whitespace in the MAS_SUB_PAGE entry? If that is the problem, that'd be really annoying (but easy to fix). But I'm spitballing at that. Would you mind removing the comments off of the "name=" lines for the SUB_PAGE and MAS_SUB_PAGE, and make sure there's no blanks after the name? Prolly only check just the one name and see if that makes it happy - if that works, I can turn a fix around later today, or tomorrow AM at the worst. The only other "maybe" I can come up with is if the PAGE node had mismatched braces, or something. I should add some extra verbose logging to list all of the sub pages MAS detects. During startup, MAS collects all of the MAS_SUB_PAGE nodes in its own database, so when you specify a SUB_PAGE, it only needs to search its smaller collection, instead of searching through the entire KSP ConfigNode database.

Based on the error (the 'Unable to find' message), there error is in the MAS_PAGE named "MAS_APEx_MFD40x20_PG_Standby". MAS thinks it sees a reference to a SUB_PAGE in the standby page with a name field of "APEx40x20 Top Menu", but there is no MAS_SUB_PAGE sub page in the config node database with that name. My first guess is that the SUB_PAGE has whitespace in the name (before and after 'Top'), when it should have underscores or no spaces?

I keep looking at that image, and I keep thinking to myself, "I think I see how to make it work". One of these weekends, I need to install Blueshift and start experimenting. Maybe it'll help me get more of the touchscreen MFD pages completed while I'm at it.

Howdy, all. It took a while, but I finally put together MAS v1.3.4, now on GitHub. This is another bug-fix release, with updated MM Patches courtesy @Stone Blue to eliminate log spamming when you don't have some IVA mods that MAS supports, and a fix for exceptions from @Angel-125. I reimplemented the vessel recovery feature, so hopefully those soft locks people were seeing are gone. And I replaced my old IAS computation (which was way wrong) with the KSP-computed IAS.

You can install Unity (it's free for download) and KSP's Part Tools from to load an IVA in Unity and add / size / position props. It's not quite drag-and-drop, but it's way easier than trial-and-error.

Both RPM and MAS use the ASET props, as you've noticed. The main difference between the two is how the mods work under the hood, since they have vastly different designs. MAS advantages: Better performance. More powerful (if you're making custom props). There are a number of props in MAS that are not available in RPM. RPM advantages: All of the ASET props are ready to use. ASET was originally written for RPM, so it includes configuration information for RPM. MAS came much later, and it doesn't support 100% of the ASET props yet (converting hundreds of props gets boring really quickly, so I'm still not done). That said, there are enough props in MAS for just about any IVA you might want to design.

Excellent question. I checked GitHub, and I did not accidentally update the version file, so it should still report 1.3.3, as far as I know. (Sorry, I meant to get an update out last weekend, but things have been chaotic lately)

Ah. Thank you. I wonder why I didn't hit that in the smoke testing I did of MAS. That's really odd. Anyway, I'll get that integrated and released as soon as I can (which will probably be this weekend, since work is already promising to keep me overly busy this week).

The only thing that looks questionable is 'powerOnVariable' - you don't need to include it unless you plan on using a master power switch (and then you'd need to define a master power variable). Nothing else seems off from a quick inspection.

Oh, that's a cool prop. I knew I had seen some rover HUD props somewhere, and I couldn't find them in the main ASET prop sets when I wanted to play with rovers. Looking through the prop config, it's also one of the more convoluted designs. I'll need to dust off some of my RPM memories to figure out how best to get that converted.

I've always wanted to build Prune-Able without kitbashing.