• Content Count

  • Joined

  • Last visited

Community Reputation

44 Excellent

1 Follower

About rmaine

  • Rank
    Curious George

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Er, in what way do you think axial tilt has any effect on getting into orbit? None that I know of, at least around Kerbin. It affects getting into interplanetary orbits, but nothing before that. Are you perhaps thinking that zero-inclination orbits would end up effectively being inclined by the amount of tilt? Not so. Orbit inclination is with respect to the planet's axis of rotation, regardless of how much tilt that might involve.
  2. That did occur to me as the one context where "crafts" is correct.
  3. (Warning. Minorly sarcastic post follows. :-)) I'm hoping the KSP 2 team has proofreaders proficient enough in English to know that the correct plural of "craft" is "craft". I cringe enough to detract from the enjoyment whenever I read "crafts" in KSP 1. I tried interpreting it as Kerbal humor, but it just doesn't fit the same style of humor. :-)
  4. Crashing things at relativistic speeds, eh? Sounds fun. :-)
  5. Sounds like you are stuck on periods implying decimal points. They don't. In version numbers, they are just separators. I was about to quote a bunch of examples such as IP addresses where dots in numbers are separators rather than decimal points, but it occurred to me that KSP already has an example even more to the um... point. I'm looking at the KSP splash screen right now on my other computer. I use that Windows machine for games and this Mac (which is running OS X 10.13.6 - note the 13) for everything else. I see that KSP says it is That 2594 is pretty hard to interpret as a single decimal digit. But even if you ignore the 2594, what do you think 1.7.3 is doing with two decimal points? What it is doing is that those aren't decimal points. They just separate degrees of change, distinguishing between major changes, significant changes, and minor tweaks. I'm reminded of the infamous Verizon math incident. If you never saw it, google "Verizon math" or "Verizon cents". That was also about decimal points, though the error was the other way. The Verizon rep (and even the supervisor) clearly had no idea what a decimal point was, or what units were, at least where money was involved. A period in an amount of money always was a separator between dollars and cents - never anything else. So ".002 cents" meant two tenths of a cent. Or something like that. The recording is downright hilarious. No it wasn't some Onion thing, much as it might have seemed so. It was a recording of an actual call to Verizon customer support.
  6. Absolutely. And since when is it a bad thing to admit to flaws, when they do in fact exist? Acknowledging your mistakes is the first step to doing better. This adage is just as true in software as it is in most aspects of real life. (Barely resists temptation to name an example of someone in current news who refuses to do that; well, I suppose I didn't completely resist, but I'll avoid the name). I fully expect KSP 2 to be better for having learned from some of the mistakes of KSP 1. Not that KSP 1 isn't pretty darn good, but it also sure isn't perfect.
  7. Of course then you are basically establishing KSC as an absolute reference frame, which is pretty much exactly the opposite of the whole idea of relativity. And once you try to go down that line, everything falls apart. That's what lead Einstein into time being relative - it was needed to make it all hold together. Hmm, speaking of things falling apart when you try to enforce an absolute reference frame, I just now thought to ask what people would mean by an upper speed limit in KSP. Relative to KSP as an absolute frame? That's not how most speeds in KSP are given and it could result in odd artifacts when near light speed; granted the real world has odd artifacts near light speed, but different ones.
  8. And time raises further issues than "simple" dilation. Time being relative to the observer ends up implying that you can't even say whether two things happened at the same time or not. Also, the thing about light speed as a limit applies to information - not just physical objects. So if you wanted to do time "correctly" (or even some approximation to it), you would not be able to switch back and forth between focusing on your interstellar craft and the space center.
  9. Heck, I already bought 2 copies of KSP 1. Originally got it on GOG and then later I bought a second copy through Steam because it seemed convenient at the time and was on sale. I can't easily add up how many hours of enjoyment I've gotten out of it over several years (I often play the steam copy offline) but it is sure a lot more than my money's worth and I'll certainly be happy to buy KSP 2 when it comes out. The OP's apparent sense of entitlement to dictate how development goes, going so far as to label things as fraud because it isn't like he pictures, brings to mind some of my experience in software development. Before I retired from NASA I did a fair amount of software development and one of my programs was fairly widely distributed in its time (relative to its specialized area of application - you are unlikely to have heard of it). I distributed it for free to anyone who asked for it; your taxpayer dollars had already paid me (fairly well in fact) for developing it. Some people well appreciated getting it from me. Others decided it didn't really fit what they needed. Both of those responses were fine with me. But I recall one case where someone insisted that I ought to customize it to fit what he wanted. He was quite upset when I declined to do that for him and expressed downright anger that I gave him a program that didn't do what he wanted. He said I should not have given it to him (for free and with complete source code) if I wasn't willing to invest my time to customize it for him.
  10. Done (mostly just a cut&paste job from my description here). Thanks for your attention. And yes, I have a pretty good idea how much of your time I have a right to expect for support of a free mod (none). If I get desperate enough, I suppose I can play at 100% UI scale by cutting my resolution way back (assuming that doesn't just shrink everything to a fraction of my screen to maintain the same dot pitch). I used to do that before KSP supported a UI scale at all. Shame to go back there to low resolution, but I suppose it's an option.
  11. what? Um, let me rephrase that more politely as Hmmm. :-) So I pick up playing the same game as I posted the above data about. My usual 170% UI scale and no astrogator window visible. I'm not really needing it at this early stage of career anyway. I launch a mission to go rescue a Kerbal stranded in low orbit. As soon as I stage (dropping my SRBs), the astrogator window suddenly pops into view. I continue to a stable orbit so I can safely quit the game. The astrogator-settings.txt file has set the main window position to 0.85,0.85 (and rounding change). I restart the game, which of course puts me at the space center. No astrogator window. Use the tracking station to go to my rescue vehicle waiting in orbit. Still no window. Quit again to examine the astrogator-settings file. It's back at 0.5,0.35 (roughly). [edit] Amused that the forum software bowdlerized my initial version of this post by changing my 3-letter common net abbreviation for an expression of surprise to the less controversial form "what". Probably made my comment about rephrasing it more politely a bit confusing.
  12. I appear to have the UI scaling bug. For some time, I thought the astrogator window just wasn't opening. Not til I perused prior posts here did it occur to me that my symptoms seemed consistent with the UI scaling bug. Reports imply that was fixed 2 years ago. My normal UI scale setting is 170% and I usually don't see the astrogator window at all. (It briefly came back right after a staging in a recent session, but when I came back later it was gone again). Indeed, if I drop the UI scaling to 100%, the astrogator window appears just fine. I pretty much can't read it or anything else on the screen, but I can see that it's there. At 150% UI scaling, the astrogator window is offset a bit low and left, but it is visible. At 170%, it disappears again. I tried manually editing the window position to a few different guesses in astrogator-settings.txt (I tried 0.0,0.0 and 0.25,.25 and 0.75,0.75) but none of them worked and after quitting I see that astrogator had automatically reset to the 0.5,0.35 that it seems to default to when UI scale is 170%. Other UI scales result in it auto-resetting to different values. I suppose I could play at 150%, though it slightly strains my eyes. 100% is just plain out. Relevant (possibly) data KSP win 64 en-us, Making history 1.7.1, breaking ground not installed (or purchased) resolution 2560x1600 full screen UI scale 170% (usually; see above) apps scale 100% (I've always been a bit confused about what this affects vs what the UI scale effects. Plus I don't know why it is only in the settings menu you get to after starting the game as opposed to the one on the main screen.) Mods (per CKAN) [x] science continued 5.22, Astrogator 0.9.2 click through blocker KEI kerbal alarm clock kerbal engineer redux mechjeb 2 module manager 4.0.3 precise maneuver 2.4.2 toolbar controller (I don't have toolbar, just the controller, which several mods require) triggerAuFlags 2.9.3 Link to a log file, though I don't see anything suspicious in it. Little about astrogator other than griping about the image files not being compressible, which seems innocuous. This log file was from just starting a saved game, which opens at the space center. No astrogator window appears. Then I quit. Doing the sam ething with UI scale 100% or 150% does show an astrogator window. I probably won't leave this log file up on dropbox forever, as it's of little long-term interest. https://www.dropbox.com/s/qq24p0d06jb7yl2/output_log.txt?dl=0 Astrogator-settings.txt: MainWindowPosition = 0.49999997,0.349999934 MainWindowVisible = True ShowSettings = False DeleteExistingManeuvers = False GeneratePlaneChangeBurns = True AddPlaneChangeDeltaV = False AutoTargetDestination = True AutoFocusDestination = True AutoSetSAS = True AutoEditEjectionNode = True AutoEditPlaneChangeNode = False TransferSort = Position DescendingSort = False DisplayUnits = Metric ShowTrackedAsteroids = True TranslationAdjust = True
  13. I can't seem to get the auto-turn-on of fuel cells to work properly. Either it is bugged or I misunderstand something about it; my bias leans towards the former, but I admit both possibilities. KSP 1.6.1, Kerbalism 2.1.2, module manager 4.0.2. I'm doing very early missions figuring out how to use Kerbalism at all. Mun flyby/orbit stuff. I build a craft with a battery, solar panels, and fuel cell. Yes, I have both H2 and O2 tanks for the fuel cell and it is dumping water. I configure it to turn on when the battery is low and turn off when the battery is high. So I tool along, enter a shadow and before on my battery is down to zero. I examine the fuel cell and it says it is running, but the battery isn't charging and my H2 tank is still 100% full. I manually click twice - once to stop it and the second click to restart it. Now my battery charge starts going up and my H2 level starts dropping. All looks fine. And when the battery gets to 80%, it looks like the fuel cell properly shuts off per the auto configuration. Seems like it was lying about actually running until I manually toggled it off and back on. This makes the auto control sort of useless. Am I missing something?
  14. Was afraid someone would suggest that; means I'll have to figure out how. :-) Ok, got it, though I was slowed down by seeing no obvious response so I thought the screenshot wasn't happening. Argh. And now I have screenshots but don't see how to readily insert them in this post. I put them in my public dropbox folder and inserted links to them there; have to see if that works. Below are screenshots of a "good" configuration (flies to 38km) and the same thing with the only change being a miniscule shroud turned on (flies to 11km). You'd probably have trouble seeing the difference if I didn't show the configuration menu in the shrouded one. Of course, I close the service bay before flying, but I have it open here so you can see more. https://www.dropbox.com/s/lsnsavliwu22vy8/screenshot0.png?dl=0 https://www.dropbox.com/s/lf2xumqxwmu7pln/screenshot1.png?dl=0
  15. I'm not understanding something about the aerodynamics here - or anyway I assume it must be the aerodynamics. I'm on KSP 1.6.1 in case that matters as I do recall some significant changes in stock aero a few versions back. Had an early-game simple craft mostly to get a bunch of science from the flying high regime. Jeb in a MK1 command pod above a service bay (for most of the science instruments) above a materials bay (aka science Jr), a decoupler and a hammer to boost it all. Almost all stock stuff except for a Kerbal Engineering system module for monitoring expected apoapsis. When flown straight up it accelerates to 810 m/s and then coasts up to 38.3 km. I usually have something along these lines very early in career. This time I had a contract to test a 0.625 m heat shield splashed down, so I figured I'd throw that in on the same flight. Oops. The small resulting gap caused to much drag that I didn't make it into the flying high regime; didn't even make it to 10km altitude, much less 20. Seemed like a decoupler shroud should be just the thing to close that gap. But turning on the shroud made only a small difference in performance. This lead to experiment a fair amount. I took out the tiny heat shield so that no shroud was needed. Verified that Jeb was able to fly to 38.3 km. Reverted to the VAB and did nothing but turn on the shroud, which wasn't actually needed, but I turned it on anyway. The auto-sizing wanted to shroud my materials bay, so I went manual and cut the shroud size down as small as allowed (.01m height) so there's practically nothing to the shroud. Jen can't fly past 11 km. Revert and turn the shroud off and he can go to 38.3 km again. Something about having the shroud turned on at all seems to be killing the performance.