Results 1 to 9 of 9

Thread: [Suggestion] Lag reducing mod

  1. #1

    [Suggestion] Lag reducing mod

    I know, I'm sure many people have asked for mods which reduce lag, but I actually have a plan of how to make it work. This mod would be a plugin of sorts, which, when turned on, would turn off rendering on moons and planets that you didn't need. It would first check what SOI you were in, for example munar orbit, and then stop rendering anything that wasn't in that planetary system. By rendering, I mean terrain, terrain scatters, lighting effects, atmospheres, and even physics for the other planets and moons. If you were in orbit around The Mun, the only things rendered would be Kerbol, Kerbin, The Mun, and Minmus.

    of course it could be customizeable, like you could turn moho on remotely if you wanted to see it's transit from eve.

    I think this would really reduce lag. It might have already been done, so tell me if it is.

  2. #2
    Most of the lag is due to physics calculations for ship parts, not rendering objects. Additionally, I'm fairly sure KSP already turns off the physics for any body besides your current SOI. That's the whole idea behind Patched Conics, after all; simplify a multi-body problem into a two-body problem. If the game had to work out how Eeloo was affecting your orbital trajectory, it would explode.

    That's even assuming the bodies have any actual physics to begin with. ...actually, if you built a massive rocket, pointed it down at the pole, and fired the engines for hours on end, could you change Kerbin's orbit?

    Anyway, sadly, I don't think such a thing is possible, or at least not from our position. The best way to reduce lag is to use part welding (using .cfg edits to combine several parts into one),

  3. #3
    Planets do not have physics, nor do ships or parts farther than about 2.5Km from the ship you are focused on. They are on rails, travelling a preset course without regard to where it takes them

  4. #4
    Wellp. There goes my "Kerbin Migration" plan.

  5. #5
    okay so some of those things are in the base game. I kind of thought that would happen.

  6. #6
    Auto Mechanic LostElement's Avatar
    Join Date
    Aug 2013
    In an alternate universe
    Couldn't there be something that groups all that parts into One part? Except for things like the staging? While its probably impossible but its something that popped into my head

  7. #7
    Generally speaking, no. At this point most but not all of the modules have been replaced with partModules, which means those left over cannot exist together or with multiple of themselves. Most importantly for things this would apply to, Struts, Fuel Lines, and Landing Legs cannot be merged.

    But also a bunch of the partModules and RESOURCE{}* are not designed to permit multiple instances, which I think is really annoying but whatever. A bunch of them do support multiples, like you can have multiple docking ports; though have fun targeting that.

    But, let's step back a bit. It's Totally Possible to merge Some Parts, like if you have a stack of different fuel tanks that contain the same thing you can sum their contents; if you have a bunch of truss lengths, there's absolutely nothing wrong with merging them together or onto whatever they connect with. Merging Everything into One part would require a lot of fixing, and a lot of that fixing is stuff that'll happen in KSP's natural development, but merging some stuff is a thing that is being worked on by several modders already, I'd expect it to be a reality before the end of the year.

    *You can have multiple RESOURCE{}, but you cannot have multiple RESOURCE{name=LiquidFuel}, the loader just ignores it, or applies the last declared, haven't tested which.
    Last edited by Greys; 7th September 2013 at 19:07.

  8. #8
    Capsule Communicator
    Join Date
    Jun 2013
    Hm, actually multiples seem to work - my 2in1 parachute "opens" twice - not visually regretfully but the drag increases.
    I just cant tell if it changes the drag to the new values or adds them both.
    ArmchairGravy: To launch your rockets, see them explode around you and hear the lamentations of your co-pilot.

    space travel can't ease the pressure on a planet grown too crowded ... stupid people won't leave the slopes of their home volcano ... What space travel does do is drain off the best brains smart enough to see a catastrophe before it happens and with the guts to pay the price and go. That's a tiny fraction of one percent. But that's enough.
    — Robert A. Heinlein, Time Enough for Love

  9. #9
    parachutes are partModules, not modules and the reason your parachute isn't working as you'd desire is because your model only has one parachute to be opened
    capName = cap
    canopyName = canopy
    semiDeployedAnimation = semiDeployLarge
    fullyDeployedAnimation = fullyDeployLarge
    The element of your model representing the cap and canopy is the same in both, and the animation is the same as well.

    Now there's also a problem that you can only have a single animation running per part (without using a mod based animator partModule), you may be able to get around this with MODEL{} but I don't know.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts