Galenmacil

Thanks a lot! Dang, the module manager syntax is so weird sometimes. I read official documentation and tried everything I could find but it all turned to nothing. Your simple "code" works!

Hi everyone. After exhausting all the different combination I could think of and wasting a few hours in the process, here I am: Asking for help. I want to create a patch that will, for every part that have a MODULE named ModuleGimbal defined, add, to this same module, the following key: "gimbalResponseSpeed = 15" IF AND ONLY IF there is no such key already defined. How would I do that? So, this example part: Would become: But this one would not get changed because it already have "gimbalResponseSpeed" defined: Thanks.

Hello everyone. I am currently trying to add FAR module definition to mod parts that do not have included FAR patches. The Readme file supplied with FAR is rather vague on what should be removed and what should be added. My understanding is that, for wings/control surface and any parts that have "ModuleControlSurface" or "ModuleLiftingSurface" you need to do the followings: A - Remove stock module. B - Replace with FARWingAerodynamicModel or FARControllableSurface module with adequate parameters. C - Set all of the following to zero: maximum_drag, minimum_drag, angularDrag, dragCoeff, deflectionLiftCoeff Is this a complete list? Other questions: 1 - What happen when a wing/control surface does not receive proper FAR definitions? 2 - Do I need to worry about defining this? 3 - What about airbrakes and spoilers? Any special procedures? 4 - What about non wings/control surface? Should any special steps be taken? Thanks.

Hi everyone. Dropping by to warn users of this mod that the FAR patches are incorrectly defined for all parts of the mod "Procedural Wings". B9 One seems OK. If you are not using FAR, things are good too. So, while searching thru the "ModuleManager.ConfigCache" file for parts that lacked proper FAR definitions, I came across this (the section is in bold): Apparently, the use of the following line in all "Procedural Wings" mod wing parts CFG files: "-MODULE[ModuleLiftingSurface]:NEEDS[ferramGraph] {}" does not produce the desired effect of removing that module definition from the targeted part because of the ":NEEDS[]" section. Ah much better approach would be to use this instead: Now, for the three "Control Surface" parts defined in Procedural Wings, the same apply but the MODULE name are different: ModuleControlSurface for Stock and FARControllableSurface for FAR. It is quite amazing (and sad actually) to see so many mods with incorrect or poorly done Module Manager patches. This often results in strange and hard to fix issues. I know this mod is no longer maintained but I do hope that any future maintainer would take care of the issues.

I can't seem to find any FAR patch in the supplied files. I would assume wings/aerodynamics parts are not properly supported in FAR?

Hello. I could not find any link to a GitHub or similar bug report page so I will post this here: The part "j_sas" defined in file "GameData\OPT\Parts\main\j_rcs.cfg" contain a redundant definition for Electric Charge. This cause a Warning to pop up in the log file: [...] [LOG 22:39:38.444] PartLoader: Compiling Part 'OPT/Parts/main/j_rcs/j_sas' [WRN 22:39:38.447] Part already contains resource 'ElectricCharge' [...] First definition is found at line 113, RESOURCE { name=ElectricCharge amount=300 maxAmount=300 } The second one at line 125, RESOURCE { name=ElectricCharge amount=500 maxAmount=500 }

Hurray! All hail linuxgurugamer, KSP mod ressurecter extraordinaire! Thank you.

Are you running Windows? If yes, this is probably related to the file system security steams. Basically, you will need to "regain access" to the KSP file. You can do that via the "Security" tab when you right click and select properties. Yes, this can get complicated real quick. Like bit Fiddler said, you could erase the KSP folder but this is not guaranteed to fix the problem if the drive itself is set to propagate security streams to it's "child". Like I said, this can get complicated. PM if you need more help.

Well, the stock feature is not as good as this mod in my opinion. You cannot clearly see which mod caused the exception. I do prefer Exception Detector. It worked for me in 1.2.0. Perhaps there is a certain mixture of mod that prevent it from working?

Apparently, KSP 1.2.1 broke Exception Detector...

But isn't the improvement of all aspect of KSP a good thing? Currently, KSP do not use GPU power to its fullest, far from that...

Microsoft and their <REDACTED BY MODERATOR> Not very productive I know but I had to say it, sorry.

