Eleusis La Arwall

I'm currently setting up a new computer and want to get back to KSP modding. I'd like to use Unity on Debian 9 and I've got some experience with Unity 5.4.1f1 on Debian 8 but it did not end very well last time. Before I install anything I'd like to know if other modders are running Unity on Linux (successfully)? If so, what version of Unity? Does anyone know where to get Unity 5.4.0p4 for Linux? Couldn't find it here.

Excellent! Thank you very much! I'm gonna give it a go right away. Also I've got an idea/suggestion for the Resource Converters. Would it be possible to have "converter-groups"? Use case example: A single part with multiple Ore refinement converters and multiple propellant production converters. One Ore refinement converter could run at the same time as one propellant production converter but not two of the same group (at the same time).

@Warezcrawler Been playing around with your plugin for some weeks now and I have to say: Nice work! Sadly it doesn't work on KSP 1.3.1 (game crashes after loading screen, fresh install, no other mods). Do you have plans for a recompile / update in the future? I'm asking because I want to make use of it with an upcoming (part)mod I'm working on.

Yes, my suspicion seems correct. Removing the rotation of the model in the config file fixed the problem. Forgot to mention that, sry. MODEL { // rotation = 0,90,0 model = WarpPlugin/Parts/Command/iHall/modelCDTcore }

I can reproduce the problem. Root part or not doesn't matter, all iHal parts have the navball rotated by 90° upon revert to launch. I'll re-export the part and remove the rotation node in the config for the next release.

@Maelstrom Vortex I have the suspicion that this is caused by the 90° rotation of the model in the config file MODEL { rotation = 0,90,0 model = WarpPlugin/Parts/Command/iHall/modelCDTcore } It is exactly the rotation you experienced and I've seen similar problems with the rescaleFactor node on root-parts Is iHal the root part? I'll run some test to see if I can reproduce it.

Most storage tanks have an integrated resource converter for liquid <-> gas that can be adjusted with a slider. Tritium must breed in (fission) reactors like the Molten Salt Reactor. Tritium also underlies radioactive decay. Deuterium is located in Jools atmosphere. Otherwise Heavy Water can be electrolyzed to Deuterium and Oxygen.

LiterVolume is a temporary resource that should not be visible. LiterVolume on each tank gives its storage volume in Liter. A MM-patch converts it to the IFS fuel switches. Think I found the problem, will be fixed

Sure you can use it! It's just an example, feel free to do whatever you like with it

Yes, that should be possible with MM. Here's a patch that should create a duplicate of the stock Mk1 Pod before patched by VensStockRevamp (untested) +PART[mk1pod]:BEFORE[VensStockRevamp]:FOR[000start]{ @name = mk1podStock @title = Stock Mk1 Pod // or whatever you want } +PART[mk1pod] makes a copy of the part named mk1pod. :BEFORE[VensStockRevamp] tells MM to apply this patch before VensStockRevamp. :FOR[000start] is just for safety (if loaded in alphabetical order this patch will be loaded first); propably not required. Important is that the name for the duplicated part is changed with @name = <something>. Title, Manufacturer, etc can also be changed that way. Since the duplicate has a different name, other mods may not recognize this part.

I'm currently running Unity 5.4.1f1 with TextMeshPro and the latest PartTools on Debian 8 (yes it's a bit old I know). For a couple of month everything was working fine, just as I was used to from Windows. A few days ago Unity seems to have broken down for no apparent reason. From one day to the other the Inspector looks like this (debug right; normal left): The Materials settings have entrys I've never seen before. Any attempts to fix this have been in vain. I've found a similar problem on the unity forums and reported my problem over there too. I was told that it seems like a bug, unless I have some strange editor plugin that is taking over somehow. So, before writing a bug-report I want to make sure PartTools is not the problem. Has anyone here encountered a problem like this or may even have a solution? The strange thing is, beside everything looking messed up, it actually still works. I went through all the Element X entrys and the fifth revealed the name "_MainTex". So I've set the texture here, exported the model and KSP loads and shows it in the VAB. Most likely I have to reinstall Unity, but I couldn't find Unity 5.4.0p4 in the linux releases. So I'd like to ask other Linux users: What unity version are you running?

