Corax

I don't know what units ECLSS uses, but here's CoolBeer's post about converting TACLS "day" units to litres: -Add aditional ModuleManager file to change parts over to new units: @PART [*]:HAS[@MODULE[ModuleCommand]]:Final { @RESOURCE[Food] { @amount *= 0.317 @maxAmount *= 0.317 } @RESOURCE[Water] { @amount *= 1.798 @maxAmount *= 1.798 } @RESOURCE[Oxygen] { @amount *= 304.27 @maxAmount *= 304.27 } @RESOURCE[CarbonDioxide] { @maxAmount *= 261.78 } @RESOURCE[Waste] { @maxAmount *= 0.56 } @RESOURCE[WasteWater] { @maxAmount *= 1.98 } } @PART[Tac*] { @RESOURCE[Food] { @amount *= 0.317 @maxAmount *= 0.317 } @RESOURCE[Water] { @amount *= 1.798 @maxAmount *= 1.798 } @RESOURCE[Oxygen] { @amount *= 304.27 @maxAmount *= 304.27 } @RESOURCE[CarbonDioxide] { @maxAmount *= 261.78 } @RESOURCE[Waste] { @maxAmount *= 0.56 } @RESOURCE[WasteWater] { @maxAmount *= 1.98 } } @PART[HexCan*] { @RESOURCE[Food] { @amount *= 0.317 @maxAmount *= 0.317 } @RESOURCE[Water] { @amount *= 1.798 @maxAmount *= 1.798 } @RESOURCE[Oxygen] { @amount *= 304.27 @maxAmount *= 304.27 } @RESOURCE[CarbonDioxide] { @maxAmount *= 261.78 } @RESOURCE[Waste] { @maxAmount *= 0.56 } @RESOURCE[WasteWater] { @maxAmount *= 1.98 } } @PART[TacAirFilter] { @MODULE[TacGenericConverter] { @outputResources = Oxygen, 304.27, false } } @PART[TacCarbonExtractor*] { @MODULE[TacGenericConverter] { @inputResources = CarbonDioxide, 261.78, ElectricCharge, 1000 @outputResources = Oxygen, 273.843, false, Waste, 1.24208, true } } @PART[TacWaterSplitter] { @MODULE[TacGenericConverter] { @inputResources = Water, 1, ElectricCharge, 100 @outputResources = Oxygen, 3126.4, false, Waste, 3.581, true } } @PART[TacWaterPurifier*] { @MODULE[TacGenericConverter] { @inputResources = WasteWater, 1.98, ElectricCharge, 1000 @outputResources = Water, 1.6182, false, Waste, 6.382, true } } -Change default consumption values in GameData\ThunderAerospace\TacLifeSupport\PluginData\TacLifeSupport\LifeSupport.cfg (This step is needed because you can't input decimals in the ingame TAC consumption editor(or at least I failed at it)). GlobalSettings { MaxDeltaTime = 86400 ElectricityMaxDeltaTime = 1 FoodResource = Food WaterResource = Water OxygenResource = Oxygen CarbonDioxideResource = CarbonDioxide WasteResource = Waste WasteWaterResource = WasteWater FoodConsumptionRate = 0.32 WaterConsumptionRate = 1.798 OxygenConsumptionRate = 304.27 ElectricityConsumptionRate = 1200 BaseElectricityConsumptionRate = 2400 EvaElectricityConsumptionRate = 200 CO2ProductionRate = 261.78 WasteProductionRate = 0.56 WasteWaterProductionRate = 1.98 DefaultResourceAmount = 86400 EvaDefaultResourceAmount = 43200 MaxTimeWithoutFood = 2592000 MaxTimeWithoutWater = 259200 MaxTimeWithoutOxygen = 7200 MaxTimeWithoutElectricity = 7200 } NOTE: Some of the items in the ModuleManager file needs the latest version of ModuleManager(2.0.1 at the time of writing) for the math functions which reduce the file size quite a bit. *LINK* WARNING: This is hardly tested for more than a few minutes in total, I might have messed up horribly and would advice backups of saves and whatnot before commencing. I claim no warranty or responsibility if this breaks your game, on the other hand feel free to do whatever with the information/configs as you please. Hopefully I got all the numbers correct. Dropbox download with the files shown: *LINK* (TaranisElsu: If you feel I'm stepping too much on your turf, please let me know and we'll work out something). - Kolbjorn That should take you at least half the way through

Create a subdirectory under KSP/GameData, copy ModuleManager.dll into GameData, and create a new config file containing the stuff Milaha wrote: KSP |--GameData |--[COLOR=#0000ff]ModuleManager.dll[/COLOR] |--[COLOR=#ff0000]MyCustomStuff[/COLOR] | |--[COLOR=#ff0000]MyCustomKASConfig.cfg[/COLOR] | |--Squad |--Squad stuff

Consider once a greenhouse has been started, it should be possible to put out a relatively constant supply (with relatively constant care). Mission planners would certainly try and optimize the plant composition for such a case. Also I'd assume – at least for manned missions – that a greenhouse module isn't launched with barren hydroponds, but pre-seeded and possibly already close to the first harvest; sending one on an unmanned, long duration cargo flight would be a different scenario though.

Simply copy the license of your favourite game or OS. Oh wait... wouldn't that be forbidden... which is exactly why you should reconsider using such a restrictive license

I'm really sorry I have to say that I can't update the plugin for the foreseeable time. If anybody wants to step in, please feel free to do so; the source code is included in the download, and it isn't a terribly complicated plugin to begin with. The main thing to be done is to include a way to activate/deactivate the module via right-click, since the old way of (ab)using the staging system doesn't work anymore. This shouldn't be too hard to implement, but I can't get around to do it myself at the moment. I still visit the forum on a somewhat regular basis and will try and assist wherever I can. I make no guarantees that I will pick up on this again at a later date, but never say never and all that... Thank you all for your enthusiasm, and sorry again if I let you down Oh and PLEASE mods, keep this thread open for discussion/development. "Necro" hunters, I'm looking at you!

Source code and license?

Not everyone has signatures enabled, so yes, somewhat surprisingly and against common "knowledge", signatures aren't that great a place for advertising. On the other hand, advertising is probably why they are being ignored in the first place. Oh well... EDIT: I'm not talking about advertising as in "commercial ads" so much as in "making things known"

Seriously, stop complaining about people bumping old threads. If there's interest in a topic, why open a new thread? It just goes to show some people actually know how to use the search function. Much better to expand an existing topic with new information than cluttering the forums with half-complete topics, increasing the chance to miss previously established info and decreasing the chance to actually find meaningful threads. Sorry for continuing off-topic (why don't you seem to care about that...?).

