Jump to content

4x4cheesecake

Members
  • Posts

    2,464
  • Joined

Posts posted by 4x4cheesecake

  1. 6 hours ago, R-T-B said:

    This is the best lead we  have, I think.  Were you able to return to "normal" after this bug out experience?

     

    6 hours ago, R-T-B said:

    EDIT:  Ok, so I can replicate this using the procedure posted by @4x4cheesecake

    once it happens too, I can't escape EXCEPT by going to main menu and returning to load the save from there.

    Does this help you?  Or not?  I don't really consider that an acceptable work around but maybe it's progress.

    In case this is still relevant: yes, I can get back a normal state after switching back to the main menu and also after entering and leaving a building like the VAB or SPH but the KSC still starts floating after reloading a savegame again.

    Glad to hear I was able to find a way for you to replicate the issue, I hope it may help to find a way to solve it or at least to find a viable workaround :)

     

  2. 1 hour ago, R-T-B said:

    If anyone else has ideas, feel free to chime in anytime.

    I dont have an idea but I was able to recreate the issue after noticing a minor detail in the logs: @SpaceInvader dont have any DLC installed and after removing them from my game, my KSC got burried under ground or started floating as soon as I reload any savegame.

    So these are the exact steps I took:

    -fresh install of KSP 1.11.1
    -installed kopernicus, MFI und MM through CKAN
    -removed the "SquadExpansion" directoy from my install
    -removed physics.cfg und settings.cfg (just becasue I dont know if they contain any presets for the DLCs)
    -launched the game and started a new career savegame
    -created a quicksave at the KSC
    -load the quicksave

    -> KSC is mostly underground, after another reload it was gone at all and after a third reload it was floating, exactly like in the screenshots of SpaceInvader.

    I have absolutely no idea how the DLCs are connected to this issue but maybe you can recreate the bug now and get an idea :)

  3. 2 minutes ago, HebaruSan said:

    Yes, bad metadata would qualify as a "bug report" when filed to the NetKAN repo.

    Okay, thank you. I'll file a bug report the next time :)

    3 minutes ago, HebaruSan said:

    Then again, I'm about to update it, so it'll probably be changed by the time you read this.

    Thank you for updating it as well :)

    Coming back from a long break, I'm glad to see this community being still as friendly and active as when I left :wub:

  4. Hi there :)

    I stumbled upon a minor metadata issue for the "Routine Mission Manager" mod: the provided homepage link directs you to the old forum thread, not the one after LGG adopted the mod.

    Usually, I would report this directly on github, but I'm kinda puzzled which category I should put this in. After following the link in the OT to report metadata issues, I still had to choose between "bug report", "fetature request" and "mod request" and IMO, this wouldn't fit in neither of these. Is there anything I'm missing or would this actually classify as a "bug report"?

  5. 42 minutes ago, R-T-B said:

    There'll be a hotfix for this shortly, thanks for the notice.  This only seems to be an issue with the 1.8.1 bundle which is how we missed it.

    EDIT:  I hotfixed it live, as well as fixed a CKAN versioning error.  Please redownload.  The issue was the System.cfg shipped with the wrong line endings, which changed the file hash and triggered a safety check.  Doh!

    Thanks for the quick fix :)

    As far as I can tell, it works fine now :)

  6. Unfortunately, release-27 failes to load in KSP 1.8.1. Tried updating through CKAN and manually installing the version found on github, always results in a massive exception spam. It happens in my highly modded JNSQ install:

    https://www.dropbox.com/s/easwjzjtmqug1ue/Player (kopernicus_issue).log?dl=0

    And also in a fresh copy of KSP with just kopernicus installed (github version, release-27, manually installed):

    https://www.dropbox.com/s/b429s3rdh9vr6gi/Player(kopernicus_issue_fresh_copy).log?dl=0

     

  7. 1 hour ago, Goaty1208 said:

    I haven't understood a thing: can ckan update mods from, I don't know, 1.7 to 1.10.1 also if the creator hasn't done any 1.10.1 version?

    Well, yes and no. CKAN doesn't update mods to another game version, this need to be done by a mod creator/maintainer. It is just a tool which simplifies the installation of mods to the game and it will always try to keep everything compatible to each other.

    But: You can always force CKAN to install every mod version to every game version you want. If you do this, you're always in the risk to break the game or at least the (probably incompatible) mod. I've described the process to do this in the "Advanced Stuff" section of the CKAN tutorial.

    Applied to the example in your question: You have to launch CKAN, pick your 1.10.1 install from the list of managed KSP instances (if you have more then one KSP instance installed and managed by CKAN). Then go to "settings" -> "compatible KSP versions" and select "1.7". This will allow CKAN to install mods which are not officially supported in 1.10.1 but 1.7.x. You can also select every other game version from 1.7 up to 1.10 to be sure, you'll always get the latest version of the mod.

    Alternative, if you don't want to allow EVERY 1.7.x mod to be available for your 1.10.1 game: In the CKAN main window, switch the filter from "compatible" to "all", search for the mod you want to install and select it.  Then, switch to the "version" tab on the right side of the window to see a list of all available mod versions. Select the mod version you want to install... CKAN will warn you about the incompatibility but also asks you, if you really want to install the mod. Select "install" and CKAN will install the mod for you, despite any incompatibilities.

    For example:

    QUOFuWB.png

  8. Check your difficulty settings for "Resource Transfer Obeys Crossfeed Rules":

    Spoiler

    GwMyGzi.png

    With this option enabled you are not able to transfer fuel through certain parts, mostly heatshields and constructural parts like this beam:

    Spoiler

    l3WyMfT.png

    You can disable/enable this option at any time but if you want to play with this option enabled, you can always bypass the crossfeed restriction by adding two fuel lines, one for each direction. For examples, it's not possible to transfer fuel between these tanks because of this option:

    Spoiler

    uFy7Kmx.png

    But after adding a fuel line for each direction to bypass the beam, it works just fine:

    Spoiler

    oHVeFEG.png

    (pay attention to the direction of the arrows on the fuel lines)

    If you add just one fuel line, the option to transfer fuel will only appear on one of both tanks but it will still not work because the game tries to move fuel from one tank to the other but also to move "nothing" (let's assume some kind of gas to keep the tanks pressurized) in the other direction. Since the fuel line only transfer in a single direction, you need the second one for the other way ;)

  9. Maybe DOE can help you:

    it will render planets, moons and vessels in the distance and show you their names once you hover the cursor above them. It doesn't work for the stars on the skybox though (as far as I know, KSP uses a "fantasy" skybox so they are no names for the stars)

  10. 2 hours ago, stk2008 said:

    The log is pretty clean for an install with that amount of mods, nothing really sticks out which would explain your issues. Did you monitor your RAM usage already? Planet packs usually add quite a bit to the RAM usage so maybe you just ran out of memory or you're close to it.

    Btw you can also try to remove just the planet pack but not kopernicus. If it loads fine, the reason is not kopernicus itself ;)

  11. 1 hour ago, stk2008 said:

    is there a way to disable the creation of colliders on these objects

    yes, you can add a MM patch to your game to disable it:

    @kopernicus:final
    {
    	@body,*
    	{
    		@pqs
    		{
    			@mods
    			{
    				@landcontrol
    				{
    					@scatters
    					{
    						@value,*
    						{
    							@components
    							{
    								!scattercolliders {}
    							}
    						}
    					}
    				}
    			}
    		}
    	}
    }

    Just create a textfile within your GameData folder, name it however you like and change the filename extension to .cfg. Then copy&paste the patch into it, save the file and restart the game.

    I personally like to add custom patches in a specific folder which is named like "zzz_Final" or something like that, to keep everything sorted.

  12. 10 minutes ago, stk2008 said:

    hi also sorry how come I still get this error in KSP version 1.8.1 using latest Kopernicus am I doing some thing wrong.

    It's not an error, it's a warning and nothing to be worried about. Kopernicus checks the surroundings in a certain distance for scatter object and if there are any, it will add a collider to them but once you are "out of range" of a scatter object, it removes the collider again. I guess this is supposed to reduce the RAM usage. These kind of log messages can be used by the mod creator to verify, this part of the mod is working properly.

    No idea what's happend when your game shows just a black screen but when it happens the next time, you may want to save a copy of the log file and upload it for others to look at.

  13. 33 minutes ago, Citizen247 said:

    Is there a way to only apply a patch if a variable is set to a value? Like if #$@MY_MODS_SETTINGS/USE_SETTING$ was set to true than certain patches should be applied, otherwise they're ignored? Like NEEDS but for variables?

    As far as I know, you cannot check for variables in other nodes to apply a patch to something different. I tried it and failed miserably but I did something like that for my own config for simple fuel switch by adding the value from the settings to the parts I wanted to modify and then checking for the value in the actual patch.
    For example:

    Config file:

    My_Mod_Settings
    {
    	change_this = true
    }

    1. Patch:

    //This must adress everything which may or may not be patched depending on the settings
    //Use multiple patches like this if you cannot adress everything in a single patch
    @PART[*]:HAS[whatever_it_is_you_want_to_adress]
    {
    	//Dummy Module
    	MODULE
        {
        	name = my_dummy
        	change_this = #$My_Mod_Settings/change_this$
        }
    	
    }

    2. Patch:

    //Actual patch to apply your changes
    @PART[*]:HAS[@MODULE[my_dummy]:HAS[#change_this[true]]]
    {
    	//do whatevery you want to do
    }

    3. Patch:

    //Cean up
    @PART[*]:HAS[@MODULE[my_dummy]]
    {
    	!MODULE[my_dummy] {}
    }

     

  14. Hm...that kinda looks like an issue within the mod itself to me. You installed everything properly, I can confirm that but there is a massive log spam of this line:

    Quote
    
    Fuel: 0.2071299, ISP: 288.6287, Thrust: 2.03125

    So it looks like the mod is stuck in a loop. I would suggest to report the issue to the mod creator in the wind tunnel thread (I just took a look at the thread and there are actually already a few reports about the same issue):

    Sorry I cannot help you any further but I'm crossing finger that the bug will be fix soon :)

  15. 4 hours ago, arthur106 said:

    I sure didn't.  That would be a problem.
    So now I'm going to look really stupid, but how do I install it?  I see there's two files and a folder with more files on the GitHub, but I'm not really sure where these go once downloaded.

    I just noticed that the mod already includes the dependency, sorry I should have checked that before. You can ignore the other github repo I've linked before.

    I've also tried the mod on my own to verify that it actually works and it does.... be sure that your GameData folder looks like this:

    Spoiler

    h7EPvkZ.png

    (I didn't install AVP since it is just visuals)

    If you are sure you installed everything properly but the issue still persists, please launch the game, try to use the mod, close the game and then upload a log file to a filehoster or cloud service to share a download link here :) Check out the thread I've linked earlier if you don't know where the log file is located.

  16. 2 hours ago, HyperStorm said:

    What the hell do i wrong?

    You forgot the most important dependency for every planet mod:

    Quote

    DEPENDENCE!

    Kopernicus

    - ModuleManager

    Install Kopernicus (and the bundled ModularFlightIntegrator) as well and it should work :)

    By the way, the version of RSS on CurseForge and the linked ModuleManager version are for KSP 1.4.5, you may want to checkout the latest version of this RSS iteration:

    Same for Kopernicus:

    https://github.com/Kopernicus/Kopernicus/releases/tag/release-1.8.1-1

  17. 1 hour ago, Muddyblack said:

    One Problem i could imagine, is that the center of lift is not at line with the center of mass but I am still a noob in planes. I started 4 days ago to build planes xD.

    They are indeed pretty far away from each other but it may work out fine anyway. The reason you are not able to take off is a different though: The gear in the rear need to be between the center of lift and the center of mass. The elevons on the wings will not pull up your nose but they will push down your rear and as soon as your center of lift is behind the rear gears, this will actually lift your nose up. So move the gears a little bit forward and you should be fine.

    Well, you can also add some more elevons/winglets to your nose though but I would suggest to move the gears instead ;)

  18. Have you already tried if the other docking port still offers an "undock" option? Sometimes, when you have to switch the focus after undocking, the undocked craft will re-dock to the other craft and the "undock" option is usually just available for one of the ports.

    Well, if you are unlucky though, your craft might be corrupted. There are some rare cases, where KSP doesn't "cut off" the connection between two vessels properly and they stay connected after undocking. Do you have a savegame before you tried to undock the craft? If you actually run into this issue, it should be visible in the log at the exact moment you try to undock so that should be easy to find if you can reload a savegame, try to undock again and then upload the log file here for us. If you don't know anything about the KSP log files, take a look at this thread an read the section about logs, that should allow you to find them:

     

  19. It works in the tutorial because it still uses the old flea engine instead of the updated one. I'm not sure if the new one is supposed to be better but using the new version will allow the vessel to gain additional ~11km height (23km vs 12km) while flying straight up. This causes your vessel to accelerate more while falling back towards the ground and therefore your chute will not open.

×
×
  • Create New...