MOARdV

Heh. I wish. A lot of the conversion work is tedious, and it bores me fairly quickly. That's why I put it off for so long. I hope to have it done by the end of this year, but that mostly depends on how soon I burn out on going though config files and trying to figure out what they're doing. I started on the props for the ALCOR lander so I could test them, and I might have 40% of them done (the MFDs are going to be the killers to convert - it took me a week to get through the simple JSI MFDs). But even the ALCOR pack uses only a fraction of the ASET collection.

When the ASET Avionics/Props update is out, I'll need help testing a lot of different IVAs. There are hundreds of props in the ASET prop packs, and there's no way for me to test all of them. I'm doing what I can, but even the classic ALCOR lander has a few hundred unique props in it.

Yes, that's the way RPM (and MAS) does it, by looking at the vessel description. You can also be fancy with it and use AG5=doohickeys on|doohickeys off to make the action group label change depending on if the AG is "on" or "off".

@JonnyOThan was kind enough to let me advertise this on the RPM thread. The IVA mod I've been working on for the last couple of years now has an update that replaces the basic RPM props with MAS-enabled props. If you're using any of the IVAs that are included in the core RPM distribution, and you install MOARdV's Avionics Systems, MAS will power the IVA. A future update will support ASET Avionics and ASET Props as well.

MAS v1.2.0 is now live on GitHub. This update adds more functions (it's over 1000, now), fixes a couple of things, and adds more props (see the changelist for more detail). Of interest to players: MAS now includes a Module Manager patch to replace JSI RPM props (the props bundled with RasterPropMonitor) with MAS-enabled versions of the props, and it patches RPM-enabled command pods to support MAS. What this means is that the example IVAs included in RasterPropMonitor use MAS instead of RPM. I'd appreciate feedback from players on their experience with it. The next planned major release of MAS will include full ASET Avionics / ASET Props MAS config files, documentation for IVA creators for the props, and an update patch to convert ASET RPM IVAs to MAS. I've got help on the conversion process, but if anyone else wants to contribute, please let me know. There are still hundreds of props to convert.

I look forward to seeing this develop. There was a really good looking Angara rocket years ago, but it was abandoned, and it was more of a real-world art style, so it did not match everything else.

I've never used any part failure mods, so I haven't added support for them.

As long as latitude +/- 90 define the axis of rotation, yeah. It doesn't matter if the latitude is 0 or 89.99999 - the period of rotation is constant. A given line of longitude will sweep across 360 degrees in a single day.

That's reassuring. From the doxygen page, it looked like the default for ModuleProceduralFairing.BaseModelTransformName defaulted to "Base", so I assumed that meant that configs that didn't include that field were going to use that default value, which was the problem with mods' procedural fairings in 1.10.0.

You know the rotation period of the planet, so you can determine how much you need to adjust the longitude based on that. I think it's a case of determine the change in time (FutureUT - now), divide that by the Body.rotationPeriod (as long as the period isn't 0), take the fraction from that result, multiply by 360, and add or subtract (don't remember which) to the longitude. And then normalize the result to [-180, +180]. That should get you the right answer, or at least get you pointed towards it - it's been a while since I messed with that type of problem.

I infer that this means that every single mod is going to need to patch every single ModuleProceduralFairing in order to work in 1.10.1. I guess it'll be a while before I move off of 1.9.1.

Super-quick feedback - most of this you're aware of, since this is all bleeding-edge new development and not official release. Hopefully these aren't something I did wrong, since I would hope I've got this "download from GitHub and install" thing figured out On the other hand, the Block D and a couple of other parts showed up all-black, so maybe there is something screwy with my test installation (1.9.1, should not be any mods that interfere). No localization yet (I don't expect any) There is a large visual gap between Block-A and the Block-A engine cluster - the bottom node on Block-A is too far down. I double-checked that the module manager cache node positions match the original part's config file. No decoupler for Block-A to Block-B. (I assume there should be decouplers, since the fuel tanks don't have decoupler functionality). I used the 'old' N-1 decoupler for B/V. Block-V has no mesh on the top - but it's easy to cover with a 3.75m fairing base. Engines don't generate power. I like the pixel density - I wasn't sure that a lower-density was going to look as good, but this thing is so huge that closeups aren't as useful. One should bask in all the glory of the rocket, not just a few side panels. Visually, it looks good. Fuel burn rates felt okay (meaning, the time I spent flying each stage felt okay), although I think Block-B (2nd stage) T/W may be a bit low. I'll have to go double-check - with a minimal payload, I think it was slightly above 1, which seems awfully low for a Kerbal 2nd stage, since that wasn't a full L3 launch complex or something like that. Sorry this is fairly brief, and I don't mean for it to sound negative, since this isn't the final config for the parts. I really like what you've got so far, and I look forward to integrating it into my play-through installation once it settles down.

