Auriga_Nexus

Cool! Thank you for your hard work. In the meantime the workaround is to make sure your ship is generating enough power to cover the Grabbers without needing to draw from Battery. My ship design is basically an autonomous section of a 2.5m form factor space station that undocks and goes to pick up station modules dropped off near the station to add to it. It has a couple of robotic arms with Grabbers to latch onto modules that don't have 2.5m docking ports on both sides such as airlocks, endcaps, and the ELP orbital pad. Since I have the Near Future suite of mods installed I just slapped a 0.625m miniature nuclear reactor and a radiator. Running the reactor at 25% generates 15 EC/s which should be plenty. EDIT: More details from my struggles... apparently it refuses to recognize certain power generators. I was able to get multiple Grabbers working with the stock RTG generators; however, when I tried using Near Future Electrical's nuclear reactors they had the same issues as they did with the batteries above despite generating twice as much power. Since I haven't gotten that far on the tech tree in my career save this has caused me to have to scrub a station construction mission and de-orbit two of my service orbiters for being, if you'll excuse my Gaelic, absolutely fecking useless. Finally, while they DO work in symmetry, they only work one at a time and you have to activate them via the PAW rather than through PartCommander. If you try to activate one in the PAW when another one is running it will do one of two things, either it will bug up and refuse to switch in the PAW, or it will activate but deactivate any others that are currently active. Which behavior is demonstrated depends on whether it was the one placed by the player or the ones placed automatically by the symmetry tool - the former seems to override the latter, so the directly placed Grabber will turn off the other symmetrical grabbers and run but must be turned off in order for the others to work. I've frankly given up on using IR for my station construction because its been too many bugs, I only have so much time for games this week before work and school start up again and my station construction has been delayed several play sessions due to having to troubleshoot this. I'll give the new patch a try in my test sandbox save once its been released, but I'm done dealing with it in my career save.

I do have IR Connection Systems and Docking Functions installed. Let me try installing your most recent update and see if that fixes things. EDIT: The IR-NXT patch released 5 hours ago does not fix the issue, but after some testing I've figured out what the issue is - the Grabber is shutting down due to lack of power. However, this is because it is not pulling power from battery, instead relying only on power being actively generated by the ship. I tested this by running the grabber on an RTG-powered vessel generating at least 3u/s of electric charge, it turned on and off just fine, but when I added a second grabber and tried running both at once (exceeding the power my ship was generating) they both shut down. This is despite having at least 1200 EC's stored in batteries. My previous ship design had batteries and solar panels, but the solar panels were insufficient to run the 4 grabbers I had installed. So the question is, is this intended behavior for the grabber? Seems weird that it won't draw from batteries at all.

I'm having a problem with the Utilitron Grabber, clicking Activate on the PAW or in Part Commander doesn't seem to work, it clicks on and then back off again in a fraction of a second. Have a pretty huge modlist, so not sure if its a conflict of mods or an issue with the part itself. If you decide to troubleshoot it let me know what you need and where in the directory I can find it (logfiles, etc) and I can send them to you.

I'm having an issue with one of the US2 wedge modules, the Soil Moisture Sensor. Somehow the SCANSat functionality isn't appearing for the part in the parts menu or in flight. SCANSat scanning works for the normal DMOS Soil Moisture Sensor, and it also works for both normal and US2 wedge versions of the Magnetometer Boom for Ore scanning and the Mutispectral Array for Biome scanning, its just the US2 wedge of the SMS that isn't working for water scanning. UPDATE: I think I may have found the problem! I was digging through the CFG files and found a typo in the module names under the DMagicSCANSatScanner file [C:/<gameDirectory>/GameData/DMagicOrbitalScience/Resources/DMagicSCANSatScanner.cfg]. The part in question is the second-to-last @PART entry and should be named "dmUS2SoilMoisture" but had the name "dmUSSoilMoisture2" instead. I edited the file to correct the name, getting ready to see if it works now. UPDATE: So while I was correct about the typo in the CFG files, I have a bigger problem. Been trying to figure out why despite having functional water scanners, water isn't showing up on my list of resources, even for planets that quite obviously have it such as, oh I don't know, Kerbin. Turns out the issue is from the supposedly final release of Community Resource Pack. SOMEONE apparently had the bright idea to remove the default resource distributions that normally came packaged with CRP, with the justification that "modders can provide their own resource distributions for harvestable resources". This was apparently after a slap-fight on the forums with JadeofMaar over the Rational Resources mod which stepped on a few toes regarding default resource distributions used by other mods. Without those resource distribution files there is no water on Kerbin, the ice caps of Duna or anywhere else for that matter, so its small wonder SCANSat couldn't find it. Ayayayi.... I mean this absolutely in the passive-aggressive Southern style of speaking when I say to everyone involved in this - bless your little hearts. Thankfully I may have a solution - they have the old resource distribution files on their GitHub. If I can figure out the structure on how to include resources and reference everything that needs to be reference, I may be able to add it to one of the mods that I need it for. Probably either TACLS which is what I need the water for, or KPBS which adds a water drill and additional scanners. Either way looks like I'm getting a hands-on crash course in modding KSP tonight. I'll keep you posted on the results.

