Deimos Rast

So...any interest?

I would vote remove BDAnimation and km_Gimbal, since I think their days are done. BDAn might be able to be replaced by "Deployable Engines" that Nertea uses in Cryo Engines. I don't know that it can handle the fancy gimbaling/vectoring jet that BDAn did or Critter Crawler, but it probably has more features than "deployanimationcontroller." I really have no idea, but it's the only one I can think of off hand. There is indeed a community build available, but I wouldn't try bundling that (it seems fine, just would get confusing). km_Gimbal might resurface, sarbian said, in a severely reduced form, but not sure it's worth it.

this looks pretty nifty; I'll have to give it a go when kct support comes out

Go big or go home, eh? I'm impressed all around - by your skill level so far and not letting the accident slow you down too much. Now you just need a "Soyuz in 6" countdown and you'll be golden... Seriously though, keep it up!

Hero linuxgurugamer again to the rescue! Awaiting response eagerly.

I decided to write the patch for you which you can find here. It follows the stock model of adding an SPU to all RLA probes, and unlocked at UnmannedTech, a small omni antenna (3000m ranged), same as stock probes get. Special note: Place the patch inside your RemoteTech folder with the other patches (just remember it's there when you update RT). If you'd like to keep it else where, change the :FOR[RemoteTech] to a :NEEDS[RemoteTech] or "bad things" might happen. In case I clean out my dropbox and delete the patch, below is the contents of the patch, in full. Cheers. @tomek.piotrowski sent a PR.

Pretty sure your problem doesn't relate to the posted plugin. You have 41,014 Exceptions alone (which, honestly, I've had worse, but that's not so good), relating to seemingly everything. Try updating your mods, starting with Kopernicus. I realize that's not much help, sorry.

Actually those aren't modified stock cores, those are unique to RLA, they just look really close to stock. Isn't there a remote tech patch included? I've customized my RLA probes, so I forget what was included. The link below goes to the relevant section on the remote tech wiki (which is quite good). RemoteTech comes bundled with a number of patches you can use as an example. Wiki page Check the link for the module info.

I poked at it a little more and I think I've got it as best as I can get it (tried about a dozen or so combinations of various input/output methods). With this new and improved method (that still has the same problem) it allows for usage of 2 (and I believe more) resources. I think. Normally the RESOURCE sub node is used to define what a module costs to use (think RX Wheel). I've re-purposed it to be the output, and I'm pretty sure you can stack/chain a number of them if desired (haven't found any example of it in the wild, so no idea). The "resourceName" up top is what the light burns when the light is on. It defaults to ElectricCharge (and in that case the field isn't required). You can set the "resourceAmount" to a negative up top as well if you want, as per the old method, that causes it to shut off immediately. There is the possibility that the bottom RESOURCE sub-node might over-ride the previously set consumption rate. Either that or it shuts off so fast it's hard to check. Also, it doesn't seem to output 100 Ore, as you would think. I get values from 20-33 on average (probably 'cuz it's a rate). This has been a rather tough nut to crack (and keep it 100% stock)...victory seems so close, yet keeps eluding me. Quite frustrating. Got any other niggling issues that need poking? I know you never asked me to look into this one, but it's been something I've been curious about for a while. Cheers. MODULE { name = ModuleLight animationName = LightAnimation lightName = spotlight useAnimationDim = true lightBrightenSpeed = 2.5 lightDimSpeed = 2.5 useResources = true //resourceName = ElectricCharge resourceAmount = 1.0 //resourceFlowMode = STAGE_PRIORITY_FLOW RESOURCE { name = Ore rate = -100 } }

Ah, sorry, read the post fast. I'm firmly entrenched in the "end user" frame of mind.

Correct... until recently. MechJeb v2.5.8 was actually released on June 22, 2016 (which at the moment looks like it was the last successful build anyway, so your advice is still good). p.s. Major props to you for helping everyone out, here and in the MJ thread as well.

@RoverDude I noticed a Firespitter version 7.3.0 hiding out in a few of your mods, while the official version is still 7.2.4. Not pushing for an update or anything, but is it okay for people to grab it from your repo in the mean time? (And no, I don't know of any problems from 1.1.3 regarding Firespitter, mainly just for the sake of checking another mod off the "update list")

I think so? Below is from NecroBones' FuelTanksPlus mod for fuel tanks cross mod compatibility. You could obviously change things around accordingly. Alternatively, you could look at the excellent module documentation here (if you haven't already). It's quite good, and can probably answer better than I can. As for the "internals switching" I seem to recall seeing something to that effect in B9 Aerospace, but that uses B9PartSwitch, which of course is another option. Sorry for the half way answers - this is a bit above my pay grade. MODULE { name:NEEDS[!InterstellarFuelSwitch] = FSfuelSwitch name:NEEDS[InterstellarFuelSwitch] = InterstellarFuelSwitch volumeMultiplier:NEEDS[InterstellarFuelSwitch] = 1 massMultiplier:NEEDS[InterstellarFuelSwitch] = 1 tankSwitchNames:NEEDS[InterstellarFuelSwitch] = LF+OX;LiquidFuel;Oxidizer;MonoProp resourceGui:NEEDS[InterstellarFuelSwitch] = LiquidFuel+Oxidizer;LiquidFuel;Oxidizer;MonoPropellant resourceNames = LiquidFuel,Oxidizer;LiquidFuel;Oxidizer;MonoPropellant resourceAmounts = #$../LF$,$../OX$;$../LF2$;$../OX2$;$../Monoprop$ basePartMass = #$../mass$ tankTechReq:NEEDS[InterstellarFuelSwitch] = start;start;start;advFuelSystems }

@NemesisBosseret Looking at the latest RPM release, there is no "0.16-17-upgrade-patch" in the archive, nor do I recall ever seeing one. It's also not from OPT, best I can determine. I would remove it, as per Starwaster's advice. ---- Regarding the Assembly exceptions: those aren't so hot. Make sure you're running the latest possible with plugins. Off the top of my head: I know there are 1.1.3 builds for CC_RemoteTech (from Contract Configurator) and MechJeb; probably for Tarsier, if not soon. Not sure on TCA or LightsOut. If you're running RemoteTech, make sure you're at least using the community hotfix for 1.1.3.

Just letting you know KAC has been updated. Not asking for an update or anything, just in case you don't get a chance to leave this thread ever. @AlbertoKermov For alarms at predefined resource levels, you could try the mods: DangerAlerts or Alternative Resource Panel. Not IVA exclusive, but it's something? Alternatively, if you want actions at predefined resource levels, try SmartParts.

I know this is a necro, guilty, but I feel bad about not seeing any posts in this thread saying thanks, and this is far and away one of the most useful and well done "mods" out there. I can't tell you how many errors I've found with this tool alone (from myself and other modders). It got me into using Atom (and away from using Sublime, thanks for that alone!), which is pretty slick. So thank you! --- There are a few things I noticed it doesn't seem to handle for MM patches, namely :FIRST and :LAST (but those aren't actually listed on the wiki I don't think). Also, usage of "|" for OR makes it go white (which usually indicates bad). Only things I can remember off hand. --- One of the big initial hurdles (besides actually figuring out how to get it installed, haha), was to get it to recognize KSP configs and automatically select the grammar. I had to add the below snippet to "config.cson" under the section "core:" and it works a treat. (Incidently, I also recommend using the Snippets feature). Highly recommended to everyone (as Atom is cross platform)! Cheers. customFileTypes: "source.ksp-cfg": [ "cfg" ]

Agreed on the update schedule, but keep in mind they also need to consider "what's good for the stock game." I shudder at the thought of playing stock, but it's not really fair to those that do to have to endure such bugs longer than necessary. And moreover, to what degree is Squad even responsible for keeping a healthy mod ecosystem? If an update scuttles a critical mod, like Module Manager, does that change anything? Wasn't it just an update or two ago that just that thing happened? I know sarbian was on the experimentals team, and I have no doubt he can handle anything Squad can dish out, but for the littler mods out there? Yeah, can be rough; also rough on the user as well, having to push the mod ball up another level. But that's the price we pay for, what I would argue, is a more enjoyable experience, is it not? Keep in mind I say this as someone who views the entire purpose of this game as "acquire mods" - you buy the game as a ticket to a playground for mods, so for me to be taking this position, I'm exercising extraordinary open mindedness. ------ Anyway, that was way off topic from the reason I'm here. I'm here because of "commenting" in the configs. I think when you comment (like with the Reactor config or the Warp Ring config) it needs to be with "//" two slashes and you seem to have your heart set on using ";" (I know different languages use different comment syntax). I use Atom note (which actually has a grammar specifically for KSP configs, highly recommended) and it's really easy to tell when something is formatted correctly. There are a few other niggling issues I've come across, but off hand the only one I can remember is the RemoteTech config for the Comm99-99. It really does need the line "!MODULE[ModuleDataTransmitter] {}" which deletes the stock data transmitter. Otherwise, the RemoteTech transmitter exists next to the stock one, and you'll have an always on half connection (will only work for beaming back science), but it screws things up. I think I'll put together some optional patches for KeepFit, CLS, EngineLight, maybe some LS (USI/TAC) and...NFE Fission reactors to replace the Zero Point Generators. Alternatively, I could go the stock route (e.g. USI Reactor Pack) and use converters...I just dislike the infinite free energy with no downside. Not necessarily from a realism perspective (this is the Warpship mod after all), it's just... well, boring. I have a few other patches in mind, but those are the main ones. Let me know what you think.

Confirmed, I'm all Chute and no Safe!

Rock on! Thank you kindly.

I was having a lot of problems with NRE's with Ion engines that I added this to in 1.1.3, even when the throttle was off and at full power and not at warp. They were largely NFP engines, but I can't see that it's any different than stock (this weren't PIT engines). But I also had the issue with a stock Ion engine. I don't have the log anymore, so I realize this report doesn't mean a whole lot. I know most mods that have anything to do with Time Warp seem to require at the very least a recompile.

