Tonka Crash

Welcome to the mod conflict party. The docking port direction patch assumes nothing but ReStock is messing around with the model definitions because stock and stock+ReStock are the only configurations I deal with. I don't have an all encompassing knowledge of every conceivable mod that might modify models in the stock parts. You have multiple mods changing the part definition that are mostly unaware of what the others are trying to do. The picture you show looks like the ReStock docking port, so I'd look at using it's patch as a model for how to address the SSPR docking port. A simpler approach would be to ask how important is the SSPR docking port to you? Is it just simpler to remove the SSPR patch than messing with an IL patch for the docking port? To be a bit rude I don't really care what you do. You have a configuration I don't run, so I'm not motivated to try to fix it, just like @Snark wasn't motivated to write a patch for ReStock. ILCE is a community driven mod, so I'd suggest you figure out what works with the configuration you have that tries to avoid trashing 1) IL+stock game and 2) IL+stock+ReStock. Sign up on GitHub and submit a PR to fix it. SSPR has 20+ crewed parts that need lights, and I've never been motivated to add that, so I don't use SSPR. Just patching one part is kind of lame. If you've never tried writing an IL patch for a part it's tedious and very time consuming to get the light placement figured out and then there's testing the logic for what you want the part to do. It's easy to spend hours per part. I figure some one that actually uses SSPR and wanted IL functionality will eventually take care of it. That person is not me. I had the same issue with ReStock. I wasn't going to figure out the new locations for all the models ReStock replaced, so initially only used ReStock for things without IL like tanks and engines. Then I started using parts with minimal changes like reaction wheels and batteries. Someone else did a pass and addressed enough part that I started using most of ReStock/ReStock+ and started fixing parts that still had issues. I'm still not satisfied with some of the parts, but I haven't been motivated to fix them yet. I originally wrote the docking port direction patch as a change to the core IL patch which was much simpler since it was in the core mod. @Snark wanted it in ILCE instead, so the patch is the adjusting the minimum necessary based on which model nodes should contain the lights that are moving based on where IL puts them in the stock part definition. A more robust fix would be to write it more like ReStock patches. First delete all IL model nodes and then add them back in.

Have you tried it in game, yet? The junior is upside down in that picture, too, but you can't tell which is precisely why I created this patch. That was my first pass to show the concept and I fixed it after flying it in game. But I didn't bother creating a new photo and in over a month since then you are the only one to complain about the photo.

The patch should have everything you need to show you how to modify YOUR game how YOU want. I don't want direction indicators on Konstruction ports, so didn't include them. (Does MKS have a different set of ports). As long as I dock at a cardinal angle, it's good enough. I also prefer that the light pattern on Konstruction ports look different at range from a standard port.

Thanks, I've updated my fork on GitHub.

FOR does announce a mod to MM, but the primary effect is to allow other patches to use :BEFORE and :AFTER in reference to the mod. If you write a patch using :BEFORE/:AFTER directed at a mod that did NOT use :FOR the patch gets deleted and your left scratching your head about what went wrong. If you are interested read the MM wik As you can see from the wiki, it also has the side effect of changing when the patches with :FOR will run. What happened when Snark added :FOR to IL it changed IL from executing before ReStock to after ReStock which affected which model nodes are actually present in each part by the time ILCE runs. It's not just models, but IL controllers and all the other stuff that goes into implementing an IL patch for a part. BTW, when I looked in my game I had an older version of IL patches in my main save, so wasn't seeing the same problems. I looked at it in a clean test environment and your problems were apparent. I just hadn't noticed them when I did my last set of updates since I'd concentrated on parts that I knew weren't working right like the antennas and Sentinel. I have provided a PR to ILCE to fix the Mk2 Lander Can (floaters), Hitchhicker (no lights) and the Sentinel (old light positions). I'd swear I'd submitted a Sentinel fix before since it was already in my fork. There were probably some others that got fixed by cleaning out old meshes that were usually buried inside ReStock models and some leftover models that throw errors in the log with the published version (again I thought I had resolved all these). I also changed lights on parts that use the common exterior hatch model in ReStock to be more consistent across parts. Until @Snark gets around to releasing an update you can get my version of the file at my fork.

