Tarheel1999

Are the stakes 15m from the edge of the base or its center of mass? I'm not sure exactly how EPL determines survey station location but I would guess it's based on the center of mass of the vessel the survey station is connected to (because that is normally how things in KSP work). If you have large fuel depots or something else heavy far away from where you are building that could be the source of your problem.

Take a look at the configs in TAC Lifesupport. Taranis has an elegant patch which increases electric charge in every manned command pod.

Try without Tweakscale. I don't know what the current state of it is now that it is under new management but it has had A LOT of issues in .90.

You need nil2work's spp patch. It's the last link in his sig. http://forum.kerbalspaceprogram.com/threads/84054-v0-90-v-25-Transparent-Pods-v1-2-2-for-KSP-v0-90?p=1230915&viewfull=1#post1230915

Nuclear Power Generator

Before leaving the editor right click them to make sure they are armed and deployable. Testing in the editor can put them in an unarmed state.

Excellent! No more invisible parts. No rotations errors. No obvious memory problems in Windows 7.

@troyfawkes I'm sorry you had that experience. I'm not sure if it's representative of other people's though. I've experienced the crash multiple times due to the reflective parts and I've never had a vessel corrupted. I just quit the game and commented out the part giving me heartburn. From the forums, I know other people had a similar experience. While shaw works on a fix for TR, the current solution is to rename the TR reflection patch like you did or comment out the problematic parts in the TR MM patch. In my experience those were the gigantor solar panels and the MK1-2 pod. Now, I'm not sure how deleting all your vessels is a solution. Why bother keeping the save if all your vessels in flight are removed? Why not start over fresh? Now if you are talking about your crafts, you can just delete them from the ships folder in the save. But, I think it is unlikely that the TR patch corrupted any crafts in your ships folder because neither TR nor KSP work that way. If you are having problems with crafts you probably deleted parts that were in those crafts. That's a no go and will always cause problems if you try and load a craft that is missing parts.

Because TR disables its compression and mipmap function when ATM is installed. So this error shouldn't occur with ATM installed. I also assume you are not using forceopengl to run KSP as I wouldn't expect a D3D call to be made in such a case (but I could be completely wrong). I'm using DDS textures, have ATM and TR installed, and the USI mod mentioned in sarbian's post and have not had this problem. However I'm also using forceopengl.

If you have USI Kolonization/MKS installed, it disables the stock EPL parts in a MM cfg. MKS has its own production cycle and replacements for most of the parts but no recycler.

It can't hurt but it shouldn't be necessary. I usually clear the cache anytime I update a mod.

Selecting attached parts in the editor like Ven's solar panels has been an issue since at least 2.2.5, for me at least. So not necessarily a new issue with the most recent dll.

Issue submitted.

Okay, symmetry is fixed but you need to do more than change moduleId to moduleID. You also need to remove the semicolon from the end of the moduleID lines. One of the Cargo Pods is also missing a moduleID = 0 in the first FStextureSwitch2 module. For consistency with the FS documentation I also placed the moduleID line under the name value/key. So the working Cargo Pod had values like this (with the ID increasing for each texture switch module): name = FStextureSwitch2 moduleID = 0 The broken Cargo Pod had values like this (note the semicolon): name = FStextureSwitch2 moduleID = 0;

Thanks Ramarren! The new Firespitter fixed the first tank issue. That's a newer version than was recently distributed in MKS. I doublecheck the symmetry issue later. Thanks again RoverDude - its FTT_Cargo_375_01 and FTT_Cargo_375_02. I don't think any other parts have multiple texture switch modules combined with a fuelswitch module.

Good job! Looks like would be a tough edge case to find. You would need TR, D3D, and no ATM. Which is probably a rare combination.

I'm not so sure the issue with stock tank values resetting using the Atomic Age MM patch is a firespitter problem. The AA patch added a FS fuel switch module without also deleting the pre-defined resource amounts in the stock tanks. I don't think that is how the FS fuel switch module is intended to be used. Look at any of the mod parts which use the fuel switch module (like B9), they don't separately define the resource nodes for resources handled by the fuel switch module.