How does it work though? Do we have to mine or extract it somehow, or does it trigger automatically on approach?

Question, what do the tetrahedron Space Anomalies actually do? Are they like asteroids for harvesting Graviolium? Also they're heavy. I have one in Munar orbit that I attached a docking node to but getting it to Kerbin is going to be a pain.

Whatever happened to the mini algae farm that was in the Kerbal Planetary Base Systems form factor? I can't seem to find it anywhere on my parts list or my tech tree. There's a greenhouse module in that form factor under the "Hydroponics" Tech, but no algae farm. Trying to figure out if it was removed from the mod or if I just screwed up something somewhere and am missing it.

I recently started playing KSP again after a long hiatus, and I'm playing with both this and the TAC-LS mod installed. I just noticed there is a part missing that was there about a year or so ago - its basically a TAC-LS algae farm that fits the quarter-cylinder container form factor used by KPBS. It converts the solid-waste resource from TACLS into fertilizer for use in the greenhouse to grow food. I'm not sure whether it "belongs" to this mod or the TACLS mod, but I kind of miss it because without it I don't have a good way to produce fertilizer for my station. Surprisingly the container greenhouse module that grows food from fertilizer and CO2 is still there. I'm trying to figure out if it's an issue on my end or if the part was removed from the mod for whatever reason.

By dependencies, you mean ClickThroughBlocker and Toolbar Controller, right? At the time I posted this originally, no. However, I went back and installed both via CKAN, and ran the game again. Still nothing. Also just an FYI I am running the Windows version of the mod. EDIT: Not sure if this is the cause or not but I did realize, rather stupidly, that the version of Toolbar Controller on CKAN is not the latest version. After manually installing the latest version from GitHub everything works. Some old bull@#$^ really. Have I ever told anyone how much I hate CKAN?

Just got back to KSP after a hiatus, now I'm having this same issue. Fresh Steam install of version 1.6.1+DLC with no other mods. Downloaded from Spacedock, followed instructions to the letter (unpack .zip file, copy contents and paste to KSP root folder). No toolbar button appears and Shift-L does nothing.

Can't help but notice it seems that the Infernal Robotics mod got abandoned. That's a damn shame as it is quite a useful mod. What surprises me is that there are other mods (such as Konstruction) that use articulated parts - arms, cranes, and the like - similar to how Infernal Robotics worked, but none of them quite manage what IR used to do. Case in point, I want to build a crane that can pull a large (2.5 m) part off of a rover trailer and place it in the hold of a spaceplane. However, Konstruction's magnetic crane is too small to do so. If IR still existed I could simply use structural parts and KIS parts to build my own crane. I guess my question here is, did IR truly get abandoned? Or am I just missing updates? I haven't been super-active on the forums for a few years or so.

Thanks for the advice about calibration, it solved my problem nicely. However, now I have a different issue. Whenever I try to use Mechjeb to automatically execute maneuver nodes, control surfaces/SAS will orient my rocket in the correct direction without my input on the stick, however the throttle will not engage automatically like Mechjeb normally does when you let it handle maneuvers for you. I suspect this is somehow related to the fact that every time I change the mod settings and then leave the flight scene, they return to default upon returning to the flight scene, even though I've saved them seven times over before leaving flight scene the first time. This includes a pesky little setting called "AFBW overrides SAS and other control inputs", which is enabled by default but I prefer disabled for the sole purpose of letting Mechjeb control my craft when I don't particularly care for manual control. I expect this setting to be the source of my problem; however, it also doesn't help that even with the setting disabled it still doesn't let Mechjeb have the throttle - that is of course, assuming the setting is disabled at all (and seeing as settings tend to revert every time I leave the flight scene I suspect what I'm looking at is effectively a placebo button that does absolute jack). Can anyone else confirm this to be the case? Running 1.4.5. Also I should mention that for a brief period last night I was not having this problem; I leave the game and come back a day later and it's back again.

Thanks, I'll give it a try and see if it works. You'll hear from me either way

Thanks for this mod - it works a lot better for my Thrustmaster HOTAS setup than using stock inputs + TM proprietary profiling software. However, I do have one issue that I haven't been able to resolve yet. When mapping the throttle slider of the TWCS controller to the game's throttle, I've noticed that it treats the throttle like a forward/reverse throttle rather than forward only. However, since there is no "reverse throttle" in the game, it just sets the throttle to zero until my physical throttle is higher than 50%. I'm trying to figure out how to change the settings so that it treats the entire range of the throttle slider as 0% to 100%, rather than -50% to 50%. I don't think I can do it with my profiler software (which is stupid) but is there a way to do this with the mod? Thanks!

Note to self, do not let the hypoglycemic post while hungry. My apologies.

Offense taken, how was I supposed to know you were going to get butthurt over a minor suggestion. But fine. I'll drop it.

Cool. Also if it helps, I noticed @jd284 mentioned that it possibly had something to do with the warp drive part being root or not, if so that makes sense because of my ship design. The warp ship itself is fully remote-controlled, but has docking rings in the fore and aft to accommodate manned modules and/or resource containers (its purpose being to deliver RocketPart and fuel containers, as well as crew, to planet and moon bases that I will be constructing via EPL) When I tried to jump I had a manned module docked to the forward docking ring. This module was actually from a larger multi-stage rocket, and in all likelihood the docking ring on the manned module was root for that ship, while the warp drive was root for the RC ship (I built it all around the drive so I could ensure parts stayed inside the bubble). It's possible docking the two craft together superceded the root part somehow which caused the drive to fail. Though it does sound like you've already developed a fix, figured I'd throw that out there as a theory. Might help catch something you missed, maybe. Thanks again - can't wait for the updated version! My crew is stuck in orbit all disappointed while Mission Control is trying to figure out what went wrong and program a software update, and you know what they say about monkeys Kerbals and typewriters

One minor thing I would like to see... would it be possible to allow the mod to generate the CCIP (Continuously Computed Impact Point, aka the red X on the surface of the planet in map mode that shows your actual landing point on the map, taking into account planetary rotation) even on planets without atmosphere? I mean yeah, the lack of atmosphere will make the trajectory the same as the stock rail projection, but even so the stock model doesn't take into account the rotation of the planet. It would make pinpoint landings on planets or moons without atmospheres much easier. Also while on the subject of the CCIP I would also like to see the possibility of it being projected onto the terrain in Flight Mode, augmented-reality style, so that you can see the affects of minor adjustments to trajectory without flipping back and forth from Map and Flight modes. This, again, would benefit people shooting to land on a dime (i.e. landing directly at KSP's launch pad to maximize return on reusable stages, or within 50m of a planet or moon base to facilitate refueling and resource transfers).

