[The Comprehensive Kerbal Archive Network (CKAN) Package Manager; v1.18.0 [19 June 2016]]

I'd like to see PWB Fuel balancer added to CKAN. The thread link is here:

http://forum.kerbalspaceprogram.com/threads/42624-0-90-PWB-Fuel-Balancer-v0-1-1-%285th-March-2015%29

[[1.0.5] PWB Fuel Balancer v0.1.2 (3rd November 2015)]

I'd sure like to see this updated for 1.04, and added to CKAN. I'll post in the CKAn thread as well.

[[1.2] Procedural Fairings 3.20 (November 8)]

If you use Tweakable Everything, go grab the latest release that was just pushed out today

This does seem to have fixed the issue. My apologies for reporting it here when it seems to have been a bug with Tweakable Everything.

[[1.2] Procedural Fairings 3.20 (November 8)]

Updated to 3.15:

• Updated for KSP 1.0.4.
  
• Merged pull request for Procedural Parts bug fix.
  
• Adjusted thermal parameters for KSP 1.0.4 (hopefully).
  

Thank you very much for the update. This is one of those mods that's truly essential for me.

Just for the record, I am still experiencing the "Interstage Fairing Adapter" kills right click issue.

[[1.2] Procedural Fairings 3.20 (November 8)]

I have also been experiencing this problem.

I too am experiencing this issue, and it seems to be caused by the interstage fairing base.

[[1.2.1] Outer Planets Mod (2.1) - Active development has moved, see first post for new thread]

I've installed with CKAN and have the same issue - no new planets.

Based on the manual download package, it looks like CKAN isn't designating all of the dependencies. DDSLoader isn't marked for installation along with OPM for instance. Doing this manually, however; didn't solve my problem, but there CKAN seems to only install the OPM folder.

Is Kopernicus an actual dependency? If so, I will try that.

EDIT: manually adding the OPM, DDSLoader, and Kopernicus folders has done the trick, and I now have outer planets. Currently CKAN only installs the OPM folder.

[[1.12.X] RealChute Parachute Systems v1.4.8.3 | 24/01/21]

I just wanted to give Stupid_Chris feedback. I did correct the halt on load issue, and it was indeed old files. It was an old MM_config file that was in the Squad folder!

Who knows how long that was there, but I thought I'd post in case anyone else is still having the halt on load and haven't found all their old files laying around yet.

[[1.12.X] RealChute Parachute Systems v1.4.8.3 | 24/01/21]

Read back a couple pages -- you need to delete the "Legacy Parts" folder that's within the RealChute folder -- it wasn't meant to be in there and was included on accident. Deleting it will fix all your problems =D

I have the same issue. Load fails at parachuteDrogue. I'm using 1.2, and I have no legacy parts folder. I'm running the x64 version, and this loads without realChute. I do have a fair number of other mods running.

[[0.90]Kerbal Isp Difficulty Scaler v1.4.2; 12/16/14]

Amazing speed with the hotfix. thanks!

[[0.23.5] Goodspeed Aerospace Parts v2014.4.1B]

I just discovered that the copy of scale.dll included with this plugin does not work well, and conflicts with the updated scale.dll included in TweakScale. Removing the .dll from this mod corrected the conflict.

[[0.90] TweakScale - Rescale Everything! (v1.50 - 2014-12-24 10:40 UTC)]

