FirroSeranel

Members
  • Content count

    318
  • Joined

  • Last visited

Community Reputation

66 Excellent

1 Follower

About FirroSeranel

  • Rank
    Rocket Scientist
  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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.
  10. Ooh, very cool! Yeah, I'll definitely use that. Yeah but... for people with modern graphics cards, lights are dirt cheap, and pretty, but part count is expensive. My GPU doesn't care how many lights are in scene whatsoever, from what I've seen. On the other hand, if I have to add other lights as parts, that adversely affects my game performance much more than lights added intrinsically to a part. It's one of the things I thought was really cool about the Duna modules, that they had built-in lights. I was really sad when they didn't work. Plus... doesn't the max lights per pixel slider in the main game settings kind of limit player stupidity on that front anyway?
  11. Even when off? If they're only expensive when on, why not just leave the user the choice?
  12. Oh, part of USI? I'm not sure... I don't think I've experimented with that yet. Is there a way to manually transfer stuff using local logistics? I've only ever seen the automated behavior. Well what I mean is the lights cast from the four spotlights on the corners of the module. Those should still be there, casting onto the ground?
  13. Because it's slow and requires lots and lots of clicking if you have multiple fuel tanks you want to transfer from/to. I can refuel a ship within maybe 30 seconds with GPO... or take about 10 minutes and hundreds of clicks, and wind up with sore hands (carpal tunnel and some other stuff) with stock. It is, at this point, a convenience mod, rather than a necessity, but frankly, many of the 1.2 changes are not very user-friendly in terms of sheer number of clicks required to do things. I logged issues in the beta for things like adding a global preference for Rigid Attachment, but it never made it. That's another feature I basically can't use. My hands just can't handle the hundreds of extra precise clicks needed during a vessel design process to turn it on for all parts.
  14. No, you're correct. I could still use it for automatic refueling, and fuel tank balance on VTOLs and SSTOs, I just need to be very careful about how I assign GPO pump levels in bases with MKS warehousing. By the way, @RoverDude... any idea why the lights on that Duna module aren't producing emissive light? I have this problem with a lot of lights lately... some work, like on the Karibou. I had to get rid of Ven's Stock Revamp's stock spotlights, and the original Squad spotlights work fine, but... why would that have any effect on Duna modules? Or do they just not produce emissives yet?
  15. Yep, that was it. The warehouses were empty because GPO was shunting their resources straight to the consumers' internal storage. So... GPOSpeedFuelPump and MKS Resource Management are... not so much with being compatible, it seems.