Wow. That beats KSP ground texturing! Maybe one day we will get that in game.

Yes it is. Be sure you have the latest version (as of this writing, that would be TCA 3.2.5). Open the archive and, like most other mods out there, copy the folders (in that case, "000_AT_Utils" and "ThrottleControllerAvionics") to your KSP "Gamedata" folder. You also need Module Manager which is a separate download. If you do this, you will get all the file you need for proper operation of TCA. In game, you should see the "TCA" button on the toolbar somewhere. If not, something is wrong. I am not an expert myself on the use of TCA. I use it only as thrust balancer for VTOL application but it can do much more than that. The important thing is to unlock the various TCA module on the tech tree in career mode to have it work.

You have to unlock "module" in the tech tree for the various features to work. Or you may not have installed the mod correctly and a file is missing...

Can you show me an image? I know that near the KSC, in a flight scene, there are some ugly switching between what appear to be the "distant" KSC mesh and the "near" KSC mesh. Is that what you mean? (an image is worth a thousand words )

Just reporting an issue with Targetron and Contract Configurator: Read this for more details

Like you said, a certain experience in modding KSP is required to start removing parts and editing those that are not "quite right" with MM patches. But, in the end, the log file is your friend to see if everything is working as intended!

I personally use, for some time now, high resolution (8192x4096) mipmapped DDS for EVA cloud textures without noticing any problems. I tend to prefer DDS because they load very quickly since the GPU can use them as is. Yes, they are a lossy format so banding and other minor visual degradation can happen in particular for normal maps in DDS format. Concerning mipmaps, they make textures appear smoother when viewed from faraway but they require more VRAM. For clouds, they are not mandatory in my opinion. A few things are important for DDS format: 1- The texture needs to be flipped vertically. This is done automatically usually if using GIMP, PS or other advanced editor. 2- KSP use DXT1 and DXT5 format. DXT1 for texture without alpha channel and DXT5 for texture with alpha channel for normal maps and calques like flags and, of course, clouds. Normal maps are touchy: mipmaps should not be used with them. Read the OP section, there are detailed explanation concerning normal map in DDS format... or leave them in PNG if uncertain. 3- PNG is a lossless compressed format. Texture needs to be unpacked first then, if required, mipmaps generated which slow down the loading process considerably even more so for higher resolution texture. You end up, however, with a very clean rendering. UI elements and Flags/Agencies logo should be left in PNG format without mipmap generation. Particularly true for flags which exhibit glitches when viewed from far away or at certain angle if in DDS format... DDS example with 10 levels of mipmaps:

You know, the coolest part about the latest update? It comes right from the future! Antipodes is a time traveler I am telling you... He will compile the mod in 2027 but we are the lucky few who can use it right now! Note: The sarcasm skill was used during the writing of this reply. It mainly refer to the release date on the original post being 31-10-27.

You can edit the TextureReplacer configuration file which contain some parameter to control mipmaps generation. But, nowadays, DDS is becoming the dominant texture format for KSP and they can include pre-generated mipmaps if the texture author decide to. So this TR feature is becoming less and less useful.

Quite frankly, the "Dummies" document are not that helpful. They are "visual" yes, but some steps are not necessary (the temporary folder part...) and the last section is no longer required not to mention the .PDF format which is, in my opinion, not mandatory: A simple .JPG or .PNG would do the trick. Also, the "regular" .TXT instructions needs to be updated and made clearer too. Our opinions differ on how KWRocketry should be arranged. No big deal here linuxgurugamer, you have a lot on your shoulders so to speak... But if you are willing to entrust this task to me, I am ready to help.

Yes, the mod will load but you will end up with several either missing or incorrectly configured parts. Believe me, the MM patches in KWRocketry are a real mess... but they work. You are right when you say the instructions should be clearer though.

Reporting non stop log spamming in the VAB with KER 1.1.2.3p as soon as a part is placed:

Possibly related to the various problems with mod buttons not showing is this post: http://forum.kerbalspaceprogram.com/index.php?/topic/55420-120-toolbar-1713-common-api-for-draggableresizable-buttons-toolbar/&page=55#comment-2770188