That is perfectly fine. All IFS tanks have an integrated (radial) decoupler. They were available for staging before, but inline-attached tanks also had a non-functional decoupler in the staging. If you don't want the integrated decouplers, you can disable them with PatchManager (Wrapper tanks still have integrated decouplers).

I'm getting myself familiar with the localization support but I have a problem with the language switcher. When I set language = de and provide a dictionary file for de and en-us, KSP shows me the en-us keys ingame. When I delete the en-us dictionary file, the de keys appear. KSP title screen shows de in both cases. I've looked into severel other mods but I don't know what I'm doing wrong.

The integrated decouplers no longer clutter the staging menu. It was a bit annoying to have decouplers from inline-attached tanks (that were not usable at all) in the staging. The decouplers are not gone entirely, they can be triggered from the right click menu or put into action groups. If you don't want to have integrated decouplers at all, it is also possible to deactivate them with PatchManager (integrated) by @linuxgurugamer. This handy tool can toggle MM configs on/off and makes life easier for modders and users. With PatchManager you can also disable the FuelSwitch patches for the stock parts or choose how much setups the CDT have. Currently there are 3 options for the CDT: Basic config is 4 Fuel+Oxidizer setups. The 7 setups config additionally allows you to have the Fuels without Oxidizer and the 12 setups config makes Noble gases available too. More options can and will be added in the future. Suggestions are very welcome but they need to follow some structure/concept. Please don't suggest personalized setups like "HydroLOx, Hydrogen, Xenon, HTP and Nitrogen-15" for example.

As mentioned above, FreeThinker and I currently encounter a problem. It's a bit weird because this setups was working at a certain point. Whenever I deactivate a patch in the GUI and apply it, nothing happens but this shows up in KSP.log: [EXC 16:20:20.560] FileNotFoundException: /home/myuser/games/KSP_linux/KSP_Data/../GameData/InterstellarFuelSwitch/PatchManager/ActiveMMPatches/InterstellarFuelSwitch_IntegratedDecoupler.cfg does not exist System.IO.File.Move (System.String sourceFileName, System.String destFileName) PatchManager.PatchManagerClass.ApplyAllChanges () PatchManager.PatchManagerClass.drawPatchWindow (Int32 windowid) UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) The file in question is not called InterstellarFuelSwitch_IntegratedDecoupler.cfg but IntegratedDecoupler.cfg. My first guess was to rename all files and srcpath to InterstellarFuelSwitch_IntegratedDecoupler.cfg but then I get a similar error stating that InterstellarFuelSwitch_InterstellarFuelSwitch_IntegratedDecoupler.cfg does not exisit. So now I guess PatchManager is looking for the wrong file. Config files are available in the latest release of IFS or on GitHub.

Yes, it works! The filename of the MM-config, the filename of the PM-config and the patchName-node must match exactly. At first I renamed just the PM configs but that alone didn't do the trick. Here is my working config: Again, thank you very much for the support!

Is there an example for the "exclusions" node? I've searched through all examples mentioned in the OP but could not find any and I couldn't get this to work by myself. Currently I have 3 different patches "CDT4SetupPatch.cfg", "CDT7SetupPatch.cfg" and "CDT12SetupPatch.cfg" but only one should be applied at a time. Here are the 3 Patches: In the GUI I can activate all 3 patches at the same time. I've also tried to include the modname like ... exclusions = InterstellarFuelSwitchCDT4Setups,InterstellarFuelSwitchCDT7Setups ... or ... exclusions = InterstellarFuelSwitch_CDT4Setups,InterstellarFuelSwitch_CDT7Setups ... but always the same result.

Yes, that fixed it. Everything is working now. Thank you for the support!

Amazing mod. You make my life so much easier once again. Thank you! I'm currently experimenting with default-enabled patches and it seems that I need to put the MMconfig in both folders (ActiveMMPatches and PluginData) like: |--GameData |--MyMod |--PatchManager |--ActiveMMPatches | |--MyMMPatch.cfg | ... |--PluginData | |--MyMMPatch.cfg | ... |--MyPatchManagerConfig.cfg If I put the patch in ActiveMMPatches folder only, start the game and deactivate the patch, I can not re-enable it after another game-restart. To me it seems like the patch is beeing deleted instead of moved/copied. After I disable it, the MyMMPatch.cfg is not located in PluginData as it should be (not in GameData/MyMod/... nor in GameData/PatchManager/...). The PatchManager config is pointing to " MyMod/PatchManager/PluginData/MyMMPatch.cfg " as described in the OP. One little detail: The OP is missing the " modName = NameOfMyMod " config-node.

