• Content count

  • Joined

  • Last visited

Community Reputation

70 Excellent

1 Follower

About FirroSeranel

  • Rank
    Rocket Scientist
  1. Ah, didn't realize that.
  2. Hi hi, @Nertea I'm having a small issue with the LT-POD landing legs from NF Spacecraft and Tweakscale. These are resized to 110% so they go down the extra bit under that cargo bay (from Lithobrake, not that it's relevant). I've tried tracking it down myself, and it seems like maybe an adjustment in landingleg-pod.cfg would be needed, but I'm not 100% sure. Let me know if it's more of a TweakScale problem, and I'll post it there instead, but I couldn't find anything in TS that is any different, as it doesn't mention either these legs or the Squad legs in particular.
  3. [1.3] Karbonite Plus (K+) - A Karbonite Expansion!

    Hey @RoverDude, I really like the model and effects and animation of the Karbonite Radial Landing Legs, but currently you have the leg module commented out. Checking the current Squad landing legs, I can see why, since they've replaced ModuleLandingLeg with a bunch of wheel modules. I'd like to get them working like the stock legs (with suspension and proper friction, as right now they have no suspension so act really weird on landing, and then slide slowly down the most tiny, imperceptible hill; they'll slide along the launch pad, for example). If I copied the LT-2 modules (minus animations, though I might keep sound effects) into kaRaidalLeg.cgf, do you have any advice on what settings to use for the settings in ModuleWheelBase, ModuleWheelSuspension, ModuleWheelLock, ModuleWheelBogey, and ModuleWheelDamage? Is there any reason other than time that you haven't converted these yet? (Like that it wouldn't work?) If I can get it working, I'd be happy to do a pull request with the fully set up config file.
  4. [1.3.0] ResearchBodies V1.9.5 (14th August 2017)

    I'm using stock planets only, and was having trouble researching Minmus, so definitely not range. If the buttons aren't supposed to work in career, then that's fine. In that case, I suspect a Contract Configurator bug. I have similar problems with Clever Sats not recognizing that I had access to deployable antennas. Yet other contract packs work fine (SCANSat, Tourism Plus, Bases and Stations). I scoured all the configs and logs for all four mods plus CC, as well as the save, and ksp.log, and could find nothing amiss, and nothing done particularly differently in the two that weren't working versus the two that were. So, stumped, I sadly uninstalled Clever Sats and Research Bodies. I've played since, so the ksp log is since overwritten. I think I still have the last ResearchBodies log though... *searches* Yep, here it is. I was able to discover planets with the telescope (though like some others, I got the full reward just for discovery). I was also able to begin "Search the Skies" and "Research a Celstial Body", just not the two telescope contracts. However, while Search the Skies seemed to behave normally (though I didn't fast-forward all the way through it to see if it completed at the end), Research a Celestial Body failed on scene change, consistently. Mods... Hope that helps, and sorry about the lack of ksp.log. If @t rock posts a similar mod list, maybe you can cross-correlate and see what mods we have in common that might be messing with things. If you really need, I could reinstall it, start a new save, cheat in some funds, and see what happens. Let me know. Edit: Screw it, I'm gonna go ahead and do it... Edit 2: Okay, so here are the new ksp.log and ResearchBodies.log, along with a video demonstrating contract failure on scene change. I can also confirm that Search the Skies completes correctly (it discovered Moho. I'd used the satellite to find Minmus). Research a Celestial Body reports success, but didn't find or accomplish anything. Log Files (Zipped Folder from Google Drive) Video Bug Report for Contract Failure on Scene Change Also pinging @nightingale since it may involve a CC bug (Some of the issues are shared with CleverSats)
  5. Part of USI Life Support.
  6. 21 Kerbals for up to 3 months, built for the Space Camp mission from the Tourism pack for Contract Configurator.
  7. [1.3.0] ResearchBodies V1.9.5 (14th August 2017)

    I'm having this exact same problem. I have a telescope in an orbit of 1,000 km, and it says that's unmet. I do have my observatory at level 2, but why would a better observatory disable research? That makes no sense. *Edit* I see in the .cfg that it's a minimum level, so level 2 should be fine. In either case, I can't do telescope missions, and I don't have the Research Aspect buttons either. Any ideas anybody?
  8. Did you ever figure this out? I'm having this bug as well. Stock cargo bays are missing the buttons to open/close/limit deployment, but others are working fine, just like what you had. Edit: In case anyone else has this problem, the culprit was Hangar.
  9. Since nobody answered me... Yes, it uses the stock Squad .cfg file, and... It's not too fidgety. Changing the Top node from 0.2828832 to 0.255 works like a charm.
  10. Ven's docking ports look so much better! But... They don't quite line up anymore for me when they're connected. There's a slight gap between them that's kind of immersion-breaking, since there clearly isn't a hard seal against vacuum. Obviously I can adjust it in the VAB, but when they dock again the gap comes back. Adjusting the node position is simple enough, but I have a couple of questions for anyone who's more intimately familiar with this mod... 1: I don't see a .cfg file for the standard docking ports here. I assume this means it uses the .cfg files in the Squad parts directories? 2: How fidgety are docking port nodes? If I sink it slightly down in so I don't have to try to get 7 decimal place precision like Squad did, am I going to run into problems getting them to dock? I've used Ven's for a long time, and I don't remember ever noticing this before 1.3 came out. It's really blatant on some models (like the basic Clamp-O-Tron), so there's no way I'd have missed it before, especially since when I'm docking, I'm typically zoomed way in on the ports to line them up.
  11. [1.3] - Modular Kolonization System (MKS)

    Ah. I may be misusing terminology then. So it'd take a model edit to make the corner lights shine light cones into the scene? I thought you'd just disabled them through configs, not removed the light emitter from the model. I may look into a separate lighting thing, like a scaled up version of the Sunflower, since if it's on a separate vessel it should have less physics rate impact.
  12. [1.3] - Modular Kolonization System (MKS)

    I realize that, and I apologize if I seem too demanding. I just get upset when people use arguments like "because an FPS drop from 70 to 60 exists on my particular rig in this scene, nobody should ever be allowed to use built-in lights", which is what it felt like Sh1pman was saying. In this case though, since the emissives used to be present, aren't we only talking about copy-pasting the light modules back into the config files for the next update? If that's an unreasonable ask, that's fine, and if you really don't want lights on those modules, that's your choice. But it seems to me that you did want them at some point, or you wouldn't have modeled them in the first place, and some complaints about performance irritated you enough that you went to the trouble of removing them. Plus, you've at least hinted at, earlier in this conversation, editing the models to remove the corner lights, since you thought you already had, which if I'm not mistaken, would be a fair bit more work than adding the emissives back in. *shrugs* It's a user request to put them back in, and my personal belief that (up to a point; it can go too far of course, but I don't think this is anywhere near that point), adding options for the user is preferable to removing features. But you're right, it is your mod.
  13. [1.3] - Modular Kolonization System (MKS)

    I can hit those numbers in scenes with fewer parts as well, but... again, it's KSP, not a racing game. And that 10 FPS isn't really very important. If it was dropping from 20 to 10, that'd suck, but 70 to 60 is from almost completely imperceptible to peripheral vision's fast motion pickup, to... still almost completely imperceptible to peripheral vision's fast motion pickup, but both are still well out of range of the point where it tricks your peripheral vision into sensing genuine motion instead of fake graphics (that starts at 90 FPS and trails off at around 150, which is why VR headsets run at 90 Hz and above, compared to 60 Hz for a typical monitor). Your high-resolution central vision cone can't even come close to sensing any of those numbers, and in fact can barely even detect 22 FPS. 13 FPS is where a flickering light looks like a constant beam, as far as light detection. Besides which, it's -my- game, -my- visual experience, and -my- base. If I want to trade 10 FPS for much a much prettier scene with real lighting... why am I limited by some other people complaining that the built-in lights impact their performance too much? I just disassembled 28 parts in that scene, and went from 34% physics and 22 FPS to 48% physics and 26 FPS. In a full Duna-based base, to replace those built-in lights with stock lights, would easily be that many parts, and I doubt the lighting impact would even come close to the physics impact of those parts. If you're a minimalist who likes fast frame rate (and there's nothing wrong with that), and the lights on the Duna modules included emissives, you could solve your problem by pushing a button to turn off the lights. I'm not, I'm a visualist who likes pretty pictures as long as the frame rate is tolerable. To solve my problem, since they don't currently include emissives, I'd have to go in and edit configs to add the emissives back in myself, or install extra parts, impacting my physics rate. Hence, I'd much prefer for the lights to exist, and for there to simply be an option to turn them off if you don't want them, rather than cater to the lowest common denominator of people who don't realize their computer can't handle some lights.
  14. [1.3] - Modular Kolonization System (MKS)

    Yes, well, I have about 250 parts in scene, so it's physics-based. And... it's KSP, not a racing game. 22 FPS is only 2 off of movie framerates, so unless you sit in the theater complaining about there being too much flicker and low FPS, I don't really see how it's "brutal". Which is exactly why I don't understand disabling the lights on the Duna bases. I can't even fathom a base design, or a CPU beefy enough, where some extra light emissives could make the slightest difference, compared to the extra parts to add lights myself after the fact. *shrugs* Especially if you added one broad, short-range emissive from the top-center of the part, rather than one from each light, and call it good enough. My preference would strongly be for built-in lights. Maybe you can have separate buttons for cabin lights and floodlights, so people can choose?
  15. [1.3] - Modular Kolonization System (MKS)

    That's... bizarre. I see no change at all with a 970. Admittedly I don't have an FPS counter installed, and for a game like this, I don't really care what the FPS is as long as it's at least as high as my brain's primary clock speed (about 13 Hz). For a shooter, I need at least 30 FPS, and for a racing game, as much as 60 genuinely matters, but 50 is totally fine, but for KSP, I just don't want a slide show. I'd much prefer lights at 40 FPS than no lights at 50. Yep, confirmed. All lights off, 22 FPS at my main Minmus base. All lights on (9 emissive lights plus dozens of glow map lights, not that that probably matters), 22 FPS. Sure you don't have something else going on? What are your Shadow Cascades set to? In my experience shadows, especially soft shadows, have vastly more impact on FPS than lights. And of course, more lights mean more shadow sources, so higher shadow cascades could make a huge difference.