SpacedInvader
-
Posts
1,168 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by SpacedInvader
-
-
I've gone ahead and written up a compatibility config for RemoteTech since I plan on using this mod in my next career. Since several people had asked for one, I figured I'd go ahead and share mine here.
Spoiler//Initial Antenna Pass //Replaces ModuleDataTransmitter on all parts containing it with ModuleRTAntenna //BEFORE[RemoteTech] is important because RemoteTech contains a patch which deletes all ModuleDataTransmitter instances without necessarily replacing them //Note: Most antennas have recieved a 200% range buff to offset RemoteTech's more restrictive standard range model //If you use the ROOT model in your careers you can either set worldscale to 0.5 or comment out the "@Mode1OmniRange *= 2" line @PART[*]:HAS[#author[tantares],@MODULE[ModuleDataTransmitter],!MODULE[ModuleCommand],!MODULE[ModuleRTAntenna]]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleAnimateGeneric] { %allowManualControl = false } %MODULE[ModuleRTAntenna] { %Mode0OmniRange = 0 %Mode1OmniRange = #$/MODULE[ModuleDataTransmitter]/antennaPower$ //Antenna power is essentially antenna range so this utilizes already configured range @Mode1OmniRange *= 2 //Flat 200% buff to antenna range to account for more restrictive RemoteTech range model %EnergyCost = #$/MODULE[ModuleDataTransmitter]/packetResourceCost$ //Draws cost of running the antenna from its packet cost @EnergyCost *= 0.1 //"Passive" mode cost reduced by 90% for normal use %DeployFxModules = 0 %TRANSMITTER { %PacketInterval = #$/MODULE[ModuleDataTransmitter]/packetInterval$ //Transmitter values drawn directly from previously configured transmitter %PacketSize = #$/MODULE[ModuleDataTransmitter]/packetSize$ %PacketResourceCost = #$/MODULE[ModuleDataTransmitter]/packetResourceCost$ } } %MODULE[ModuleSPUPassive]{} !MODULE[ModuleDataTransmitter]{},* } //Dish antenna reconfigures //All ranges and angles are based on best-guess values for mission profile of the part //Ranges have been increased for interplanetary dishes to account for the more restrictive range model of RemoteTech @PART[vela_high_gain_antenna_srf_1]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 90000000 %DishAngle = 10 } } @PART[lepus_high_gain_antenna_srf_1]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 90000000 %DishAngle = 10 } } @PART[lepus_high_gain_antenna_srf_2]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 90000000 %DishAngle = 10 } } @PART[eridani_high_gain_antenna_srf_1]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 10000000 %DishAngle = 25 } } @PART[octans_basic_high_gain_antenna_srf_2]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 2000000 %DishAngle = 45 } } @PART[octans_high_gain_antenna_srf_1]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 2000000 %DishAngle = 45 } } @PART[octans_high_gain_antenna_srf_2]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 2000000 %DishAngle = 45 } } @PART[1mv_high_gain_antenna_srf_1]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 40000000000 %DishAngle = 0.1 } } @PART[4mv_v_high_gain_antenna_srf_1]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 40000000000 %DishAngle = 0.1 } } @PART[1f_high_gain_antenna_s0_1]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 40000000000 %DishAngle = 0.1 } } @PART[atria_antenna_srf_1*]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { @MODULE[ModuleRTAntenna] { !Mode0OmniRange = DEL !Mode1OmniRange = DEL %Mode0DishRange = 0 %Mode1DishRange = 2000000 %DishAngle = 45 } } //Initial Probe Pass //All probes initially configured with the RemoteTech standard 3km always-on omni antenna to allow for on-pad control @PART[*]:HAS[#author[Tantares],@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],!MODULE[ModuleRTAntenna]]:NEEDS[RemoteTech,!SETIRebalance]:BEFORE[RemoteTech] { %MODULE[ModuleSPU]{} !MODULE[ModuleDataTransmitter]{},* %MODULE[ModuleRTAntennaPassive] { %TechRequired = unmannedTech %OmniRange = 3000 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 15.0 } } %MODULE[ModuleSPUPassive] {} }
Some things to note:
- I used a decent amount of automation in creating the configs, so if I missed any parts, let me know so I can add them
- Most range values have been increased to account for RT's more restrictive range model
- I didn't find any special case parts (i.e. probe cores with built-in long range antenna) in my initial run through of the part configs so if I accidentally obliterated something like that, again, just let me know
Anyway, just copy all of this into a new cfg and you should have pretty much full RemoteTech support for your parts.
EDIT: Updated 02/24/2021 to correct an error in capitalization that invalidated many of the edits
-
2 minutes ago, Zorg said:
Thanks. These are now on the Github master for anyone wishing to try them out.
Glad I could help
-
17 hours ago, Zorg said:
The Remote Tech configs are community maintained by BDB users since the authors dont use the mod. They are quite old so Im not surprised there are configs for parts that dont exist anymore. If you do make RT configs they would be appreciated though its worth saying you are like the 4th or 5th person to have announced such intentions over the last year
You can share the complete files directly or make a pull request to the master branch on github.
EDIT: Oh also worth mentioning now that I recall there in fact were some updates submitted by someone. They are on github and not released at the moment. You should look at these to ensure no duplication of effort.
Couldn't figure out how to do a pull request so I'll just post it here as a zip.
What these configs do:
- Dynamically configure all antennas to RemoteTech omnis based on their prior vanilla CommNet configurations (those numbers were set for a reason, might as well utilize them)
- Buff range of most omnis by 200% to account for RemoteTech's more restrictive standard range model. If you use the root range model, just use the recommended 0.5 worldscale
- Nerf range on a few others because huge omni ranges felt unbalanced
- Dishes are manually reconfigured from the initial omni state based on their intended mission profile (couldn't figure out a way to automatically configure dishes in a satisfactory way)
- Probe cores are automatically configured to have the RemoteTech default 3km always-on antenna for pad control
- Probes which are described as communications relays and had been configured already with improved internal antennas have retained those
- Going forward, this should automatically configure all new omni antennas and probe cores correctly, with a need to manually patch dishes or special probes / pods (but all would still work as omnis / regular probe cores at least)
If anyone spots any balance issues or other issues, I'd be happy to fix them and reupload if needed.
-
4 hours ago, JebIsDeadBaby said:
Pretty sure it's gone but it's understandable, since after patching RF does not act on the jet pack.
Either way, I'm glad its sorted
-
I've been planning on using this for a playthrough that I'm getting started which will have RemoteTech and I'm running into an issue in that all of the antenna that have been configured to work with RT seem to be missing. I understand that most of the newer antenna don't have a compatibility patch yet, which is not what this is about, but rather the ones that do don't appear anywhere in the parts list at all. For example, the DP-75 appears to be properly configured, gets all its associated MM patches in the log, but then when I go looking for it in game, it literally doesn't exist and I can't figure out where it disappeared to because there doesn't appear to be any patches that would rename it or delete it. Is there something I'm missing in the configs that's leading to these parts vanishing?
Thanks
PS: I'm also going to be patching the newer parts to work with RT and I might post it here if I'm happy with the results.
EDIT: I'm using v1.7.1 from CKAN on KSP 1.11.1 in case that might be the issue
-
6 hours ago, JebIsDeadBaby said:
Your patch works like charm. The only tweak I had to do was to add :BEFORE[RealFules] to both patches. The reason for this is that I use Kerbalism, and it's Kerbalism that patches EVA Propellant into Monopropellant. Then Real Fuels comes, sees Monopropellant on the jet pack, and turns it into a service tank , which it can't further handle I guess. So the trick it is to "hijack" the jet pack and fill it with something that is not stock fuels after Kerbalism but before Real Fuels.
I get this log input from part compiler:
[LOG 22:27:39.212] PartLoader: Compiling Part 'Squad/Parts/Cargo/Jetpack/Jetpack/evaJetpack' [LOG 22:27:39.220] RealFuels.Tanks.TankWindow:HideGUI() RealFuels.Tanks.ModuleFuelTanks:OnDestroy() UnityEngine.Object:DestroyImmediate(Object, Boolean) UnityEngine.Object:DestroyImmediate(Object) PartLoader:StripComponent(GameObject) PartLoader:CreatePartIcon(GameObject, Single&) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
This RealFuels.Tanks.TankWindow:HideGUI() looks like a reason why jet pack tank can't be accessed via GUI.
I've never been very good at deciphering unity errors, but it looks like the game doesn't want any special GUI to be added to the jetpack because its a cargo part. I could be wrong though... Is this an error you're still getting after applying the patch, or something you were seeing before?
-
15 minutes ago, JebIsDeadBaby said:
That's the thing - it's not me. From the moment I installed 1.11, jet packs were patched to 25l service tanks. I don't recall any patch regarding EVA propellant but I guess it is there somewhere and it does it's job on jet packs.
Do you mean remove service tanks for jet packs? Anyway, I'll try your patch today.
BTW, since 1.11 I don'y get rescue contracts. Can it be related to this change in EVA?
You might have a patch somewhere that does a search for all containers that hold resources and then replaces them with service module tanks. Best I can suggest is doing a search through your gamedata folder with a program like notepad++ that lets you search for text in files for something that looks like "@RESOURCE[*]" as that might lead you to the culprit. And yes, I'd remove the service tanks on the jetpacks, but that's been added through a patch somewhere so you've got to figure out whats adding it and disable that.
As for rescue contracts, I've got no idea at all as I've got them disabled since I never do them.
-
3 hours ago, JebIsDeadBaby said:
I don't mean refill, I mean how do you add any fuel at all? My jet packs come empty and there is no option to fill them, as with any other RF tanks. They are patched as service tanks though, I'm kinda not sure where this patch comes from. I don't recall any patch regarding EVA Propellant. How come no one complains about it? Am I the only one with this problem? Do your jet packs come filled with any fuel?
So it turns out I wasn't quite paying attention to what I was reading from when I replied to your post, the patch notes are from KSP 1.11.1 actually and after downloading that, I do see the line they were referring to in the configs. After some testing it looks like it doesn't matter what resource you patch into the jetpacks because they don't actually refill from whats on the ship but rather from a magical stockpile. With that said, I think I might know where you went wrong here... did you change both the tank contents and the KerbalEVA module's fuel of choice? Here is the patch I just whipped up to make my jetpacks use Hydrazine instead of EVA Propellant and it works just fine:
@PART[kerbalEVA*]:NEEDS[RealFuels] { @MODULE[KerbalEVA] { @propellantResourceName = Hydrazine } } @PART[evaJetpack]:NEEDS[RealFuels] { !RESOURCE[*]{} RESOURCE { name = Hydrazine amount = 5 maxAmount = 5 isTweakable = False } }My thinking is you changed the jetpack's contents, but not the fuel the kerbal's eva module, which is actually a part of the kerbal themselves, wants to see. If I'm still wrong here, my best suggestion is to remove the service tanks from the kerbals and just pick a single fuel for them to use and define it in a fixed way like I did in the patch.
EDIT: Considering the fact that the tanks refill magically, it might be better from a realism perspective to use something like nitrogen since hydrazine is just a little too terrible of a chemical to be put into something you might accidentally fire inside the ship...
-
Can anyone give me some information on how BARIS handles multi-launch orbital construction as well as mods like Konstruction and Global Construction that allow you to build a ship on site without actually launching it from the surface per-se? I've got Extrasolar and Far Future Technologies installed and I'm expecting to launch several missions that will take months or even years to construct in orbit since I also use KCT. I'm fully aware that MTBF will degrade while in orbit, but I'm curious how that MTBF will interact with things like new parts being welded onto the ship sometime after launch.
-
On 1/27/2021 at 5:08 AM, Ollz said:
So does it always take time to build Vessels, Or is that only With KCT.
I Appreciate that Mod, But I Enjoy just being able to launch a Rocket ( Or Send it to the Launch Pad At Least ) With No Strings Attached, like Having to Timewarp to a Certain in game day just to launch My Rocket
KCT Complaining aside, Great Mod! I Plan to use it soon in a JNSQ, Science Mode with Unkerballed Start and A Bunch of other Mods
I'm only just starting to use the mod myself, but if you want no-strings-attached launches of your rockets, this isn't the mod for that. I've been reading through the thread and the wiki for a couple of days now am pretty comfortable in saying that the whole mod is built around testing and patience to get the highest reliability from your craft. That said, yes, if you don't have KCT installed, I'm pretty sure you can skip vehicle integration completely, just expect lots catastrophic failures during your missions.
-
I'm hoping to get a little help from anyone here who's got experience working with the various US config modules. I'm working on a series of patches to integrate US2 to work with Real Fuels and I've run into somewhat of a minor issue, but its been bothering me for two days nonetheless. While trying to adapt the 1.5m shroud, I've run into an issue where no matter what I try, I can't get the bottom detail to switch between the flat-bottomed structural variant and the toroidal tank variant. This won't work at all for me unless I leave the config in its vanilla state, let alone how I'd like it to work which is have each of the shroud heights cycle through its structural variant and then its tanked variant before stepping up to the next level.
Currently, this is what I've got for this part:
Spoiler@PART[USCylindricalShroud1500]:NEEDS[RealFuels]:FOR[zzzMyMods] { !MODULE[USFuelSwitch],*{} MODULE { name = USFuelSwitch SwitchID = 0;2 resourceNames = Structural|Aerozine50;Kerosene;LqdHydrogen;LqdMethane;LqdOxygen;HTP;Hydrazine;MMH;NTO;UDMH|Structural|Aerozine50;Kerosene;LqdHydrogen;LqdMethane;LqdOxygen;HTP;Hydrazine;MMH;NTO;UDMH|Structural|Aerozine50;Kerosene;LqdHydrogen;LqdMethane;LqdOxygen;HTP;Hydrazine;MMH;NTO;UDMH|Structural|Aerozine50;Kerosene;LqdHydrogen;LqdMethane;LqdOxygen;HTP;Hydrazine;MMH;NTO;UDMH|Aerozine50;Kerosene;LqdHydrogen;LqdMethane;LqdOxygen;HTP;Hydrazine;MMH;NTO;UDMH|Aerozine50;Kerosene;LqdHydrogen;LqdMethane;LqdOxygen;HTP;Hydrazine;MMH;NTO;UDMH resourceAmounts = 0|300;300;300;300;300;300;300;300;300;300|0|300;300;300;300;300;300;300;300;300;300|0|300;300;300;300;300;300;300;300;300;300|0|300;300;300;300;300;300;300;300;300;300|500;500;500;500;500;500;500;500;500;500|800;800;800;800;800;800;800;800;800;800 initialResourceAmounts = 0|300;300;300;300;300;300;300;300;300;300|0|300;300;300;300;300;300;300;300;300;300|0|300;300;300;300;300;300;300;300;300;300|0|300;300;300;300;300;300;300;300;300;300|500;500;500;500;500;500;500;500;500;500|800;800;800;800;800;800;800;800;800;800 tankCost = 0|2;2;2;2;2;2;2;2;2;2|0|2;2;2;2;2;2;2;2;2;2|0|2;2;2;2;2;2;2;2;2;2|0|2;2;2;2;2;2;2;2;2;2|2;2;2;2;2;2;2;2;2;2|4;4;4;4;4;4;4;4;4;4 tankMass = 0|2;2;2;2;2;2;2;2;2;2|0|2;2;2;2;2;2;2;2;2;2|0|2;2;2;2;2;2;2;2;2;2|0|2;2;2;2;2;2;2;2;2;2|2;2;2;2;2;2;2;2;2;2|4;4;4;4;4;4;4;4;4;4 hasGUI = False availableInEditor = False displayCurrentTankCost = True ShowInfo = False } @MODULE[USSwitchControl]:HAS[#SwitchID[2]] { @ButtonName = Tank Contents @ModuleDisplayName = Tank Contents @CurrentVariantTitle = Tank Contents @FuelSwitchModeOne = True @ObjectNames = Aerozine50;Kerosene;Liquid Hydrogen;Liquid Methane;Liquid Oxygen;HTP;Hydrazine;MMH;NTO;UDMH @VariantColors = #eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999 } @MODULE[USSwitchControl]:HAS[#SwitchID[0]] { @ObjectNames = Single;Single Toroid;Double;Double Toroid;Triple;Triple Toroid;Quad;Quad Toroid;Bulkhead;Bulkhead Toroid !FuelSwitchModeOne = True FuelSwitchModeTwo = True @VariantColors = #68984d,#999999;#68984d,#999999;#537a3d,#999999;#537a3d,#999999;#3a562a,#999999;#3a562a,#999999;#2e4321,#999999;#2e4321,#999999;#2e4321,#999999;#2e4321,#999999 } !MODULE[USMeshSwitch]:HAS[#SwitchID[0]],*{} !MODULE[USMeshSwitch]:HAS[#SwitchID[2]],*{} MODULE { name = USMeshSwitch SwitchID = 0 MeshTransforms = 1500TorusStructural;1500TorusLF;1500TorusStructural;1500TorusLF;1500TorusStructural;1500TorusLF;1500TorusStructural;1500TorusLF;1500TorusStructural;1500TorusLF AffectColliders = True DebugMode = True } MODULE { name = USMeshSwitch SwitchID = 0 MeshTransforms = OneHigh;OneHigh;TwoHigh;TwoHigh;ThreeHigh;ThreeHigh;FourHigh;FourHigh;Bulkhead;Bulkhead AffectColliders = True DeleteUnused = True } @MODULE[USCargoSwitch]:HAS[#SwitchID[0]] { @CargoBayCenter = 0,0.2,0;0,0.2,0;0,0.3,0;0,0.3,0;0,0.55,0;0,0.55,0;0,0.75,0;0,0.75,0;0,0.75,0;0,0.75,0 @CargoBayRadius = 0.55;0.55;0.6;0.6;0.8;0.8;1;1;1;1 } @MODULE[USDragSwitch]:HAS[#SwitchID[0]] { @DragCubes = A0,B0;A0,B0;A1,B1;A1,B1;A2,B2;A2,B2;A3,B3;A3,B3;A4;A4 } @MODULE[USAnimateGeneric] { @AnimationControlState = 3;3;3;3;3;3;3;3;1;1 } @MODULE[USNodeSwitch]:HAS[#SwitchID[0]] { AttachNodes = HeightOne;HeightOne;HeightTwo;HeightTwo;HeightThree;HeightThree;HeightFour;HeightFour;BulkheadGroup;BulkheadGroup } }And with this, I've pretty much got everything else in the config for the part working. The structural and tanked versions do cycle in the way I want, the various fuels are available in the correct quantities based on which model is selected, the colors work just fine, and even the things like nodes and drag cubes appear to work correctly, but literally no matter what I try, the only mesh that will ever show up for the bottom of the part is the tanked variant. As such, I'm really hoping someone who knows a lot more about the inner workings of the USMeshSwitch Module could step up here and give me an idea of where things are going wrong. In the end, its a relatively minor problem because its just a minor visual component of a single part, but I'd still really like to try to work it out.
While we're at it, if anyone has any experience in working with ModuleFuelTanks from RF and USModuleSwitch from US2, I could use some help there as well. The reason I've got such a mess of fuel configs for this patch is because I've not found a way to get ModuleFuelTanks to properly update dynamically with the settings fed to it by USModuleSwitch. I've been able to get the tank type to switch correctly, but its volume refuses to budge from whatever I've set it to initially. I'd originally hoped I could get the tanks to work in a similar fashion to their procedural parts function where as the US2 module feeds the RF module with new volumes as the size increases / decreases, the tank reflects the new size / type, but I've not been able to manage the volume change at all and I've tried a bunch of different approaches in MM.
Here's where I got to before giving up:
Spoiler@PART[USAerozineWedge]:NEEDS[RealFuels]:FOR[zzzMyMods] { !MODULE[USFuelSwitch]{} @MODULE[USSwitchControl]:HAS[#SwitchID[0]] { @FuelSwitchModeOne = False } MODULE { name = ModuleFuelTanks volume = 0 temp = 0 @volume = #$temp$ utilizationTweakable = true type = Default } MODULE { name = USModuleSwitch SwitchID = 0 TargetModule = ModuleFuelTanks TargetFields = temp TargetValues = 65;130;195;260 } MODULE { name = USModuleSwitch SwitchID = 1 TargetModule = ModuleFuelTanks TargetFields = type TargetValues = Default;Cryogenic;ServiceModule;ElectricPropulsion } MODULE { name = USSwitchControl SwitchID = 1 ButtonName = Tank Type ModuleDisplayName = Tank Type CurrentVariantTitle = Tank Type ShowPreviousButton = False ObjectNames = Default;Cryogenic;ServiceModule;ElectricPropulsion FuelSwitchModeTwo = False VariantColors = #eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999 } }If anyone has any ideas on what would need to change to get this to work, that would be amazing as it would be a much better solution than manually editing in every tank content / amount I've got a desire to use for every part.
Thanks
-
On a different note, @Starwaster I wonder if you could help me sort out a config I've been beating my head against for 3 days now. I'm trying to integrate the modular tanks from Real Fuels into the Universal Storage 2 parts using the provisions built into the US2 modules for switching components of modules. Here's what I've got so far:
Spoiler@PART[USAerozineWedge]:NEEDS[RealFuels]:FOR[zzzMyMods] { !MODULE[USFuelSwitch]{} MODULE { name = ModuleFuelTanks volume = 65 utilizationTweakable = true type = Default } MODULE { name = USModuleSwitch SwitchID = 0 TargetModule = ModuleFuelTanks TargetFields = volume TargetValues = 65;130;195;260 } MODULE { name = USModuleSwitch SwitchID = 1 TargetModule = ModuleFuelTanks TargetFields = type TargetValues = Default;Cryogenic;ServiceModule;ElectricPropulsion } MODULE { name = USSwitchControl SwitchID = 1 ButtonName = Tank Type ModuleDisplayName = Tank Type CurrentVariantTitle = Tank Type ShowPreviousButton = False ObjectNames = Default;Cryogenic;ServiceModule;ElectricPropulsion FuelSwitchModeTwo = False VariantColors = #eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999;#eb7c10,#999999 } }This setup uses US2's built in switch controls to create PAW selectors like this:
Spoiler
The second switch does work correctly, swapping the tank type from Default to Cryogenic etc, but the first one which is supposed to increase the volume of the tank to match the increasing size of the model refuses to work. I'd hoped it would work in a similar way to the procedural parts tanks where when the tank changes size and the volume value is increased or decreased, it prompts ModuleFuelTanks to update its volume based on the new volume value I've fed it through the switch. Unfortunately, it refuses to update and stays stuck on 65L no matter what I do to try to get it to update dynamically.
I'm really hoping you might have some ideas on how to force ModuleFuelTanks to update dynamically with this changing value in the same way that it does for Procedural Parts as I'm completely out of ideas and about to give up.
Thanks
PS: Really sorry about the ping, but I felt that you might be one of the only people who might be able to help solve this and it doesn't seem like you pay much attention to this thread anymore.
EDIT: Just in case it isn't clear, SwitchID 0 is already part of the part and also controls which version (1 high through 4 high) of the model is shown.
-
On 1/27/2021 at 2:38 AM, JebIsDeadBaby said:
Guys, how do I add fuel to jet packs? I have hydrazine on board, yet when I go to EVA I have a warning about lack of fuel in the jest pack. I can see that the jet pack has a defined fuel tank in VAB, but it has no right-click menu with a button to edit tank's contents.
If you're using KSP 1.11 you can't refill EVA tanks from the pod stores anymore (honestly not sure if you ever could) from what I'm reading in the cfgs. You need to put EVA Fuel Cylinders into the pod's inventory and use those.
EDIT: So apparently they included the config flag reinitResourcesOnStoreInVessel in 1.11 which would allow you to refill your EVA propellant when placing your jetpack into the inventory of the pod, but I haven't been able to get it to work since there's literally zero documentation about it...
-
10 hours ago, Kielm said:
@SpacedInvader This is caused by NVIDIA MSAA setting, which is enabled when you choose the optimised options in Geforce Experience.
Don't use MSAA or revert that setting in NVIDIA control panel to avoid that ghosted image.
Thanks for clearing that up, at least now I know that it wasn't the new driver per-se, but rather a setting that it decided to impose on its own during install.
-
I've been testing this in KSP 1.11 and have found that it throws out lots of the following Null Reference Exception whenever you open the PAW on any part of a ship that has at least one kerbal assigned to it:
[EXC 04:35:06.513] NullReferenceException: Object reference not set to an instance of an object UniversalStorage2.StockVariants.EditorPartIconListener.PartIconSpawn () (at <da28f16225654a6e9aa3c0ba261544dc>:0) UniversalStorage2.StockVariants.EditorPartIconListener.Start () (at <da28f16225654a6e9aa3c0ba261544dc>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
This happens if there is any kerbal assigned to any part on the ship, but luckily the workaround is just removing all the assigned kerbals while you work on the ship and then reassigning them before launching. I understand that this mod's devs are taking a break for the moment so this might not get fixed anytime soon, but I'll go ahead an leave my logs here in case they have a chance to look at it.
One thing to note, it appears that there may be some mod interactions that worsen the problem. In a test install with just US2, there are 20-40 NRE's whenever you open the PAW for a part, but in a heavily modded install like I usually run, it spews out literally tens of thousands without ever stopping. I've saved those logs as well if anyone wants to look at them, but I know mod developers tend to only want to see what their specific mod is doing, so I won't post them unless requested.
EDIT: Whoops, I just noticed the post a few above mentioning this same issue. I'm leaving my post up though as I was able to find a temporary workaround for anyone like me who was getting so many NREs in their main install that the VAB was barely functional. Also the added logs can't hurt imo.
-
For the last two days I've been getting odd behavior during scene changes (i.e. from main menu to KSC, KCS to VAB, etc) where instead of going to a black screen for loading, I get a weird ghosted image of the previous scene like this:
Spoiler
Spoiler
At first I thought it had to do with an nVidia driver that I'd just updated, but I've since rolled back and am still getting the same behavior. I don't think its something critical, but I'd like to fix it anyway so I'm wondering if anyone has ever seen anything like this in the past and if so, what can I do to fix it? Also, is it possible that this could be the result of a mod as I run quite a large modlist and more than a few were updated yesterday.
Thanks
EDIT: I've now tried removing all of the mods that were added / updated since the issue appeared and its still occurring so I don't believe its a mod related issue.
EDIT2: Solved with a complete uninstall, cleaning, and reinstall of older drivers. The Game Ready driver v461.40 was apparently the culprit and a rollback to v460.89 corrected the issue.
-
41 minutes ago, Zelda said:
Not sure about DangIt! but I know OhScrap! has a mechanic like that.
That appears to be the one... no wonder I got them mixed up with such similarly clever names...
-
Did this mod at one point have a mechanic where the more you built a specific craft / part, the more reliable it got? I really remember there was a failure mod with that mechanic and I really thought it was Dang It!, but I've read through the documentation and haven't found anything about it. Was that something the mod used to have and has since been removed, or am I thinking of an entirely different mod?
-
I'm hoping to get some help in sorting out a series of patches I need to to apply. I'm trying to convert a lot of parts from the Near Future mods to work with Real Fuels and its customizable fuel tanks. Normally this wouldn't be an issue at all as swapping in the RF module is a fairly simple process of deleting to old tank contents and patching in the module. Unfortunately, Nertea's approach to part variety was to create a few parts which use B9PartSwitch to change their appearance and contents and I really want to preserve the variety of appearances while replacing the tank contents that come along with each appearance. This is where things have started to go sideways for me as I've found it impossible to affect the individual options through a patch in any way that hasn't also resulted in invalidating them.
Anyway, here's what I've tried so far...
First, an example of the config I'm trying to edit:
SpoilerMODULE { name = ModuleB9PartSwitch moduleID = surfaceSwitch switcherDescription = #LOC_NFEX_Switcher_FuelTank switcherDescriptionPlural = #LOC_NFEX_Switcher_FuelTankPlural baseVolume = 240 SUBTYPE { name = Gold transform = Tank1875_Large_Foil title = #LOC_NFEX_Switcher_FuelTank_Gold descriptionSummary = #LOC_NFEX_Switcher_FuelTank_Gold_summary descriptionDetail = #LOC_NFEX_Switcher_FuelTank_Gold_detail primaryColor = #fccb0a secondaryColor = #fccb0a tankType = LFOX addedMass = -0.15 } ... }
This was an attempt to search out the fuel tanks from the mod that I hadn't done a custom edit on (there are a few that I think might need it for various reasons) and delete the tank type and mass adjustment from each subtype, which would then be replaced with its own RF module. I also tried skipping the addition of the RF module and just deleting the tank type references so I could just add a single RF module afterward to the whole part. This is the only one of my attempts that did anything at all and that was generate an error. I'm not really sure where I went wrong with it though.Spoiler@PART[nfex-fueltank*],HAS[@MODULE[ModuleB9PartSwitch],!MODULE[ModuleFuelTanks]]:NEEDS[RealFuels]:FOR[zzzMyMods] { @MODULE[ModuleB9PartSwitch] { @SUBTYPE,* { !tankType !addedMass MODULE { name = ModuleFuelTanks utilizationTweakable = true type = Default typeAvailable = Default typeAvailable = Cryogenic typeAvailable = ServiceModule typeAvailable = Fuselage typeAvailable = Balloon typeAvailable = BalloonCryo typeAvailable = Structural typeAvailable = ElectricPropulsion } } } }This was my second attempt where I tried to affect the B9 tank definitions instead thinking that if I couldn't affect the part switcher subtypes I'd instead change what those tank types inserted into the part. Unfortunately, this patch didn't work at all and I didn't even get errors.
Spoiler@B9_TANK_TYPE,*:FOR[zzzMyMods] { !tankMass !tankCost !RESOURCE,* MODULE { name = ModuleFuelTanks utilizationTweakable = true type = Default typeAvailable = Default typeAvailable = Cryogenic typeAvailable = ServiceModule typeAvailable = Fuselage typeAvailable = Balloon typeAvailable = BalloonCryo typeAvailable = Structural typeAvailable = ElectricPropulsion } }I've tried a few other minor patches, but so far nothing has created the desired result. I've thought about trying to create a new B9 tank type with the RF module already built in, but I'm not sure that the B9 Part Switch module can handle inserting a whole other module like that and even if it can work, I'm still stuck with the problem of not being able to edit the subtypes correctly through a patch.
Any help would be greatly appreciated.
EDIT: Managed to solve it on my own through lots and lots of trial and error.
-
Thought I'd post this here in case anyone ran into the same problem. I'd downloaded the mod using CKAN and had run into an infuriating issue where decreasing the thrust limiter would proportionately decrease the maximum throttle available . Example given in the following image where thrust is limited to 60% but even at maximum throttle position it would only go up to 35%.
Spoiler
At first I thought it would be RF because it seemed like something RF might have a hand in, but after setting up a test install with just KSP+RF and not getting the same result, I went through my entire gamedata folder looking for the culprit (nearly 200 mods), only to eliminate everything except RF. As it turns out, the version of the plugin that's installed through CKAN is broken somehow while the version from the latest Github release (the one I used for the original test install) is perfectly functional. So, if anyone sees this behavior and has used CKAN to install the mod, I'd recommend the first thing you do is do a fresh install of it from the Git. Also, I'm not sure if this had anything to do with it, but I did the same for RealFuels - Stock engine configs and all of this is on KSP 1.11.
-
Has anyone tried this in 1.11 yet? Seems like its been quite a while since it was last in development...
-
@ValiZockt Have you thought about adding the optional Methalox configurations for the Near Future Launch Vehicles engines? I'm thinking about trying to adapt them myself, but I've never rolled a single engine config in all the years I've been using RF so I'm unsure of the results...
-
11 hours ago, KawaiiLucy said:
Wouldn't that be doable by just changing some names in the cfg files that are already there? i.e changig lfo for the fuel you want
Yes and no... like I mentioned its been years since I've really spent much time messing with patches, but RF tends to be a special case because it requires proper balancing and needs changes made to tankage and such if you want to keep the functionality of the mod. For example, if you want to output liquid hydrogen and oxygen from a water splitter, you've got to ensure the ratios are at least somewhat correct, then any tank that will hold the outputs uses the RF plugin to simulate boiloff correctly.
-
10 hours ago, hermano said:
Removing and earning veteran status works fine in 1.11. I'm also using KerbalRenamer, so I cannot say for sure if randomizing Kerbals works. Just starting a new game with Earn Your Stripes should answer that question, though.
Sounds like that's about the scope of the mod so it works well I'd say? I've installed it and will do my own testing.
Thanks
[1.8.1 - 1.9.1] Kopernicus Continued
in KSP1 Mod Releases
Posted
I'm curious what the status of ModuleFlightIntegrator is currently. I've seen on the last couple of pages that there have been some special patches for this that might not make it into the proper branch of MFI, but that discussions with Sarbian were in progress. Since then however, MFI has been updated and I'm curious if I can update to the 1.2.8 version available on CKAN or if I need to keep the version bundled with Koperinus-BE edition?