Nils277

Thanks for the report. This is definitely a bug in the plugin. Will take care of that. Since when did you experience this bug?

This is unfortunately not possible. As @Starwaster mentioned, it is a limitation of KER. Will take a look at the staging of the decoupler. It should be howver a Stock functionality that should work out of the box Might change some of the parts in the future to be rotated better. But there have been some reasons why i did not do that in the first place, but i don't remember what those were. The screenshots in the OP already show the parts with normal and specular maps but only the stock shaders. It should show what the users get without additional mods. But you are right, at least one or two screenshots with TU would be beneficial. What additional support for MKS do you have in mind?

I'm afraid that i can't do much about some parts being held off the ground. The flexible corridor is just the hose from the KAS with a different model, all the work of connecting the parts is done by KAS alone. There is nothing i can think of that i can do from my side. I will take a look at the landing legs though, they got more fragile when Squad updated/changed things on the wheels again. Maybe both of your problems are caused by the physics easing of landed crafts. It changed in the last updates and might cause some side effects. I will take a look at KAS 1.0 when i have some time. A flexible version of the corridor might really be a cool idea.

Update to 1.2.7 ~Doppler Effect~ Changelog: Download:  @se5a I have not found the time to find the cause or a fix for your problem. Hopefully there will be one one day.

What did not work? Do the parts not show up? All the sites in the first post in this thread work and will provide you with the correct download. If you don't have KSP 1.4.0 or above you should look for the files that support your KSP version. When the parts do not show up you have installed to mod incorrectly. The content of the folder GameData from the download (The folder KerbetrotterLtd and the file KSPModFileLocalizer.dll) have to go into the GameData folder of your KSP installation. There should NOT be a GameData folder inside the GameData folder of KSP

Update to 1.6.5 Changelog: Download: @alexus The iva with JSIATP should work now.

@alexus I don't think that it will look more realistic with just a plain (gray) texture from the inside but will simply significantly increase the complexity of the parts. I simply have no time at all to do such a work at the moment. The IVAs with JSI-ATP should'nt look like the ones you posted. Will try to look at it and fix the bug once i get time.

What you quoted was meant for @krrishtheamazing who had problems with missing parts. It is not simply putting a texture inside. The model would have to be changed with many new triangles to have an inside. I don't see a use in it when there is a plain texture inside compared to opaque windows. You will have tje exact same Problem on all parts, even Stock. Why don't you use JSI Advanced Transparent Pods for transparent windows?

It is working in 1.4.5. This problem is very well known. It happens when you install the mod into the wrong folder. The folder has to be: Kerbal Space Program/GameData/PlanetaryBaseInc All parts with windows have an interior. It is visible when you switch into IVA or have JSI-ATP installed which adds transparend window functionality. You can't just make windows transparend and expect the IVA to be visible. You'd have to add the IVA model via code to be visible. Adding the IVA model to the external model to be always visible is is not really sensible. If you want to have the IVA visible with your own transparent windows, use JSI-ATP or look at it's code to accomplish what you want.

Thanks! If you happen to have a save file before the error occures and the problem can be reproduced reliably, i would be happy to see it to find and hopefully fix the problem. Hmm, changing the adapter to not have the wheels on the same height seems a bit weird to me. What height would you expect? In a way tha the top of the rovers is the same?

rotation1 and rotation2 depict the relative rotation change of the movable part of the hitch in regard to the part before and after the hitch. Depending on the direction of the hitch, either rotation1 or rotation2 changes when the hitch rotates. When the hitches are in default state, they should be (0,0,0,1) What are they in your case? Is the hitch locked or unlocked? (Was it unlocked at some time before?) This is indeed a very hard to find bug. It is the first time this problem is mentionend since this mod was released. Have you secured the payload with extra struts to secure it during atmo break? This might at least mitigate the problem . It should prevent the node itself from bending which might cause a difference between the saved relative orientation and the actual relative orientation. I have nearly no time at the moment to find and solve the cause of this problem...especially as it seems to only rarely occure.

Now that you say it, i'm pretty sure that the other converter are switched to TACLS converter when it is installed. Will take a look at the code and might do this change for the reactor too.

From the version file it should be usable for all versions of KSP 1.4.+ will take a look and try to fix that in the next update. I'm not really sure what how it can be fixed. Since the hitches, and the docking port are using the smallest type of attachnode i suspect that the forces from launching the ship were so high that the attach nodes bend too much. I think some struts might have mitigated that problem. Since the docking hitch saves its original orientation it might be that it tries to bend back against the bend cause by the external forces. I'm sorry to say, but i doubt that your craft can be saved without an engineer.

I heard already about that problem. But there is nothing a know that i can do about it. It is a problem from TAC not recognizing some converter as EC producer. I'm not sure but i think the problem will also occur for fuel cells and reactors from other mods. It would be somehting that has to be added to TAC. And i think it is a lot of work that has to be done.