Cool, I was just about to ask about this exact issue, it's always a good day when you come to report a bug and someone else has already found it. So yes, I'm having the same problem here but since it seems a fix is already in the works, I'll be paitent

Let me know if and when this change is compiled and I'll test it out. I haven't had that many issues with KAS other than the autostrut issue. It could be possible that you forgot to add the function call to the code for disconnecting the vessels. Autostruts are kind of a new thing after all, and something that works more in the background than anything else. That being said... how much of the code governing stock docking/undocking is used for KAS?

But they don't autostrut to the root, they autostrut to the heaviest part which may or may not change depending on the composition of a ship. If they autostrutted to the root and STAYED there even if the ship docked or was connected via KAS, that would fix the issue while still maintaining the reason for autostrutting in the first place.

They're not much use with that anyway because of the issue with landing gear autostruts, any lander of mine that connects to my base once is stuck there forever or at least until I C4 the @#$%er. Then it's a pile of landing legs with no real purpose.

It's already been reported to KAS, but right now they've only got the workaround of "not using landing gear and KAS parts on the same ship" which is zero help. I'm trying though to figure out why its necessary to have autostruts on landing gear turned on automatically and why they're locked to the heaviest part - can we at least change it so that it is locked to the root or grandparent part instead? That way I can at least have a craft with landing gear that won't fuse with my base every time I need to transfer resources.

No no no. you misunderstand what I'm getting at. The problem is not that the two craft become one when connected. That is not the issue. The issue is what happens when I do the opposite and disconnect, making one craft into two. When the crafts are first connected, the autostruts are reconfigured as if they were one craft, but they do not change when the crafts are disconnected. The main issue is I've got landers that are still "connected" to a base even after they've been disconnected.

This has already been mentioned in several mod reports but from what I understand it's an issue that extends to most, if not all, mods that deal with attaching/unattaching parts and vessels together without using docking ports. Basically, if a part has been auto-strutted, and the ship that part is attached to is linked to another ship via, say, the KAS connector ports, the auto-struts re-configure themselves if they are set to "heaviest part". Whichever ship has the heaviest part, the auto-struts on the other ship will link to those instead. The problem, however, is that the re-configured auto-struts remain in place linking the two ships together even if the ships are later un-linked, meaning that you have two ships that are visually separate but invisibly attached together, making it impossible to move the two apart. Which wouldn't be so much of a problem if wheels and landing gear weren't already configured so that they are locked to auto-strut to the heaviest part. I'm not sure why these are set and locked that way, but we need to be able to change that so as to avoid this happening. The option to change autostrut even appears on the context menus for landing gear, but it does absolutely nothing - why even put the option there if they are hard-coded to strut to the heaviest part? This is making planetary and moon-based surface operations nigh on impossible for me since I rely on KAS links to refuel landers and pass harvested resources between entities. I've had to on-purpose destroy several landers that became locked to my base upon unlinking, because they would not move upon takeoff. Either we need more flexibility in changing auto-strut options, or we need better recognition when two ships are separate.