Dr. Jet

Update ChopShop, please. It has English, Russian, Spanish and German. Other languages can be committed here https://github.com/doktorjet/ChopShop

Если что - комменты сюда. Полезные дополнения и баг-репорты - на гитхаб.

Localizing a big mod is not an easy task. Moreso if mod author "forgot" to implement #LOC tags for that whole gazillion of parts... This tiny script will do a huge part of the job for you. Just grab your mod folder with a mouse and drop it on top of autoloc.py. (Python 2.7+ needed.) What it CAN and WILL do: Find a defined agency in mod (only one!) and use it as a default part manufacturer for all mod parts. Generate most of the #LOCs needed and write them in proper places, thus freeing you from that boring repetitive task. Automatically create \Localization folder and en-us.cfg as a default language config. Copy it and edit to make other languages. What it CANNOT do (in current version): Generate #LOCs for science descriptions. Generate #LOCs for parts GUI. Generate #LOCs for ModuleManager patches. What it ABSOLUTELY CANNOT do (and never will be able to): Generate #LOCs for plugins. It is something that only plugin author can do. Tested on Contares collection, KW Rocketry Redux and Raidernick's mods. Feedback is appreciated.

В помощь локализаторам - сделал небольшой скриптик, который автоматически генерирует en-us.cfg и #LOC-и в файлах запчастей для тех модов, где не прикручена локализация вообще. https://github.com/doktorjet/KSP_Mod_Localizer Пользоваться проще простого - перетащить мышью директорию с модом на скрипт. Требует Python.

Seems that I made a solution for all that huge unlocalized mods... Check this https://github.com/CONTARES/CSA_Contares_CORE/pull/1 made by this https://github.com/doktorjet/KSP_Mod_Localizer

https://github.com/CONTARES/CSA_Contares_RUS/pull/1

Well, it was the main reason why Squad implemented it in place of self-made .mbm. I believe they tested it a lot. And self expirience too, of course. Conversion saved a couple of seconds loading even my tiny mod alone.

It will be easier after localization implementation. All strings in one file. Difference is faster loading time and a bit less memory usage. Tested. For russian rockets and engines one should use russian wiki at least. https://ru.wikipedia.org/wiki/Космос-3М#Космос-3_(11К65) Western sources oftenly rely on cold war intelligence materials, so they are not always correct. Lower stage engine for Cosmos-3 is 11D614 (modernized 8D514 engine from R-14) and upper one is 11D49 (exclusively developed for Cosmos-3). Proper english abbreviation for "ЖРД" is RD, not RK. RD-216M is early engine of military R-14, even earlier than RD 8D514. As for DU-49, I can only interprete it as "двигательная установка образца 1949 года" ("propelling system, model of 1949"), but cannot find a corresponding engine in documents. OK, will use a model change and re-check for nodes. It's still a functional decluttering. "SWE", "LFO Vipera" and "Micro-Gabun" at least. First node is inverted, other two are rotated by 90º. Will possibly fix myself if nodes are declared in config rather than being empty objects.

Some bits and bobs. Current part titles are awful. Most of em. And descriptions... are not very descriptive. Textures are not .dds (fixed) Writing "Salute" ("Salyut") as "KALJUTE" is eye-tearing. Do you know that "KIR" means literally "dick" in Farsi? Some engine indexes are wrong (early R-14 engines instead of Cosmos-3 engines). Don't use english wiki as a source for those. (fixed) Some parts have wrong node orientation (docking radar and inbuilt RCS engine). Also some parts are functional duplicates (KIR_BACK_9 and KIR_BACK_6 for example). I suggest ModulePartVariants for decluttering. P.S. What is "PCS Transport Vehicle"?

Вот подборочка, например.

Делаю Contares-RUS. Осложнено отсутствием вообще какой-либо локализации, так что создаю лок-теги с нуля. Оригинальный текст - та самая "лютая пыжня". В частности, надеюсь, все помнят политические анекдоты про "кир"?

What about localization support? I can do Russian for you.