have you tried the to do the same thing withe the base from KIS/KAS? Does this happen there too? The part uses the very same modules to work exactly like the ones shipped from KIS/KAS. I'm also not quite shure what exactly you meant, so it might be that i misunderstand you, screenshoots might help to illustrate the issue The side docking port of the Lynx is actually able to adjust its height (from the right click menu) to also be able to dock to bases that are lower than the rover:

It is used in the very same way the ground base (or plate?) from KIS/KAS is used. The documentation from KIS/KAS should describe that thoroughly.

No there isn't. The support for Tweakscale is only very limited. Only the corridors can be scaled by it. All other parts (especially the crewed ones) are not really meant to scaled up or down. Which parts did you want to scale?

You are right, thanks for the report. Will be corrected in the next version. The hover engines are not meant to be able to be usable in full speed over difficult terrain. Just like a wheeled rover will likely flip over or worse when passing the same terrain with an equal speed. The maximal hover hight is also acutally 4m The limit for 4m is also due to technical restrictions. All KSC buildings are considered terrain in KSP. So when to rover hovers high enough so that one or more hover engines can get on top of a building in hover mode the rover would immediately flip over. If you really want to hover higher, go into the "GameData/KerbetrotterLtd/FelineUtilityRover/Parts/Engine" folder and open the files "HoverEngine.cfg" and "HoverEngine_rear.cfg" search in both files for the line "maxHoverHeight = 4" and change it to whatever height you want.

Hmm, i remember that i did have plans for an adapter between KPBS and FUR that i wanted to add to KPBS. I did not get the time yet though to do that. Not sure about the adapter to 1.25...will have to think about that. I do not have Patreon or similar to get money for my mods as they are as much a hobby for me as playing them is for you. If you really want to spend some money, donating for a good cause is always a good way: e.g. for the Huntington's Disease Foundation Sorry, but i'm afraid that FUR and KPBS are and will be my only two mods for KSP. Being more aware than ever how limited time can be i don't think i can afford the time to create a new full scale mod. That'll be a task for another modder.

Hmm, seems i forgot to make the docking ports passable for CLS. Shouldn't be a problem with 1.4.4 Will take care of that problem in the next update.

You'll be able to produce Supplies with the Greenhouse and the container greenhouse. I just don't know if RO changes something in that regard. You'd have to ask that in the RO thread if those parts do not produce Supplies Have you even tried to run this Mod with KSP 1.4.4? I don't know of any problems of the latest version of KPBS with 1.4.4. If you have found any problems that are caused by 1.4.4, please tell what these problems are, they can't be fixed otherwise. See here to learn how to report bugs:

Have you even tried to run this Mod with KSP 1.4.4? I don't know of any problems of the latest version of FUR with 1.4.4. If you have found any problems that are caused by 1.4.4, please tell what these problems are, they can't be fixed otherwise. See here to learn how to report bugs:

Going trough your calculations and e.g. universal storage i see that you are right in that the ratio is not correct. But at least for the elektron in the other direction. You calculated that the ratio has to be 2:1 rather than 4:1. Looking at universal storage the values are 8:1. Exaclty what you correctly said to be the mass relation. And the mass relation is what has to be used for the convertes rather than the volumes. I'm not quite sure how much i will change the conversion rates of the parts because this influences and more importantly imbalances the whole setup maybe causing bases that were self sufficient before to lose that self sufficiency. Will see how i can apply the changes without destroying this. You can of course also post the changes you made to the config files if you like.

Hmm...i did not really try to make the conversion rates as scientifically accurate as possible, but tried to balance it against the conversion rates from other mods (mainly TAC-LS itself and universal storage). Will take a look at them again and adjust the rates if i find differences between the ratios. To you edit: You are right. Will fix that for the next update. I will have to add the wheel explicidly to the contracts via ModuleManager so that contracts accept the wheels from KPBS. Will do so in the next update. HOWEVER these changes will not affect contracts that are already accepted, only new contracts. The only way for you might be to fiddle with the save file itself and add the wheels there to the correct contract. If you try to do so, make sure to make a backup of the save beforehand. You'd have to add the name "KKAOSS_Landing_Gear2_g" to the names of accepted wheels. Sorry i do not really play around with save files that often and don't know where exactly the change has to be made.

@JonBar I might have found the reason. I actually did one change for the reactor. I changed it so that it does not run/produce EC when the EC is full. So when your EC is full it does not use any Uranium and also does not produce any DepletedFuel. With the already pretty low resource consumption it might appear to be nearly zero. Will change that behaviour in the next updates as it fits better for a nuclear reactor to always run regardless whether EC is needed or not.