Maybe installed something wrong? TS and IR behave really well together even with my local copy being present(it's version 1.20)

I was having this same problem - no scale option on most things that could be tweaked. In the end, I guess, the problem was pretty obvious.

I had the Goodspeed Aerospace mod installed as well. This mod contains a copy of Scale.dll. I'm guessing that it's old.

Once I removed this .dll all is well.

[KSP 64bits on Windows (this time, it's not a request)]

So, from my perspective the 64bit engine works, even with my crapload of mods.

There are some fairly serious issues however. As has been pointed out, procedural fairings seem to have no separation force when staged. Also, they seem to not be protecting anything inside the fairings from air resistance.

I have FAR running, so that's a possible issue there, but I have had satellite solar panels blown off during launch even though they were shielded inside the fairings.

I've also seen the difficult right-click issue, but I think that's no big deal.

Turns out I was wrong about the fairings not protecting the contents. this was just a staging error on my part.

[KSP 64bits on Windows (this time, it's not a request)]

So, from my perspective the 64bit engine works, even with my crapload of mods.

There are some fairly serious issues however. As has been pointed out, procedural fairings seem to have no separation force when staged. Also, they seem to not be protecting anything inside the fairings from air resistance.

I have FAR running, so that's a possible issue there, but I have had satellite solar panels blown off during launch even though they were shielded inside the fairings.

I've also seen the difficult right-click issue, but I think that's no big deal.

[[WIP] Sum Dum Heavy Industries Service Module System (Stockalike)]

The key point of this feature is that, should a user decide to uninstall SDHI, the pod's appearance will revert back to its original stock appearance. No permanent harm

Next up: modelling the actual umbilical and figuring out how to trigger a part animation when the SM is decoupled.

Let me ask a stupid question. Could it be possible to make a part that is essentially the same as the fuel line part (the part that allows fuel to cross from one tank to another) that handles the lifesupport resources? Alternatively, it could be purely cosmetic, but still serve the purpose of justifying the transfer.

[[1.2.0] Precise Node 1.2.4 - Precisely edit your maneuver nodes]

Is your game set to display Kerbin days, or Earth days? Sounds like PreciseNode and Alarm Clock are talking about 38 Kerbin days, where RT2 is talking 9 Earth days. Go into settings and check to see - the 23.5 update runs on Kerbin days by default. Changing it to Earth days should fix your issue.

Just to note, PreciseNode should display Earth/Kerbin days and durations correctly.

Ok, by switching to "Earth days" all the stats sync up. Of course, I don't really want to run in Earth days.

Also, if you note from the previous screenshot, even though "Kerbin Days" was selected in settings, the time that PreciseNode was showing was still in Earth days. Could this be because this save game originated from .22?

[[1.2.0] Precise Node 1.2.4 - Precisely edit your maneuver nodes]

Does anyone else have problems placing a node far into the future? Or have I dropped a few IQ points?

I'm currently trying to get a stable node set up for my return journey from Eeloo. Based on phase angle projections, the next available window is in 182 days.

I'm punching in numbers to get to the approximately correct date-time, using finer grain numbers to attune my exit angle and velocity. Trouble is, the greater precision results in all sorts of wobble and paradoxical behaviour.

For example, I add "1" to each additional decimal place on the date-time, which should result in an increasingly smaller (but unidirectional) increment on the ejection angle:

http://i.imgur.com/D2HuyY9.png

Uhhh... as I'm writing this, I just noticed the ejection angle readout going absolutely crazy, spitting out hundreds of numbers per second. I expect the problem is something to do with stock KSP (increasing error further in time), but felt the need to log it.

What happened to the "we've fixed nodes" statements of .23.5???

I'm having a different, but similar issue. I'm not sure what Mod is at fault, but there seems to be a major timing issue going on with the placement of the nodes:

Note that PreciseNode shows Year 2, But everything else shows Year 5. Also, the node is placed in the future, but PreciseNode and Alarm Clock show it as 38 days in the future, whereas RT2 shows it as 9. Needless to say, I'm having trouble sending my Duna probe.

[[PLUGIN+PARTS][0.23] SCANsat terrain mapping]

What do you mean "it still works the same"? The only working on focussed craft thing?

That shouldn't be the case should it? my understanding of this mod is that it displays sections of a pre-created image. So I would assume that Kethane will have a data image somewhere of the deposits that SCANsat can hook into and use its own multi sat scanning technique with.

Incidentally related to my question actually, can anyone explain how I can hook the KSP Interstellar resources into SCANsat? There are a series of images for each planet and each different resource so there is a far greater volume of scanning to be done.

To my knowledge, this is not how either mod works.

I could be wrong but neither mod has an image somewhere that is just uncovered as the scanning takes place.

[[1.2.0][WIP, PLUGIN][0.11.9.8][30/10/2016] KeepFit - Kerbal fitness degradation]

Feedback

Aside from actually getting my arse in gear and finishing writing v1.0 of this, I'd like to know what people think - is this a waste of time? would anyone else be interested to use this mod? Would you want any other features implemented or existing ones done differently? I'm interested to hear anything, even if its 'meh' (as long as there's a constructive addendum to the 'meh').

Yes, please continue working on this mod. It would be really nice to have some in-game motivation for including things like habitat modules and the wetworks tanks.

[[1.10.x] SDHI Service Module System (V4.0.4 / 11 October 2020)]

That is because of mistake in cfg after changing mod folder structure in last update.

You need to remove "parts\" from

MODEL {
		model = SDHI/Service Module System/[B][s]Parts/[/s][/B]SDHI_ParaDock_1_ClampOTron/model
		scale = 1, 1, 1
		rotation = 0.0, 180.0, 0.0
	}

Thanks. This has worked to fix the problem.

[[1.10.x] SDHI Service Module System (V4.0.4 / 11 October 2020)]

Thank you very much for this mod. I love it.

I just updated to the new version which requires Firespitter.dll and I have the docking clamp issue. What I mean by that, is the docking clamp that has the built in chutes, now displays as a standard clamp and does not function.

I verified that I have the newest version of Firespitter.dll, RealChutes and DeadlyReentry.

Reverting back to the previous version of SDHI resolves the issue. Am I missing something obvious?

[[1.0.5] TAC Life Support v0.11.2.1 [12Dec]]

I really like the idea, but the implementation as resource breaks down as soon as you can switch ships. If you exchange your crew, the new ones shouldn't start stressed out. It would have to be tracked per Kerbonaut, not per Vessel, as currently all resources are.

Interesting point.

As a counterpoint, perhaps just a simple implementation is better than nothing. And, you could make the case that a well used ship might be less comfortable than a new (and clean) one.

I will think about how you might be able to make some accommodation for per Kerbal tracking, but from a basic gameplay standpoint, I still think it makes a fair amount of sense to track it by ship especially because this is relatively easier and it serves the purpose of making living space, and the modules that provide it, more valuable.

[[1.0.5] TAC Life Support v0.11.2.1 [12Dec]]

I was wondering if Taranis would comment on the possibility of adding something like comfort into TAC Life Support. I'd be happy to do the grunt work of the addition, if you, Taranis, thought it would be ok.

What I'd like to see/do is implement a resource like comfort or sanity perhaps that's dependent on the amount of living space available to each Kerbal. The idea would be to make a compelling reason to implement habitat space and modules like the Wetworks tanks/habs and the inflatable habs.

My thinking would be a fixed resource based on the volume of living space available to each Kerbal. This resource would be consumed over time based on the number of Kerbals on board. In a more complex implementation, perhaps the consumption rate could be slowed slightly from multiple Kerbals on board, such that the rate is not quite a linear consumption per Kerbal - to allow for larger occupancy vessels. Also in a more complex implementation, there might be a maximum volume necessary for full comfort, such that the Kerbals onboard never run out of comfort.

In between though, or in a low complexity implementation, Kerbals would eventually, if put on long missions with very little living space, use up their comfort. I was thinking of perhaps a way to make ship maneuvering/functioning less reliable as the Kerbal comfort drops to simulate their distraction/inattention, but an reason that could be used to make the loss of comfort meaningful would be fine.

Anyway, I'd be willing to do the work on this, if you thought it's be a nice thing to have in TAC life support, even as an option perhaps.

[[1.0.x] Habitat Pack v0.41]

You could do something similar to TAC -- define a custom "Sanity" resource, start each crew capable model with n-sanity, and tick down the resource until it hits zero. Larger modules hold more sanity, enabling longer missions. Replenish sanity on distant bases with care packages.

I like this idea a lot. It doesn't sound too hard, and would give me a reason to use the Wetworks ranks as well.

[[wip] Differential Sails]

I'd sure like to see a solar sail version of these rather than a Casimir engine.

[ECMAScript Control Scripting for KSP]

That is currently the plan, I hope to have something minimally usable along with an API posted in the next few days. The hardest part will most likely be implementing the console interface

It may be worth looking at the kOS license to see what may be freely used there regarding the console interface.

As far as minimally working goes, it may also be worth simply reading in a text file to make sure the system works, and leaving a functioning console out, at least initially.