snakeru

I like the design, especially the sticky note over the monitor. Also the grouping makes a lot of sense. I would, however, remove props that are not related to doing experiments in orbit, namely these 5 toggles (in the order of decreasing priority): recover, stage, abort, gear and brakes. The toggles on the right (stock ones) should probably also be removed/replaced, otherwise they don't quite fit into the new design. Dummy/made up toggles can be used if nothing useful is available. Also, I noticed you have X-PTR instrument, but no ARRT. ARRT is invaluable addition to X-PTR for dockings. Also the monoprop gauge has to be somewhere around as well.

Hi @Max-Ksp Please have a look at the Mk1LanderCan IVA that is included in the latest release of the MAS. Perhaps you can borrow a couple ideas from there (both in terms of what instruments to use and how to organize the .cfg files). The only instrument that is present in ASET Mk1LanderCan and not in MAS Mk1LanderCan even though supported by MAS is the TV screen (the reason being that I considered it to be too high-tech for Mk1).

Use MAS props. I don't think ASET props use MAS by default (though they often use RPM which won't work with MAS).

Hi @it0uchpods You probably also need to update one of .xml files in the project root that are used for auto-generation of these props. Also: since it's much easier for @MOARdV to reject a PR than to make one from a gist I'd recommend going for PR anyways. There is only one him and there are so many us.

@MOARdV, how does one make a pushbutton that automatically goes back to inactive state? I hoped to get an action group button that does not action as a switch. There are MAS_pb_AGx buttons, but they also get stuck in the depressed state and don't go back. I tried to edit it like in the snippet below, but it does not seem to have any effect. Any clues?

In my case I got my IVAs working by reading the KSP.log and searching for errors. Normally KSP reports why a particular thing is not activated (usually missing dependencies). I'm running the 1.5.1

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.

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) 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).

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? 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. 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. 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. 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. 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. Sounds good. I'll just kill it in my copy then :-) 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. 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?

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.

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:

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.

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.

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.

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).

I like #3 because it has more gauges and they show different things. I like #2 because gauge needles are bright blue (though both gauges seems to show the same measurement and there are only two of them). I dislike the #1 because the colors are dull and the needle movement seems to be inverted (counter-clockwize).

Hi. I have a question about RPM MFDs and their function without the energy. In my ship designs it sometimes happens that energy is being consumed all the time and then, eventually, runs out. MFDs at this point freeze and stop updating. That would have been OK, if not that other thing - my kerbal pilots often have 100% stupidity. They keep staring dumbly at non-updating monitors and keep playing with time speed up/down buttons to figure out what went wrong. And when they finally decide to take a look out of the window - it's already too late to make this "High over the Mun" report and time to write down the "Low over the Mun" one. Or better yet, stage and transition directly into landing sequence. What setting should I tweak to make monitors go OFF when there is no more energy?

I agree with you here. Fun > realism. May be I should retract my "make the Elektron more power hungry" demand. We should probably still sync the resource rates b/w Elektron and Fuelcell Not sure anymore if oxygen:hydrogen ratio should be changed. Some spreadsheeding is required to see how this will affect the total balance.

Actually I am probably wrong here. It won't be economical to run it at night but during the day time it would be perfectly fine. One will just need to care about having big enough oxygen tanks to survive the night and big enough solar batteries to make it through the day.

Hmm? Decrease? Isn't increasing the Elektron energy consumption more logical? Let's compare to the stock parts: 1) Stock fuel cell: 0.0017 fuel/s + 0.0020 oxidizer/s => 1.5 energy/s. Mass: 0.05t. "power density"=1.5/0.05=30 energy/tonn (http://wiki.kerbalspaceprogram.com/wiki/Fuel_Cell) 2) Stock fuel cell array: 0.02025 fuel/s + 0.02475 oxidizer/s => 18 energy/s. Mass: 0.24t. "power density"=18/0.24=75 energy/tonn (http://wiki.kerbalspaceprogram.com/wiki/Fuel_Cell_Array) 3) K&K Fuelcell (stock): 0.02025 fuel/s + 0.02475 oxidizer/s => 18 energy/s. Mass: 0.35t. "power density"=18/0.35=51 energy/tonn 4) K&K Fuelcell (TACLS): 0.9024 H2/s + 0.00674 O2/s => 18 energy/s (+9e-5 H2O/s). Mass: 0.35t. "power density"=18/0.35=51 energy/tonn So it seems that currently the Fuelcell fits somewhere in-between of stock parts in terms of "power density" (or how you name it) whereas it should be probably a little bit more powerful because it is almost 1.5 times bigger than the stock 'fuel cell array'. I understand, of course, the implications of making Elektron much more power-hungry: it's value will greatly reduce on non-Kerbol-tidally-locked solar bodies.

Hi. TAC support bug report here. Elektron and Fuelcell are containers that do opposite things - one consumes energy&water and produces oxygen&hydrogen and the other does the opposite. However I discovered that amount of energy consumed/produced differs 56 times. It would have been understandable if that could have been explained by efficiency (13% efficiency of both machines can do that), but it's the OTHER WAY! Burning hydrogen gives us 56 times more energy than we spend cracking the resulting water back into elementary substances (please excuse me for the lame screenshot, made it with my phone and then edited with Gimp). Another small side problem is that the oxygen:hydrogen ratio seems to be 1:90 for the Elektron and 1:133 for the Fuelcell. If we measure by weight then the ratio should be 8:1 (16 kg Oxygen vs 2 kg Hydrogen) OR if we measure by volume then it would be 1:2 (1 liter of Oxygen vs 2 liters of Hydrogen). I would guess that this one would be much harder to fix as it would likely also require to rebalance a lot of other things in the Game. Thank you for the very good mod, BTW!