I'm not experiencing the problem that I know of but I can tell you what mods I don't have in that list (it's a short list). Fusebox precisenode stage recovery targetron transferwindowplanner advancedanimator universal storage mini-avc there are a couple of Firespitters in the wild right now and so I couldn't tell you if I have the same version.

TCFirebird, They all appear to be fixed in the Cargo Pods except for the first resource (Ore). The tankcost value is correct but Firespitter doesn't seem to be updating the value in the editor or in game. So an empty cargo pod of Ore will still return negative values. I think this has to be fixed in the Firespitter code and not the part cfg.

You can do that or you can just copy and replace the part cfgs into the appropriate directory. The trick is that the "tankcost" line in the part config file needs to be more than the cost of the resource. So for a tank that holds 9000 rocket parts the tank cost needs to be more than 9000 * 5 (45,000). This is because Squad decided to define tank cost as the cost of a FULL tank and not an empty one. So when you empty a tanks is subtracts the resource amount from the cost of the part. I'm sure most modders would have preferred if they had done it the other way. Resource unit costs can be found in the Kolonization and the CommunityResourcePack folders.

This problem shouldn't affect the Kontainers (or the MKS Storage Tanks). I misspoke when I referenced Kontainers rather then Cargo Pods in my post below (I've since edited it - whoops). The problem should only exist with parts with multiple FStextureSwitch2 modules like the FTT Cargo Pods (small and large). The Cargo Pods give you three options - Change Cargo, Change Main Texture, and Change Trim Texture. Each of those is handled by a separate texture switch module. Firespitter appears to be getting confused about which module changes what when you attach the cargo pods in symmetry. Which is why the Cargo changes when you change a texture and the textures of the Cargo Pods get out of sync. I pretty sure this is a bug in Firespitter that happened when Squad made changes to the Editor and Symmetry in .90.

Taniwa - When you get a chance could you add the info about survey stakes (origin, direction, bounds) to the OP? Right now the information is contained in the version releases where you added or changed features which makes it a little hard to find. Thanks.

It fixes the crashes using Ven's parts but definitely also causes invisible parts in flight and in the editor and throws a lot of NullReference Exceptions. I was both able to launch a vessel and view a vessel already in flight with gigantors. I also launched a Mk1-2 pod with two OX-STAT solar panels (both using Ven's retextures). So far so good, I couldn't do either before. I reverted to the VAB and removed the OX-STATs and then the Mk1-2 disappeared. I was able to fix it by adding a part (the nodes still show up when you select a part) and then hitting Control-Z. I looked at a Mk1-2 in flight with two OX-STATs in a similar location (on the sides at the very top) and the Mk1-2 disappeared leaving all other parts visible. When I changed to the map view I was still able to see the parts when I went pack to ship view I could see the vessel plus a super-sized, exploded view of several of the parts. It was like the Hell Kraken but with parts rather then the blue hole of death. Here's the log. https://www.dropbox.com/s/y9fyv7vajwjx0mb/TRNullRef.txt?dl=0

While not clear from your post, my guess is that you are only having this problem when you attach the cargo pods with symmetry. The same thing happens to me when I use symmetry. It doesn't happen when I attach the cargo pods individually. I think this is a bug in Firespitter. @RoverDude - My best guess is that Firespitter gets confused when there is more than one FsTextureSwitch2 module and parts are attached using symmetry. The moduleids are supposed to prevent this but they don't seem to be working. The editor changes in .90 are probably responsible for the breakage. I spent a couple of hours playing with configs and modifying my persistent without success. I never thought to test what would happen with just one textureswitch module because I was going for a certain look but I bet this problem would disappear. I haven't noticed this problem with parts with just one module (like the storage tank but I'll test next time I load up KSP). Edit - Tested with the MKS Storage Tanks attached with symmetry and no problem with Firespitter. Tested Large Cargo Pod attached with symmetry with one the cosmetic texture switch modules commented out and it was still buggy/flaky. Tested with both cosmetic modules commented out and there was no problem.

I assume NK is referring to .11 which had the fix but wasn't officially published after Net-Burst reported a hang/crash.