I think I might have solved your problem or at least taken a bite out of it. However, it's not working 100% for me. The solar panels would probably work if you wanted Natural Lighting, but what about grow lamps? Well, there is ModuleLight. ModuleLight has an animationName field (which you want), but it also has the option to useResources. Rooting around a bit, I figured out how to define which resource the light uses, and...here's the fun part...I set the resourceAmount to a negative value, meaning it outputs the resource instead. It works, and with the below module, I successfully got the MK1 Illuminator to beam out Ore. However! It shuts off immediately after you hit "Turn On". It pops out 0.1 Ore per click, then turns off. I suspect it's because it really doesn't like the negative. I've had issues in the past where lights won't work at all if they don't consume some resource, and that might be at play here. I have a few ideas to get around it (multiple inputs/outputs streams, trying alternatively the Converter or Generator models), and I'll poke at it a bit more for the sake of science. I figure with your plugin wizardry though, you might be able to sustain that little bit of momentum, as it were, and keep the light pumping out the 0.1 Ore/Photons/Gummy Bears/etc. And at the Photon level, you probably don't need more than 0.1 (or you could scale it some how). Hope that helps somewhat. MODULE { name = ModuleLight animationName = LightAnimation lightName = spotlight useAnimationDim = true lightBrightenSpeed = 2.5 lightDimSpeed = 2.5 useResources = true resourceName = Ore resourceAmount = -5.0 resourceFlowMode = STAGE_PRIORITY_FLOW }

Seeing this alot with the latest version of both AmpYear and USILS. Cheers. 160624T194239.453 [INFO] [AY.USILSWrapper.LogFormatted] 6/24/2016 7:42:39 PM,AmpYear-USILSWrapper,Invoke LifeSupportRecipe Method failed: Object reference not set to an instance of an object 160624T194239.453 [INFO] [RSTUtils.Utilities.Log] 6/24/2016 7:42:39 PM,AmpYear,Wrong USI LS version - disabled.

Bit of a long shot, but in the off chance you converted it wrong, you could always try DDS4KSP. No ideas otherwise.

Well the panels are just gutted stock solar panels with a new skin; the only really relevant part was the photons. Alternatively, you could try an always active generator with requires all inputs / resource threshold that kicks in when the first photon enters the system from the solar panel or where ever, and ends when the panel is stored. Good luck on finals.

IIRC that mod is a BDArmory based mod, and last I checked, that mod was way out of date. Unless there is a community fix floating around, I think you might be out of luck. Generally, you'll have better luck getting support in the dedicated mod thread: Edit: Nevermind, I see you've already been there and had your question answered.