Rybec

Hey, glad you're maintaining all these great old parts. However, there's an issue with CKAN dependencies. You removed Atomic Age's dependency on Firespitter in the parts themselves, but CKAN is under the impression it's still a requirement. And not just Firespitter Core either, the ENTIRE Firespitter mod. Looking at just the Atomic Age portion. The combined all-in-one CKAN listing does not list firespitter as a dependency. Thanks again for taking on this ridiculous pile of maintenance.

Whoa, working shadows..... ....could you make other bodies cast them as well, for visible eclipses? It'd be really nice to finally have a visual indicator for being in the shadow of a body other than the one you're orbiting. No more wondering why your EC is suddenly running out, if Kerbin's blocking your sun on the Mun (or vice versa) you'll see it.

Well. That explains the blown out horizon.

Well this is interesting. Part of me really wants to install this. But the OCD part of me has an issue, which maybe you can find a way to address: Is there any way you can roll the camera in map view to be level with the ecliptic? That would make this perfect.

I don't know how possible this would be within KSP, but one clever solution I've seen for killing terrain tiling is to use a single texture that will tile seamlessly to itself from any orientation, or if flipped. Then, you make each tile pick a random x/y flip and rotation (increments of 90 degrees, in case that wasn't obvious).

This is a neat idea, you should advertise on the kOS Subreddit.

I like the idea of experience effecting habitation duration, and I think it ties in well with the concept of orange-suit immunity. Maybe an option to make the badass flag also grant immunity would make sense? On the other hand, that could also make things rather more complex and harder to plan for, which is the opposite of why I use USILS over the other options...

Counterpoint: Who says they have to stick out? Why not stick IN? http://puu.sh/jWypv/d0be6e63d5.jpg Without the docking ports, a simple square t-hub fits nicely within 3.75m. With the docking ports, the very edges just barely stick out. Otherwise, they'd have to be all the way out here: http://puu.sh/jWyAS/6824f7dc38.jpg Something you might consider is some "fairings" on the bottom nodes that lets you stack modules on top of eachother and have support structures appear (or take a leaf from Ven's Stock Revamp and have multiple nodes, one with a fairing and one without). Going along with that idea, the normal T-hubs could have a support structure that appears if you stick something on top of it: http://puu.sh/jWzEy/f617f897f0.jpg I really like these parts. They have a wonderful aesthetic to them. They even make nifty rovers; though I needed to use Infernal Robotics arms and wheels to get enough ground clearance to avoid bashing my cockpit in.

Is there any particular reason why KSP AVC is now a listed as a dependency in CKAN?

Mk2Expansion/Parts/Aero/Chines/ Mk2Expansion/Parts/Aero/mk1Chines/ Mk2Expansion/Parts/Command/Fishhead/ Mk2Expansion/Parts/Command/Raven/ Mk2Expansion/Parts/Command/Viper/ Mk2Expansion/Parts/Engines/Aerospike/ Mk2Expansion/Parts/Engines/PLUTO/ Mk2Expansion/Parts/FuelTank/Inverter/ Mk2Expansion/Parts/Structural/ Mk2Expansion/Parts/Utility/DockingPort/ Mk2Expansion/Parts/Utility/RCS/C_Block Mk2Expansion/Parts/Utility/RCS/Cblock Mk2Expansion/Parts/Utility/RCS/E_Block Mk2Expansion/Parts/Utility/ServiceBay/ Mk2Expansion/Spaces/RavenPit/ Mk2Expansion/Spaces/TunaPit/ That's all the stuff I've pulled out. I don't need chines because I have b9 procedural wings (but would totally use them if I didn't). I've pulled the cockpits out largely to reduce part clutter (most of the time I'll probably use the mk2 inline with the hypersonic nose as it has the least drag). Engines/service bay were removed due to overlap with other mods. Docking nosecone was removed because it's not pointy enough for supersonic flight and my use of connected living space means I can't really put it at the back. The inverter and the structural hubs are interesting, but I just don't see myself ever using them. I've seen cool stuff made with them, but that's just not my build style.

That's what I do, some parts in here are really neat and I like them a lot, but others I would never ever use or are redundant with other mods I use. In other words, just do whatever you want, it's your mod. You can have as many or as few engines as you like, and if we disagree we can tweak it to suit ourselves.

