Jump to content

Sigma88

Members
 View Profile  See their activity

  • Posts

    4,252

  • Joined

  • Last visited

 Content Type 

Everything posted by Sigma88

  1. Sigma88
    what you explained is mostly correct, not sure if the order is culture specific or not except that when there were multiple pass specifiers, mm didn't just "pick one". MM went through all mods BEFORE/FOR/AFTER, and as soon as a patch matched that pass specifier it was applied once applied a patch was removed from the list of patches to make sure the same patch wasn't applied twice
  2. Sigma88
    this is not true in the past it used to apply the patch at the first valid pass definition this is a new requirement introduced by 3.0.0 still, there is little use for multiple pass specifiers so they were rarely used for a purpose. it was more a result of misunderstanding of how MM works or lazyness while updating cfgs
  3. Sigma88
    yes as far as I know that's the only difference between the old MM and the new one. still, a quick report to the developers can save them a lot of time testing their mods (expecially if they have a lot of them) make sure you make a clean bug report so that the developer doesn't have to waste more time trying to understand your problem that what it would take to look for the bug without reports here's a guide on how to report, just in case
  4. Sigma88
    if you report these errors to the devs of the respective mods it might help speeding up the process
  5. Sigma88
    that's my fault, I updated GN to use OPM_Galileo but I haven't update the links. from GN v0.4.6 the version of OPM you need to use is the one from galileo88 this is because I don't provide compatibility for GPP_Secondary when installing GPP for GN just install the GPP folder from the main archive and the GPP_Textures folder from the textures archive all the extra stuff is not supported on GN for the sake of my mental sanity
  6. Sigma88
    Those pass specifiers tell mm when to apply the patch If everybody uses after[kopernicus] all patches will apply at a certain point and compatibility mods will have an hard time get in between patches of different planet packs
  7. Sigma88
    a small suggestion since the number of planet pack is growing ever more, it might be a good idea to apply your patches at a specific pass specifier like :FOR[OtherWorlds] instead of using :AFTER[Kopernicus]
  8. Sigma88
    you have a body without name that's bad nothing to do with SD or Rescale!
  9. Sigma88
    If you click the nyan cat in my sig you will find the instructions on how to make a complete bug report
  10. Sigma88
    I don't think so, if you want to stick with older version of SB you will need to use the versions of Kopernicus that were relevant at the time sorry :|
  11. Sigma88
    this has nothing to do with SD tho, so it's out of my hands this depends on what kind of features the new kopernicus introduces. when updating any mods, the best thing is to backup your saves regardless, just be on the safe side
  12. Sigma88
    I have experienced the floaded KSC in stock as well, I have no ideas what causes it, I guess it's just a matter of something going bad during the loading process of the scene which is made worst by having a lot of heavy mods installed or, like in my case, by using a potato-powered computer
  13. Sigma88
    I guess this would be more in topic over here:
  14. Sigma88
    any modifications you want to save with KK has to be saved without SD installed then add SD and everything should be in the right place
  15. Sigma88
    Nevermind
  16. Sigma88
    The most likely cause is KSS having cfgs written in a way that breaks MM patches. This has already been reported in the past so I don't know if that issue specifically has been solved. The devs should look through their cfgs for type-less nodes. That's what has caused issues in the past
  17. Sigma88
    @Fergrim as long as the cfgs are written properly it should work, but KSS has already caused problems in the past for having errors in its cfgs so I can't vouch for that. GN on the other hand should work properly, if it doesn't click the nyan cat in my sig and follow the instructions
  18. Sigma88
  19. Sigma88
    @Fergrim the only valid SigmaDimensions node is the one provided inside the Settings.cfg And it loads first Then all patches (cfgs with @SigmaDimensions) are applied to it by MM and will likely change the settings. Once MM is done, SD will rescale the system using whatever parameters ended up in the settings node Regarding GN it should work with SD. I'll double check when I have some time
  20. Sigma88
    GN is fully compatible with SD in fact, SD is required if you want to play with RSS in the GN if you are having any trouble you can always ask for help in the GN thread or in the SD thread, I've never refused support for any of my mods generally speaking, SD will work with any planet pack which is written properly. as long as the things you ask SD to do make sense
  21. Sigma88
    I think that's already a very good choice!
  22. Sigma88
    @Citizen247 I released a new version of SD, it contains changes to how statics are replaced hopefully, this new approach should give a better result let me know if you are still having issues
  23. Sigma88
    I worked on the assumption that there would only be one IFI_Tech at any given time, but yes, using the ,* would probably be recommended but this still wouldn't solve the "delete only when others are present" problem
  24. Sigma88
    the better strategy will of course change with the situation for example, you could just delete the IFI_Tech in the cfg that adds IFI_Extreme/IFI_Improved/IFI_Advanced
  25. Sigma88
    or you could just delete it 3 times @PART:HAS[@MODULE[IFI_Extreme]]:FINAL { !IFI_Tech = none } @PART:HAS[@MODULE[IFI_Improved]]:FINAL { !IFI_Tech = none } @PART:HAS[@MODULE[IFI_Advanced]]:FINAL { !IFI_Tech = none }
×
×
  • Create New...