SpacedInvader
-
Posts
1,168 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by SpacedInvader
-
-
On 7/30/2023 at 7:35 AM, linuxgurugamer said:
I'd like to hear from the RealFuels people before doing any work on this, since the exception is in the RF code
The issue was resolved on the RF side by a patch, so hopefully that's the end of it.
-
On 8/2/2023 at 12:04 PM, Starwaster said:
[Snip]
Thanks for this, sounds like I may have experienced the issue so I'll throw this in my custom folder for good measure.
-
11 hours ago, Starwaster said:
That second item is something you will probably never notice if you only deal with cryogenic resources for launch and not long term storage, such as ISRU or cryo depots. If you play with either of those then you may have noticed that over time you built up more heat than you could easily get rid of.
I have tried using hydrolox to fuel Duna missions in the past and things didn't really go so well because I couldn't really prevent boiloff, though IDK if it had anything to do with this specific issue or just failing to properly account for it. Is there an easy(ish) way to test this? Seems like at the very least, if it really is going to be an issue for me, it can be quashed with a MM patch, but I'd like to be sure its needed for my applications.
-
That's fair, though according to Starwaster (who doesn't actually participate in RF development anymore), the RF team may not even the forums anymore and suggested posting it to the github issues or the RO discord and I'll have to look into doing one or the other.
EDIT: Have posted this to the RF github page, so hopefully it catches their attention.
-
1 hour ago, Starwaster said:
@SpacedInvader I'll take a poke at it and see if I can find out what's happening, but I have to warn you, I'm not involved with Real Fuels development anymore and only use my own branch for gameplay.
I'll have to install the current official branch and the other mods you mentioned. I can do that, but you might have better luck going into the Realism Overhaul discord channel and bugging them about it directly. I don't know if they even monitor these forums anymore. You could try making an issue on the github repository page but I don't think they really look at those anymore either. They definitely don't care about the last issue I raised.
I see... I mean, if you're not really involved anymore, then I'd say don't worry about it too much. As I mentioned before, the only reason I pinged you was because you were the only person I knew to have worked on RF (at least at some point in the past) who had been active here for a while. There's also the fact that since I posted this, I've decided not to use the info mod because now that I've finally got a chance to test it without it breaking my game, I've found it doesn't actually work for most non-squad experiments. So if you want to put in the effort to track down the issue, its mostly to try to fix it for the sake of fixing it or if it ever comes up again. Since LGG is responsible for the other two parts of the interaction, he may be able to fix it on his end if its important.
That all said, what's different about your branch compared to the official? Looks like its been several years since your branch has been updated based on the github info?
-
@linuxgurugamer Sorry for the ping, but this one is sorta nasty and now that I've got it figured out I wanted to make sure its on your radar. Have also posted this on the Real Fuels thread, but I'm not sure how active they are these days.
Anyway the issue is that there is a rather nasty 3-way interaction between Real Fuels, Extended information about scientific experiments in VAB & SPH, and Rover Science Continued, or potentially their associated dependencies.
To replicate, have the following installed (also to be clear, except for BG, everything on this list is a dependency for at least one of the three primary mods):
Breaking Ground (BreakingGround-DLC 1.7.1)
ClickThrough Blocker (ClickThroughBlocker 1:2.1.10.21)
Community Resource Pack (CommunityResourcePack v112.0.1)
Extended information about scientific experiments in VAB (ScienceSituationInfo 1:1.3.5)
Module Manager (ModuleManager 4.2.3)
Real Fuels (RealFuels 1:v15.6.2.0)
RealFuels-Stock (RealFuels-Stock v5.1.0)
Rover Science Continued (RoverScienceCont 2.3.5.7)
Solver Engines plugin (SolverEngines v3.14.0)
SpaceTux Library (SpaceTuxLibrary 0.0.8.5)
Toolbar Controller (ToolbarController 1:0.1.9.11)Start / Open a game, and then enter the VAB or SPH. After this, the following NRE will begin repeating endlessly until you exit out to the main menu and has resulted in 300MB+ log files before I realized what was going on:
[LOG 02:16:41.719] [RealFuelsFilters] Updated info boxes [EXC 02:16:41.720] NullReferenceException: Object reference not set to an instance of an object RealFuels.ModuleShowInfoUpdater.Update () (at <f43ec557c13d4aa9907800f6eb365ca2>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
The bug requires all three mods to be installed and any two of them can coexist without issue.
Here are the logs from the minimal install: Logs
EDIT: Not going to cross-post this to both of your mod threads since I don't think you need to be double notified
EDIT2: For the time being I've just uninstalled EISE since it doesn't seem to work on most non-squad experiments, so if this isn't really high on your list, don't feel like I'm adding any pressure to fix it, just wanted you to know the issue existed.
-
@Starwaster Sorry for the ping, but 1: IDK who else to ping about this for RF these days, and 2: this one is sorta nasty and now that I've got it figured out I wanted to make sure someone actually looks at it. Will also be pinging LGG on his thread because the three-way issue involves two of his mods and this one.
In regards to the above issue, it turns out that its a 3-way interaction between Real Fuels, Extended information about scientific experiments in VAB & SPH, and Rover Science Continued, or potentially their associated dependencies. To replicate, have the following installed (also to be clear, except for BG, everything on this list is a dependency for at least one of the three primary mods):
Breaking Ground (BreakingGround-DLC 1.7.1)
ClickThrough Blocker (ClickThroughBlocker 1:2.1.10.21)
Community Resource Pack (CommunityResourcePack v112.0.1)
Extended information about scientific experiments in VAB (ScienceSituationInfo 1:1.3.5)
Module Manager (ModuleManager 4.2.3)
Real Fuels (RealFuels 1:v15.6.2.0)
RealFuels-Stock (RealFuels-Stock v5.1.0)
Rover Science Continued (RoverScienceCont 2.3.5.7)
Solver Engines plugin (SolverEngines v3.14.0)
SpaceTux Library (SpaceTuxLibrary 0.0.8.5)
Toolbar Controller (ToolbarController 1:0.1.9.11)Start / Open a game, and then enter the VAB or SPH. After this, the following NRE will begin repeating endlessly until you exit out to the main menu and has resulted in 300MB+ log files before I realized what was going on:
[LOG 02:16:41.719] [RealFuelsFilters] Updated info boxes [EXC 02:16:41.720] NullReferenceException: Object reference not set to an instance of an object RealFuels.ModuleShowInfoUpdater.Update () (at <f43ec557c13d4aa9907800f6eb365ca2>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
The bug requires all three mods to be installed and any two of them can coexist without issue.
Here are the logs from the minimal install: Logs
-
Recently I've been getting literally hundreds of thousands of the following in my KSP.log after entering either the VAB or SPH:
[LOG 02:34:26.917] [RealFuelsFilters] Updated info boxes [EXC 02:34:26.969] NullReferenceException: Object reference not set to an instance of an object RealFuels.ModuleShowInfoUpdater.Update () (at <c6afe99770794e0f8e6d2c11be87d511>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
And then this in the Player.log:
[RealFuelsFilters] Updated info boxes (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) NullReferenceException: Object reference not set to an instance of an object at RealFuels.ModuleShowInfoUpdater.Update () [0x00068] in <c6afe99770794e0f8e6d2c11be87d511>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) (Filename: <c6afe99770794e0f8e6d2c11be87d511> Line: 0)
This does not happen in a minimal install, so there's clearly a mod conflict going on. I am currently trying to zero in on the culprit, but its going to take me a while as I've got 250ish mods and that means a lot of time sitting on the game loading screen. In the meantime, I'm hoping someone here will be able to clue me in to what this function does and why it might be getting called hundreds of thousands of times as that might help me narrow down the source of the issue more quickly.
I'm also going to include my KSP / Player log files (zipped because even with just a quick pop-in and out, they are 40Mb each) from the full install until I can narrow it down. I know its not optimal, but if anyone is willing to have a look at them in the meantime they might be able to find the offender where I could not.
Some things to note about the issue in case anyone has any ideas:
- It starts as soon as I enter either the VAB or the SPH without requiring a part to be selected.
- Once it starts, it does not stop (at least for the several minutes I waited here) whether I move to the flight scene or exit out to the space center.
- Searching for the error returned exactly one result reported in the RealFuels-Stock thread about a year ago, but that never saw any resolution.
Hoping someone has an idea of what might be going on and in the meantime, I'll be reloading the game a whole lot of times trying to narrow down the possible list of culprits.
EDIT: Not much luck so far... Its looking like a combination of mods (or at least one that wasn't in the install at the same time as some needed dependency while I was testing) as I've gone through the entire folder pulling mods and restarting and can only replicate it when everything is installed still. Still hoping someone familiar with RF's inner workings can give me some guidance on what the NRE means and what could be causing it to run into the hundreds of thousands like that.
EDIT2: Still working on narrowing the issue down. Have found that at least one component of the problem is related to the mod Extended information about scientific experiments in VAB & SPH, but there is still another component to the issue as a minimal install with only Real Fuels, its dependencies, and the extended info mod still does not produce the endless NREs.
-
1 hour ago, Boris-Barboris said:
Hello! No, unfortunately it was not done.
Ok, thanks for the quick reply!
-
On 2/12/2016 at 12:01 PM, Boris-Barboris said:
Will do in next release, if i will find ergonomic way to.
Was this option ever added, and if so, how can I access it? Have been looking through the buttons and config file, but can't seem to find any way to switch from the main toolbar to Blizzy's where I keep all of my "mission critical" buttons.
-
Is there a guide (preferably video) or wiki on how to use these parts correctly? I've been fiddling around with them for about 3 hours now trying to make an aircraft and, while I feel like I'm making progress, it also feels like I'm beating my head against a wall trying to make things work because I don't really know what I'm doing. I've spent some time searching through this thread and online for some sort of guide and come up with nothing, so I'm hoping that my google-fu is just failing me and there is some sort of guide or reference that I'm just not finding.EDIT: To clarify, I get how to manipulate the various parts to make shapes, but am having trouble with details like getting control surfaces to fit properly with the wings etc.EDIT: Nevermind, have since brute forced my way through figuring it out.
-
On 7/13/2023 at 6:16 PM, AlphaMensae said:
Ok, posted v2.6.1 on Spacedock and GitHub. I removed a lot of colliders from the hold-downs, leaving just a reduced-size one on the base/mount of the smaller ones. Anything that had an arm in it had the arm collider removed or shrunk in size.
Worked like a charm... Am able to basically stuff the supports all the way up into the cowling if I want to with no ill effects, thanks for the quick update.
-
Have both Space Dust and Cacteye installed and was wanting to have access to the original Space Dust telescope model which gets overwritten by this mod, so I wrote up a patch to split the versions so that they can coexist. Thought I'd post it here in case anyone else wanted to use it. Also, I was having issues with the Cacteye telescope tubes duplicating endlessly in the tech tree and this might fix that issue (my guess is that this was the result of two parts with the same name getting created at every game load), but I can't be sure until I test it for a while on my main save.
Spoiler//Delete the old parts to prevent duplication !PART[spacedust-telescope-1]{} !PART[spacedust-telescope-1-small]{} //Recreate Space Dust Telescope PART { name = spacedust-telescope module = Part author = Chris Adderley (Nertea) rescaleFactor = 1 MODEL { model = SpaceDust/Parts/Scanning/spacedust-telescope-1 } scale = 1 node_attach = 0.0, 0.0, -1.254, 0.0, 0.0, 1, 1 node_stack_bottom = 0.0, 0.0, -1.254, 0.0, 0.0, -1, 1 TechRequired = advScienceTech entryCost = 52000 cost = 25000 category = Science subcategory = 0 title = #LOC_SpaceDust_spacedust-telescope-1_title manufacturer = #LOC_SpaceDust_manufacturer_postkerbin description = #LOC_SpaceDust_spacedust-telescope-1_description attachRules =1,1,1,1,0 mass = 3 dragModelType = default maximum_drag = 0.25 minimum_drag = 0.25 angularDrag = .5 crashTolerance = 8 breakingForce = 200 breakingTorque = 200 maxTemp = 1500 bulkheadProfiles = srf, size1p5 tags = #LOC_SpaceDust_spacedust-telescope-1_tags MODULE { name = ModuleSpaceDustTelescope // Power cost per second when scanning PowerCost = 12 // Animation ScanAnimationName = OpenDoor // Size of the lens/mirror, for calcuations ObjectiveSize = 1.8 // FOV (radians) FieldOfView = 0.000969627362992369 SLOT { name = slot1 Instrument = None } SLOT { name = slot2 Instrument = None } } MODULE { name = ModuleB9PartSwitch moduleID = instrumentSlot1 switcherDescription = #LOC_SpaceDust_switcher_instrument_slot1_title SUBTYPE { name = None title = #LOC_SpaceDust_switcher_instrument_none descriptionSummary = #LOC_SpaceDust_switcher_instrument_none_summary descriptionDetail = #LOC_SpaceDust_switcher_instrument_none_detail primaryColor = #111111 secondaryColor = #111111 addedMass = 0 addedCost = 0 MODULE { IDENTIFIER { name = ModuleSpaceDustTelescope } DATA { SLOT { name = slot1 Instrument = None } } } } // SUBTYPE { name = XeInstrument title = #LOC_SpaceDust_switcher_instrument_xe descriptionSummary = #LOC_SpaceDust_switcher_instrument_xe_summary descriptionDetail = #LOC_SpaceDust_switcher_instrument_xe_detail primaryColor = #60a7be secondaryColor = #60a7be addedMass = 0.2 addedCost = 50000 MODULE { IDENTIFIER { name = ModuleSpaceDustTelescope } DATA { SLOT { name = slot1 Instrument = XenonSpectrometer } } } } SUBTYPE { name = OxInstrument title = #LOC_SpaceDust_switcher_instrument_ox descriptionSummary = #LOC_SpaceDust_switcher_instrument_ox_summary descriptionDetail = #LOC_SpaceDust_switcher_instrument_ox_detail primaryColor = #3399cc secondaryColor = #3399cc addedMass = 0.2 addedCost = 50000 MODULE { IDENTIFIER { name = ModuleSpaceDustTelescope } DATA { SLOT { name = slot1 Instrument = OxidizerSpectrometer } } } } SUBTYPE { name = LFInstrument title = #LOC_SpaceDust_switcher_instrument_lf descriptionSummary = #LOC_SpaceDust_switcher_instrument_lf_summary descriptionDetail = #LOC_SpaceDust_switcher_instrument_lf_detail primaryColor = #3399cc secondaryColor = #3399cc addedMass = 0.2 addedCost = 50000 MODULE { IDENTIFIER { name = ModuleSpaceDustTelescope } DATA { SLOT { name = slot1 Instrument = LiquidFuelSpectrometer } } } } } MODULE { name = ModuleB9PartSwitch moduleID = instrumentSlot2 switcherDescription = #LOC_SpaceDust_switcher_instrument_slot2_title SUBTYPE { name = None title = #LOC_SpaceDust_switcher_instrument_none descriptionSummary = #LOC_SpaceDust_switcher_instrument_none_summary descriptionDetail = #LOC_SpaceDust_switcher_instrument_none_detail primaryColor = #111111 secondaryColor = #111111 addedMass = 0 addedCost = 0 MODULE { IDENTIFIER { name = ModuleSpaceDustTelescope } DATA { SLOT { name = slot2 Instrument = None } } } } // SUBTYPE { name = XeInstrument title = #LOC_SpaceDust_switcher_instrument_xe descriptionSummary = #LOC_SpaceDust_switcher_instrument_xe_summary descriptionDetail = #LOC_SpaceDust_switcher_instrument_xe_detail primaryColor = #60a7be secondaryColor = #60a7be addedMass = 0.2 addedCost = 50000 MODULE { IDENTIFIER { name = ModuleSpaceDustTelescope } DATA { SLOT { name = slot2 Instrument = XenonSpectrometer } } } } SUBTYPE { name = OxInstrument title = #LOC_SpaceDust_switcher_instrument_ox descriptionSummary = #LOC_SpaceDust_switcher_instrument_ox_summary descriptionDetail = #LOC_SpaceDust_switcher_instrument_ox_detail primaryColor = #3399cc secondaryColor = #3399cc addedMass = 0.2 addedCost = 50000 MODULE { IDENTIFIER { name = ModuleSpaceDustTelescope } DATA { SLOT { name = slot2 Instrument = OxidizerSpectrometer } } } } SUBTYPE { name = LFInstrument title = #LOC_SpaceDust_switcher_instrument_lf descriptionSummary = #LOC_SpaceDust_switcher_instrument_lf_summary descriptionDetail = #LOC_SpaceDust_switcher_instrument_lf_detail primaryColor = #3399cc secondaryColor = #3399cc addedMass = 0.2 addedCost = 50000 MODULE { IDENTIFIER { name = ModuleSpaceDustTelescope } DATA { SLOT { name = slot2 Instrument = LiquidFuelSpectrometer } } } } } } //Create large Cacteye telescope version PART { name = cacteye-spacedust-telescope module = Part author = Chris Adderley (Nertea) rescaleFactor = 1 MODEL { model = CactEye/Parts/SpaceDust/Scanning/spacedust-telescope-1 scale = 1.25, 1.25, 1.25 } scale = 1 node_attach = 0.0, 0.0, -1.5675, 0.0, 0.0, 1, 2 node_stack_bottom = 0.0, 0.0, -1.5675, 0.0, 0.0, -1, 2 TechRequired = largeElectrics // advScienceTech entryCost = 52000 cost = 25000 category = Science subcategory = 0 title = CactEye Telescope Optical Tube manufacturer = CactEye Optics description = Originally developed by an overseas agency as a wind analysis satellite, we swapped a few sensors to make a small telescope. This telescope will not allow much science return, but it is useful as an easy way to increase the rate at which near-Kerbin asteroids are found.\nThis is the main part of the telescope. Attach a service bay directly underneath this piece with necessary modules inside. attachRules =1,1,1,1,0 mass = 3 dragModelType = default maximum_drag = 0.25 minimum_drag = 0.25 angularDrag = .5 crashTolerance = 8 breakingForce = 200 breakingTorque = 200 maxTemp = 1500 bulkheadProfiles = srf, size1p5 tags = #LOC_SpaceDust_spacedust-telescope-1_tags MODULE { name = ModuleAnimateGeneric animationName = OpenDoor startEventGUIName = Open Bay endEventGUIName = Close Bay actionGUIName = Toggle Bay evaDistance = 1.85 } MODULE { name = CactEyeOptics isSmallOptics = false scienceMultiplier = 1.0 CameraTransformName = GameObject CameraPartOwner = CactEye cameraForward = 0, 0, 1 cameraUp = 0, 1, 0 cameraPosition = 0,0,1 } MODULE { name = ModuleTestSubject situationMask = 32 useStaging = False useEvent = True } } //Create small Cacteye telescope version PART { name = cacteye-spacedust-telescope-small module = Part author = Chris Adderley (Nertea) rescaleFactor = 1 MODEL { model = CactEye/Parts/SpaceDust/Scanning/spacedust-telescope-1 scale = 0.66, 0.66, 0.66 } scale = 1 node_attach = 0.0, 0.0, -0.82764, 0.0, 0.0, 1, 1 node_stack_bottom = 0.0, 0.0, -0.82764, 0.0, 0.0, -1, 1 TechRequired = spaceExploration //advScienceTech entryCost = 52000 cost = 25000 category = Science subcategory = 0 title = CactEye Telescope small Optical Tube manufacturer = CactEye Optics description = Originally developed by an overseas agency as a wind analysis satellite, we swapped a few sensors to make a small telescope. This telescope will not allow much science return, but it is useful as an easy way to increase the rate at which near-Kerbin asteroids are found.\nThis is the main part of the small telescope. Attach a service bay directly underneath this piece with necessary modules inside. attachRules =1,1,1,1,0 mass = 1.5 dragModelType = default maximum_drag = 0.25 minimum_drag = 0.25 angularDrag = .5 crashTolerance = 8 breakingForce = 200 breakingTorque = 200 maxTemp = 1500 bulkheadProfiles = srf, size1p5 tags = CactEye telescope optics science aperture MODULE { name = ModuleAnimateGeneric animationName = OpenDoor startEventGUIName = Open Bay endEventGUIName = Close Bay actionGUIName = Toggle Bay evaDistance = 1.85 } MODULE { name = CactEyeOptics isSmallOptics = false scienceMultiplier = 0.5 CameraTransformName = GameObject CameraPartOwner = CactEye cameraForward = 0, 0, 1 cameraUp = 0, 1, 0 cameraPosition = 0,0,1 } MODULE { name = ModuleTestSubject situationMask = 32 useStaging = False useEvent = True } } -
29 minutes ago, AlphaMensae said:
A great tool to use is Collide-O-Scope, which lets you see the actual colliders of a part in the Unity colors: Blue for mesh colliders, yellow for box, green for cylinder and red for sphere.
I'll give this a try, can think of some other areas where this could be pretty useful, thanks.
31 minutes ago, AlphaMensae said:I also should remove most of the colliders from the hold-downs, leaving just the one on the base pad. I had already reduced the size on the bolt types, but didn't go far enough.
This seems like it would fix the problem with pretty much all engines and allow for an easier time fitting the bolts in, especially for multi-engine setups.
-
1 hour ago, AlphaMensae said:
Some engines, like the stock Reliant, have a simple cylinder collider the same width as a 1.25m tank, so it can be a problem if the bolt is too close. The end of the bolt hold-down with the bolt itself and any kind of mount doesn't have a collider to help out.
I think this is likely what's been going on for me. I use mostly modded / ReStock engines so I'm guessing they might not all have tightly conforming collision meshes. Here's an example of my most recent attempt to use them:
That lip seemed like a good place to put them, but caused the issue. I also tried it on the lower cowling and it still gave me issues. Would this be an example of an engine that just isn't going to work with the bolts, or would maybe another one of the options work instead?
-
Could someone give me some guidance on how to use the bolt style hold downs properly? I don't know exactly where to situate them and every time I try to use them, the vehicle catches on them and immediately skews a little to one side before straightening out. I'm sure its because I'm placing them in the wrong place since this doesn't happen at all with the fall away arm style, but it seems that no matter where I put them, if they are even close to touching the rocket, it'll cause things to go sideways, literally.
-
On 8/10/2022 at 1:20 PM, papste said:
@linuxgurugamer
No change when I delete the @thumps folder
I know its been almost a year, but were you ever able to find a solution for this? All of the SAS modules from this mod are just grey models without textures for me even though it appears the textures are loading properly and without errors.So I've resolved the issue. It turns out there was the following error showing up in the log:
[ERR 02:15:21.828] PartCompiler: Cannot replace texture as cannot find texture 'SAS_PrimaryMat_high_BaseColor' to replace
Upon inspecting the part config and the assets folder, it looks like its calling what's supposed to be a base texture of some sort and then replacing it with the PNG texture in that folder, but the base texture is apparently missing so the game was erroring out and failing to replace the texture as requested. To resolve this, I just copied a DDS file at random from the same folder and renamed it to 'SAS_PrimaryMat_high_BaseColor.dds' which gave the part a texture for the game to replace and now I have properly textured SAS wheels. As far as I can tell, there doesn't seem to be any issue from using just a random DDS for this, but just in case, if you're still watching this thread at all RoverDude (don't want to ping as its not really a huge issue and I've found an apparent solution that anyone can do), you may want to release a hotfix with the "proper" 'SAS_PrimaryMat_high_BaseColor.dds' file included.
-
On 6/13/2022 at 2:24 PM, VelRahnKoon said:
I found the root cause of the issue with the missing textures! I was looking through my player.log file and found this line:
Texture 'UmbraSpaceIndustries/ExpPack/PackRat/Assets/model000' not found!
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)I opened the 1.4.0.0 build and copied (
the model.mu anddon't need it, works without) the model000.dds into the directory above and the texture loads properly!I'm not a programmer by any stretch, so I have no idea how to fix this properly or even how to go about locating what file is calling for the model000 file. Anyone have any ideas so we can submit a pull request?
I know its been a year, but this solved the issue for me and wanted to say thanks. Seems like KSP doesn't like the way the seat texture was supposed to be loaded and wouldn't accept the non-standard name for it.
-
7 hours ago, Lisias said:
Hi!
In order to get TweakScale to scale something, we need some requirements fulfilled:
-
A patch adding a TweakScale module to a part
- respecting the bulkhead profile, the part's "behaviour" et all
- Having TweakScale Exponents for every PartModule the part uses.
The problem you described happens because Kopernicus used to use a specialised PartModule for the solar panels, as now you can have multiple sources of light (Stock only knows how to handle one). But since Kopernicus usually patches the existent parts replacing the Stock PartModule with its own, then by just adding the new Exponent things used to just works.
However, since some time Kopernicus is being heavily changed using Harmony, and now Kraken knows what is being changed inside KSP itself - so I'm unsure if I can really help.
What I can say for sure is that TweakScale (the main distribution) only Supports Stock and DLCs, and this is not going to change. What it can be done is adding Kopernicus support by a TweakScale Companion. This way, only Kopernicus users would be risking their SASes on unorthodox patching and I don't risk screwing up everybody else.
In a way or another, https://github.com/TweakScale/Companion/issues/27
I expect to have time for modding again next month (hopefully).
Makes sense then why my attempt at a patch failed miserably... Kopernicus does the KSP equivalent of rewriting the laws of physics to make itself work, which is a lot more involved than I'd originally thought. It also makes sense that this would necessarily be a companion mod rather than trying to put the compatibility into the main branch. I'll keep an eye on the github issue in the hopes that you'll figure out a way to make it work, and in the meantime I guess I need to go looking for some more solar panel options. Thanks for the reply.
-
A patch adding a TweakScale module to a part
-
5 hours ago, Starwaster said:
When useRealisticMass is set to false, engines are scaled 4x and tanks are scaled 4.8x. If set to true then the part's configured mass is used as is.
There is an implicit assumption there that engines are scaled realistically already and if useRealisticMass = true then don't touch engine/tank masses. It also assumes that they are set to 1/4th of what they would be in stock, so the simple answer to your question would be that if you're using a stock Kerbol star system then the setting should be set to false. A realistically scaled star system (Real Solar System, Kerbin 10x, JNSQ) should have the setting at true.
BUT. (caveat time) This mod, while having scaled down engine masses, does not necessarily have engine masses at 1/4th of their stock sizes. For instance, MassiveBooster (I think that's the shuttle SRB styled one...) has a stock mass of 4. But this mod sets it to to 2.4. If you set useRealisticMass = false then you're going to end up with a booster that is 9.6 tons. YOU DO NOT WANT THAT. That's more than double the stock mass for that part. I'm not sure of the relevant config file's history, maybe the ratio between mod and stock used to be different. But I would set useReaiisticMass = true to avoid unnecessary headaches.What I ended up doing was setting it to false for the engines (RFSettings) and true for the the tanks (MFSSettings) as the latter led to some truly ridiculous values (~30 tons dry for a 20mx1.25m procedural tank). That said, I'm starting to have some second thoughts about even setting the engines to false as I've noticed some of what you've mentioned already as I've progressed through the tech tree in my career save with various engines being poor performing outliers because of their mass. Knowing that there are more issues to be had further down the line makes me think it might be better to start over and just deal with the fact that my rockets aren't going to be very big. I guess the worst case scenario is that I could add some structural segments to make things look better...
-
On 4/23/2019 at 10:21 AM, Lisias said:
You probably right, I don't play kopernicus often, and I missed this one .
A patch should be trivia. Hopefully.
i will update my task list when in home.
I'm curious if this patch ever made it into TweakScale? I'm getting this same behavior (up-scaled solar panels do not produce up-scaled power) in my test install with just TweakScale (2.4.7.1 installed manually from Github along with Recall 0.4.0.1 and UberPaket 2023.3.28.4 just for good measure) and Other Worlds + Kopernicus (installed through CKAN). After looking through the MM config cache, it appears to be the same issue described by Tonas1997 where TS is targeting the vanilla module, but OW/Kopernicus have replaced it with "KopernicusSolarPanel", so TS doesn't actually update the power module.
Including logs + MM cache: Logs
EDIT: Doing a sanity search for "KopernicusSolarPanel" in CFG files within the test install's GameData folder shows that TweakScale makes no reference to this module, so I'm guessing the answer to my question is "no". This prompts me to ask, would a custom CFG file with this fix this issue?
TWEAKSCALEEXPONENTS { name = KopernicusSolarPanel chargeRate = 2 temperatureEfficCurve = 2 }Thanks
EDIT2: So I've tried to use the above code both in a custom config file, and by inserting it into 020_ScaleExponents.cfg immediately below the same block targeted at "ModuleDeployableSolarPanel" and neither has had any effect on the issue. I have deleted the MM config cache for good measure on both attempts as I recall seeing that being needed somewhere else in this thread, but apparently has no effect in this case. Something I find interesting is that the up-scaled power production seems to work correctly while the panels are on the surface of Kerbin, but placing them in orbit removes the effect. Going to keep playing around with it in the hopes that I'll figure out how to insert my own patch, but still hoping for some sort of "official" response.
EDIT3: Further testing shows that this is specifically related to Other Worlds because it patches "KopernicusSolarPanel" into the solar panels to get the second star to work. With just Kopernicus installed, the behavior of scaled solar panels is correct as well as when Kopernicus and OPM are installed. It's only when Other Worlds is introduced that the scaled behavior fails to work as expected. Still blindly poking around in the configs for myself, but it still looks like the issue is the "KopernicusSolarPanel" module as that is specifically invoked for Kopernicus configs with multiple stars.
EDIT4: Playing around with trying to get TweakScale to recognize that I want it to add the same exponents to the "KopernicusSolarPanel" module hasn't produced any results, so I'm back to hoping for a better answer from someone who knows how to make this work correctly.
-
Curious how System Heat interacts with Real Fuels with regards to boiloff. I have both installed and both have boiloff as a feature, but that has me a little worried that they will end up double dipping and causing me issues. Searching through both threads hasn't returned any sort of relevant results, so I'm wondering if there is any information about whether or not they are compatible or will cause each other issues.
Thanks
-
So I know its been a couple of years since any of the mod creators for this have replied, so I'm not too hopeful for an answer, but I am curious if we're supposed to be using "useRealisticMass=false" or not for this? I've tried multiple combinations and it feels like leaving the settings on "true" leads to fairly small rockets, while setting either of the options to false leads to comically oversized rockets (i.e. just to put a single Kerbal in orbit takes an absurdly large rocket and is nearly impossible with early tech). In searching through the thread I noticed at one point there was some talk about an update to rebalance things and remove the reliance on the setting, but looking at the patch notes there was only one update after that before it development stopped and its unclear if that rebalance happened in that update. So basically, I'm left with the following question: Have the configs been reworked such that we're just supposed to use the default RF settings, or are the current configs not rebalanced and we're supposed to set realistic mass to false and really work hard to engineer workable rockets?
Thanks
-
Nevermind, was thinking of an entirely different mod...
Unable to save game
in KSP2 Technical Support (PC, unmodded installs)
Posted · Edited by SpacedInvader
Just in case anyone else ends up with the same issue and lands here, this appears to be an issue with KRASH where after a simulation session, it fails to reset the ability to quicksave and load back to "True". You DO NOT HAVE TO START OVER, just open your persistent.sfs file for your save (while not actually in playing in that save) and change the lines "CanQuickSave = False" and "CanQuickLoad = False" to "True", save it and you'll be back on your way.