"timing the transmission to coincide..." with brute force Yes, that could certainly be an option. You will probably need a way to make certain the command is executed only once, though...

Ideally, it would not receive commands as soon as it opened its dish if the dish is closed when the transmission arrives. You can queue received commands, but you can't queue radio waves to be received when it's convenient. You might time your transmission to coincide with the reopening of the dish, if (when) that is possible, but that's about the only way for the scenario you described to be possible.

Possibly because of Maybe it isn't just that simple from within a running instance of Unity, or maybe it isn't that simple on Linux and MacOS. Or maybe it's just not high enough on the priority list. And especially if it is that simple, why put time and effort in it when users can simply type in a few letters and fix it for themselves, let Squad squash a bug or add a more interesting feature instead.

Yes, that is quite obvious. I was serious about BIL though... I think it'd look much nicer, and as I said, for "authenticity's" sake.

EDIT: (Was about to suggest three-letter acronym when I found this) Continuity would actually suggest BIL 9000. One "L"... On the other hand, continuity would also suggest a name starting with "K".

I haven't seen this mentioned before, so I'd like to suggest variable power consumption for the different modes and lights. Basically make the consumption relative to the "on" time of the lights, maybe plus a tiny overhead for control circuitry, and adjust the nav lights and beacons to require different amounts of power, considering their relative brightness. This may seem like nitpicking, but I just had a staging accident which left a capsule stranded in orbit, with just enough battery power for about ten hours of nav lights (by sheer luck I did pack extra batteries in the first place). Right now, I could of course turn off the lights completely, but with what I proposed, setting them to flash only might save enough power for several times that long, without going completely dark. Just a small detail really, but it's in situations like these when they are noticed.

Excellent! Your technology has saved many a test pilot's life, and all my production aircraft have been equipped with ejection seats for longer than I can remember EDIT: PS.: I had to rename VNG_Parachutebox/Textures to ./textures (lowercase), and VNG_Eject/textures/EjectionModule.png to ./ejectionmodule.png (also lowercase) to fix two warnings and get the textures to load properly. This is likely an issue with Linux only (maybe MacOS as well, since they both use a similar foundation) and (guessing only) the way you have set up texture names in the Unity editor. Path and file names are case sensitive on those systems. I understand you have new models and eventually an overall new version in the making, so maybe a release just to fix this is unwarranted; but if you do an interim release, I'd suggest either renaming those files/folders, or changing the texture names within the editor, to reflect actual case.

With 0.21 just around the corner, there will certainly be no more update for .20; I'll see what I can do for .21 when it's out.

Careful with that airlock

Time to change ISP then I guess... not much of an "internet service" they seem to provide! Technically it does run a web server on the same machine you're running KSP on, which you may or may not forward from your router, so it may or may not be visible from the internet. 'IP' stands for 'Internet Protocol', so yes, all this is using IP, specifically TCP over IP.

The module should work; the problem is activating it. Since the KSP staging system was overhauled (0.18 IIRC), parts don't get assigned a stage icon automatically anymore, so you can't rearrange the module's staging sequence. Currently the only way to activate it is with the final logical stage, and only if it's still part of that same physical stage. As a workaround you could edit your safe file and change the part's state=1 and LaunchState=True (requires you to exit to the main menu and/or reload, and be sure to make a backup before) KSP is currently a bit on the back burner, but either I will get around to fixing it sometime (just don't hold your breath), or you could have a look at the sources yourself.

Correct on both points of course. I reckoned that would overcomplicate things, when I should have been more precise. Better to overexplain than to add more sources of misinformation...

You could spoon away all day and wouldn't change the density a bit... Exercise to the reader: Explain why.

ahem...

Keep in mind Squad are developing a computer game about a space program, not a space program as such. While docking might be the logical next step in developing a space program, it may, for a variety of reasons, not be (and apparently it is not) the next step in developing this computer programme.

It seems to me as though roughly half the voters would actually like some form of fuel consumption... For example, I voted for (read: I'd prefer) a separate fuel type, but I guess I would be fine with any kind of fuel consumption, after all. I don't think it needs to be physically perfect, just plausible enough to be believable. It's still just a game I haven't really looked into this, but maybe it could be as simple as finding the height of the atmosphere, calculating the distance light has to pass through in the direction of (from) the sun, assuming a linear decline in atmospheric density between the current altitude and zero (at the edge of space), and applying some attenuation factor to that, before applying any other factors like angle of incidence etc.

Not sure if it can be done from in-game data, or if it had to be determined empirically, but it would be absolutely awesome if you could figure in atmospheric losses. Very true, and although the majority of the voting crowd seem to prefer "no fuel", that would only be correct for a photon engine, an ion engine does require some sort of reaction mass, ie. fuel. With rkman's suggestion, you could have both types in one go.