Jump to content

BudgetHedgehog

Members
  • Posts

    4,216
  • Joined

  • Last visited

Everything posted by BudgetHedgehog

  1. It should already be on there as RPM can display up to 17 different resources and those are pulled directly from the game i.e. whatever resources show up in the top right resources panel on the GUI will be in RPM. If you can't see them there, maybe scroll down or go to next page?
  2. By 'this', I hope you mean retaining inertial rotation while on rails, because there's nothing else to fix here that would keep stations stationary.
  3. That would be latency mode (apparently to improve performance, but I haven't noticed any drop when I turn it off). You can turn it off in the config menu in RPM for it or you could add a line into the cfg, but I tried that and it didn't work and I don't know if it's the same with RPM 0.16 or something.
  4. Bingo. Until MechJebRPM is updated, it only works with the 2.2.1 version from Spaceport. Don't hold your breath for a recompile of MJRPM until the next stable full release of MJ (that isn't a dev build).
  5. So that's what those little blips are! I never realised/understood..
  6. I like most of the ideas, but every time I see a suggestion about something 'continually producing a steady amount of Science', I can never agree with it. If the rate is too high, it can be abused by timewarping for a few years so obviously, the rate should be lowered. But to what? If it's too low, there's no point in it being there. I personally think there's no middle ground to be found - there'll always be some people that are patient enough to timewarp for a few years and to stop them, it'd be lowered too much to be useful. I do like the external experiments rack thing though. Always down for more reasons to EVA.
  7. Yeah, I'm not fond of this idea. I get that it increases realism which I'm always for, but there comes a point where you really shouldn't have to worry about every single thing because it's there and realistic - that point is bleeding out monoprop to stop a ship spinning wildly during spin-downs. If that happens and I run out of monoprop, I'd have to wait until the next transfer window or whatever and that's not something I enjoy.
  8. No idea at all, but I've had that happen too. I don't use either cam so it doesn't bother me, but yeah, that's happened to me too.
  9. What version of MJ do you have? Do you have MechJebRPM installed correctly?
  10. Depends on the patch in question, but a safe bet is in that mods thread. If I made a cfg that adds KAS grab functionality to a RT2 antennae, I'd post it in the RT2 thread. If I made a cfg that limits data transmission for KSI antennae according to Antennae Range parameters, I'd post it in the KSI thread.
  11. So the 86% of people who answered this poll and thus, are those who not only know what dV is but also know how to use it... should be ignored? I'm not sure what you're getting at here. Are we taking into account new players? Because I already said that to new players, a dV readout will neither mean a lot nor will they see the relevance between that and attaining orbit. It's safe to say that people answering the poll already know what dV means, and besides, if 86% of voters know what dV means, then, using your logic, 14% of voters also know what it means. It seems that the people who understand dV and do not want it implemented in stock are in the minority. Which is why I stand by the suggestion of making it optionable/unlockable via the settings. For people who don't understand dV and orbital mechanics, they don't have to be bogged down by numbers (there's not really that much maths involved... if your rocket has 4.4km/s dV, then you can pretty safely achieve orbit. However, see my previous points about things going wrong, knowing what 4.4km/s dV actually means etc etc) and the people who want it, they can have it. Yes, it's not simulating real life or a real solar system, but it's basics are grounded in reality (if you orbit a planet with a G of X at a height of Y, you will travel at Zm/s etc) so there must, fundamentally, be some way of displaying basic real orbital physics. It is literally just more information. You're given Eeloos physical characteristics before you ever even have a chance to go there so why aren't you told how much dV your rocket has? It's like saying, with absolute certainty, that "Pluto has a diameter of X, a gravitional constant of Y, an atmosphere of Z atm, a sidereal day of A, that it has B number of moons" without even seeing pictures of it and in the same breath, saying "well, to be honest, I don't know exactly how far this rocket can travel...". Yes, trial and error is the kerbal way, I don't deny that, but personally, I find it more frustrating than anything when I get to Laythe and find out I don't have enough dV to orbit again.
  12. I don't see how making it optionable isn't a bad idea though. Yes, for everyone else, it's useless, but for others (apparently 86.5% of people who have answered this poll), it's not only useful, but desirable. Well they didn't, so any argument based around the fact they did is moot. The point remains that they added a node system that displays dV needed but no way of easily calculating if you can achieve that. This raises the question of how useful it actually is - the only people who find it useful are, I imagine, either people who can work out their total dV by hand (via time-consuming methods) or by people who have mods that show the crafts total dV. Either way, the end result is the same - it's only useful for people who know how much dV they have left.. so why not include a dV readout in stock? Sorry, I must've missed the part where 86.5% isn't "most players". 86.5% of people who have answered this poll have said yes, KSP needs a stock dV readout. Whether this is useful or relevant to them doesn't matter, the simple fact remains that over 4 out of 5 people want it. Please explain to me the part where ignoring over 80% of your userbase is good practice. Because any number of things can go wrong on the way. You might accidentally stage a decoupler, mess up your intercept, crash into your solar panels, forget parachutes or RCS ports.. all very kerbal things and also all very possible. Being told "you have enough dV to do this mission" presumes absolute perfect everything - launch, orbit, transfer, insertion, landing, takeoff, rdv, return back, re-entry.. if any step of that goes wrong, your total dV goes down. I repeat, a dV readout is not saying "you can perform this manoeuvre", it's saying "if executed perfectly and under ideal circumstances, this manoeuvre can be performed with your current dV, which is XXXXm/s". Rarely in KSP is something executed perfectly. EDIT2: Again, I do not find reverting to VAB/a quicksave particularly fun, especially if it's done more than once. As I said, I'm not made of time, the time I spend playing KSP is limited, so yes, I'd much prefer it if I was told in advance that I won't be able to perform what I intend to do. If I get to Eeloo and find that I don't have enough fuel to launch to orbit and rdv, I'm going to be seriously annoyed at the fact I've basically just wasted a couple of hours of my time playing KSP.
  13. [emphasis added]I'm not saying they SHOULD have it, I'm saying they WOULD have it. Seriously - ask NASA if they'd launch a rocket without knowing its dV under all circumstances. Ask the Indians, the Chinese, the Canadians.. every single space program ever has had information on how far their rocket can go and not had to look at it and say "yeah, that looks about right.. let's launch it and when we get to Jupiter, we'll find out if we have enough fuel left". Basic information is not only useful but absolutely required for space travel. It makes no sense at all that KSP would not have some way of showing the player this (not even by showing the vehicle wet/dry mass without a complicated workaround). I get that it's a comical game, that killing kerbals or reverting to launch is keeping in the spirit of the game but some people actually want to play realistically (me included). And as it's "some people", why not make it optionable/unlockable? Also, stock KSP already has something reference it to - the manoeuvre nodes. "Oh hey, you need to change your velocity by this much. Can you do that? I dunno". I for one, do not enjoy finding out that I do not have enough and have to either revert to VAB or wait ages until the next transfer window to be able to send a refuelling mission. I'm not made of time, I do have a life outside of KSP, despite what my username says. EDIT: Yes, it's not vital, I'm not arguing that. Players that are sufficiently informed about their vessel wet/dry mass, their engines ISP and that are supplied with enough pencils and paper don't need a dV readout, I'm not denying that. I'm just saying "what's the harm in adding an optional display for people who want it?".
  14. Still kinda waiting on that update that was going to be uploaded to Spaceport in a few hours which was like, a week ago. Hard to give feedback when nothing's changed (please don't take this the wrong way, I adore your pack and textures)
  15. Slippery Slope argument. Why have this game at all if the user is given what you propose? Build stuff, "launch", "land".. Being given the information to be able to perform orbital manoeuvres is not the same as the game performing those orbital manoeuvres for you. You still need to know that to reach orbit, you need 4.4 km/s dV, to get to the Mun you need about 800 m/s and to Minmus about 950. As you said, that means nothing to a new player/someone that doesn't yet understand orbital mechanics. Even if you had MJ installed, showing dV is meaningless if you don't know what to make of the information. So what's the harm in having it? How will it negatively impact your gameplay if a dV display was optional and/or unlockable? That way, people who don't want it can hide it and people who do want it can have it. Also, there's no reason Squad "should" add things to the game at all - if you have a dV readout, it should be up to you to find out what you can do with how much dV you're given. There's no clause stipulating that "if Squad gives a dV readout, they must also include xyz".. the readout isn't telling you "you can land and return from Duna with this", it's literally telling you "you can change your velocity by this much". I don't see how that's in any way coming close to having an autopilot. And please don't bash MJ - it has many useful functions beyond the autopilot feature, including information readouts that A, any space program would have anyway and B, KER is missing.
  16. Quick question: is it safe to just delete the lines excludedHeads, excludedSuits, femaleHeads and femaleSuits from the @Default.cfg? The female heads I have (from KSPRC) look weird and I never send Jeb, Bill and Bob on a mission so I'd like to make their heads and suits available for everyone and just get rid of female stuff entirely (until someone can make a decent looking female kerbal head that doesn't include lipstick, huge eyelashes and a hairpin).
  17. I feel so bad because this is what I told you to do but apparently something has broken along the way and I don't know what it is.. I'm so sorry, I can't help you with this, I don't have RT2 so I can't replicate this but yeah.. sorry!
  18. It shouldn't do. I imagine sarbian and idolilodadabath (I can never spell his username) were very careful not to break backwards compatibility, due to the sheer number of mods that use it. There could be an issue with poorly written cfgs though. Either way, it's something best brought up with MM authors, not ferram. Also, the update makes use of the :FOR[modname] features of MM 2.0.3 - specifically, it specifies that the control surfaces are only changed for FAR:
  19. KAC, Enhanced Navball (it was supposed to be stock anyway), PreciseNode or similar, RLA Stockalike and SPUE all should be stock. Edit: Also, I'd like for FAR (with some kind of fairings. I don't like Procedural Fairings so fixed ones would do nicely, like the ones from KW) to be stock too, along with RPM, Antennae Range, Environmental Visual Enhancements, NavballTextureExport, HullCam VDS, Toolbar, DOE, EditorExtensions, KerbQuake, SCANsat or similar, SelectRoot, TweakableEverything, SurfaceLights and, of course, FloorIt.
  20. So with this aerodynamic-induced destruction, watching deorbited lifter stages is a whole load of fun! Thanks ferram!
  21. Sounds like you're attaching the chip that displays flight data only. Have you tried attaching a different one?
  22. No, you're absolutely correct, sorry. I guess my video wasn't shaking enough, but having just done a re-entry from Minmus, I can definitely say that window clicking does maintain the shaking
  23. Ooh... I think that with some playing around of syntax from ModuleManager 2.0.3, having the LV-Ns generate electricity AND waste heat could be possible, but ONLY if Interstellar is installed (since that introduces waste heat management).
  24. It already has a power generator - the nuclear reactor. I'd suggest maybe making it a bit heavier if the generator/alternator additions I posted above were implemented to make it more balanced (and to take into account the fact you have all the extra gubbins to make electricity).
×
×
  • Create New...