v 0.11.3 Eng: German localization by Nils277 updated. Fixed missing SSP Mk3 patch for CTT. (https://github.com/doktorjet/ChopShop/issues/4) Rus: Обновлён перевод на немецкий от Nils277. Исправлен отсутствующий патч для УСП-3 под CTT. As I'm an unfortunate GoG customer, I can't test this patch under KSP 1.4.2 right now. Though it should work... I guess...

Version 0.11.2 is out. Eng: German localization by Nils277 added. Updated sample crafts to be compatible with KSP 1.4 Fixed some uncritical typos in configs. Rus: Добавлен перевод на немецкий от Nils277. Обновлены примеры аппаратов для совместимости с KSP 1.4 Поправил несколько некритичных опечаток в конфигах. Also included alpha version of compatibility patch for ETT. It's a temporary measure, as ETT GitHub source is terribly outdated and not suitable for commits. P.S. Curseforge source will not be updated any time soon. Those... bad guys are forcing me to register at Twitch for UNNEEDED additional services. Download from SpaceDock.

Oh! Syntax has changed... Thank you. That part is so-o-o-o old, I didn't even notice. SkinMaxTemp it should be. Will fix. Thank you. BTW, you can also use https://github.com/doktorjet/ChopShop to report issues and suggest fixes or improvements.

AFAIK, USI MKS is not ready for ANY localization. When there will be tags in place of strings - I'll do russian.

SkyCrane1.cfg: skinTemp = 1800 // Complex electronics don't feel very well near the engines, so it's lower then stock 2000. Parameter is in place. Can't see how you didn't find it. It is "scale" there. Can't remember if it ever was "size". BTW, what versions of KSP and ChopShop do you use, seeing such weirdness? I personally recommend KSP 1.3.1 and ChopShop 0.11.1 for maximum compatibility. There are not many mods available for KSP 1.4 yet. "impactTolerance" is a parameter for landing legs and landing gear. It definitely should not be in antenna config. Will remove, thank you. I'm not sure if I will do even 2.5m ones, not speaking about bigger. For huge payloads I recommend RealChute - chutes recalculate automatically for every planet atmosphere and descent speed you chose.

Should work fine in 1.4 (tested). Except for craft files. Waiting for Spacedock to renew it's version list to update and add .

Looks plausible. At least we don't have mass appearing from the middle of nowhere. Are those rates divisible by single kerbal CO2 production rate?

Yeah, it would be MUCH simpler if Food was just fresh veggies... But Kerbalism Food density equals TAC LS Food density. And TAC LS Food resource acccording to TAC LS math sheet is half-dehydrated (52% water) packaged food*. TAC LS Water consumption rate is calculated concidering that. Don't know about Kerbalism rate, but there is a high chance that numbers were just borrowed from TAC LS. * - We actually can think of it such as some products are fully dehydrated (freeze-dryed) and some are still fresh. Oh... it seems that my brain is still not OK with that flu. Number is truly weird and I can't remember how I got to it. Biomass is ~90% water. We need water to be at 52%. That means 0.1 kg of solid fraction from 1 kg Biomass becomes 48% and mass of unpackaged half-dehydrated food should be 0.1/0.48 = 0.208 kg Water squeezed back from Biomass should be 1 - 0.208 = 0.792 kg. Hm-m-m... Maybe for the sake of simplicity we should just ignore the "packaged" thing? Kerbals will eat a bit MORE from greenhouse than they should, but... the whole thing will be simpler. One more thought - Kerbalism "harvesting" mechanic - can we use it to periodically batch-convert constantly growing Biomass to Food?

Seems that I was terribly wrong. That's what happens when one start doing math under flu and high temperature. Greenhouse solid output is plants. Veggies. Not dehydrated Food i calculated above! Veggies are juicy, they are 85-95% pure water. Thus much more water is needed. Also Fertilizer contains Carbon, which I forgot to count. I'm still sick, but brain works kinda better... i hope. First thing first, there was a mistake in fertilizer calculation. Minerals should be 49.3%, not 50,5%. Water CO2 NH3 (NH4)2CO3 Biomass (Food?) Fertilizer C 27,27% 12,50% 4,50% 6,34% O 88,89% 72,73% 50,00% 84,20% 25,35% H 11,11% 17,65% 8,33% 10,65% 4,23% N 82,35% 29,17% 0,15% 14,79% M 0,50% 49,30% For each 1 kg of biomass we should input 0,01014 kg of Fertilizer to fulfill both Nitrogen and Minerals. This amount of Fertilizer will also add Carbon (0,00064 kg), Oxygen (0,00257 kg) and Hydrogen (0,00043 kg). Remaining Carbon should be inputed as CO2 which give us 0,16264 kg of CO2 input. Photosynthesis CO2 -> O2 mass conversion rate is 44/32. Thus main O2 output is 0,11829 kg. Remaining Hydrogen should be inputed as Water which give us 0,95464 kg of Water input. BUT! Let's check water by oxygen. Hm-m-m... It gives us 0,94436 kg Water input. Mismatch, yes. Noone promised that percentages for plant composition are EXACT. But those numbers are pretty close. What we'll do is just take bigger number to cover hydrogen needs and exhaust that extra oxygen for kerbals to breathe which will be mere 0,00914 kg. So-o-o... for greenhouse inputs and ouptuts should be proportional to: Input: 0.16264 kg CO2, 0.95464 kg Water, 0.01014 kg Fertilizer Output: 0,12743 kg O2, 1 kg Biomass BTW, mass balance was achieved, which is a good sign. Hope no more mistakes were made. But how to convert Biomass to Food? Do we suppose that Food should be dehydrated? (Most RL space foods are). According to TAC LS math sheet, Kerbalism "Food" resource (which have the same density) is "half-dehydrated (52% water) packaged food". Packaged food is BAD for calculation. We don't have packages growing in greenhouse! Fortunately, @TaranisElsu mentioned a mass fraction of Food that is packaging (17.52%). Thus half-dehydrating 1kg of edible Biomass and re-packaging it in re-used packages will produce 0.568*1.1752=0.6675136 kg of Food and 0,432 kg of Water. (Careful here! Mass conservation law is abused, actual food mass is only 0.568 kg! Re-calculating Foood density for non-packaged variant could do the trick, but it's laboursome). The last question remaining - is what percent of Biomass produced is edible and what percent is Waste?