I'm glad you brought this up and we can talk about it because I'm not 100% sure that this is all correct. I'm always open for better solutions. ... and it won't be the last time! Will be added.

Yes, the correct way would be to say "the tank X can store up to 100 bar pressure". Then we'd need to find the density for each resource at 100 bar and use it to get the actual capacity. Instead we say each gas can be compressed to a maximum of 75% of the liquid state. The problem is that some gases are better compressable than others and the maximum density is individual for each gas. An accurate solution would take a lot of time and I rather use my time for other stuff because it is very boring That would result in more odd numbers. In some way it would make sense to define liquid, gaseous and pressurized resources; The PGT would store the same amount of each resource. For me the odd numbers on the PGT are a smaller evil than new resource definitions.

True, but 100 liter baloon filled with xenon gas at very low pressure might weigh less than a 100 liter baloon filled with hydrogen at very high pressure. The volume itself does not say much when dealing with gases. The density is most important but the game handles densities as constant which is almost true for most liquids and solids but not gases. Technically we would have to define new pressurized resources. Maybe I expressed my thoughts behind this a bit irritating. I'll try again with Ammonia as example: If 4793271 units of gaseous Ammonia at std. conditions would be compressed to 75% of the density of liquid Ammonia it would match the tank volume. This way we don't need to define new resources to have a different density. CRP defines Ammonia with the Density = 0.000000769 and LqdAmmonia with the Density = 0.0007021. Without pressurization the CT tank could hold ruffly 1000 times more Ammonia than the PGT. ^^ Yeah I can understand that. As you can see in the spoiler of my last post we tried to do it even more complicated at first. The background on this is balancing. CT, CDT and PGT hold the same resources and so they need to be consistent. The PGT should not store more resource per volume than the CT/CDT. With the same amount of ingame units on the PGT, some resources would be more efficiently stored than others (compared to CT). This is getting way too complicated. Maybe this is a better explanation: Currently the tanks are balanced against resources in the liquid state. All resources stored in the PGT will result in 5250 L (+/-1) of the liquid counterpart when converted.

Currently not paying much attention to KD, but the time will come The range depends on the beam and the dish-diameter. This is just one of the many reason why tweakscale is very usefull. Great! Also I've discovered this neat addon yesterday: With that we can make almost everyone happy I think. Config with the current 4 setups. Config with the current 4 and additional 3 fuel only setups. Config with the 7 fuel setups above and the noble gases. ... Yes, it is true for liquid resources that have a constant density. It is a bit harder for pressurized gases because the density increases a lot. Also it needs to be balanced with the other tanks and this is where the odd numbers come from. We assume each resource is stored at 75% density of the liquid counter-part. Why 75% ? Well it's a start and may change in the future. Suggestions are welcome! Some other things we've tried:

At the beginning they should just hold 2 liquids (a fuel and an oxidizer), hence the name Cryogenic DUAL Tank. All other tanks are simply not designed to hold 2 liquids at the same time. Later on I realized that 2 liquids are mostly used by launcher-stages and the tanks would have to look kinda aerodynamic, what lead to the current design. After a bit of playing around, I have to admit that it bothers me not to have the option to switch the CDT to Methane only (I mostly fly with MethaLOx launcher and Methane upper stage(s)). Problem is if we now put a setup for each liquid on the CDT, the CT has no real purpose anymore. Also I don't wanna have 30 setups on these tanks to browse through every time. I suggest we add the common fuels as setup to the CDT. LFO MethaLOx HydroLOx HydroOxi LiquidFuel Methane Hydrogen If requested we could also add Kerosene Ammonia Hydrazine "Exotic" fuels (CO, B2H6,...) The oxidizers, noble gases and fusion-fuel shall remain exclusive to the CT. Discussion/feedback/suggestions are welcome!

Thank you for the input! The engine should work in atmo and vacuum like the SSME, so the shape and size will remain unchanged. Model is almost finished: I see, it was just bothering me that the generators have no smooth transition to attached parts and don't use 24 sided cylinders. If you already started to work on a model I don't wanna take it away. Otherwise I'll thankfully take your offer.