That's a start. When can we expect the launch gantry? (and, to make sure I'm clear: I DO NOT expect Beale, or anyone else, to make a launch gantry. It's Friday afternoon, my time, and I'm being a smart aleck because I'm ready to be done with work for the week) And now to grab the Github snapshot and enjoy some rocketry dialed to 11. Or, at least, 10.625.

I remember seeing Förbidden Lämp open for Unplanned Rapid Disassembly in the Whisky a Go Go back in '89. Anyway... I'll go back to waiting (im)patiently for N-1.

That's good news! I'll have to keep an eye out for that. OLDD and RaiderNick both have separate Block A engines. If I had any talent modeling, I'd try fixing collider issues in the OLDD meshes, since that's my favorite released N-1. For Block A, I think having all the engines on one part will be fine, particularly since they're entirely shrouded by the hull. For the upper stages, placeable engines would be preferable for the sake of making ahistorical variants with different engines. I look forward to seeing how Beale's version turns out, since I'd like to have an N-1 and N-11 for heavier launches.

There's a pretty good reference on the N-1 called "N-1: For the Moon and Mars", although it looks like it may be out of print (glad I got it when I did). It's got quite a few scale color illustrations of the four flown variants from multiple angles that show lots of greebles.

That is an understatement! I've been wanting -- for YEARS -- to have a decent looking N-1. I've hacked up config files for a couple of old mods trying to get it them to work, and I even went so far as to re-texture a mod (that didn't end well... I'm a coder, not an artist). The only criticism I have for these screen shots is pedantic: on the shroud for the Block B engines, I believe the boxy greebles house separation motors, so they should be at the seams between the panels, not in the middle. The upper and lower boxes blasted one direction, the center box blasted the other, to ensure the shrouds were blown clear of the engine fixture. That would make a cool detail during ascent. But, on the other hand, that matters for a few seconds during launch, and only to people who spent too much time reading about the N-1 are going to notice.

Thank you for confirming the fix. Sorry that I misdiagnosed it initially as a mod conflict.

I *think* I sorted it out. MAS v1.1.1 is now available. This fixes the launch site exception and a couple of issues that will pop up in 1.10.0. It also finally fixes the cameras for Windows players (which I forgot to add to the release notes - I'll need to fix that). This release should work on 1.8.0 and later. It was lightly tested on 1.9.1, and briefly checked over in 1.10.0, but I haven't had time to test it extensively. On GitHub as usual.

The MAS navigation module tries to fetch the localized name of the launch site (either a LaunchSite.launchSiteName or a SpaceCenterFacility.facilityDisplayName). if that's not configured the way I expect, then MAS generates an NRE that causes the main MAS module to fail to configure correctly. Which mod is it? I'd like to see if I can tweak MAS so it shows the launch site name. TL;DR: It is indeed a MAS bug.

This is going to sound random -- where are you launching from? One of the stock launch sites (if so, which one)? Or a mod's launch site? I am hoping to get a MAS update out SoonTM that may help figure out why MAS is unhappy with your setup. You've still got exceptions firing from other mods, but the specific MAS error that's triggering everything else is very odd.

There are so many untrapped exceptions and errors in that log prior to getting to the flight scene, I'm not surprised MAS is failing. You've got one or more mods that are causing all sorts of problems, and it's preventing other mods from working correctly - PersistentThrust shows up repeatedly, for example. Sorry, but until the other exceptions are resolved, I can't do anything with this log. I am able to load and run MAS in 1.8.1 and later, so there's something in your installation that's preventing MAS from configuring.

First, the disclaimer: I'm not a lawyer, and the following does not constitute legal advice. You said that you're reviving a mod (well, working to fix one, which is close enough) - the short answer is, you use that mod's existing license - unless it says "All Rights Reserved", or it doesn't state a license (which is assumed to be the same as "All Rights Reserved"). If it's ARR, you can't redistribute the mod without express permission of the original creator. If you were creating a new mod, or completely new configs (to replace configs in an existing mod), it'd be a different matter - you'd select a license.

I've released AviationLights 4.1.1 this morning. This includes a fix that enabled the Spotlight toggle in the PAW for lights that were marked non-tweakable. It also finally updates the version file to include 1.9.x as well as 1.10.x. Available at the usual place GitHub.

Woops - wrong thread.