prog

Main difference is - wiith 30 days lifespan kerbals will WORK full 30 days while with 15+15 days they will work only 15 days and another 15 days they will do nothing being on strike. (And I'd rather use 10+300 or so, not 15+15)

If only there will be option to make death occur not instead of strike but after configurable amount of time in strike mode...

You could store "spent" amount of RCS fuel in database as well. Increase it every tick and really spend it when vessel is focused. Use current "remaining" value from database to calculate estimations and decision making or, to avoid math duplications, transform it to never decreasing "max RCS avalible" value that will be compared with "spent" value for estimations and decision making (refresh with current RCS fuel amount for active vessel). This will transform problem of disappearing RCS fuel into less severe problem of not all RCS fuel available to orbit keeper service.

How hard is it to have not only max part volume but min part volume as well? I'd like to make config file for workshop designed to make only large enough parts so I'll have to bring both types of workshop to fully cover my construction needs. And it will help with craftable parts list cluttering as numerous small parts will not be shown in large-scale workshop.

Just two words: "mass conservation". And another three words: "predictable mass change". And your production cycles could be easily implemented with pre-calculated resource amounts (anyway you need them both calculated for display) so calculation order changes nothing except more mass or more credits will be spent. There is another, more accurate variant - calculate semi-balanced distribution: - take half mass, calculate main resource amount - take full cost without cost of main resource from previous step, calculate secondary resource amount - fill remaining mass with main resource May be adjusted for smaller steps to get more accurate result.

It's only my personal point of view on this and I don't ask to implement anything exact this way - just sharing in case you'll find something interesting enough to be implemented. If it were me doing cost calculation algorithm, it will be something like this: 1. get partCost and partMass 2. calculate secondaryResCount from partCost and secondary resource cost per unit 3. calculate secondaryResMass from secondaryResCount and secondary resource density 4. calculate mainResCount from (partMass - secondaryResMass) and main resource density 5. calculate techCoefficient from mainResCount and secondaryResCount with values between 0 and 1 where 0 means only main resource used and 1 means only secondary resource used 6. calculate productionTime from mainResCount, secondaryResCount and techCoefficient 7. apply efficiency modifiers and/or production fees to productionTime, mainResCount and secondaryResCount 8. display mainResCount, secondaryResCount, productionTime and techCoefficient (techCoefficient may be multiplied by 10 or 100 and rounded for better readability) Starting from secondary resource leads to a bit credits-greedy way to calculate resources but I find it better than mass-greedy variant and waaay easier to implement than balanced calculation for both. Important notice is that secondary resource may be almost massless but it should not be hard restriction to have it massless as someone may want to use resources from other mods for production (for example, RocketParts and something like RareMetals with USI mods looks like good alternative for me if algorithm will be capable to account for density and cost differences). And in addition there could be part module or modules to adjust part parameters in special cases: 1. resource in container production with all necessary coefficients and parameters 2. techCoefficient override 3. base cost in resources override (apply before fees) 4. scaling coefficients for resources and time costs (apply after fees) 5. part production restriction to remove part from production list That techCoefficient is important thing as it's not only used to influence part production time but could be as well used to add diversity to workshops based on min and max techCoefficient values supported by workshop. It's only my personal point of view on this and I don't ask to implement anything exact this way - just sharing in case you'll find something interesting enough to be implemented.

That's how EL do it and personally I badly dislike that - for example enriched uranium can't be directly pumped in most mods and making it from material kits or rocket parts... It's even better than making fuel.

I'm glad that you find my ideas useful. By the way, I have another thing to say while you are working on UI - amount of mods that use their own tab for parts is increasing so more and more parts are marked as having no category. Finding such parts in full list is slow and boring process while you have no "search by name" functionality so I think it may be helpful to have separate tab in workshop UI for such parts, something like "Special" or "Mods" or whatever. Search will be better but it usually takes more time to implement and even more to implement it without lags so I understand why you are not doing it yet. And is it possible some day to have separate part module or any other way to put any part to your part tab without really converting it into workshop? I'd like to put some production themed parts from other mods there as separate tab for two or three or even five parts looks like overkill to me.

Nice UI, looks better for me. Maybe selected part name and limits of current workshop placed somewhere could improve it a bit. WIP features showcases are always interesting to look at but it may take more time than expected so be careful with it. Btw, what do you think about implementing part module that could apply overrides on cost and tank filling or even exclude part from list. Some parts are too powerful or too cheap or even both so it will be great to have precise control over part parameters for special cases. And tank filling override is sometimes necessary as well - for example, I have part called "portable repair kit" with limited supply of special resource. Main concern is that this resource should not be produced without producing repair kit. With workshop I could get only useless empty repair kit while said resource is just a kind of spare parts so it should be possible to produce it from material kits. I'd like to add module with override "make tank content from material kits" and "pay 50% more material kits for each unit of resource produced" to my part so it could be produced in working state and for balanced cost.

Avedis, try to use decoupler. BTW, I find packrat not stable enough for my liking so in latest missions I use micronode structural part as ballast (with some config tweaking) - it fits ideally between wheels and chassis. Only problem is - it looks terrible. So here it comes - new feature request for optional ballast part that may be used to offsetcentre of mass down and extend rover width.

protoz, are you by any chance using save where you already unlocked that node in techtree before?

Hevak, "of" could have different meaning. Think about it as "that is part of". BTW, I took nothing as an insult as well so let's just keep constructive discussion.

Sorry but I did not say that. Maybe word "from" will suit better than "of" there and cause less confusion, fixed. Gameplay-wise what will change for you if there will be stress indicator in addition to supplies left? You'll have the same one single resource you cold control - supplies. The same numbers - kerbal who lost all supplies will have 15 days of productive time left. There will be safe zone around kerbin to feel more comfortable from start. There will be the same 4 orange suits invulnerable to stress. You agree to have recuperation period but then it will have no gameplay difference from having stress dissipation over time. All that scary things about activating parts and so on are there just for example of what could be used as additional consequences. So, what really differs then so much that you may stop using this mod if such thing will be ever implemented, except some decorative things and less tolerance to prolonged starvation? Looks like that's you who took this small "pack of ideas to think about in a free time" as personal insult.

I agregated some ideas about lifesupport in feature request here. https://github.com/BobPalmer/USI-LS/issues/10 Sorry for providing only ideas and no pull request but unity is not my favorite platform to code things for.

Maybe it deserves another line in config? So one could make it 0 to disable or, say, 600K to cover some space around kerbin or whatever.

Gfurst, well, it's easier to repeat with more config examples this time. There is "perk" - a mere graphical button to inform you that you'll get bonus there. And there are multiple configs in antenna parts depending on node in techtree where perk should be. Just look at this antenna declaration from RemoteTech_Squad_Probes.cfg @PART[probeCoreSphere]:FOR[RemoteTech] { %MODULE[ModuleSPU] { } %MODULE[ModuleRTAntennaPassive] { %TechRequired = unmannedTech %OmniRange = 3000 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 15.0 } } } See that "%TechRequired = unmannedTech" line? It's where real unlock happens disregarding perk position in techtree. So you need to do something like this to really change perk position: First: what SR fix does - move perk to node of choice @PART[RTPassiveAntennaTech]:NEEDS[RemoteTech,UmbraSpaceIndustries]:AFTER[RemoteTech]:FINAL { @TechRequired = start //or whatever node you choose } Second: what SR does not - change all pointers to technode in all parts (note that it's just example and not real MM patch - it may need some changes to work) @PART [*]:HAS[MODULE[ModuleRTAntennaPassive]] { @ModuleRTAntennaPassive:HAS[#TechRequired[unmannedTech]] { %TechRequired = start //or whatever node you choose } } - - - Updated - - - I'm not expert in MM yet so I just tweaked a bit what got from other RT compatibility configs. Regarding antenna in cone - it's mainly to prevent abuse of cheap SR core as it will have free 100km antenna then. While cones will be a bit harder to abuse due to form and attachment rules.

Gfurst, you have sounding rockets installed. Remove file RemoteTech_SoundingRockets_Probes.cfg as fix in it is not working properly anyway. And use something like this instead: @PART[SR_Nosecone*]:HAS[!MODULE[ModuleRTAntennaPassive]]:NEEDS[RemoteTech,UmbraSpaceIndustries]:AFTER[UmbraSpaceIndustries]:FINAL { //antenna for nosecone %MODULE[ModuleRTAntennaPassive] { %TechRequired = start %OmniRange = 100000 %TRANSMITTER { %PacketInterval = 0.3 %PacketSize = 2 %PacketResourceCost = 15.0 } } } @PART[SR_ProbeCore]:HAS[!MODULE[ModuleSPU]]:NEEDS[RemoteTech,UmbraSpaceIndustries]:AFTER[UmbraSpaceIndustries]:FINAL { //control for probe core %MODULE[ModuleSPU] {} } P.S. I explained you a few pages back why and how this happens but who cares.

I'm not MM expert but I think using selection by index should help to make it more clean. - - - Updated - - - Checked this @PART[sR_Nosecone*] { -MODEL,1 {} } Works as expected. More clean way will be to add check to apply this patch only if FAR is installed.

It may be latest KIS bug with launch clamps - latest KIS is known to make decouplers not working sometimes. Personally I reverted to KIS 1.1.1 and experience no issues with launch clamps while EPL is still installed and working.

Confirmed. Latest KIS makes attached decouplers unusable. Reverted to 1.1.1 and decouplers work as expected.

HotSandwich, checked in latest KIS and it looks like I have the same issue. Will try to revert back to 1.1.1 and check again.

HotSandwich, I use small inline decouplers and all works fine for me. Only problem I have is that used up decouplers can't be recharged. The best solution would be docking ports but it looks like kraken likes to live there. (Not checked in latest KIS)

That attachNodeName = wheelmount in KASModuleGrab was widely used as it was only known way to make nodes snap while KIS gives you this possibility for any part and any node (just hit R to choose node to snap) so you just want to rearrange attachment nodes sometimes. For stackability, ground attachments, volume override and other special application you have to use KIS modules.

SirJodelstein, did you try to do something from this list? - changing attach node using R - saving and reloading game - looking for errors in log - attaching different part to that node

ssdctm, that's because KIS changed how it handles attachment to ground. before it was like this (took it from EPL stake) MODULE { name = ModuleKISItemStatic allowAttachOnStatic = true stackable = true editorItemsCategory = true equipable = true equipSlot = leftHand equipMeshName = body01 equipBoneName = bn_l_wrist01 equipPos = (-0.07,-0.03,0.05) equipDir = (85,0,0) } And now it should be more like this (took from ground base in latest KIS) MODULE { name = ModuleKISItem volumeOverride = 100 stackable = true allowAttachOnStatic = true } MODULE { name = ModuleKISPartStatic breakForce = 10 }