Far's voxels can work from either/both. It's possible to force it to use one or the other through an MM patch but unless I setup the patch wrong, it made no difference if I set it to visual mesh or colliders. You may want to contact Ferram directly.

You know, spreadsheets seem like a great way to keep track of everything. It should be possible to make a parser script that reads the spreadsheets and spits out the .cfg files. Maybe even parse formulas into MM math. I'm with WLLP on the whole spending more time tweaking than playing. I've spent basically all week setting up an install, pruning unneeded parts, trying to make things mesh together better, and I'm not even done. I still need to figure out what I'm doing for EPL (because the parts that come with it.... no. Just no.) and I think I'll have to make tech tree adjustments because the part that does ore->metal comes way later than the one that does metal->rocket parts, and what am I storing the resources in... I really liked the balance mod for 0.9 because all I had to do was drop it in and it went. Being able to snag all the mods at once via ckan will be extravagant icing on the cake. EDIT: Oh, and FYI Yemo, you may want to consider manually overriding the KIS volume of the stock radial batteries. KIS is seeing them at their full size instead of the little parts you've shrunk them down to. You can verify this by pulling one out of the inventory and trying to place it; it displays at full size in the placement preview then shrinks down once actually placed.

Anyone else having a strange issue with some of these parts under FAR? Their cross-sectional area isn't working right. http://puu.sh/jH66I/995c7955c7.jpg There may be other parts than this with issues, but I've pruned a lot of the pack out since they're parts I won't use. I've tried using MM to force these three parts to use both their visual models and their colliders, but neither option seems to have an effect. Looking at the debug voxels, for some reason FAR is seeing the low-area regions as hollow. It sees the skin but not the inside. On the dropship cockpit, for instance, the glass area is filled with debug voxels, then it's hollow the rest of the way back: http://puu.sh/jH98E/0d2d9012c4.jpg The same partial filling, mostly hollow can be seen on the other two parts as well. As you can imagine this creates quite a lot of transonic drag.

Do not use my cfg edit, it is not working correctly with career mode. Currently trying to fix this. Expected behavior is that all pods have a 160km antenna that cannot be shut off. Instead it is display the tech perk in the VAB but it is not operational in flight. Should be as easy as changing "None" to "Start", loading game to confirm this as I type. EDIT: No, that's not working either. EDIT2: Got it! It's not supposed to be in quotes. %TechRequired = None

