• Content Count

  • Joined

  • Last visited

Community Reputation

289 Excellent

About micha

  • Rank
    Sr. Spacecraft Engineer

Contact Methods

  • Website URL www.micha.name

Profile Information

  • Location London, UK
  • Interests Computer (games); Motorbiking; Scuba-diving; reading; travelling; ...

Recent Profile Visitors

2,364 profile views
  1. Yes I do have a Mk16 parachute on top (how else to return in the early game?); but no you don't have enough bits in the early game. Steerable fins are way down the tech tree (at least 3 nodes) so we don't have those by the time we try to make it to space (second or third launch usually, unless you grind out all the local science first by which point you'll probably have access to far more capable pods anyway). I'll just have to practice flying a bit more with this pod; was just surprised at how much worse it was than the Mk1 but the lack of reaction wheels and different aerodynamics could account for that. The tech tree doesn't really make sense anyway from a tech/realism perspective. Not even sure from a game perspective. It just seems to be what it is because that's how it evolved during development. Anyway, thanks, I think the core point I had overlooked was the fact that the Onion doesn't have reaction wheels. I'll try turning them off on the Mk1 to see how much of a difference they make.
  2. Lol, ok, I missed that! Still, the LV45 (ah yes, it's called the "Swivel" now..) is a gimballing engine which gave me enough control authority early in the flight, so no steerable fins required. And no, I did not adjust the gimballing on the engine; just bolted everything together and hit launch. I wonder if it's a combination of it being a lighter and less aerodynamic part as well as not having gimbals that causes the flips once there's less air pressure for the fins? I figured once I got through MDP I'd be golden but the problems seem to occur just after the rocket enters the upper atmosphere. I did manage to recover the rocket sometimes but by then I'm out of velocity and fuel to make it to space. At least no Kerbals died in these attempts (so far)... ED1: ..but then if you need some additional control authority, my point stands, why give us this pod so early without the necessary bits to use it? ED2: (To reply to your redit): Heh, yeah, my caveman days are long ago, I need to re-learn the fine skills I had required then to nurse this up. Just seems a bit pointless considering we have the much more capable Mk1 pod available at the same time.
  3. So I only recently got the Making History expansion, downloaded 1.5.0, and started a brand-new game, no mods. For larks I decided to use the Onion pod for the early missions instead of the Mk1. And I just can't get the darned thing into space. Basic rocket : Onion, bunch of tanks, and an LV45 engine (oh, and some basic (non-steerable) fins on the bottom-most tank). Rocket flips once I get to about 10k or so. Throttling down, adding more/bigger fins, etc only delays the inevitable. I just can't stop it flipping once I get above a certain altitude. Same rocket but with a Mk1 pod instead makes space no problems. So am I doing something wrong, or does the KV-1 need to be in a fairing to launch (ie, historically accurate)? If the latter, what's the point in making it available so early in the game without also giving us the corresponding fairings?
  4. Just FYI, in the 1.5.0 update the new Mk1 pod does not have Kemini slots; a fix for this will be coming "soon" (*) along with fixes for a number of recently reported issues/tweaks. Existing missions should still be using the old Mk1 pod so should be fine. Haven't exhaustively tested yet, but it -appears- the rest is still functional. If you find any issues, please let me know here or on the GitHub bug tracker. Anything non-obvious will need log files and please try to reproduce with a minimal number of other mods.
  5. The executable is only the Unity runtime, actually, and the only time it changes is if they change Unity versions. The entire game is in the assets and dll's which ship with it. You can prove it yourself by downloading the correct Unity version and comparing the checksums of the standalone player binary shipped with it against the KSP executable. This is how modders can debug their mods actually - they take the *debug* executable from Unity and use that instead of the real one to run the game. Ooohh boy... Well, true, not all... Solitare and Calculator tends to continue running most times although the interface changes are debatable. And the latest update can wipe all your data. </offtopic>
  6. Great stuff, thank you! But why do you remove the Kemini experiments from the Mk1 pod if Making History is installed? EDIT: Also, what about the other MakingHistory pods?
  7. micha

    Time for KSP 2.0

    Minor graphical updates would be nice (clouds, better water, better terrain etc), but I actually LIKE the cartoonish looks. This game is not supposed to look photo-realistic. Not really essential though as mods cover it, unless a stock implementation could vastly improve on the performance. What I would like to see more from a potential major revision is basically things which mods can't do. I have no issues taking the vanilla game and adding mods to it to tweak the experience to my liking. In fact, I've actually been a little disappointed at some of the "mod integrations" in recent versions because the stock implementation of a feature which was previously provided by a variety of mods meant I've now got less choice in how I want my Kerbal experience to be. Things which mods can't really do include: core optimisation improvements new functional frameworks (such as the mission builder); for example adding AI-based competing space programs (aka, have a space-race where you have to beat the other programs to various milestones and/or compete against them for contracts by being faster/cheaper/better etc) a proper in-game mod management system (mods need to pass some sort of QA to be part of the official "mod store" although people should still be able to install any mod they like; each save can specify which mods to load, etc) There's not so much point in having revisions to add some mod feature to stock (let's face it, every persons' list of "must have" mods is different) or adding new textures or parts as these things are easily covered by mods.
  8. @Daniel Prates To expand on the above, I've already fixed it in Corvus (v1.3.4) and as @linuxgurugamer said, if you want to fix it for stock heatshields, all you have to do is edit "GameData/DeadlyReentry/DeadlyReentry.cfg" and change line 103 from "@pyrolysisLossFactor = 600" to "@pyrolysisLossFactor = 6000". For some reason DeadlyReentry has a specific configuration section for the stock heatshields instead of just using the generic override near the top of the file (which also seems to have a bug - it has two entries for 'reentryConductivity'; @Starwaster?)
  9. I just released v1.3.4 which (hopefully) fixes DRE (@Daniel Prates) and adds the crossfeed toggle to the heatshield (@StevieC).
  10. micha

    Universal Storage II

    Ah, so 'CurrentSelection' doesn't feed into the other Modules.. ok, I think I understand how it works now. Thanks muchly!
  11. micha

    Universal Storage II

    Awesome! That seems to work now! I re-added all the drag-cubes and the 'USDragSwitch' module as well; not sure if that's needed now or not.
  12. micha

    Universal Storage II

    Hmm, that's not quite working - it's always the 4-height variant irrespective of what 'MeshTransforms' is set to. Actually, on closer inspection, it's displaying all 4 variants at the same time.
  13. micha

    Universal Storage II

    Awesome, thanks! I just needed an example as I wasn't sure how I could strip out the other variants. Presumably I can use the 'A1' drag cube and 'WaterWedgeDouble' instead if I want it to be double-height?
  14. Sure; but many people do. Anyway, does this mean you'd rather not have someone add a Netkan .meta file for HGR even though you'd never have to deal with it yourself?