theonegalen Posted November 25, 2018 Share Posted November 25, 2018 15 minutes ago, Warhorse said: Maybe he wants to develop his own IVAs with MAS? I love that idea, and would love to see anyone's MAS IVAs. @Anders Kerman can you be more specific? What exactly are you trying to do? Quote Link to comment Share on other sites More sharing options...
Warhorse Posted November 25, 2018 Share Posted November 25, 2018 15 minutes ago, theonegalen said: I love that idea, and would love to see anyone's MAS IVAs. I've actually been contemplating doing that myself, no promises though ... Quote Link to comment Share on other sites More sharing options...
snakeru Posted November 28, 2018 Share Posted November 28, 2018 Hi. Fantastic cockpit, thank you! There is this instrument that is probably useful, but (1) I don't really know how to use it and (more importantly) (2) that shows Kerbin globe whereas I fly at Gael. Can I replace the texture so that it shows the Gael map? If yes - how? I tried to find the instrument in the cockpit model, but failed miserably (may be I was looking in a wrong cockpit model). Quote Link to comment Share on other sites More sharing options...
Stone Blue Posted November 28, 2018 Share Posted November 28, 2018 That should be part of the prop model, not the cockpit model... also, I could be wrong in this case, but you could change the navball textures in the RPM props... even the digital navball on the MFDs... hopefully thats carried over to MAS, but MOARdV would be the one to answer that. Â Quote Link to comment Share on other sites More sharing options...
MOARdV Posted November 28, 2018 Author Share Posted November 28, 2018 1 hour ago, snakeru said: Hi. Fantastic cockpit, thank you! There is this instrument that is probably useful, but (1) I don't really know how to use it and (more importantly) (2) that shows Kerbin globe whereas I fly at Gael. Can I replace the texture so that it shows the Gael map? If yes - how? I tried to find the instrument in the cockpit model, but failed miserably (may be I was looking in a wrong cockpit model).  1) How to use the Globus / IMP instrument: First, click the IMP switch to ON. Globus will now rotate so that your current vessel position is in the middle of the globe. The LAT / LONG gauge will update to show your current latitude and longitude. This allows you to track where you are above the planet. If you click the rotary switch next to the IMP switch, you will tell the IMP to display VESSEL (current vessel location), TGT (current target location, if there is a target), or LANDING (if your current orbit will hit the planet). All of these are updated continuously, so you can switch between VESSEL and TGT, for example, to know how close you are to your target. If the globe switches off when you select TGT or LANDING, that means you have selected an invalid mode. 2) The map for Kerbin is GameData/ASET/ASET_Props/Instruments/ASET_IMP/map_Kerbin_sat.png The prop is hard-coded to use the texture at that location, so it is not easy to change. You will need to get a map of Gael (the Kerbin map is 1024 x 512) and replace the Kerbin map file with the Gael map file (which must also be called map_Kerbin_sat.png).  You could also write a Module Manager patch to update the config file in MAS to add the correct 'texture' node, but that is more complex, and I don't have all of the information from the ASET_IMP model file to tell you how to do that correctly. Quote Link to comment Share on other sites More sharing options...
Stone Blue Posted November 29, 2018 Share Posted November 29, 2018 (edited) ahhh... ya... having the map texture name hardcoded makes it tough to dynamicllly switch the texture depending on what body is being orbited... you would have to most likely add code to detect which body, in order to tell the prop which body texture to switch *to*... vOv Edited November 29, 2018 by Stone Blue Quote Link to comment Share on other sites More sharing options...
snakeru Posted November 29, 2018 Share Posted November 29, 2018 9 hours ago, Stone Blue said: ahhh... ya... having the map texture name hardcoded makes it tough to dynamicllly switch the texture depending on what body is being orbited... you would have to most likely add code to detect which body, in order to tell the prop which body texture to switch *to*... vOv Well, given that this imitates a physical globe - probably a plastic or a metal one with actual paper map glued over it - it does not have to dynamically switch over. That would be against the spirit of the "early cabin". I just wanted it to show my home planet, that's it.@MOARdV I'm done, thanks a bunch for precise instructions. Adapting the map happened to be not very straightforward - I had to rotate it 180 deg, then shift 90 deg west and change color of the oceans (apparently GPP has the hi-res pack with oceans drained). Do you want me to share it somehow?  Also: the instrument is great for landing prediction, but I think UX could be slightly improved if you change the order of the modes. Right now it is : VESSEL-TARGET-LANDING. If you make it TARGET-VESSEL-LANDING then it would be more convenient because then vessel would be in the middle and one can visually estimate the angle by switching back and forth and noticing how much the globe rotates. Right now if I want to check how far I am still from my landing site I have to go through target mode and it always starts rotating to 0,0 first. If you tell me where the texture for this one is then I can probably try updating it myself and then sending you a pull request. Quote Link to comment Share on other sites More sharing options...
theonegalen Posted November 29, 2018 Share Posted November 29, 2018 (edited) 11 hours ago, Stone Blue said: ahhh... ya... having the map texture name hardcoded makes it tough to dynamicllly switch the texture depending on what body is being orbited... you would have to most likely add code to detect which body, in order to tell the prop which body texture to switch *to*... vOv I'm absolutely certain that it would be pretty trivial to set it up to automatically switch using module manager to Gael when gpp is installed as long as I know what texture is needed. You just have to know how prop configs work. Edited November 29, 2018 by theonegalen Quote Link to comment Share on other sites More sharing options...
MOARdV Posted November 29, 2018 Author Share Posted November 29, 2018 10 hours ago, snakeru said: Do you want me to share it somehow? I think we'd need to have working MM patches for the prop (like @theonegalen proposes), first. And I suspect someone, somewhere, will want an Earth map, too.  And I would want to have MM patches that can also update the MFDs, as well (the MFD uses that same texture for its orbital views). Otherwise, yes, I'm amenable to including alternate maps. 10 hours ago, snakeru said: I think UX could be slightly improved if you change the order of the modes I fully agree. I think I configured that prop to mimic the RPM version of the prop, which was configured the way it was due to RPM limitations. I'll need to reconfigure the switch to swap TARGET and VESSEL, and update the scripts the IMP props use to account for the new ordering. I added an issue to GitHub to remind me once I'm able to spend more time modding. Quote Link to comment Share on other sites More sharing options...
snakeru Posted November 30, 2018 Share Posted November 30, 2018 Hi @MoarDV Thanks. I also opened a few github issues in case you'd like to track them (the Gael map is attached to one of them) - that is by no means a request to support - just so that you're aware of them. Quote Link to comment Share on other sites More sharing options...
MOARdV Posted December 1, 2018 Author Share Posted December 1, 2018 14 hours ago, snakeru said: Hi @MoarDV Thanks. I also opened a few github issues in case you'd like to track them (the Gael map is attached to one of them) - that is by no means a request to support - just so that you're aware of them. I see those. I will look into them when I've got the time. Thank you for putting them on GitHub - otherwise there's always the possibility of me forgetting. Quote Link to comment Share on other sites More sharing options...
Anders Kerman Posted December 1, 2018 Share Posted December 1, 2018 On 11/24/2018 at 3:41 AM, theonegalen said: What other IVA using MAS do you have besides the defaults? That is, why not remove MAS altogether? well I need MAS for the Ultimate shuttle IVA mod but MAS' own IVA's cause conflicts with RPM IVA's Quote Link to comment Share on other sites More sharing options...
theonegalen Posted December 2, 2018 Share Posted December 2, 2018 (edited) 2 hours ago, Anders Kerman said: well I need MAS for the Ultimate shuttle IVA mod but MAS' own IVA's cause conflicts with RPM IVA's I haven't had that issue. I'm away from my computer right now, but later tonight I will give it a look and see what might be going on. What version of MAS are you running, what version of Kerbal Space Program, and what version of RPM? Also, go into your KSP folder and upload a copy of your KSP.log file somewhere like pastebin or Google Docs so I can look at it and see if there's something going on that shouldn't be. Edited December 2, 2018 by theonegalen Quote Link to comment Share on other sites More sharing options...
snakeru Posted December 6, 2018 Share Posted December 6, 2018 (edited) Hi @MOARdV Here is some feedback after playing a bit with your mod: 0) AWESOME! AWESOME! AWESOME! The RPM was awesome, but MAS beats it hands down. 1) The docking mode has a minor glitch: when I set the rotary switch to "Target" and flip switch to "-/Docking" the "Error" flag extends. I guess that this happens because I exit the cabin to select "control from here" on the docking port and when I enter the cabin again the MAS automatically switches to control from the cabin. But that's just a guess. 2) For probably the same reason I can't really use the propulsion of the docked vessel. That is - if my vehicle ran out of propellant and I'm docked with a tug. The docking scheme looks like that: |Tug><Craft|. Both have docking ports at the nose. If Tug does not have a cabin or I don't want to transfer to it for some reason then controlling from the tug is not really possible - the focus switches automatically back to my own cabin which means that Pro- and Retro- grade vectors are now 180deg. rotated and SAS goes crazy. Same thing with trying to control ship from outside and then going inside when having SAS set up to something like "Prograde". It immediately decides that craft is misoriented and burns through my precious RCS fuel. 3) I wonder - do we really need all these 10 buttons on the right (SAS mode buttons)? Can we link them instead to the FDAI input? So that:  * if SAS is off and switch is in Sync to SAS - that's an error  * SAS is on and switch is NOT in Sync to SAS - that's the basic SAS mode  * SAS is on and switch is in Sync to SAS - that's one of the SAS modes (would be actually cool if SAS can align crafts - but I don't know if that's possible) 4) I see you have a dedicated switch "Arm Parachute" - that's VERY handy, thank you for that! Can we also have some more?  * A rotary switch "Comm off - low-gain - high gain" to activate/deactivate antennas? Or just two flip-switches. This will extend/retract antennas that can do that. In some mods these consume EC and besides it's always nice to do something without leaving the comfort of the pressurised cabin.  * A flip-switch to turn ignition on or off - that one might be actually tricky. I thought of somehow detecting which engine is staged and then working with it.Turning off would be easy - just find the one that is active and deactivate it. But how to find the one that is to be activated? May be make it unstaged again? But then we'll lose the reading of remaining fuel/deltaV. Can engine be somehow marked in-memory that it was deactivated through a switch? Also you'll need to listen on a hook somewhere to flip this switch automatically if an engine gets activated through a staging sequence. In short - I'm not sure how feasible this is.  * A flip-switch to activate radar mode of the docking port - I never saw that feature before, probably something added in the 1.5 Oops, sorry, that is the MAS feature, LOL  * A flip-switch / a button to transmit science.  * A flip-switch to toggle solar panels  * A mean to exit the ship (start an EVA) of the current Kerbal would be cool. ==== Some minor things === 5) Action groups switches and lights are sorted differently. 6) Some action switches are actually buttons (like if it is set to "Science" mode) - may be they can auto-switched back to lower position - just like the "Stage" switch? Or add a mean to assign different actions to up and down positions (like make science when switched up and clear science/collect when switched down)? 7) Action groups lights are always marked with "AGn" even if there are AGn=... strings in the description of the ship. Would be nice to have matching names. 8) "Stage deltaV" does not work when engine is throttled down to zero. I have to manually switch to "Total" (but total probably shows all stages together) 9) Neither "total deltaV" nor "stage deltaV" include something I can get out of RCS thrusters. For example if I have an Mk1 Pod equipped with RCS thrusters then it can get some reasonable deltaV as a last-ditch effort to deorbit itself, but that is not indicated. 10) Looking out of the window does not work anymore (double-clicks are ignored) 11) A crude, "5-minutes-invested" lander can equipment would be a huge win over the stock one. Just the SAS mode buttons would be enough! Nevermind, I figured out how to make one myself, will provide one once I'm done. 12) The staging switch safety cover is always open after the game loading. I guess that's the default position. Would it make sense to make it default the other way? Otherwise it doesn't really give much safety. Same goes for the recovery switch - it's a pity that I can't operate its cover. Please don't perceive the above as a critique or anything of the kind. I'm just trying to be thankful and somehow contribute to the piece of art you created. Edited December 7, 2018 by snakeru Quote Link to comment Share on other sites More sharing options...
snakeru Posted December 6, 2018 Share Posted December 6, 2018 (edited) Just noticed some more (in addition to the 12 above): 13) The FDAI seems to not liking some corner cases. I am on a polar orbit right now and needed to reorient the ship from retrograde to prograde. I switched off the SAS and used the yaw rotation. My initial orientation was 0 degrees and as I was passing 90 degrees the pitch needle started moving. It went off-scale for a moment and then smoothly returned back. There was probably some floating-point extremity. 13b) BTW - do you think it would make sense to allow these needles to go off-scale? That is - allow them to point to something like 6.5 while the actual scale end at 6? 14) The globe below has a similar behaviour. As I pass the pole it rotates madly (much faster than the perceived "maximum" rotation speed when you switch it on on the launch pad). It might be better to give it the third degree of freedom and actually roll it according to the ship's orientation. Though in this mode it will probably behave strangely when the ship is on the launch pad. 15) The instruments keep operating when the electric charge is zero  Correction: re-testing this showed that they correctly shut down. Will be paying more close attention to it. 16) Probably not fixable, but still: if I press "Esc" and then "Tracking station" I sometimes hear a click. Most often this is a FDAI power switch, but I shudder to think that one day this might be a decoupler action group switch. I doubt though that a click-through blocker will help as the menu is a stock Squad element. 17) That's probably an intended behaviour I'm observing, but still: I designed two crafts both having action groups. One had AGs 1,5,9,0 defined and the other 2,3,4,6,7,8. Both crafts had AGn=... strings in their description. When these crafts dock - action groups don't merge, they show up as if the other craft is not docked. Sadly, I didn't try trying them through a keyboard so I don't know if the AGs from the other craft actually function.  An illustration to the points (13) and (14) above:  Edited December 7, 2018 by snakeru Quote Link to comment Share on other sites More sharing options...
Stoney3K Posted December 7, 2018 Share Posted December 7, 2018 On 8/7/2018 at 11:26 PM, MOARdV said: It's been asked a couple of times over the years. I am unaware of such a mod. I think it's technically feasible in the abstract. Practically speaking, however ... it is probably not viable. There are several issues: First, most IVAs have multiple MFDs. There would have to be a way for the plugin to select an MFD. I suppose it could always grab the first MFD it encounters when it scans the IVA's InternalModule list. Second, many IVAs have multiple types of MFD (different screen sizes, different configurations, different pages). In those cases, there'd need to be a way to decide which MFD to show (for instance, the Kerbal Flying Saucer Flapjack IVA has 3 distinct styles of MFD, and more than one instance of two of those types). Third, an ideal implementation would be able to pipe keypresses back to the MFD. Otherwise, the player has to switch to IVA, click a button on the right MFD, and switch back to external view. The way I've plumbed MAS, I don't think it can really be done. Realistically, I think what would need to happen is a PartModule that is attached to the same part as the MASFlightComputer module. The PartModule would more-or-less implement the same functionality as the MASMonitor InternalModule, but it would also manage a UI (both displaying the RenderTexture and detecting / routing button presses). (I'm not proposing you should write it - I'm just kind-of mentally walking through how it could be implemented when I run out of things to do  Although, if you're done updating all of the mods you're maintaining, and you're looking for something else to do, let me know  ). I can add it to my MAS Issues list as a feature post MAS 1.0. Externalizing IVA controls would be a great addition, but as you said, it's a time-consuming task because all of the props and instruments are rendered in the IVA view (in 3D) and a separate window is obviously not 3D. So you would need to have a way to define an IVA 'panel' layout which can be viewed in a window, and render all of the props in some kind of 2D representation accordingly. All user interaction (key presses, mouse events) will have to be sent back to their respective places. It would also require drafting up 2D artwork for each of the props so they can be displayed in 2D and look realistic. I mean, I would be all in favor of having some kind of 2D panel like you have in MS Flight Simulator, as the sim builders would really want to toy around with it, but it's a complicated piece of programming. Quote Link to comment Share on other sites More sharing options...
snakeru Posted December 7, 2018 Share Posted December 7, 2018 (edited) Continuing through my feedback spree here, hope that's fine. 15) Above is corrected. Let's consider me wrong until I make a screenshot. 18) DSKY can not be shut down. IIRC in the Appolo 13 flight they actually had to shut down some pretty important systems so I think this option should also be provided. 19) Devices on/off status seem to have no effect on the EC consumption. Should probably have. The only device that actually actively drains energy seems to be docking radar. Or may be that's just me incorrectly rigging the Mk1LanderCan - I didn't really tested that particular feature in the Mk1Pod. 20) The digital altimeter (MAS_RetroAltitudeDisplay) is definitely out of place in the Mk1 cockpit - it feels like cheating (because it is). DSKY+regular radar altimeter should be enough for Mk1Pod. The Mk1LanderCan can have the ARRT.  Yes, it will be far less convenient, so what? 21) The IMP LATLON gauges rotate instantly to correct position when you turn on the device. The globe behaves correctly by rotating slowly. 22) "Stage Propellant" should probably trigger the "MasterCaution" when it reaches 40% and not 10%. This will make sense for landings. If you land before you reach 40% of the fuel remaining then you'll likely have enough fuel to go back to orbit again and make a rendezvous. I'm not sure, may be even 33% would typically be enough. Actually, that would still be pretty rigid and is acceptable only for one very specific class of missions. Perhaps a knob allowing you to set the "warning level" would be of much better use - just as you have it right now on the radar altimeter. Edited December 8, 2018 by snakeru Quote Link to comment Share on other sites More sharing options...
MOARdV Posted December 8, 2018 Author Share Posted December 8, 2018 Wall-of-text warning (trying to reply to all of @snakeru's feedback) .... On 12/6/2018 at 2:07 PM, snakeru said: 0) AWESOME! AWESOME! AWESOME! The RPM was awesome, but MAS beats it hands down. That was what I was attempting. I'm glad you're enjoying it. On 12/6/2018 at 2:07 PM, snakeru said: 1) The docking mode has a minor glitch: when I set the rotary switch to "Target" and flip switch to "-/Docking" the "Error" flag extends. I guess that this happens because I exit the cabin to select "control from here" on the docking port and when I enter the cabin again the MAS automatically switches to control from the cabin. But that's just a guess. If memory serves correctly, stock KSP changes the reference when you switch back to IVA. That is why there are switches / buttons / MAS functions to set the reference part to either the current IVA or to a docking port (such as MAS_tggl_ReferencePart_T1_G1_D - look for any prop with 'Reference' in its name). The FDAI is configured so that docking alignment works only when (a) you have a docking port set as a reference part, and (b) when you are targeting a docking port. I originally did not require (a), because I thought it was too restrictive, but that makes it impossible to dock using a TKS spacecraft, where the docking port is on the "back" of the vessel compared to the DM's facing. On 12/6/2018 at 2:07 PM, snakeru said: 2) For probably the same reason I can't really use the propulsion of the docked vessel Yes, this is the same issue. KSP resets the reference part. There may be a way for MAS to override the behavior, but that capability does not exist yet. On 12/6/2018 at 2:07 PM, snakeru said: 3) I wonder - do we really need all these 10 buttons on the right (SAS mode buttons)? Can we link them instead to the FDAI input? The FDAI is a somewhat complicated system (go look at the script and the prop configurations for it). Attaching SAS control makes it a little more complex - stock KSP always sets SAS to Stability Assist when it is switched on. For MAS to override that, it will have to use a script every update asking "Is SAS On? What mode do I think it should be? What mode does KSP think it is?" A couple of other reasons: When I'm using the FDAI and the X-Pointer to dock, I often switch modes on both instruments to help guide me into the correct docking alignment. I do not want the FDAI overriding my alignment during this time. The other reason, there is no requirement to have exactly 1 FDAI. If you look back a few pages, I showed a picture of an Apollo IVA that has two FDAIs. Those are two separate devices - you can set them to different modes. That makes automatic SAS control from the FDAI a problem. All of that being said: If you're up to experimenting with Lua scripting and some prop configuration, you are more than welcome to modify the FDAI GMCP to also control SAS mode. It would certainly be an interesting experiment in usability, and for a compact craft like the stock Mercury-alike, it may make sense to simplify the control systems. On 12/6/2018 at 2:07 PM, snakeru said: 4) I see you have a dedicated switch "Arm Parachute" - that's VERY handy, thank you for that! Can we also have some more? I think some / most of the switches you're asking for already exist, but I'm not using them in the simple IVA. For examples, MAS_tggl_Radar_T1_G1_S, MAS_tggl_Antenna_T1_G1_S, MAS_tggl_SolarPanel_T1_G1_S, MAS_tggl_EngineEnable_T1_G1_C1_S. Engine Enable is tricky - it only activates engines in the current stage, but it will deactivate any engine. The reason for that is it is not easy to decide which engines are supposed to be activated if they have not staged yet - there are ways around that, but it requires the player to set up engine groups correctly in the VAB, and it requires custom switches to toggle each group. For Science support - I have *never* played career or science (maybe 6 hours total when it was new). I have intended to add science support, but I simply don't know enough about that game feature to feel confident that I can get it right. For the EVA button - RPM supported this, and I really should make sure MAS does too, if I didn't already add it and forget about it. On 12/6/2018 at 2:07 PM, snakeru said: 6) Some action switches are actually buttons (like if it is set to "Science" mode) - may be they can auto-switched back to lower position - just like the "Stage" switch? This is possible - I can add a complete set of action switches that behave that way, so the IVA creator can pick a style. Action groups are tricky, since they can be a toggle (which is how these switches behave), or they can be a single event. As far as KSP is concerned, they're all toggle switches (each action group is 'on' or 'off', just like SAS, RCS, etc), which is why I typically use a two-position switch. On 12/6/2018 at 2:07 PM, snakeru said: 8) "Stage deltaV" does not work when engine is throttled down to zero I will need to check that. Stage dV does not care about engine throttle. It looks for active engines on the current stage, and it determines how much fuel is available to the current stage. The only time it should read zero is if there is no fuel, or the engines are shut off, or you just undocked (because KSP changes the active stage). When I've got time, I'll investigate and see if I can reproduce. On 12/6/2018 at 2:07 PM, snakeru said: 9) Neither "total deltaV" nor "stage deltaV" include something I can get out of RCS thrusters Correct. They both look at ModuleEngines and ModuleEnginesFX. Trying to compute deltaV accounting for RCS would be very complex, and it is a lot of code I don't want to write (and I don't want to support - I've seen the complaints about both MechJeb and KER delta V computations over the years, and I don't want to spend that much time handling strange configurations). On 12/6/2018 at 2:07 PM, snakeru said: 10) Looking out of the window does not work anymore (double-clicks are ignored) MAS includes a double-click detector so that the player doesn't accidentally cancel their target selection while clicking instruments. However, selecting windows still worked for the IVAs I've used that support that ability. On 12/6/2018 at 2:07 PM, snakeru said: 12) The staging switch safety cover is always open after the game loading. I guess that's the default position. Would it make sense to make it default the other way? Otherwise it doesn't really give much safety. Same goes for the recovery switch - it's a pity that I can't operate its cover. The staging switch cover is tied to the stage lock function in stock KSP. Staging is unlocked by default, so the cover is open. Shutting the cover locks staging (so you can't stage pressing the keyboard). The recovery switch cover is designed to be open when you are able to recover the vessel. It shuts when you lift off, and stays shut until you land on Kerbin again. I could change it to be a manual cover, but I would then want to add a "Recovery available" light or flag somewhere so that there's visible feedback that the switch should work. On 12/6/2018 at 2:48 PM, snakeru said: 13) The FDAI seems to not liking some corner cases. Yes, it doesn't  The issue is that I'm taking the dot-product of two vectors, and then taking the arcsine of them. There is probably a better way to compute it that does not have the numerical instability in certain spots. On 12/6/2018 at 2:48 PM, snakeru said: 13b) allow these needles to go off-scale? That is a possibility, as long as the error flag is also activated. Right now, they all return to the home position (0) instead. I have not tried moving the needles outside of the range alexustas defined for them to see if they clip the model.  On 12/6/2018 at 2:48 PM, snakeru said: 14) The globe below has a similar behaviour. Globus provides me only two axes of rotation. Both axes have speed limiters, but the limit is in degrees per second per axis. Although it'd be possible to simulate a globe like you propose by replacing the texture on a navball prop (a config-file change for the sake of experimenting), and configuring the navball to use vessel latitude / longitude instead of pitch and yaw. On 12/6/2018 at 2:48 PM, snakeru said: 16) Probably not fixable, but still: if I press "Esc" and then "Tracking station" I sometimes hear a click Yeah, stock UI click-through is a problem. I suppose I could add a "Return to Tracking Station" button. On 12/6/2018 at 2:48 PM, snakeru said: 17) That's probably an intended behaviour I'm observing, but still KSP docking is a challenge for IVA mods (RPM as well). Here's why (based on my observations): When two vessels dock, KSP destroys one of them and connects its parts to the other one. When you undock, KSP creates a new vessel using the parts that were separated. All vessel-specific state is lost (such as which action groups are on or off, what position the other groups are in (SAS, RCS), etc), and your active stage is wrong. That's why sometimes you're kicked out of IVA when you dock or undock - if the vessel you're currently flying in IVA is the one being destroyed or created, KSP kicks you out to the flight view. MAS already has to do an ugly hack to get action group captions - when you're in the VAB, each command pod scans the vessel description text field and picks out the action group info (if it exists) so it can save that information into an internal string. When you dock, that information remains attached to the command pod. There is no vessel-wide database where different MAS flight computers can collate action group captions. With the problems MAS already has due to KSP docking / undocking behavior, I don't see that being fixed. 16 hours ago, snakeru said: 18) DSKY can not be shut down. Correct. That wasn't a feature in the RPM DSKY, and I never bothered adding it. The DSKY prop is still incomplete, since it still requires a lot of Lua scripting to finish implementing its features. I suppose adding a power switch to it wouldn't be too much additional effort. 16 hours ago, snakeru said: 19) Devices on/off status seem to have no effect on the EC consumption. Should probably have. The only device that actually actively drains energy seems to be docking radar. Docking radar consumes EC because the radar is a separate module on the docking port.  I would need to think of how to manage EC consumption from props. I would have to add a function to the flight computer module to adjust its EC requirements, and then I would have to make sure each power switch correctly told the FC "Start using this much more power" when it is activated, and "Start using this much less power" when deactivated. 16 hours ago, snakeru said: 20) The digital altimeter (MAS_RetroAltitudeDisplay) is definitely out of place in the Mk1 cockpit - it feels like cheating (because it is) Yes, it is. I did not want to make an entry-level IVA too difficult for people not used to it - there's a lot to figure out as it is, especially if you're not familiar with the instruments. The digital altimeter is superfluous, since the altimeter and radar altimeter provide enough information in the atmosphere, and the DSKY can tell you when you're near the apoapsis for the optimal reentry burn. But I wanted to leave at least a little bit of easily-accessible info available. 16 hours ago, snakeru said: 21) The IMP LATLON gauges rotate instantly to correct position when you turn on the device I still have not figured out why. I don't know if I didn't configure it properly, or I need to slow it down even more. With the hundreds of other props + coding, I simply haven't had the time to go back and spend time on fixing it. The AR/RT distance strip likewise move extremely quickly near the lower end, although that's because of the way it was designed. I know I can slow that one down, but it may take a really long time to seek to the ends. 16 hours ago, snakeru said: 22) "Stage Propellant" should probably trigger the "MasterCaution" when it reaches 40% and not 10%. I think 10% has been traditional (for RPM and MAS). 40% is a good number for a lander, but I think it's a bit too high for a launch vehicle. It may be that some of the props need to be customized for particular applications - things that may be a problem for a lander may not be as important when launching from Kerbin. I have been trying to rethink how the Master Caution and Master Alarm props should work - they are not well implemented, since they are hard-coded to detect certain conditions. I think there needs to be a voting system, where other props can detect a condition and say "This is a problem". Thank you *very* much for detailed feedback. alexustas has been busy with Real Life, so he's been quiet for a while on his feedback, and I've only heard extensively from one other modder recently. Quote Link to comment Share on other sites More sharing options...
Stone Blue Posted December 8, 2018 Share Posted December 8, 2018 (edited) On 12/6/2018 at 3:07 PM, snakeru said: 8) "Stage deltaV" does not work when engine is throttled down to zero I will need to check that. Stage dV does not care about engine throttle. It looks for active engines on the current stage, and it determines how much fuel is available to the current stage. The only time it should read zero is if there is no fuel, or the engines are shut off, or you just undocked (because KSP changes the active stage). When I've got time, I'll investigate and see if I can reproduce.  On 12/6/2018 at 3:07 PM, snakeru said: 9) Neither "total deltaV" nor "stage deltaV" include something I can get out of RCS thrusters Correct. They both look at ModuleEngines and ModuleEnginesFX. Trying to compute deltaV accounting for RCS would be very complex, and it is a lot of code I don't want to write (and I don't want to support - I've seen the complaints about both MechJeb and KER delta V computations over the years, and I don't want to spend that much time handling strange configurations).  In regards to the above, and incase you havent seen this yet, @MOARdV, might be ideal to wait till this drops to put any real time into looking into staging and deltaV... vOv  Edited December 8, 2018 by Stone Blue Quote Link to comment Share on other sites More sharing options...
MOARdV Posted December 8, 2018 Author Share Posted December 8, 2018 58 minutes ago, Stone Blue said: might be ideal to wait till this drops to put any real time into looking into staging and deltaV I saw people talking about it in the ... whatever the sneak peeks in the Daily Kerbal forum are called, but I hadn't seen anything officially saying it would be in 1.6 (Seriously, Squad, why dribble out bits and bobs on various social media in addition to the official forum? Not all of us have an hour a day during Study Hall to go visit all of the venues... But I digress ). Stage delta-V is a very simple computation. MAS does it itself: vc.currentIsp * Utility.StandardG * Math.Log(vessel.totalMass / (vessel.totalMass - stagePropellantMass)). But if I have to account for RCS, then I need to figure out which thrusters actually contribute to dV (lateral-only RCS blocks would not, for instance), and I have to account for monopropellant running out at a different time than the main propellants (which I don't really do as-is - I suspect if there are SRBs and a LF core that run out of fuel at different times, the stage dV computation is wrong). Total dV is even messier due to the weird things that people can (and do) do with staging, and gets more complex when RCS is added in. That's why MAS does not compute total dV - it will ask MechJeb or KER for the dV total (if one of those mods is installed), but otherwise MAS says "0". But, yeah, I look forward to seeing if 1.6's dV computations are accurate enough to use - the less duplicate computation that MAS has to do, the better the performance will be in the long run. Quote Link to comment Share on other sites More sharing options...
snakeru Posted December 8, 2018 Share Posted December 8, 2018 2 hours ago, MOARdV said: All of that being said: If you're up to experimenting with Lua scripting and some prop configuration, you are more than welcome to modify the FDAI GMCP to also control SAS mode. It would certainly be an interesting experiment in usability, and for a compact craft like the stock Mercury-alike, it may make sense to simplify the control systems. That's tempting for sure. However, I don't have any suitable computer to install unity on (I guess that would be needed) right now. Can one try doing that using only the simplest text editor (notepad) and a copy of the KSP? 2 hours ago, MOARdV said: I will need to check that. Stage dV does not care about engine throttle. It looks for active engines on the current stage, and it determines how much fuel is available to the current stage. The only time it should read zero is if there is no fuel, or the engines are shut off, or you just undocked (because KSP changes the active stage). When I've got time, I'll investigate and see if I can reproduce. Ah! Now as you said that I think I know what happened. RPM started behaving exactly the same right after I discovered the RF mod. So that's a Real Fuels thingy. Please ignore. 2 hours ago, MOARdV said: Correct. They both look at ModuleEngines and ModuleEnginesFX. Trying to compute deltaV accounting for RCS would be very complex, and it is a lot of code I don't want to write (and I don't want to support - I've seen the complaints about both MechJeb and KER delta V computations over the years, and I don't want to spend that much time handling strange configurations).  Understood. The calculations themself aren't tricky (I do them often), but I guess that's only if you assume that thrusters are co-axial with the ship.  2 hours ago, MOARdV said: MAS includes a double-click detector so that the player doesn't accidentally cancel their target selection while clicking instruments. However, selecting windows still worked for the IVAs I've used that support that ability. Tried that with Mk1LanderCan. It works. So I guess that's the problem with Mk1Pod. The model has changed in 1.5 as far as I understand. 2 hours ago, MOARdV said: That is a possibility, as long as the error flag is also activated. Right now, they all return to the home position (0) instead. I have not tried moving the needles outside of the range alexustas defined for them to see if they clip the model. I'm not sure if we understood each other so I'll explain again, just in case: I meant exactly the current behaviour just a little wider allowed movement range. Right now if an error needle wants to show "8" and the error rate is switched to the most sensitive then it stops at "6" which exactly corresponds to the 6th marker on the FDAI. Most likely you have something like min(err, 6) somewhere in the code. My proposal is to do min(err, 6.5) and keep exactly the same texture so that the error needle will move a little bit father - just a couple degrees giving the visual feedback of being "off scale" (because scale spans from -6 to 6). That's all. 2 hours ago, MOARdV said: Correct. That wasn't a feature in the RPM DSKY, and I never bothered adding it. The DSKY prop is still incomplete, since it still requires a lot of Lua scripting to finish implementing its features. I suppose adding a power switch to it wouldn't be too much additional effort. Ah. So the DSKY is not quite finished? Ok, I'll still report one thing since I prepared the screenshot already, but may be that's just not implemented yet. 2 hours ago, MOARdV said: Yes, it is. I did not want to make an entry-level IVA too difficult for people not used to it - there's a lot to figure out as it is, especially if you're not familiar with the instruments. The digital altimeter is superfluous, since the altimeter and radar altimeter provide enough information in the atmosphere, and the DSKY can tell you when you're near the apoapsis for the optimal reentry burn. But I wanted to leave at least a little bit of easily-accessible info available. Sounds good. I'll just kill it in my copy then :-) 2 hours ago, MOARdV said: I think 10% has been traditional (for RPM and MAS). 40% is a good number for a lander, but I think it's a bit too high for a launch vehicle. You probably were answering my post exactly as I edited it. I came to the same conclusion. Probably a knob setting up a desired value on when to raise an alarm will be better - in the same way as the radar altimeter works. 2 hours ago, MOARdV said: Thank you *very* much for detailed feedback. alexustas has been busy with Real Life, so he's been quiet for a while on his feedback, and I've only heard extensively from one other modder recently. Thank you for your work! As promised, here is a bug report: the DSKY seems to fail to deliver the rendez-vous predictions. No matter how I tried it didn't display anything. Am I doing something wrong? Quote Link to comment Share on other sites More sharing options...
snakeru Posted December 8, 2018 Share Posted December 8, 2018 5 hours ago, MOARdV said: For Science support - I have *never* played career or science (maybe 6 hours total when it was new). I have intended to add science support, but I simply don't know enough about that game feature to feel confident that I can get it right. I have a lot of experience playing career mode. Never played sandbox, not even 1 hour. It feels boring for me - no challenge - I know I can do anything given enough tries. In career the main problem is that you should do it AND stay profitable. Main actions are therefore: * take a measurement * discard all measurements that are zero or almost zero * collect science into the science container. * take a reading from a particular instrument even if there is a reading already. Or take a reading and transmit it even if it gives you zero science points (if you want to role-play). Often there are missions like "take temperature readings at these coordinates: PlaceA, PlaceB, PlaceC, PlaceD" * transmit all science (rarely useful) * transmit a particular piece of it (makes total sense for items that has no penalty for being transmitted, like crew reports)  5 hours ago, MOARdV said: Yes, it is. I did not want to make an entry-level IVA too difficult for people not used to it - there's a lot to figure out as it is, especially if you're not familiar with the instruments. The digital altimeter is superfluous, since the altimeter and radar altimeter provide enough information in the atmosphere, and the DSKY can tell you when you're near the apoapsis for the optimal reentry burn. But I wanted to leave at least a little bit of easily-accessible info available. As I think more of it - actually even stock IVAs don't have it. They have a 3-hand-altimeter instead which is useless above 100k. (And they have a digital speedometer, but that thing is even more out-of-place on the old-style instrument panel).  Quote Link to comment Share on other sites More sharing options...
theonegalen Posted December 10, 2018 Share Posted December 10, 2018 On 12/8/2018 at 3:53 PM, snakeru said: I have a lot of experience playing career mode. Never played sandbox, not even 1 hour. It feels boring for me - no challenge - I know I can do anything given enough tries. In career the main problem is that you should do it AND stay profitable. Main actions are therefore: * take a measurement * discard all measurements that are zero or almost zero * collect science into the science container. * take a reading from a particular instrument even if there is a reading already. Or take a reading and transmit it even if it gives you zero science points (if you want to role-play). Often there are missions like "take temperature readings at these coordinates: PlaceA, PlaceB, PlaceC, PlaceD" * transmit all science (rarely useful) * transmit a particular piece of it (makes total sense for items that has no penalty for being transmitted, like crew reports) I opened an issue about science controls in github a while back. What do you think about the variables I asked for here? https://github.com/MOARdV/AvionicsSystems/issues/141 Quote Link to comment Share on other sites More sharing options...
snakeru Posted December 11, 2018 Share Posted December 11, 2018 (edited) 21 hours ago, theonegalen said: I opened an issue about science controls in github a while back. What do you think about the variables I asked for here? https://github.com/MOARdV/AvionicsSystems/issues/141 Since I'm not quite a modder yet, it's difficult for me to estimate how exhaustive this list of functions is. Besides, you seem to think in terms of MFD interface whereas I usually prefer flying an "old-style" cabins. However, you have a sketch of an "appolo-style" science console. So I'll comment on that one.  1. There is an "experiment 1" string at the top. Do you intend to have more than one? 2. The "collect" button seems to be missing, but that's a good thing - most of the time this button will do nothing as only a few ships actually has the container. 3. What exactly is the plan of addressing multiple experiment copies? My most regular science rig contains: Mk1 crew report, thermometer, barometer, 1 or 2 Mystery Goos and (most of the time) 0 or (rarely) 1 or (extremely rarely, on some specialised filghts) 2 material bays. There might be also a science container which comes very briefly into the game. It is usually used only for 2-3 missions and then goes straight to the aeronautics museum. The gravioli detector and other instruments could probably be omitted from the NASA-style console since there is no chance getting to them in the career mode while still flying Mk1. 4. The "available" and "has data" seem to have three lights each whereas "XMIT RDY" and "Needs cleaning" only one. What's the idea behind? 5. Shorten "Needs cleaning" to "Dirty"? 6. It is often a problem that you don't really know how much electricity you'll need to transmit a particular experiment. The most ugly situation is when you think that it's enough and then you end up with totally drained battery (especially if it gets transmitted with a wrong antenna that has different EC consumption). To add insult to the injury usually the data is returned to the experiment in this case. 7. For similar reason you often has to sacrifice the usefulness of data transmitted by allowing partial transmits (that is an antenna feature though).  All in all, such console will definitely add some atmosphere to the game and free up a couple of action group toggles (and most importantly free someone from decision of what action group should mean what). Alternatively the instrument setup might be just a number of 3-position switches (rotary or not), rigidly bound to their experiment types: READY/CLEAN - DO SCIENCE - TRANMIT with a 3-section lamp above it: CLEAN/HAS DATA/DIRTY. Ah, to state the obvious: such setup will operate all experiments of the same type at once effectively making them only a single copy. That is totally fine in 99% of cases. And for the remaining 1% one has action groups. Offtopic: is there such a prop as "Ditch Head Shield"? I can't seem to find it. Edited December 11, 2018 by snakeru Quote Link to comment Share on other sites More sharing options...
theonegalen Posted December 11, 2018 Share Posted December 11, 2018  40 minutes ago, snakeru said: Since I'm not quite a modder yet, it's difficult for me to estimate how exhaustive this list of functions is. Besides, you seem to think in terms of MFD interface whereas I usually prefer flying an "old-style" cabins. However, you have a sketch of an "appolo-style" science console. So I'll comment on that one. I also prefer the old style gauges and switches. See my signature for my Warbird Cockpits IVA mod. I did originally think of an MFD implementation because I wasn't sure if a Regarding the little sketch, it was something I just threw together in moments. Everything on there is easily changeable, as long as we have the proper functions in MAS. Multiple experiment banks would 43 minutes ago, snakeru said: Alternatively the instrument setup might be just a number of 3-position switches (rotary or not), rigidly bound to their experiment types: READY/CLEAN - DO SCIENCE - TRANMIT with a 3-section lamp above it: CLEAN/HAS DATA/DIRTY. Ah, to state the obvious: such setup will operate all experiments of the same type at once effectively making them only a single copy. That is totally fine in 99% of cases. And for the remaining 1% one has action groups. Sure, that would also work. Either way, I'm planning to kitbash the existing ASET models rather than ask for or create brand new ones.  Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.