snakeru

Having worked on MAS LUA quite recently, I can share the development harness - the unit test framework that I wrote specifically for this purpose. It might require some work though if run on Windows.

No, it's not that simple. MAS is not a drop-in replacement for RPM. There are chances that a mod works with both, but there is no guarantee (every mod has to be manually adjusted) and also probably not much point (if a mod supports MAS - why would it need RPM support?).

I think I can answer that one. There is a lot of functions exposed for LUA usage in the MASComputerProxy. While you won't be using LUA in your mods, I expect it to be about same difficult (that is - not difficult).

Actually, now as I checked out the "source of inspiration" (the "Race to the Moon") and also discovered the concept of the MTBF I think that this is already implemented :-D I wanted something that could only be improved by actual flights and would not be achievable by just testbenching. So I think now that MTBF is probably thought as exactly that. Except for that problem that I described above, but if that's a bug - then it could be fixed and if not - even better!

I can not understand how to help the "Condition" parameter. By reading the posts in the thread I have figured out that the condition is an MTBF indicator, except that it is not numerical, but a textual one. However, I am struggling now with bringing it up: I have noticed that my flights fail often even though I do the integration. So I started experimenting: 1) If I put together a craft, go through integration and launch - I get "Condition: Poor | Quality: 80/80" for a lot of parts. 2) If I do a series of test stagings (staging events while the craft is still held by the launch clamps) - that doesn't seem to affect the condition 3) If I do test fires (throttle up the engines just a little bit and let them burn fuel while still held by the launch clamps) - that still doesn't seem to have any visible effect either. BTW - I used 9 engines in the same craft in hope that the experience will come at 9x rate. 4) If I make a couple of quick-saves while in test firing mode (with some firing in between them) and then diff these two saves - I can't see anything with "mtbf" in the name changing. So I suspect such firings have no effect 5) That doesn't seem to depend on the part tier either. The LV-909 "Terrier" is always in "Poor" condition (and the next Tier is already researched) while the "Probodobodybe OKTO" is always at "Excellent" (and this is the latest Tier I researched). In other words - no matter what I do, the condition is always "Poor" for some parts for me. What do I miss? EDIT: I have tried making a craft that contains all engines that are currently available.Apparently, I have a bunch of combinations: most engines are in state "80/80 Poor", one is "36/36 Fair" and one is "35/35 Excellent". And I am quite certain that just on the previous launch that second one was also "35/35 Excellent". Which hints at rather counter-intuitive idea: the higher quality the engine has - the worse state it is in. Why? EDIT2: And yet, monoprop tanks are "80/80 Excellent", batteries are "80/80 Good" and high gain antennae are "80/80 Fair". I'm confused. EDIT3: Weirder still - I have loaded one of my old designs and it has a different condition for the exactly same part! I have specifically loaded two different designs and integrated them side-by-side. See the picture.

I am working on a MAS-based "ascent assist" autopilot. Would anyone volunteer to test it? You'll need a "Making History" mod for that. The idea is to make launches more predictable in terms of orbit reached and dV remaining. I specifically didn't want to use MechJeb because for me it feels like it takes fun out of the game. You click "Launch" and then you can go away for a few minutes and still find yourself in a perfect orbit once you come back. So to avoid that experience the AA device is not really smart. The device is very limited in its functionality. It can do, in this particular order: hold vertical attitude (initial ascent), hold near-vertical attitude (initial rotation), hold surface prograde (gravity turn), hold orbital prograde, hold near-horizontal attitude (final touches to your ascent, optional).

Hi @MOARdV. Sorry for bombarding you with questions. I am converting my LUA script into a set of TRIGGER_EVENT entries and have hit the following problem: [ERR 20:26:12.932] [MASComponent] System.ArgumentException: Error parsing variable "fc.GetPeristentAsNumber("someVariableName") > 0" ---> System.NullReferenceException: Object reference not set to an instance of an object Is this a bug or something on my part? For the reference, here is the whole block: TRIGGER_EVENT { name = Circularisation Assist logic event = RunCA() exitEvent = fc.SetSASMode(0) autoRepeat = false variable = fc.GetPeristentAsNumber("someVariableName") > 0 } Ah, and a side question while we are at it: If the "autoRepeat" set to false and the variable goes multiple times from false to true and back again - will the event fire multiple times?

@MOARdV, cool! That means - LUA could be used for prototyping, but once the logic is clear, we can rewrite [most of the] things to native syntax. Thank you for very detailed explanations!

Hi @MOARdV Yet another question: what technique can I use to reduce the CPU load? I've got it that the LUA should be running as little as possible - but do I also take care of how I design the indicators? My question is specifically this: if I have 'variable = fc.GetPersistent("aaa")<5 and fc.GetPersistent("bbb")>0' - then would this variable be recalculated every world update or is MAS smart enough to figure out that it depends on two other variables and only run updates if one of these other two changes? A side question: if MAS is smart enough to only recalculate if needed - if I want to do 'fc.SetPersistent("ccc", fc.GetPersistent("aaa")<5 and fc.GetPersistent("bbb")>0)' - then I can use TRIGGER_EVENT to be efficient and not resort to LUA, right?

Ah! I was looking at the "name" attribute whereas the right one was "transform". This is obvious now, in retrospect. Thank you, @MOARdV! BTW, I am having some success with LUA scripting. So far I have some primitive ascent autopilot and am about to improve it - moar lights, switches and rotary knobs %-)

@damonvv Your log says: Unable to find MASFlightComputer in part Did you check that you have it? You can search for this name in, say, Mk1Pod config. It's a module that you have to install in your pod.

-- post deleted. It was messy and not interesting to other readers. Instead of it a short summary below. -- I had a question about how best to do some repeated condition checking and have found out that it is to be done with LUA, using the TRIGGER_EVENT.

Hi @MOARdV. How can I use a different model for a rotary switch? I want to use a 6-position switch. 1) I have edited this line: "model = ASET/ASET_Props/Control/SwitchRotary/model/Switch_Rotary_3_Marks" now it says: "model = ASET/ASET_Props/Control/SwitchRotary/model/Switch_Rotary_6_Marks" 2) I have added 3 more text labels ("4 Mark", ...) However, it seems that neither new, nor old labels work anymore (I get 6 error messages like these, one for each label): [ERR 14:05:28.524] [AvionicsSystems] INITIALIZATION ERROR: Error configuring prop #120 (MAS_swRotary6_RotateSpeed) [ERR 14:05:28.524] [MASComponent] Error configuring prop #120 (MAS_swRotary6_RotateSpeed) [ERR 14:05:28.524] [MASComponent] Error in TEXT_LABEL 6 Mark: [ERR 14:05:28.524] [MASComponent] System.NullReferenceException: Object reference not set to an instance of an object

Hi @MOARdV. Since the "ascent autopilot" is disabled I was having the exactly same idea as @Geonovast in some other thread. I guess, I can try the attitude autopilot + SAS modes to do the same thing. I also guess, I'll be able to hard code a couple of MAS computer actions to action groups. However, it would be a shame to rigidly steal a couple of "traditional"action groups every time a specific pod is used. That would be very un-intuitive, especially since it won't be immediately visible in the UI. Can we somehow expose some properties in the pod itself, so that they could be added to AGs? See the screenshot for an illustration. --- EDIT: or, even more generically - it would be nice to expose this way just about any prop. That is - add a configuration similar to a collider action, except that it will be not a collider, but a hook for the AG menu.

Ah, that wasn't about going up to 100%. It's fine if the upper limit would still be less than that. It was about that test bench can only get you that far. Ironing out subtle problems requires actually using parts (be it rocket parts of software applications - doesn't matter). And cheating up every single part that you flew after every mission is a bit tedious If you don't mind sharing - what kind of test concept you think of?

I've put together a beta version of a Mk2 pod (from the "Making History" expansion). The pod still has many dark spots from where the old instruments were. I will try to remove them. Any feedback is welcome! The pod has two seats: right: ascent and launch abort left: everything else (orbital, approach, docking, descent, landing) Download at: https://github.com/MOARdV/AvionicsSystems/issues/264

I will, yes. If @MOARdV agrees, this will be a part of MAS, otherwise I guess I can publish a zip. I'm pretty slow with it, probably averaging about 1-2 props a day, but it's nearing completion now.

Heh. OK, a screenshot then. Don't mind the "RETRO" button over the gauge, I'll remove it.

Hi @MOARdV I'm trying to mod the stock (OK, OK, "making history" one) Mk2 pod (that's Squad's Gemini as I take it) and... I found your post above in this thread (Feb 27th). I now wish I found it earlier. The download links are removed from it though. Do you think you would be able to share the gemini files (the one without digital monitors). I can try adopting it to the Mk2 pod.

Hey @Angel-125. Thanks for the mod! Do you think the following would be a worthy addition? If I'm not mistaken then right now there is a single quality cap for all kinds of checks. That is, for example, if you have this cap set to 100 and have a lots of money then once you unlocked the part you can just pour in enough cash and you'll get the 100% quality part on your very first launch. How about making a second cap - for test bench specifically? The actual maximum would thus be reachable only with actual flight experience - slowly ironing out all these remaining problems instead of just testbenching the sh*t out of it until it's perfect.

I have a question/idea about the BARIS & Contracts interactions. Every now and then I get a contract of testing a part in certain conditions. Quite often that part is something that I didn't research yet. Do such contracts have any influence on what reliability this part will have once it is researched? For example, if I accepted a contract and run a test successfully - could it be made that the part will have higher reliability rating later on, as I unlock this part with the usual research?

@Raptor831 knowing the open-source development from inside, I still think thanks are in order. BTW, if you'd like to hand the maintenance off to someone - this might be a good moment to announce that.

Hi @Iso-Polaris. Thank you again for contributing the configs! In case you are still feeling up to it - there are still two engines not covered - the RT-5 "Flea" and RT-10 "Hammer". There is of course not much to be added to solid fuel engines, but this is still a disparity. :-)

I have verified that config and it: 1) enables RF configs for LV-909 and Poodle (may be some others, I only checked these two). The characteristics are the same, as far as I can tell 2) disables the heat maps - there is no heat glow anymore Being an RF user I consider that change to be still a worthy addition and I'll be using it from now on. I will also prepare a pull request. Note though that I'm not a mod developer so it will still be up to the mod authors to accept/reject that patch. Thank you, anyway! --- UPDATE: PR is here: https://github.com/Raptor831/RFStockalike/pull/97 -- UPDATE 2: Oh WOW. This is merged already! Thank you, @Raptor831

Oh, yeah - some people definitely will. Some even will do that in the atmosphere, without parachutes and planned abort sequence. But I don't think that IVAs should differ from each other only by layout of props. Some IVAs are for ascent, some for descent and some for orbit. What belongs to one does not necessarily has to be in another and should be missing from a third.