snakeru

Members
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

7 Neutral

About snakeru

  • Rank
    Rocketeer

Recent Profile Visitors

299 profile views
  1. snakeru

    [1.6] BARIS - Building A Rocket Isn't Simple

    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?
  2. @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.
  3. 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. :-)
  4. 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
  5. 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.
  6. 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.
  7. 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).
  8. Use MAS props. I don't think ASET props use MAS by default (though they often use RPM which won't work with MAS).
  9. 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.
  10. @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?
  11. 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
  12. 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.
  13. 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).
  14. 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?
  15. 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.