Jump to content

hippomormor

Members
  • Posts

    29
  • Joined

  • Last visited

Posts posted by hippomormor

  1. On 16/7/2017 at 1:02 AM, hippomormor said:

    I'm having the same issue. My (large) Procedural RF SRB's can't have a burn time of 150s any more. I can set it in VAB but it gets reduced at launch.
    This worked in PP 1.2.8 on KSP 1.2.2 but after i updated to PP 1.2.11 (also KSP 1.2.2) it stopped working.
    It's VERY close resembling the non-RF SRB issue on GitHub so I'm reluctant to create a separate issue on this behalf. Should i?

    Note: I'm not using RealismOverhaul, just RF and PP

     

    I looked in to the issue - i posted a possible fix here:

    https://github.com/Starwaster/ProceduralParts/issues/12

    I'm not sure if this has any other negative effects since I'm not intimate with the ProceduralParts source-code, but it seems to be working fine with both RealFuels and stock.

  2. On 13/7/2017 at 2:44 PM, wb99999999 said:

    Edit: It is not about the ratio. Build a large enough booster and set its burn time to anything below 180 seconds, will cause the problem to surface. The thrust will be reduced to a specific 2,335 kN and the burn time will scale with it. I speculate that the size cap is at the exact point where setting the burn time to less than 180 seconds will cause the resulting thrust to be higher than 2,335 kN... this is very bizarre... 

    I'm having the same issue. My (large) Procedural RF SRB's can't have a burn time of 150s any more. I can set it in VAB but it gets reduced at launch.
    This worked in PP 1.2.9 on KSP 1.2.2 but after i updated to PP 1.2.11 (also KSP 1.2.2) it stopped working.
    It's VERY close resembling the non-RF SRB issue on GitHub so I'm reluctant to create a separate issue on this behalf. Should i?

    Note: I'm not using RealismOverhaul, just RF and PP

     

  3. 21 hours ago, Shadowmage said:

    Updated release is available:

    https://github.com/shadowmage45/KSPWheel/releases/tag/0.9.2.10

    Fixes FAR problems, a few ALG symmetry cleanups, drag-cubes on scaled wheels, new spring model, and a few other minor updates.  See the link for downloads and full change-log.

    Wow, Nice job man! Thx for the FAR effort! Much appreciated! Going to test it out ASAP

  4. 4 hours ago, Shadowmage said:

    In your main KSP directory there should be files like 'KSP.exe', KSP_x64.exe, Settings.cfg, etc. 

    One of those files should be KSP.log.  That is the log file that you want.

    Edit:  That is on Windows, using Steam.  Should be the same on other platforms, but if you are using Linux or Mac, others may have more precise information....

    Thanks mate :) That was incredibly stupid of me to miss that....

    Here ya' go

    https://www.dropbox.com/s/isfo2hx6uzyhvzd/KSP.log?dl=0

  5. 18 minutes ago, Shadowmage said:

    No worries :)  (Yea, its confusing to me even to figure out where to post news for wheel related stuff)

    Hopefully the log files point out what is going on with the FAR problems.  Really -shouldn't- be anything interfering, as for most intents and purposes these are quite 'simple' parts -- there is no model swapping, no model rebuilding, just simple standard parts with some extra physics attached (and the physics shouldn't be interfering, or else the stock wheels would break it; unless far has hard-coded special handling support for stock wheels, in which case the solution will have to be on FAR's end... (you shouldn't hard-code stuff like that...)).

    Forgive me for my ignorance, but how do I get the log when it doesn't crash?

  6. You could make a very simple program which displays all cfg files in /GameData/ and then you can distinguish between config cfg's and part cfg's. Then select your parts. A script then reads the word preceding the words: name = (which contains the part name) and appends it in a cfg file with some standard size values.. You could maybe add an option to choose between small, medium or big part. Unfortunately i don't have the time to make it :(

  7. First thing is to make sure it is RealChutes, by removing it, just to be sure it is that. Also make sure the fault is there all the way from a new start, just in case you have a broken savegame. Then, if you are sure it is RealChutes and not another mod or a broken save, you need to search this thread for Chris' many, many requests for more info (various logs) - note down the files he asks for, run the game, cause the fault, kill the game immediately and upload the logs to a file-sharing site and link to them on here.

    Sorry. I will do that.

    It's not crashing. Just black when i'm at the launchpad. I can navigate menu's etc.

    The problem doesn't occur when i mount the chute without editing it in the Action Group menu.

    I'll look in to some logs.. But again. there's no crash-log..?

  8. @Boamere: I have not been able to reproduce your issue using just KJR. I suspect it is another mod; uninstall them one by one until you find the issue. As KJR does not change the CoM of any parts under any circumstances, nor does it cause any exceptions during loading that could cause this issue, KJR is incapable of causing that issue. You will have to ensure that your mods are up-to-date and that you have followed all the instructions to the letter installing them / updating them. I cannot help you with this.

    @hippomormor: You probably have a ship with a very large number of stretchy tanks and decouplers. There was demand for super extra stiffening for stretchy tanks, and the lag in v1.7 is the result of the physics calculations necessary for that.

    Part of the g-force issues with the experimentals is the issues involved in starting up the simulation and the fact that DR doesn't wait a bit after loading before checking g-forces.

    That's correct! I use both DR and have a lot of stretchy tanks. The experimental works awesome though.. Except for the "killing my crew" part ;) Wouldn't this be fixable in collaboration with DR's maintainer?

    Thanks for a great mod! This mod is VITAL! :)

×
×
  • Create New...