[1.3.0] Kerbalism v1.2.9

[kunok]

What about adding malfunctions based in planet weather?
Dust storms in duna or in the deserts biome in kerbin than dust your solar panels, so you need to eva to clean them , wind or storms that breaks panels or antenna in atmospheric bodies, ice storm in the poles and in the tundra, you get it. The kind of things with effects similar to the space weather

[Senior Slaphead]

...or some EVA peril... accidentally bumping into red-hot radiators or charged solar pannels has to be a bad thing right?  Me mate KiToban did some work on this... we called it 'Kerbal Frier' From a gameplay standpoint it's probably not kosher to just zap Kerbals, but stunning them or giving them a damaged suit might be interesting... e.g. 20 seconds to get back in the ship.

[pwhk]

Great mod

Apparently I killed my Kerbals when hitting the Wrap button (when next KCT completion is 6 days from now...)

After some experimentation it seems that Kerbalism may treat my Kerbin Station 1, which is on LKO, to be in shadow when it is not, if I use a wrap of x1000 or over... As the station completely depends on Solar panels you know what happen next

Offending save: https://www.dropbox.com/s/yjgf7u2qeajox74/A2 - copy.zip?dl=0

[bpilgrim]

@pwhk I've experienced this as well with my Kerbin low orbit station. I was warping for a Duna transfer when I got a message that all the Kerbals on my station were dead or dying. The station has more than enough EC production/capacity to survive while in Kerbin's shadow but it seems to not be calculating correctly when in background. I can upload the save when I get home if it would be helpful.

I was using Kerbalism and SCANSat as my mods.

[Starslinger999]

Hey guys, I want to say i am building a Jool 5 mission with Kerbalism and i'm just waiting for the mod to update to 1.2

Edited September 30, 2016 by Starslinger999

[The-Doctor]

I'm eager to play RSS but I want to wait until 1.2, yet I can't lol. I really want to build bases everywhere but I really need a 100% recycling capability

[ShotgunNinja]

Ok guys good news and bad news.

 

Good news #1: support for arbitrary complex resource chains

Kerbalism has a 'resource cache' that is used to deal with resources, both for loaded and unloaded vessels. It has been developed not only for performance, but to resolve all issues with consumption/production at high warp speeds. And it worked well. One of the thing that were required to make it happen was to have 'atomic recipes' of resource transformation. However order matter, and is not trivial to solve dependencies because there are loops in the resource transformations. Up until now the order of some processes was hard-coded: this worked in most cases, but it was possible to fabricate some problematic sets of producers/consumers that would break it to some extent. That was always a temporary solution, in fact, and the last 'hint' that the time was ripe for me to actually solve the problem came today when, dealing with the new pressurization system (and after my sixth espresso), I realized that hard-coded order was not possible because the correct order is dynamic based on resource levels, in that specific case. So the actual good news: I found a simple algorithm to deal with order automatically and dynamically. It can digest messy chains like this, and it just work in all cases (tm).

 

Good news #2: fast simulation of massive numbers of converters

This one is even more complex to explain. The problem encountered was that, with the new converter-galore, I was simulating a ton of ModuleResourceConverters in background, and there were a ton of them in general. And ModuleResourceConverter is not exactly lightweight. It does a lot of things, all of them useless to me. So in a single stroke I found an elegant way to just get rid of it once and forever and to finally scale to huge numbers of converters simulated at once, both on loaded and unloaded vessels. The way it work: there is an hidden pseudo-resource defining the 'capability' of some part to execute a resource conversion. Then, elsewhere, there is a definition of that resource convertion process. Finally there is a token module used to 'start/stop' that process but in reality it just set the flow to true/false (just like that little arrow icon next to a resource indicator). In code then I merely check the amount of the pseudo-resource and run the process at most once per-vessel, irregardless of the number of actual converters the user see. This work transparently for unloaded vessels too. Example:

Spoiler

// somewhere, you define a process: this is similar to how you defined a converter before
Process
{
  name = pressure_control
  resource = _PressureControl
  input = [email protected]
  output = [email protected]
}

// in some part
@PART[xxx]
{
  // this is hidden from the user
  RESOURCE
  {
    name = _PressureControl
    amount = 1
    maxAmount = 1
  }
  
  // add an optional ui to toggle the process on/off
  MODULE
  {
    name = ProcessController
    resource = _PressureControl
    title = Pressure Control System
    desc = Maintain internal atmosphere pressure
    metric = L/s
  }
}

 

Bad news: way behind schedule

I vastly underestimated the changes that were required for the new features, and how long it took to design them. In addition free time is very scarce at the moment (that's an understatement), and KSP 1.2 is changing a lot of stuff. So the next release could be one or two months from now, perhaps. Who really knows. If you are waiting, make yourself comfortable. I prefer to do this right, at my own pace, instead of rushing an half finished 'product'. 

[lordcirth]

Sounds like Squad should implement a similar resource handler in stock!

[TheSaint]

31 minutes ago, lordcirth said:

Sounds like Squad should implement a similar resource handler in stock!

Bingo. Background resource processing is exactly the sort of fundamental process/service that should be built into the game from the get go, not tacked on in a mod. Good job, ShotgunNinja. Shame on you, Squad.

[goldenpsp]

2 hours ago, TheSaint said:

Bingo. Background resource processing is exactly the sort of fundamental process/service that should be built into the game from the get go, not tacked on in a mod. Good job, ShotgunNinja. Shame on you, Squad.

It's easy being an armchair quarterback.

[The-Doctor]

@ShotgunNinja will 100% O2 recycling be available in 1.2? Also, is that methane? Will we be able to make methane? Please take your time and thanks for creating one of the mods I REFUSE to play without, this mod is my most favorite mod of all time 

[bradleyjh]

One thing I'd really like to see added is procedural life support tanks, only thing I miss about TAC, was just a tank the same as fuel tanks/structure fuselage with options for water, food, oxygen or a mixture of all three. Super useful, other than that, now that I know about this mod I won't play without it, it's fantastic and thank you!

[ShotgunNinja]

@The-Doctor Technically the sabatier process produce methane, however as a compromise I'm going to have it output LiquidFuel. The alternative is to go all the way and use realistic fuels, but that's a lot of work better done in other mods. So LiquidFuel represent Kerosene/Methane, Oxidizer is Hydrogen Peroxide, and Monoprop is Hydrazine. That's a necessary simplification.

Pods can include a small Solid Oxide Electrolyzer, after the necessary tech has been discovered. But this has an efficiency less than 100%, so that the player need to look into other ways to produce oxygen from other available sources. There will be processes to produce it from water, from ore or from atmospheric carbon dioxide. I'll do some infographic on all the available processes for the next week.

 

@bradleyjh The supply resource containers will be configurable in the VAB.

[pwhk]

For some reason, when I load my Kerbalism save the oxygen tanks become NaN%. Poor Jeb (who's on a trip to minmus) can't breathe and is now doomed

Offending save: https://www.dropbox.com/s/t3l4bodk2elkh6e/A2.zip?dl=0

Ship: Minmus 11

[nosscire]

On 10/2/2016 at 10:21 PM, ShotgunNinja said:ntents

// somewhere, you define a process: this is similar to how you defined a converter before
Process
{
  name = pressure_control
  resource = _PressureControl
  input = [email protected]
  output = [email protected]
}

// in some part
@PART[xxx]
{
  // this is hidden from the user
  RESOURCE
  {
    name = _PressureControl
    amount = 1
    maxAmount = 1
  }
  
  // add an optional ui to toggle the process on/off
  MODULE
  {
    name = ProcessController
    resource = _PressureControl
    title = Pressure Control System
    desc = Maintain internal atmosphere pressure
    metric = L/s
  }
}

Bad news: way behind schedule

I vastly underestimated the changes that were required for the new features, and how long it took to design them. In addition free time is very scarce at the moment (that's an understatement), and KSP 1.2 is changing a lot of stuff. So the next release could be one or two months from now, perhaps. Who really knows. If you are waiting, make yourself comfortable. I prefer to do this right, at my own pace, instead of rushing an half finished 'product'. 

 

For me, take all the time you need pal. All these changes look completely amazing, and as it will be save game breaking, I think we all agree it's better to get them all at the same time

 

I'm completely psyched to start a new game with the next version of Kerbalism, so i'll just pretend that KSP 1.2 doesn't exist until you are ready for release.

Quick question, have you decided yet how to deal with the new built in com system? I looked through the thread, and as far as I can see last you mentioned it you hadn't decided if to integrate it, or just scrap it for the vanilla system.

 

Thanks for an awesome mod

[The-Doctor]

@ShotgunNinja so co2 and water is planned for the next release? That would be interesting

[Bonus Eventus]

On 10/2/2016 at 2:21 PM, ShotgunNinja said:

Ok guys good news and bad news.

 

Good news #1: support for arbitrary complex resource chains

Kerbalism has a 'resource cache' that is used to deal with resources, both for loaded and unloaded vessels. It has been developed not only for performance, but to resolve all issues with consumption/production at high warp speeds. And it worked well. One of the thing that were required to make it happen was to have 'atomic recipes' of resource transformation. However order matter, and is not trivial to solve dependencies because there are loops in the resource transformations. Up until now the order of some processes was hard-coded: this worked in most cases, but it was possible to fabricate some problematic sets of producers/consumers that would break it to some extent. That was always a temporary solution, in fact, and the last 'hint' that the time was ripe for me to actually solve the problem came today when, dealing with the new pressurization system (and after my sixth espresso), I realized that hard-coded order was not possible because the correct order is dynamic based on resource levels, in that specific case. So the actual good news: I found a simple algorithm to deal with order automatically and dynamically. It can digest messy chains like this, and it just work in all cases (tm).

 

Good news #2: fast simulation of massive numbers of converters

This one is even more complex to explain. The problem encountered was that, with the new converter-galore, I was simulating a ton of ModuleResourceConverters in background, and there were a ton of them in general. And ModuleResourceConverter is not exactly lightweight. It does a lot of things, all of them useless to me. So in a single stroke I found an elegant way to just get rid of it once and forever and to finally scale to huge numbers of converters simulated at once, both on loaded and unloaded vessels. The way it work: there is an hidden pseudo-resource defining the 'capability' of some part to execute a resource conversion. Then, elsewhere, there is a definition of that resource convertion process. Finally there is a token module used to 'start/stop' that process but in reality it just set the flow to true/false (just like that little arrow icon next to a resource indicator). In code then I merely check the amount of the pseudo-resource and run the process at most once per-vessel, irregardless of the number of actual converters the user see. This work transparently for unloaded vessels too. Example:

  Hide contents

// somewhere, you define a process: this is similar to how you defined a converter before
Process
{
  name = pressure_control
  resource = _PressureControl
  input = [email protected]
  output = [email protected]
}

// in some part
@PART[xxx]
{
  // this is hidden from the user
  RESOURCE
  {
    name = _PressureControl
    amount = 1
    maxAmount = 1
  }
  
  // add an optional ui to toggle the process on/off
  MODULE
  {
    name = ProcessController
    resource = _PressureControl
    title = Pressure Control System
    desc = Maintain internal atmosphere pressure
    metric = L/s
  }
}

 

Bad news: way behind schedule

I vastly underestimated the changes that were required for the new features, and how long it took to design them. In addition free time is very scarce at the moment (that's an understatement), and KSP 1.2 is changing a lot of stuff. So the next release could be one or two months from now, perhaps. Who really knows. If you are waiting, make yourself comfortable. I prefer to do this right, at my own pace, instead of rushing an half finished 'product'. 

Great job SN, looks dope! Looking forward to integrating Kerbalism into Mother when the new release is out. Cool to see you implemented the emitters module, now I can make some awesome shadow shield parts!

[WishmasterTheKerbal]

Exploit ?

I successfully managed to plot and execute maneuver on a probe with no signal (blackout, storm?) by using mechjeb.

[nosscire]

On 10/8/2016 at 11:01 PM, WishmasterTheKerbal said:

Exploit ?

I successfully managed to plot and execute maneuver on a probe with no signal (blackout, storm?) by using mechjeb.

MechJeb is not compatible. Not compatible with RemoteTech either for that matter.

[Senior Slaphead]

A little question about radiation... is it based upon which part a Kerbal is actually in or is it an amalgum of the total shielding on a craft irrespective of where the Kerbal is?

[Bonus Eventus]

Shields subtract rads, so I believe it's calculated at the vehicle level and not per part—cumulative. 

Edited October 10, 2016 by Bonus Eventus

[John Nowak]

6 hours ago, Senior Slaphead said:

A little question about radiation... is it based upon which part a Kerbal is actually in or is it an amalgum of the total shielding on a craft irrespective of where the Kerbal is?

My understanding is that Kerbalism has two gaming mechanics related to how long your Kerbals remain in space: stress and radiation. The problem is that these two mechanics sort of work against one another.

If you have Connected Living Space installed, then the stress rules will assume your Kerbals are moving freely between the connected passable parts. So, if you (e.g.) have two Kerbals in a lander can (2 kerbals) attached to a Hitchhiker (4 kerbals), the morale rules will assume that each Kerbal has (2+4)/2 = 3 "units" of room, plus the morale benefits of a Hitchhiker. The more space they have, the less stress they undergo. Fine so far. 

With shielding, though, it's not clear exactly how the different parts "add up" to provide protection. This can get complicated.

Let's suppose that in the above example, the Lander Can is heavily shielded while the Hitchhiker is not shielded at all. I think the mod applies 1/3 of the shielding of the Lander Can to the radiation coming in, again because the assumption is that they're moving happily between the parts. Again, that makes sense. 

The problem is that during a CME event, you'd expect the kerbals to stay in the shielded Lander Can during the storm. 

I guess the ideal way to handle it would be that most of the time, kerbals get the "average" shielding of the habitable parts and the (reduced) stress of the larger living space, while during a CME they get the shielding and stress of the part they are occupying, because they're locked down in a smaller part of the ship. 

 

[Senior Slaphead]

11 hours ago, John Nowak said:

My understanding is that Kerbalism has two gaming mechanics related to how long your Kerbals remain in space: stress and radiation. The problem is that these two mechanics sort of work against one another.

If you have Connected Living Space installed, then the stress rules will assume your Kerbals are moving freely between the connected passable parts. So, if you (e.g.) have two Kerbals in a lander can (2 kerbals) attached to a Hitchhiker (4 kerbals), the morale rules will assume that each Kerbal has (2+4)/2 = 3 "units" of room, plus the morale benefits of a Hitchhiker. The more space they have, the less stress they undergo. Fine so far. 

With shielding, though, it's not clear exactly how the different parts "add up" to provide protection. This can get complicated.

Let's suppose that in the above example, the Lander Can is heavily shielded while the Hitchhiker is not shielded at all. I think the mod applies 1/3 of the shielding of the Lander Can to the radiation coming in, again because the assumption is that they're moving happily between the parts. Again, that makes sense. 

The problem is that during a CME event, you'd expect the kerbals to stay in the shielded Lander Can during the storm. 

I guess the ideal way to handle it would be that most of the time, kerbals get the "average" shielding of the habitable parts and the (reduced) stress of the larger living space, while during a CME they get the shielding and stress of the part they are occupying, because they're locked down in a smaller part of the ship. 

 

Right... that maybe explains why I lost four Kerbals in the last storm. I had dutifully stuck them all in the only shielded habitat (the Hitchhiker in this pic) for the duration but they got absolutely hammered by the rads. It doesn't help that they're on Minmus for longer than I'd want anyway due to research and gold mining... but it seems there really is no substitute to fully shielding everything.

 

Edited October 11, 2016 by Senior Slaphead

[John Nowak]

50 minutes ago, Senior Slaphead said:

Right... that maybe explains why I lost four Kerbals in the last storm. I had dutifully stuck them all in the only shielded habitat (the Hitchhiker in this pic) for the duration but they got absolutely hammered by the rads. It doesn't help that they're on Minmus for longer than I'd want anyway due to research and gold mining... but it seems there really is no substitute to fully shielding everything.

Interesting! Is the Hitchhiker the only habitable module on your base?

[Senior Slaphead]

1 hour ago, John Nowak said:

Interesting! Is the Hitchhiker the only habitable module on your base?

The Mining Rig has a lander can at the bottom (1 kerbal), the Science Lab is a Mobile Processing Lab (2 kerbals) and the return vehicle /gold hauler has a Hitchhiker can (4 kerbals) but none of this is shielded. There is also a rover for the Rover Science mod.  Only the crew hab / power plant has a fully shielded hitchhiker.  Usually there are four crew (2 scientists, an engineer and a pilot) but at the time of the storm it was during a rotation so there were eight and the old crew died off before I'd finished filling the gold cans, even though I'd put them in the shielded hab.  I think it was just too much on top of the mild rads they'd had there for some weeks.   I've returned the new crew with the gold this time until I can improve the shielding, so research has stopped.

What I may try is just disconnecting the KAS pipe from the shielded habitat during a storm.  It kinda makes sense actually as you wouldn't want resources being pumped from an irradiated part of the base.