• Content count

  • Joined

  • Last visited

Community Reputation

63 Excellent

1 Follower

About FirroSeranel

  • Rank
    Rocket Scientist
  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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?
  7. Even when off? If they're only expensive when on, why not just leave the user the choice?
  8. 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?
  9. 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.
  10. 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?
  11. 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.
  12. Ah. Okay, I think I've nailed it down. I think it's an unfortunate interaction between GPOSpeedFuelPump and MKS. Not a bug in either case, just... my top-priority modules for GPO are the production modules... which don't have warehousing. The lowest priority are the inflatable warehouses that do nothing but storage. So... I'm guessing the warehouses are pulling resources from the other base, then they're immediately being whisked away to the production modules by GPO, leaving them with 0, so they call for another pull request? Trying turning all pumps off... Alright, I can upload it, but you'll need some mods to load the base. Still want it?
  13. No, that's not it. There are plenty of Specialized Parts in the main base...
  14. Yes, but it's actually not taking the MKs for some reason... It used to, but it's not now. It is still stealing the Specialized Parts though. Probably because it's consuming them faster than it's producing them, while the MK production is net positive. I suppose I could temporarily turn off the main base' local resources on its Specialized Parts storage? Actually I think I know what's going on... it's just listing all the materials required when it says it has insufficient resources. The only thing it's actually missing at this point is Specialized Parts, and there actually are zero of those, net, between the two bases, with all warehousing turned on, maybe.
  15. That's from GPOSpeedFuelPump. It lets me designate priority levels for resource tanks within the same vessel, and have resources automatically flow from higher levels, to lower levels, in real-time, and balance between equal levels. Very useful for automatically refuelling a ship upon docking, shifting lots of fuel quickly without hundreds of button presses like the stock system, or balancing high-fuel-percentage SSTOs. I think it sucks it out, because there are no consumers for those parts on the outpost. So the equalization probably happens through mutual pull requests, but the outpost isn't making any.