There's an... interesting interaction that occurs if you have Remotetech installed. SETIctt adds a 160km omni antenna to all command modules. However, due to what (as far as I can tell) is a bug in Remotetech, that new antenna takes over any animations the capsule may have. If you've installed the SETI modpack, you'll notice this immediately with the window lighting added by Ven's Stock Revamp. When an antenna is not provided the index of an animation module, it's supposed to not use any of them. Instead, it's attaching to ALL of them. This can be seen with Ven's replacement cupola which has two animations; one to toggle the window shutters, and one to toggle the window lights. As-is, the 160km omni antenna will attach to both of these things and you loose control over them. Turning the antenna on/off opens and closes the shutters and toggles the lights. Remote tech allows two broad categories of antenna: Active and passive. Actual antenna and dish parts are active, and passive antennas are what makes that "tech perk" where your probe cores can be given built-in 3km antennas (in stock Remotetech) Passive antennas are always on and cannot be turned off, but they only consume power when transmitting science. However, SETI's active 160km antenna isn't being set to consume any power either, so I made them be passive antennas instead to get around the animation issue (since passive antennas can't have animations). There'd be no reason to turn them off since they weren't consuming power anyway and I never do, personally. Long term, what would need to happen is the built in antennas SHOULD consume power (so there's a reason to turn them off), and Remotetech has a bug to fix.

So I've been toying around with the whole "integrated omni antennas eating animations" thing, and I believe it to be a bug in RemoteTech. The RT antenna should only bind to an animation if told to, and the SETI MM patch isn't telling it to. It also isn't setting any EC usage for keeping the antenna on, so I figured why not just make it a passive antenna and be done with it. I never shut the integrated antenna off anyway. Anyone wishing to make the same change to regain proper control of their command pod animations can use the following workaround: In SETIctt-Settings.cfg, replace the first block with the second: //------\\ //---160km Omni Antenna on Probe Cores and Command Pods---\\ //------\\ @PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[RemoteTech]:AFTER[RemoteTech]:FOR[SETIctt] { !%MODULE[ModuleRTAntennaPassive]{} %MODULE[ModuleRTAntenna] { %IsRTActive = true %Mode0OmniRange = 0 %Mode1OmniRange = 160000 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 5.0 } } } //------\\ //---160km Omni Antenna on Probe Cores and Command Pods---\\ //------\\ @PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[RemoteTech]:AFTER[RemoteTech]:FOR[SETIctt] { %MODULE[ModuleRTAntennaPassive] { %TechRequired = "None" %OmniRange = 160000 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 5.0 } } }

...What were you trying to do, add political assassination missions?

Got the popup for failing to load KCT data. Per it's instructions, here's my log: http://puu.sh/hl6Wq/fe72b7b349.log Here's what happened: I launched a satellite, with another sitting in the inventory. From the flight scene, I rolled out the second sat and tried to launch it (quicksaving right before I hit launch). Everything went kinda wonky; the scene didn't load right. I attempted to load the quicksave, and after the quicksave "loaded" the flightscene was still screwy and the message appeared. This report will probably be useless since I'm running 100 mods and the root cause most likely wasn't KCT but you(r mod) asked for it so here it is. EDIT: Ah crap, here's another one:http://puu.sh/hl8xU/1f10026d3d.log After I restarted the game, everything seemed fine. My second sat was ready to launch, so i launched it. Everything went off without a hitch until I returned to the space center when I got the popup again.

What is this, a ladder for ants? XD

I can confirm the memory leak when servo config is open in Editor, and not in Flight. You can watch the memory usage climb at nearly 1mb/s. Close the servo config, leak immediately stops. Open it back up, starts again. Debug log shows no errors while this occurs. Only way to get the memory back is to restart the game. I believe this issue has been around for a while, pre-rework. I remember noticing it months ago but for some reason never reported it. I wasn't really using the parts at the time so I just removed them and paid it no mind...

While your at it: Any chance you can make the heatshield toggle fully functional with deadly reentry? I can't bring myself to use any other kind of landing gear, but I've had to take to some rather... unpleasant deorbiting techniques (dive into atmo at ~45 degrees and pull an 8+g turn) to make sure I still have gear to land on when I reach the runway None of my scientists want to go on plane rides anymore. I can mimic the MM patch for the stock landing gear, but having the editor toggle be more than cosmetic would just be slick. Unless it already does this and my install is misconfigured, in which case feel free to tell me how much of an idiot I am.

Also experiencing no part issue, although I don't even get SRBs. Debug console doesn't show any errors: http://puu.sh/et4dX/de39506405.png

With a sufficiently tuned PID controller, I don't think you need to worry about it. Let me see how mine responds to jets and get back to you. EDIT: Yup, I was able to adapt my existing hover script to work well with jet engines just by altering the gains. If you don't know how to make a PID controller, there's a tutorial in the Kos documentation (which is pretty much all my script is, just some minor boilerplate added to let me control the setpoint with action groups, switch between radar and ASL altitudes, etc.) You'll want your Derivative gain to be the highest to counteract the spinup times. Through experimentation I was able to find acceptable gain values in three tries. There was some minor undershooting and some overshooting which could be reduced with more tweaking. Exact values, as always, will be unique to your craft and due to the nature of jet engines a little overshoot will be unavoidable, but I got mine to settle into it's setpoint after a single oscilation and it was easy to land as long as you're gentle. Basically any time you have a value you need to control and an output to control it with, PID will solve your problems and you can ignore any other math entirely. If only making them self-tuning were straightforward... Like the time it took me two weeks to realize that bad things happen when you define parameters and then don't pass them in. Feature request: Optional parameters.

Something else you could do is install hyperedit and only use it during simulations. That way you can setup any scenario you please. In fact, perhaps the simulation interface itself could gain similar features; letting you change the scenario at any time and not just at sim start. One thing to keep in mind though is large changes like changing orbital bodies sometimes does not play nice with deadly reentry, resulting in exceeding g-limits or if you jump into/out of an atmosphere parts will burn up. If you were to implement your own method of altering orbital parameters in-flight I would suggest pausing the simulation, making the change, then resuming it. I think that would put the ship "on rails" during the change and bypass any possible shenanigans or kraken attacks.