Jump to content

micha

Members
  • Posts

    1,106
  • Joined

  • Last visited

Everything posted by micha

  1. I had the same problem; one thing I failed to notice was that they don't have reaction wheels, unlike the Mk1 pod. Still, they are far less aerodynamic than the Mk1, so much more care is required to get them to orbit. But with a bit of practice, I had no problems. Just have to throttle down a bit while they are going through the upper atmosphere and make sure the gravity turn is nice and slow and smooth. Still, I'd argue that a basic fairing for these pods should be available very early in the game.
  2. PSA: v0.8.0 is live; download links in the updated first post. Any feedback and bug reports appreciated.
  3. PSA: v0.8.0 is live; download links in the updated first post. Any feedback and bug reports appreciated.
  4. ..and as it turns out while not trivial it wasn't exceedingly difficult either. ED: But I had to fudge Kemini and MEP a little. In the case of Kemini it doesn't matter as the fudge relies on a hard-coded value anyway, but in the case of MEP, it's possible for someone to change the configuration (either by editing the file or via a ModuleManager script). In this case the MEP times will be incorrect.
  5. Hi, I just looked into this, and it's not trivial. The time required to run an experiment depends on many factors, spread across various configuration files and different objects at runtime. Basically it's a function of how many resources the experiment requires, and how quickly those resources can accumulate in the lab and lab-equipment into which the experiment is installed. So @linuxgurugamer's suggestion of just adding the time to the description kindof would work but would need adjusting every time somebody adjusted the values in the configuration files (either due to an actual update to the mod, or from a ModuleManager entry etc). The "correct" solution is to calculate the time at runtime and inject it into the description. I'll look into it in more detail but it's not a quick fix, unfortunately. I'm happy to report that I've identified the underlying cause and fixed it for the next release.
  6. Ok,. figured it out. The "double-click" to add an experiment and the "why don't experiments persist on revert" are related. And, in fact, the experiments -do- persist, just that when you get back into the VAB after a reset, the UI isn't initialised properly. So it shows the slot as Empty, instead of containing the experiment, despite it actually containing the experiment. The first click actually removes it, the second then adds it back. So "double-click" is only on revert, not with a clean ship. Will be fixed "Soon"(tm).
  7. micha

    1.5.1 Hotfix

    Until recently, Linux was actually the *better* platform for running KSP on. And having Linux support was pretty much the reason I bought KSP way back. And thanks for the quick bugfix, KSPDevs
  8. I can't repro; even went so far as to unpack a clean 1.4.5 from my archives and install NEOS from CKAN to ensure I'm running the current build. Any other mods installed which might interfere with the UI? And I'm guessing you guys meant "Kemini", not "KEES" If there's problems putting KEES items into inventory then that is down to KIS, nothing to do with this mod. Ah, that's something that's been bugging me too. I'm sure there's a technical reason, but I haven't investigated it. I'll see if I can figure it out. It adds Kemini to various other non-stock capsules as well. And the next version will add to the Mk2 pod from Making History. I'm still undecided whether to add Kemini to the various Vostok/Voskhod pods considering that they are supposed to be *Gemini* experiments.
  9. .. and as I said, with a touch more practise and a longer rocket I could get it to orbit so my question was answered. Still, ideally you'd get other relevant tech (rcs, fairing) along with it to make a Vostock/Voskhod style launcher. And yes, apart from the sheer novelty as an alternative to the Mk1 it's hard to justify why you'd use them. Although you do get the 2-Kerbal one earlier than the Mk2 along with reaction wheels so potentially a rescue pod? Shame they didn't include Soyuz styled capsules as a follow on.
  10. Ok, a longer rocket helped. A lot. I barely had to throttle down. Not only did I make it to space, but also orbit (with a second stage). Still, I'll be glad to unlock RCS/reaction wheels!
  11. 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.
  12. 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.
  13. 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?
  14. 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.
  15. 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>
  16. 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?
  17. 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.
  18. @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?)
  19. I just released v1.3.4 which (hopefully) fixes DRE (@Daniel Prates) and adds the crossfeed toggle to the heatshield (@StevieC).
  20. Ah, so 'CurrentSelection' doesn't feed into the other Modules.. ok, I think I understand how it works now. Thanks muchly!
  21. 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.
  22. 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.
  23. 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?
  24. 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?
×
×
  • Create New...