Pouring wastewater into space greenhouse (aeroponic most probably) is a bad idea. You don't have soil bacteria there to convert toxic substance into something that plants can consume, also spraying nozzles can get clogged. WasteWater processor should filter water, separate useful minerals and produce ammonia from nitrogenous solids. Roughly for each 1 kg of WasteWater processed we should get 0.95 kg of Water, 0.013 kg Minerals and 0.009 kg of Ammonia. Notice that some mass is lost (jettisoned), though if you want to add oxygenous pyroliser and recover some CO2, you may add extra input of 0.0117 kg O2 to recieve extra output of 0.0131 kg CO2. BTW, speaking about self-sustaining colonies, those will need not only Water and Minerals, but also some sources of Nitrogen and Carbon. Carbon is easy, it's most likely to be found alongside with Oxygen when processing some Ore in potassium fluorine cycle. Though finding Nitrogen is trickier. Though it's abundant in Kerbin and Laythe atmospheres, but very scarce in Duna (Mars) and Eve (Venus) atmospheres and it's a matter of luck if it can be found in ores anywhere.

Did not understand your question. First 3 resources were added to CRP from USI MKS. Fertilizer IIRC is used in KPBRS (+ TAC LS) and was also used in Biomass mod when it was alive. Thus using existing resources instead of creating new ones is actually a good idea. Methane is regretfully not used in most cryogenic engines mods IIRC, though IRL there are rocket engines that work on liquid methane + liquid oxygen. Units proportional to metric tons - that's GOOD! All my numbers are in percent-by-mass! Let's calculate exact rates... Concidering Food is mostly carbohydrates, rough molar rate of CO2 and Water input should be around 12/11. Thus we have greenhouse input of 65.5% CO2, 24.6% Water and 9.9% Fertilizer (by mass). Concidering greenhouse is mass-neutral (input mass equals output mass) and photosynthesis conversion rate for sugar, we can calculate that 65.5%*32/44=47,64% of greenhouse output (by mass) will be Oxygen, and remaining 52.36% will be solid output, which is Food and Waste (ineadible plant parts). Notice that those rates does not take into account kerbals consumption rates (0.84 kg of Oxygen and 1.77 kg of Food per day according to Default.cfg). For each kerbal breathing (if we don't have another source of CO2 onboard) both greenhouse input and output should equal 0.84/0.4764 = 1.76 kg per day. That gives us 0.923 kg of solid output per day. Best closed cycle experiment - the soviet BIOS-3 achived at most 50% closed cycle on food. Thus each 1.77*0.5=0.885 kg of Food produced should be accompanied by 0.038 kg of Waste. Huh! Those plants are almost whole edible. So finally we have Input: 65.5% CO2, 24.6% Water and 9.9% Fertilizer Output: 47.64% O2, 50.2% Food, 2.16% Waste Harvest cycle can be as long as you wish, it does not matter, just keep it proportional. P.S. Some calculation results from my earlier studies. 4 meter long 2.5m wide cylindrical "phytotrone" part should be able to produce 50% of single kerbal's needs in Food and 100% of his needs in Oxygen.

Yes, but what I want is robust STOCK mechanic to change part parameters according to animation state. Deflated parts obviously has less volume and less or even zero crew capacity. For now it can be done (in reverse) with some engines, but not with regular parts.

True multithreading. All your 4-8 CPU cores should calculate current craft physics. Integrated ModuleManager. Integrated CKAN or NexusModManager. Integrated Editor Extensions. Realistic life support system. Maybe something like Kerbalizm. Will give a reason for complex multi-habitable-parts designs. Realistic resources system. (No more combustible "Ore", hunt for water (hydrogen) or noble gazes, produce your own methane for both chemical and atomic engines...). Logical and sane TechTree with manless start OR a handy ingame instrument to make your own. Integrated RCSBuildAid. Procedural and switcheable parts (stock module to make those). Procedural planets (will have MUCH smoother terrain with better textures). More of them also, maybe even other star systems. More (MUCH MORE) reasons for sustaining an orbital station of sending a rover (corresponding science experiments and contracts). Propellers (stock module to make those). Inflatables (stock module to make those). Nodes, moving along with animation (Yay! Robotics!) Integrated KIS (KAS is pretty much useless) and more maintenance/repairing activities for engineers. Unity shaders. Also some Unity weather system maybe. Optional means of automation - either KOS-style (with examples library) or MechJeb-style. Haters should be able to turn those off. Optional N-body physics (Lagrange points are tricky but cool). Will work perfect with True Multithreading. ISRU manufacturing system (integrated ELP with USI MKS resources). Some way to automate logistics for ISRU MS. P.S. Voxel planets are a very BAD idea. Any digging will bloat you savegame files to ridiculous size and drop load speed dramatically.