ALL modded fairings are broken in 1.10 if that hasn't been clear enough. The fixes I suggested are just turning off ReStock and reverting to the stock fairings that do work in 1.10, i.e. shutting off a broken parts where stock parts exist. If you insist on trying to implement a size0 fairing, I would try patching a known working stock model into the size 0 part config and scale it down. I haven't tried this and I'm not interested in offering help to try working around unpatched bugs in 1.10. I went back to 1.9 and will wait for 1.10.1 to come out.

Even that isn't a great solution. A good number of the IL patches work fine with ReStock. If core IL shuts off if ReStock is present, then everything has to move to ILCE instead of just workarounds. It's doable, but it's a lot of patches that would need to be copied to ILCE. When I was first fixing this locally only I did go through and set :NEEDS[!Restock] :NEEDS[Restock] all through IL to get it to work, but was updates were a pain. I found it simpler to let IL behave with no knowledge of ReStock and just fix it later.

I've been round and round with IL, ILCE, Missing History and Restock. The last several updates were stuff I did, but I didn't see issues with the Mk2 Lander Can V2. I need to check to see if the current releases matches what I'm running. @Iodyne could you upload a copy of the KSP.log and your ModuleManager.ConfigCache? Maybe post a photo of what you are seeing, because I'm not seeing a problem with the Mk2 lander can. I used a vessel with it Sunday. @DStaal The problem is the indicator lights (core) patches often explicitly load the model when a "mesh=" definition was originally used. Restock does the same thing when it reskins these parts, so when you combine the two you sometimes have multiple models being defined. The order of patches can also affect how things end up looking. The last go around I had with the Restock patch I was looking at what ended up in the ConfigCache and adjusted the Restock ILCE patch to deal with what I was seeing. Sometimes this meant deleting "extra" model nodes. When @Snark added :FOR clauses to IL on his last update this changed the sequencing again, so I had to make adjustments and may have missed something.

You can look in your ModuleManager.ConfigCache. Find the Mk2 Lander configuration there and see if the CLS config represents what you think it should. This is usually my first step troubleshooting any config file issue. Look at what got into the ConfigCache and then try to fix it. When I used CLS, I used this patch to deactivate the impassable nodes. It's safer to use patches to change behavior than editing a mod directly. When the mod updates you risk losing your changes your changes are overwritten by the update. @PART[mk1pod,Mk2Pod,cupola,mk2LanderCabin,landerCabinSmall,MEMLander,kv1Pod,kv2Pod,kv3Pod,TaurusHCV]:NEEDS[ConnectedLivingSpace]:FINAL { @MODULE[ModuleConnectedLivingSpace] { @impassablenodes = } } I don't use CLS anymore. I think it's a good design paradigm for craft and still follow it in principal. I just found I'd rather do it by the honor system than waste time debugging connection I thought should work and always having to open hatches to transfer crew. I really don't miss it.

For short videos I use the built in Windows 10 Game Bar and upload to YouTube..

Sounds like you are on 1.10. It has issues and needs an update before working properly.

Well since you quoted a month old post of mine for some reason, I didn't really see anything obviously wrong. No errors are thrown in the logs, but I didn't spend time investigating whether or not this was really working. It was a low priority compared to the mods I had that were throwing exceptions and errors. I only spent a couple hours in 1.10 in my modded install before reverting to 1.9.1. Too many other mods I rely on have showstopping issues. (ReStock, NFLV, KIS, Extraplanetary Launchpads) Until these are patched, it's not worth it to me to play with 1.10.

@IgorZ Minimal install on 1.9.1 KIS/KAS/B8PS and just a couple other mods. To get parts I used ArcAerospace Wyvern Capsule just downloaded the latest version of the code. I've been play testing this as it's being developed. It's a small 2 part mod. Capsule and engine pods. The engine pods use B9PS to swap LFO/Monoprop and long/short variants. It's not just having B9PS installed that I think causes the problem, but trying to install a part that uses B9PS to change models. In the attached video I stuck an engine in a KIS container in the VAB on either side of the capsule. When Bill tries to attach one it blows the capsule off the pad. The engine pod should be at the bottom of the engine category in the VAB with this mod. KSP.Log The first time I tried to make the video I forgot the B9PS install and there were no physics freakout, so I went back added B9PS to the install and got this:

@HansAcker @rrlevy I'm guessing you have a Breaking Ground scanner arm attached to your rovers. This is a bug I discovered a year ago. With a scanner arm something throws off MechJeb at low speed. Without the scanner arm MechJeb behaves normally. I tested it over the weekend in 1.9.1 with whatever the latest DEV version that installs on 1.9.1.

@Joker58th @DeadJohn @IgorZ I just ran a test pulling a part that used B9 Part Switcher (It wasn't from SSPX) straight from inventory and attached it to a capsule on the pad and the resulting explosion blew my capsule from the launchpad to the other side of the tracking station. I think there's a bad interaction around the KIS/B9PS part creation. When KIS pulls a part out of inventory it's created in the game as if it never existed before. I think how B9PS handles multiple models is doing bad things if the part is created as it's attached. I guess I haven't seen this before because I don't have that many mods that use B9PS and the parts that I do have are typically big enough I wouldn't be hauling them around in inventories.

Someone else reported problems with a SSPX docking port recently in the KIS thread (where this belongs). I'm wondering if has anything to do with B9 partswitch on the parts, but haven't had time to test that yet.

Use CKAN and it will install any dependencies automatically. Otherwise the first post in this thread lists the mods this supports. Depending on what mods you use will affect what parts are available to you.

Simple rover all stock parts from my stripped test environment. Same power parts as the rover having the issue, 2 solar panels and 3 fuel cells. Timewarped to night tried to start it and it stops with not enough fuel. Set to use batteries and fuel cells. The test rover has excessive amounts of fuel for a destination that's just up the hill from KSC Test Rover KSP.log

KAS at one time used a compatibility patch to swap parts and change modules to migrate saves from legacy KAS to current KAS. I don't know how if this makes use of a poorly documented KSP mechanism or if @IgorZ wrote his own patch handler to deal with the syntax here. It might be a place to start. https://github.com/ihsoft/KAS/commit/93c39e8dd7fd582030e8b5a38939160a2a24986b#diff-61887a9cb52341a3b0e4b01c5b395a05

@Lisias Anyway to trigger a process to strip craft of the Resourceful node when the process is launched to calculate the .loadmeta file?

@etmoonshade Maybe @IgorZ will have something else to say, but KIS has some issues with 1.10. This may just be another symptom. I tested 1.10 when it came out with my modded install and went back to 1.9.1 to wait for mods to catch up.

@maja I pestered you about a year ago about getting warnings about not enough fuel from fuel cells and the rover stopping. It seems like your fix was to just disable using fuel cells entirely when at night. I carry fuel cells to continue driving at night. I think the fuel consumption or power required calculations are off by quite a bit. Yesterday, Bon Voyage stopped my rover at sundown and I continued the final 170km on fuel cells. Overall it barely made a dent if fuel. Starting from Full 78.2/63.8 LFO End 74.79/61.03. The rover has 2 OX-STAT-XL panels at 2.8 EC/sec (5.6 total) and three fuel cells that say 9 EC/sec (27 total) as reported in the VAB. So it should have more than adequate power. The fuel cells seem to operate on demand, so if they aren't needed they aren't producing power or burning fuel.. A Bon Voyage system check reports 14.94 Generated power /7.00 Required Power, but because it's night it won't run. The (?) info in the system check shows: Solar power 5.94 (while at night with no sun) Generators and reactors: 9 (only counting one fuel cell instead of 3)

Thanks, I was on a break from KSP when those were added, so missed it then and hadn't noticed them until this past week.

I'm guessing you're on 1.10. KIS has issues with 1.10 that match your description and EL has reported problems with 1.10, too. I'd wait for updates.

Mostly hauling Tourists around. 16 tourists headed to Mun to have a walkabout. 10 Tourists to Minmus along with some supplies for the transfer station in Minmus Orbit. Most of my time was dealing with a contract to take some readings near the UFO at Mun's southern pole. @maja's Bon Voyage let me down when it shut down the rover 170 km from it's destination, so I had to finish myself. I gave MechJeb's rover SAS a workout. Speed locked at 30 m/s and do it Baja style. MechJeb gave the rover cat like reflexes to keep the wheels down. Some of the crater rims launched the rover for some serious hang time. I was surprised nothing blew up on the landings. I was able to pick up some science in flight low over the Mun's pole biomes.