Deimos Rast

good way to spin it; downloading now. Download is taking a bit (as I'm in a hammock outside and connectivity depends on how close to the house I swing) so I can't check yet, but did you convert any/many of the modules to stock?

https://spacedock.info/mod/739/Soviet Engine Pack ?????

Here be the patches. And a few more comments. The remote tech patch is standard stuff, 3000m omni antenna unlocked at unmmanedTech. I would honestly boost it, since where are you going to put an antenna on this guy? Unless you want to stick a DP-10 in the Cargo Hold. The Ablator + Cargo Bay combo is a bit...awkward. Cargo bays get ModuleConductionMultiplier generally, which your's has, but doesn't that affect the Ablator as well? As is, conceptually, the entire cargo bay is encased in an super ablative substance, not just the bottom. I took one out for an orbital spin to test the parachute, and the bottom doesn't glow, but the cargo bay does, which seemed odd. I would drop the ablator down significantly, as it weighs a lot for such a bitsy part. I personally find the stock ablators rather dense as is, and I think your's is even denser (assuming I'm reading things right, and a test seemed to confirm it). Cheers. KIS RealChute RemoteTech SciBox

@CobaltWolf I did the unthinkable and...skipped siesta. I finished the patches. RT, KIS, SciBox, RealChute. A couple things: I think the Min/Max drag values on the cargo box are flipped (at least the min>max) RealChute might have an issue with the drag on the probe/parachute. I know it adds in a maxdrag value when there isn't one, and sets it at 0.32, whereas the capsule has 0.01, which might affect the parachute (although I think other values override this, not sure exactly which has final say). Unsure on this, probably not an issue. KIS. Currently the patch just adds 500 volume in a 6x8 grid (pretty generous, but 500 volume won't get far and a kerbal seat defaults to getting 300). That's in addition to the cargo bay. That might seem a bit much. What I've seen some people do is create two versions, and on the KIS version, obscure/remove the cargo bay module, so it's just storage. It jives a little better balance wise (since that space has to live somewhere). SciBox was originally taken from the Lab, but I commented out the portion that allows duplicates (last line). I figured it might be a good option to have. RealChute patch - I scaled diameter based on the 375 drag vis-a-vis the 500 drag of the stock Mk1 parachute RealChute patch. Works out to a clean 75%. Probably other ways of doing it, but should be fine. RealchutePatch - has a portion that sets the cost & mass to the current mass and cost 0.1 & 725. This is only and issue if you change it in the configs and forget to change the patch. Not sure it's strictly necessary (it's for procedural sizing changes I believe, which we're not doing here), so can probably be removed. I could probably switch things to variables (for casemass atleast), but, I'm just doing what RealChute stock patches do. I'll post them in a sec, just making sure they load, then it's not my department anymore. Edit1: Initial tests promising, especially because I forgot to install half the mods required to test them.

well you can always transmit back at terrible returns on your investment, but that is a good point. What I neglected to mention is the part in question is a probe, thus gets a RT omni transmitter at (I forget the exact tech) unmannedTech, at a range of 3000m. If you can transfer data at 3000m from KSC, lol, you might as well recover the probe.

Awww, it looks so cute. Looking at the config, generally when you do a remote tech patch it replaces a stock data transmitter, but I don't see one in the parachute module. Also, as is the patch looks like it just adds a standard communotron to the capsule, but it requires a deployment animation, which the parachute part lacks, so it effectively doesn't do anything. You can make it into an always on omni antenna (probably at a reduced range for balance). Also, having the maxQ value will cause the part to break under dynamic pressure, which can cause issues if the part is the root. I'll have a go at rewriting it, and maybe add a data transmitter to the parachute module, if you're cool with that. I'll also have a go at adding a real chute patch as well. Also, if you're open to it, we could do a KIS patch, but that might change the nature of the item a bit. Might I also suggest adding a ScienceContainer module to the cargo bay? Might be a bit, as I'm at brunch, and after brunch comes siesta, and you can't fight that.

Gecko, we need you talk. The rate at which you're cranking out these "must have mods" ...you're spoiling us. You must be on holiday or something, no mere mortal can code this fast! Anyway, grabbing now - thanks!

https://github.com/KospY/KAS/issues None seem too recent, but obviously he can tell you more. I wouldn't worry too much.

EDIT: I see you already know about this, NEVERMIND. I batch converted them to DDS and they now take up around ~140MB. Maybe a little less even. ---- Has it already been mentioned about the size of this mod? (This is with version 1.1.2.01 by the way, stock version, the only one available on Spacedock). Extracted total file size: 511MB Size of entire Squad Folder: 378MB There are Fuel Tank textures that are 16mb large. I have no doubt that's 16mb worth of awesomeness (and from the pictures alone, the parts look to be very high quality), but...damn. I think I might look into file compression options. My computer doesn't lack for resources, but it's the principle of the matter: your mod is 1.35x the size of the base game! It goes without saying, it's your mod, your prerogative, etc etc.

Thanks! I keep bouncing back and forth between the two, hah.

I still get this from time to time.

@SpannerMonkey(smce) Actually no, you can use an RCS thruster, for example, with a negative ISP curve for IntakeLqd as the inflow and another with a regular ISP curve as as the vent. It'll fill and vent the IntakeLqd reservoir as you would expect; you'd need to obviously disable or enable the respective thrusters via action group or they fight it out. Works pretty well and it's 100% stock + CRP. Alternatively, intakes should work fine as long as the resource is defined and present, no? I just know you can have intakes pull in IntakeLqd.

I meant the game, yeah. Unlikely that 1.1.3 Remote Tech will help any with 1.1.2. Something like this would work for you. I use it myself. Adjust to taste. Note: it's written as a patch, but you could simply rip the modules out if you wanted. //-----------------REMOTETECH-------------------------------// @PART[INSERT_POD_NAME_HERE]:NEEDS[RemoteTech] { MODULE { name = ModuleSPUPassive } MODULE { name = ModuleRTAntennaPassive OmniRange = 50000 //---50Km TRANSMITTER { PacketInterval = 0.3 PacketSize = 2 PacketResourceCost = 15.0 } } }

I'm getting a lot of NRE's with the mod still. It happens when I switch to craft with Ion engines - pops 43 NRE's exactly. And again when I time accelerate to a node. Burning a node (without time acceleration) is fine. Haven't tried with time acceleration yet. Seems to all be the following NRE: 160708T065327.041 [EXCEPTION] [PersistentThrust.PersistentEngine.CalculateDemands] NullReferenceException: Object reference not set to an instance of an object at PersistentThrust.PersistentEngine.CalculateDemands (Double demandMass) at PersistentThrust.PersistentEngine.OnFixedUpdate () at Part.ModulesOnFixedUpdate () at Part.FixedUpdate ()

Heh, yea. A few more things: Maybe make the MIT license bit a bigger or it's own section; it's easy to overlook the little icon. You might need to include it in the download as well (and maybe mention the MM license somewhere just in case). I looked into doing the RemoteTech patch for you (see below). Feel free to use if you like it (or not). Not trying to steal yo thunder - just trying to help a local boy out, ya know? I added a couple things to your current patch (see below). Feel free to use if you like it (or not). My thinking is that (albeit rarely) pods will already have data transmitters and your patch will double it. I added a check for it. You probably don't need "DeployFXModules = 0" as that assumes there is a ModuleAnimateGeneric (or something similar) is Module index slot = 0 which deploys the antenna. Unlikely to be the case in this situation. Seriously, not trying to step on your toes - you really don't have to use any of this. //--------------------Stock Support---------------// @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[ModuleDataTransmitter],#CrewCapacity[>0]]:FOR[RadioFreeKerbin] { MODULE { name = ModuleDataTransmitter packetInterval = 0.6 packetSize = 2 packetResourceCost = 12.0 requiredResource = ElectricCharge //DeployFxModules = 0 } } //----------------RemoteTech Support------------// @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[ModuleRTAntenna],#CrewCapacity[>0]]:FOR[RadioFreeKerbin]:NEEDS[RemoteTech] { !MODULE[ModuleDataTransmitter] {} %MODULE[ModuleRTAntenna] { %Mode0OmniRange = 0 %Mode1OmniRange = 2500000 %MaxQ = 6000 %EnergyCost = 0.13 //%DeployFxModules = 0 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 15.0 } } %MODULE[ModuleSPUPassive] {} }

To save you typing:

sent loadingTips spreadsheet via PM; mainly for TriggerAU, but figured you might want a peak.

Thanks for the update! Does this fix the SM colored overlay persisting after crew transfers and the like? The easy work around is to just go to the map and back to the ship and things are cleared up (that's why I never mentioned it prior).

Oh, I forgot I did that (I'm using a customized version I made a few months ago). Whoops, sorry. Middle node might not matter it's orientation, since it's, you know, in the middle. The annoying thing is though, this part (or one of them at least) doesn't get picked up by the IR category filter (not having a MuMech toggle and all).

----- This really isn't a bug, but it took me by surprise and might be of interest to anyone trying to get RT to process queued Maneuver Nodes across SOI changes (as in queue up a node for Circularizing the Mun while still in the SOI of Kerbin). Everything would seem golden till RT got to then end of the burn...and it just kept on burning. And burning. This was with a full connection and with a Spark engine (not exactly a powerhouse) on a ~400 dV burn maybe. After going around and around with the issue, thinking the SOI change was the culprit, it turned out the real culprit was...too much thrust. Apparently RT doesn't like throttling down engines and just goes hog wild (or so it would seem), but a Spark engine at 30% thrust was enough to do the trick.

Do you have Mechjeb Installed? Sounds like you have another autopilot at work. Eitherway, the SAS issue is due to some auto pilot currently being in effect, and it's overriding it and probably conflicting with RT as well. If you don't have MJ, check that you have a clear RT queue. Click the ">>>" button and if there is stuff in line up, "x" out of it. It might be holding a previously issued command for you still. Is this with the official version? There was an unofficial version (but I think that was 1.1.3) that was a debug version. Either way, is there a reason you're tied to 1.1.2? 1.1.3 is so much nicer and will likely clear up (almost) all your VAB crashes. I just checked now and RT doesn't do that under 1.1.3. I checked the most recent patch notes and a few back and haven't seen any thing relevant. Dunno. A ...remote...possibility is you have a DTS-M1 with *Blink Lights* flashing that's triggering updates, but that's unlikely.

Not sure, I put it aside (haven't been at my main computer much lately). On another issue, I was looking at the AmpYear MM patch and I think I might have some suggestions on "improving" it. Actually, it'll be easier to just show you how I rewrote it. I never agreed with the "if it ain't broke" mentality. Does the RealismOverHaul part of the patch work? It seems like it needs to have the "@" removed otherwise it might over write a random resource. Why 80? Does the CrewPart have any usage for non-commanded parts (Hiker's Crew Storage for example)? You could probably use FOR instead of NEEDS, for no real advantage that I can think of off hand, but you could. The important part is that it checks to see if a part already has reserve power....since I might know of a...friend...who has been adding reserve power to all his customized parts (and it's not a measly little 80). If the Mechjeb cleaner part doesn't work as is, could change it to :FOR[zzz_AmpYear] or something, since people get mad at the usage of FINAL. Just food for thought. @PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[AmpYear] { MODULE { name = AYCrewPart } } @PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[ReservePower]]:NEEDS[AmpYear&!RealismOverhaul] { RESOURCE { name = ReservePower amount = 80 maxAmount = 80 } } @PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[ReservePower]]:NEEDS[AmpYear&RealismOverhaul] { RESOURCE { name = ReservePower amount = 1000 maxAmount = 1000 } } @PART[*]:NEEDS[AmpYear] { MODULE { name = AYPart } } @PART[MechJebAR202|MechJebPod]:FOR[AmpYear]:AFTER[AmpYear] { !MODULE[AYCrewPart]{} !RESOURCE[ReservePower]{} }

That...shouldn't be happening. Looking at the config, it's a straight RESOURCE node. Do you have any fuel switchers installed (IFS/B9Partswitch)? Obviously, this mod requires Firespitter - the one bundled with it is out of date, do you have an uptodate one? Do you use the Cryo-Tanks/Cryo-Engines mod? I believe you, but what I think is happening is another mod is deleting the resources an unsuccessfully applying a fuel switch part module to it. I know Cryo-Tanks does that, and recently had a brief buggy release, which may (however unlikely) be the cause. It's a stretch, but if you use that mod, an update of that should fix it.

I'm in a similar boat with github, but I haven't done much reading... yet. I too find it somewhat confusing, but I've been using a program called GitKraken to poke around the repo stuff. I'm not sure if that's the way to go about it, I just like the visual manner it presents things in. Why GitKraken? No real reason...it's free, cross platform, seemed reasonably up to date, and 'cuz Kraken. Not sure how you're going about it, but maybe try something similar? Honestly, you're ahead of where I'm at, so that's the best advice I can give you (which admittedly isn't the greatest). Good luck.

By K+ I'm assuming you mean Karborundum...and CRP still adds Karborundum to asteroids (along with the other stuff you mentioned). See below, it's from Asteroid.cfg in the CRP folder (v0.5.4). --- @Booots FYI, if I'm reading the comment on the cost of the LB15 beacon correctly, you factored in the resource cost into the beacon price. KSP costs in the config are "dry costs" and don't factor in resource costs until the player gets to the VAB. You've changed that, and now effectively the player gets double charged for Karborundum (an additional 1000000) - once in the config and once again in the VAB when they fill up the Karborundum tank. Ouch. MODULE { name = ModuleAsteroidResource resourceName = Karborundum presenceChance = 25 lowRange = 1 highRange = 10 }