Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Rodger

  1. Keyboard controls would probably be good enough, as long as reliance on MMB dragging for panning is gone. The 'horizontal' VAB mode camera panning is especially weird atm, you pan the mouse up and down to move the camera sideways lol The shift-scroll combination for 'fast zoom' is also pretty weird, doesn't seem different enough to the normal scroll zoom to justify it. It could be scrapped to make room for a more useful control, like holding shift for a SPH pan or something.
  2. Being so reliant on MMB means you can't play on most laptops without an external mouse. This was no issue in KSP1, you could easily play on laptops without control issues. The main change I'd like to see is set scroll wheel scrolling to vertical camera panning, with shift-scrolling for zoom. Even with a mouse, I'd prefer this control scheme. This wouldn't remove MMB usage entirely though, so maybe allow that to be rebound to a modifier key + left or right click for other uses, like focusing a part. It would also free up MMB drag for a SPH style free pan, which is a more niche use, so not required for play thus still allowing laptop use (maybe it could also be bound to modifier + arrow key), but would be a nice addition. The lack of SPH camera controls in KSP2 is just a straight downgrade/missing feature.
  3. You can post bugs here and tag me, or in the issues section on the github https://github.com/CobaltWolf/Bluedog-Design-Bureau/issues
  4. If you have System Heat installed, the bdb boiloff mechanic should be disabled automatically.
  5. Thanks, looks like the SSS patch isn't getting applied. And after checking, it seems like the last release of SSS doesn't actually have the required patch. If you download this (just save link as): https://raw.githubusercontent.com/CessnaSkyhawk/SkyhawkScienceSystem/main/ModSupport/Bluedog_DB/Apollo_CrewPod.cfg and place it in your GameData/SkyhawkScienceSystem/ModSupport/Bluedog_DB folder, that should fix it for now, until there's a new release of SSS. Same goes for @Royalswissarmyknife
  6. Actually @Spike88 if you're able to, could you zip and upload the 'ModuleManager.ConfigCache' file from your game data somewhere and link it? It would help see if the SSS patch is working or not.
  7. So SSS does patch that part's required upgrade: https://github.com/CessnaSkyhawk/SkyhawkScienceSystem/blob/main/ModSupport/Bluedog_DB/Apollo_CrewPod.cfg But from looking at that patch I don't see how it wouldn't work. Perhaps patch order? I'd say it's likely fine to ignore at least, and I'd be interested if you can actually unlock the probe core functionality with SSS installed in-game.
  8. @Spike88 and @Queen Ultima, that could happen if either the upgrades.cfg and/or the Shared folder are not present in the Parts folder, causing that upgrade to not exist. The Apollo capsules have an option to enable probe control, unlocked via that upgrade, so unless you want to use the probe option, and the parts still loads, there should be no issue. I could also make it an optional patch in BDB Extras, like the Gemini and Mercury pods if it causes issues.
  9. Part side count is definitely inconsistent, some other examples I've seen: The mk1 cockpits actually have two different side counts (and different cap textures), both higher than the rest in the size category, the in-line is *very* high res: The Reliant and Swivel have 32 sides, which doesn't match sm sized tanks, and also doesn't match their own shrouds: The Terrier has a 'mount ring' which adapts it to the standard 24 sides of it's appropriate tanks and it's shroud, this works pretty well: The md size fl1 monoprop tank has 24 sides instead of 36 (and the md pod has 64 sides). It seems like an old ksp1 asset not updated yet. And the Kickback is rotated 7.5 degrees so there's a flat side at the sides of the part, instead of a point: The mk7a nose cone might just be a KSP1 model too, with 24 sides, instead of 36: And the mk2 lander can flare are the base is a lot bigger than 2.5m:
  10. In my op I did suggest it could just automatically set warp to 0, but still allow you to use other controls, by which I meant you could resume time if wanted. And while yes, it is just a different set of buttons to get used to, I feel making the esc menu pause the game /time would be the default expected behaviour for basically everyone, making it more intuitive for new players, or even old ones returning from ksp1. It doesn’t impact gameplay much either way, so why not choose the option that is generally going to be expected by people? There currently also isn’t actually a pause time button. If you’re warping you have to stop warp with / then lower it one more step to stop, or just spam the slow time key. so maybe just a single button pause time key would be a good addition too.
  11. That’s why it’s not in the bug report forum, but the suggestion/feedback forum
  12. I do wonder who actually *wants* wet noodle rockets? I guess it can be funny once or twice, but the popularity of autostrut and mods like KJR seems to suggest most people prefer a more rigid node setting. And ksp2 being new game is a good opportunity to set a new standard, instead of just redoing the “ksp1 feel”. At least it being a configurable value in a json means it’s easy to tweak now.
  13. You could probably make a cool ground-interaction effect with this over expansion though, for example as a lander touches down (in vacuum), the plume gets forced outward a bit.
  14. Or having a node editor window instead could help with this too, so you can stay focused on the intercept and adjust the node without aiming the camera at the node itself. Personally I’m quite used to using a node editor window mod in ksp1 (Precise Maneuver, I prefer it to the stock ksp1 node editing system which is just some small tabs at the bottom left of the screen) and I find it very convenient doing it that way.
  15. Quite a minor thing, but I don’t really like how non-magnetic nozzled engines have slightly exponential expansion in a vacuum. I feel like they’d look more realistic if they stopped at linear expansion in vac, and not have “concave” sides. Unless there’s actual science behind why they’re set to do this? For future parts with magnetic nozzles and charged exhaust it makes sense. And just to clarify, this is what I mean by a 'concave' side:
  16. I feel like it goes against convention for the esc menu to not also pause the game, which makes it feel “weird” that it doesn’t pause. I get that it’s just a different button to pause, but people will instinctively press esc when they want to pause. Other controls could even still be active while the esc menu is up, just have it set time warp to 0 when opened.
  17. I've even had them produce reverse thrust: https://cdn.discordapp.com/attachments/1075863855881797804/1078984504213000252/KSP2_x64_hs7X8ulb7N.mp4
  18. For future-proofing new part sizes, it would be good to standardize the VAB part icon size tags at 3 characters, to allow for more tag options. Like for stuff like 1.875m (Maybe SMD?), or XXS. There's already strut parts of different sizes in the same categories which are almost impossible to tell apart visibly, so it would help differentiate those already too. Also, when it comes to making it moddable, it might just be best to allow anything to be put in there, scaling the width of the tag to fit it. It may end up being best for modded sizes to just list the actual size in the tag, like “1.5” or “0.9375”.
  19. This is quite important for laptop use, as laptops mostly don't have a MMB (without using an external mouse). Mainly for the VAB part focusing, up/down panning, and part favoriting. The ksp1 VAB was perfectly usable without a mouse on a laptop, due to using modifier keys with the main mouse buttons and scrolling. So even if not rebinding (as what do you use instead of MMB then? There's not always a good option for clicking tasks), adding secondary modifier key based controls would be good.
  20. Just noticed this too. The base is also wider than 2.5m, and it has 64 sides instead of the size-standard of 36.
  21. install this and it should fix it: https://drive.google.com/file/d/10zdtxBecBq6KDjLS19GIM4_HnNkzK_mp/view?usp=sharing lmk Let me know if it doesn't @DaveyJ576the GATV fairing nosecone is fixed on dev now too
  22. If you make a new cfg file with this in it, somewhere in your game data, it should fix it: @PART[bb_Prop|bb_PropSingle]:AFTER[KRnD] { !MODULE[KRnDModule] {} } Without knowing exactly how krnd works, I’m guessing this should stop the prop parts from being affected by it at all.
  • Create New...