[1.3.0] Kerbalism v1.2.9

[lajoswinkler]

1 hour ago, ShotgunNinja said:

@lajoswinkler The magnetosphere function is like this: 1 inside the sphere defined by the magnetopause, gently fade from 1 to 0 in a 'fat falloff' area just outside it (20% its length), then zero outside.

 

@lude Added to next version, thanks.

 

I could make you some nice infographics with graphs if you give me equations that govern the rules in Kerbalism.

 

6 minutes ago, cicatrix said:

Which planets have magnetospheres according to this mod?

Kerbin and Jool certainly, but I'm not sure about the rest.

[cicatrix]

2 minutes ago, lajoswinkler said:

I

2 minutes ago, lajoswinkler said:

9 minutes ago, cicatrix said:

Which planets have magnetospheres according to this mod?

Kerbin and Jool certainly, but I'm not sure about the rest.

 

This is kind of important if you plan to maintain a long-term base. Radiation can be a problem.

[Nansuchao]

1 hour ago, cicatrix said:

Which planets have magnetospheres according to this mod?

Every planet with an atmosphere, so Eve, Duna, Kerbin, Jool, Laythe.

[ShotgunNinja]

New version: 0.9.9.4

•   - new part! an artificial gravity hab by mehka
•   - new part! small food container by Nazari1382
•   - new part! a better 1.25m food container by tygoo7
•   - added support for ConnectedLivingSpace
•   - vessel info window
•   - new 'medium' scope for antennas  
•   - doubled amount of EC on eva suits
•   - minor changes in the EnergyTweaks
•   - reduced radiation influence over malfunctions
•   - MM patches for NearFutureElectrical and NearFuturePropulsion by Fraz86
•   - default antenna patch by speedwaystar
•   - greenhouse module can specify an emissive object for the lamps
•   - fix: greenhouse module do not assume there is a shutter anymore
•   - fix: monitor tooltip, this time for real
•   - fix: antennas should work with contracts now
•   - fix: issue with EVA prop getting created out of thin air
•   - fix: curved solar panels weren't working
•   - fix: kerbals don't stop eating anymore

 

The gravity ring habitat from mehka!

 

The food containers by Nazari1382 and tygoo7!

 

The vessel info window:

 

ConnectedLivingSpace support:

Quality of Life and Radiation mechanics apply to individual internal spaces if ConnectedLivingSpace is installed, else the whole vessel is assumed to be a single internal space.

[TheUnamusedFox]

6 hours ago, ShotgunNinja said:

@JonGustav, @Squelch7 Good idea, I'm going to look how I can do it.

 

@White Owl There is a new medium scope in new version. You are right its simpler this way.

 

@lajoswinkler The magnetosphere is spherical, I know its a bad approximation. In a later version I want to make them drop-shaped and show them in the tracking station somehow.

 

@lagcity613 I will investigate. Quick question, where you using curved solar panels? Because those are broken in current version and a fix is in the new one (coming soon).

 

That would explain part of it. Yes, I was using curved solar panels. However, I did also put a 10 ec/s rtg module onto a part all the satellites had, and it did nothing to help. That's far, far more than they consume. -edit tried the latest update, all are charging correctly! Thanks

Edited April 26, 2016 by lagcity613

[ShotgunNinja]

@lagcity613 I am unable to reproduce it. What RTG were you using?

 

@cicatrix Use the planner in the editors, click to change body. There are magnetosphere details in the 'radiation' section. An atmosphere isn't a requirement for magnetospheres.

 

[TheUnamusedFox]

10 minutes ago, ShotgunNinja said:

@lagcity613 I am unable to reproduce it. What RTG were you using?

 

@cicatrix Use the planner in the editors, click to change body. There are magnetosphere details in the 'radiation' section. An atmosphere isn't a requirement for magnetospheres.

 

I didn't use an RTG - I added a 10ec/s rtg module to the microwave relay, which all the satellites had. However, I'm still testing it, but the issue seems to be gone in the latest version.

[ShotgunNinja]

@lagcity613 Ok, maybe it was related to curved panels (that's now fixed). Let me know if the problem resurface.

[Brucey]

This mod looks neat.  Think I'll give it a try.

Will this....

On ‎4‎/‎18‎/‎2016 at 9:44 PM, ShotgunNinja said:

SCIENCE TWEAKS

  Early experiments have been rearranged in the tech tree. Data is either transmissibile in full or not
  at all. Experiments provide full science values. Situations have been tweaked, no more ladder dance.
  Probes can store data and perform a simple telemetry experiment

...play nice with ETT?

btw, the "coherent background simulation" was something I was looking for, and failed to find, a year ago.  I'm glad someone's finally figured out how to do it.  How did you deal with variable ec production from solar panels?  That always seemed to be the difficult part. 

 

 

Edited April 26, 2016 by Brucey

[Toonu]

3 hours ago, goldenpsp said:

Dude, seriously give it a rest.  Your constant questions are as bad as someone pestering a modder about upgrading for X.X compatibility.

It is important to keep in mind that modders aren't our personal programmers.  To paraphrase another popular and prolific modder "I made these mods for myself.  I am nice enough to share them with everyone else"

 

Yes, I know I was bit too annoying. I'm sorry for that. I didn't want push on @ShotgunNinja in any way. I'm sorry for that...

[KocLobster]

This mod looks absolutely amazing, I can't wait to try it!

Does it play well with UKS if I uninstall USI-LS?

[Nansuchao]

 

9 minutes ago, KocLobster said:

This mod looks absolutely amazing, I can't wait to try it!

Does it play well with UKS if I uninstall USI-LS?

It can create some issue seen that UKS and all the USI mods rely on the Community Resource Pack, while Kerbalism not again. But you can try it by yourself.

[Mynhardt Kitshoff]

Dude this mod is freekin awsome!!! Love it!!! love the neat display/format... Just thought I mention it though that I had a problem where I could not launch any probes...it just did not want to stage... When I use your mods comunitron/arial it works fine but any of the other antennas does not work... which means I can not combine your mod with remote tech :-( I'll check in from time to time to see if it has been fixed. Good luck and thank you for putting in the effort for this great mod. 

Edited April 26, 2016 by Mynhardt Kitshoff

[RoverDude]

32 minutes ago, Nansuchao said:

 

It can create some issue seen that UKS and all the USI mods rely on the Community Resource Pack, while Kerbalism not again. But you can try it by yourself.

I'd say at the moment, this mod and anything that uses CRP is pretty much incompatible (or at the very least, will break in some really unpredictable ways).  For UKS I'd recommend USI-LS or (once it's updated) TAC-LS.

Even with a resource sorting, I'm not sure how this will play with the UKS production chains as those all use stock converts (or stuff based on stock converters), and as I recall, Kerbalism changes some of that.  I have not heard of folks mixing them yet, but likely that's mostly because of the resource conflict.

[ShotgunNinja]

 

@RoverDude Everything that uses stock generators will work in background. Also everything that uses stock resource converters and harvesters. Essentially I run the simulation for converters and harvesters at each fixed step (for all unloaded vessels) and set the 'lastUpdateTime' value constantly to current universal time to 'disable' default stock background simulation.

[RoverDude]

As the fellow who wrote the stock resource system, I would say that doing the calcs every frame may not be a good idea at scale with long resource chains and multi-step conversions.  

[iguana_man]

7 minutes ago, ShotgunNinja said:

 

@RoverDude Everything that uses stock generators will work in background. Also everything that uses stock resource converters and harvesters. Essentially I run the simulation for converters and harvesters at each fixed step (for all unloaded vessels) and set the 'lastUpdateTime' value constantly to current universal time to 'disable' default stock background simulation.

 

3 minutes ago, RoverDude said:

As the fellow who wrote the stock resource system, I would say that doing the calcs every frame may not be a good idea at scale with long resource chains and multi-step conversions.  

Every frame seems excessive! Since this is background processing something closer to every in game hr would be fine, no?

[ShotgunNinja]

@RoverDude Well keep in mind I'm ignoring temperature completely. Also all my background resource updates ignore stacking altogether. It boils down to something like this:

Spoiler

// converter
// note: support multiple resource converters
// note: ignore stock temperature mechanic of converters
// note: ignore autoshutdown
// note: ignore crew experience bonus (seem that stock ignore it too)
// note: 'undo' stock behaviour by forcing lastUpdateTime to now (to minimize overlapping calculations from this and stock post-facto simulation)
if (module.moduleName == "ModuleResourceConverter")
{
  // determine if active
  bool activated = Convert.ToBoolean(module.moduleValues.GetValue("IsActivated"));

  // if active
  if (activated)
  {
    // get module from prefab
    ModuleResourceConverter converter = part_prefab.Modules.GetModules<ModuleResourceConverter>()[converter_index++];

    // determine if vessel is full of all output resources
    bool full = true;
    foreach(var or in converter.outputList)
    {
      double amount = Lib.GetResourceAmount(vessel, or.ResourceName);
      double capacity = Lib.GetResourceCapacity(vessel, or.ResourceName);
      double perc = capacity > 0.0 ? amount / capacity : 0.0;
      full &= (perc >= converter.FillAmount - double.Epsilon);
    }

    // if not full
    if (!full)
    {
      // calculate worst required resource percentual
      double worst_input = 1.0;
      foreach(var ir in converter.inputList)
      {
        double required = ir.Ratio * TimeWarp.fixedDeltaTime;
        double amount = Lib.GetResourceAmount(vessel, ir.ResourceName);
        worst_input = Math.Min(worst_input, amount / required);
      }

      // for each input resource
      foreach(var ir in converter.inputList)
      {
        // consume the resource
        Lib.RequestResource(vessel, ir.ResourceName, ir.Ratio * worst_input * TimeWarp.fixedDeltaTime);
      }

      // for each output resource
      foreach(var or in converter.outputList)
      {
        // produce the resource
        Lib.RequestResource(vessel, or.ResourceName, -or.Ratio * worst_input * TimeWarp.fixedDeltaTime * Malfunction.Penalty(part));
      }
    }

    // undo stock behaviour by forcing last_update_time to now
    module.moduleValues.SetValue("lastUpdateTime", Planetarium.GetUniversalTime().ToString());
  }
}

 

 

EDIT: I'm not detecting chains of transformations or anything like that, I do it 'verlet style'.

Edited April 26, 2016 by ShotgunNinja
verlet style!

[RoverDude]

@ShotgunNinja - you seem to be missing a lot of the calculations like efficiency bonuses (both base and override), skill bonuses/penalties, required resources (which are pretty critical to how MKS works)), etc. - also, handling of core heat when you leave focus during warm-up (especially for long-running initial cycles like the large ISRU) is missing.

While I totally get that this is your mod, etc. - the omission of some of those bits pretty much renders this incompatible with UKS (i.e. efficiency updates and required resources are absolutely core to how it works).

(Edit)

just because tone can sometimes come off weird on the internet

I am in no way disparaging your mod - it's a nice piece of work.  Building performant software means we do a lot of compromises.  We make some compromises for stock, you make a different set of compromises.  Neither way is right nor wrong.  My only note is that mods that lean on one set of rules are not necessarily going to work with mods that lean on a different set.  

 

16 minutes ago, iguana_man said:

 

Every frame seems excessive! Since this is background processing something closer to every in game hr would be fine, no?

If you did it every hour or so for unloaded vessels, you are essentially back to a catch-up mechanic ala stock   

Edited April 26, 2016 by RoverDude

[ShotgunNinja]

@RoverDude I'm doing it at every simulation step (so assume something like 60hz). The ISRU temperature bit was too hard to simulate in background. The required resources i check, i believe. Or you mean that some resources may be required and others not? Trait bonus i can add it, as I already using it in the Drill simulation.

 

EDIT: btw, do the trait bonus scale resource produced only, or also the required one in converters?

EDIT2: what is efficiency then? damn i've missing something here

Edited April 26, 2016 by ShotgunNinja

[RoverDude]

Thermal is actually pretty important for some mods (heck, it's really important for stock), so I'm not sure on the answer there for ya.  And yes, there's a whole set of optionally required resources that have an impact on overall efficiency (so you can simulate things like machinery wearing down, or actinides clogging up a reactor).

You also have ancillary bits unrelated to stock resource that will also break down - i.e. the handling of disconnected resources for background ships, etc. (plus other modules that work off of the base converter class or make assumptions based on chunking delta time during warp or return to focus).

 

 

(edit)

Again, I don't want to have this come off as negative, just helping out and hopefully pointing out some potential problem spaces.

[ShotgunNinja]

@RoverDude I find it very positive instead. I want to improve this, and so you are being extremely usefull really

[RoverDude]

Ok good deal   Feel free to ping me with questions

[Wjolcz]

I think I might have found the perfect life support mod.

[Fraz86]

@ShotgunNinja Regarding NearFuture compatibility:

• The NFSolar patch strikes me as excessively harsh. Stock static panels were cut to ~23% output and stock deployable panels to ~10%, but the NF panels were cut to 5% (non-curved) and 2.5% (curved). As a result, the NF panels have terrible EC/mass ratios - significantly worse than any stock panel despite being much larger and more advanced.
• I think the capacitors from NFE might need some further changes. In the patch, I only cut their charge and discharge rates, leaving capacity unmodified, because I regarded capacitor capacity as analogous to battery capacity. However, upon further consideration, perhaps capacitors' 800% capacity/mass (relative to batteries) is too great an advantage considering the increased importance of EC storage. Maybe the capacity should be cut in half?
• I have a few additional patches to share...

NFSpacecraft

// The Mk3-9 pod was intended to have advanced technology that allows it to continue operating even when there isn't a Kerbal at the helm. The game doesn't allow a part to actually function as both a manned command pod and a drone, so technically it was just a drone (it could not be piloted by a Kerbal). With Kerbalism's signal requirement for drones, this becomes a disadvantage rather than an advantage. Thus, this feature is replaced with conventional crew command, and SAS is converted to standalone.
@PART[mk3-9pod]:AFTER[NearFutureSpacecraft]:NEEDS[NearFutureSpacecraft]
{
	@description = This newer command cockpit is optimized for orbital operations - it sacrifices some durability for lower mass. Advanced computer-assisted flight control allows even an untrained pilot to operate the pod with ease.
	@MODULE[ModuleCommand]
	{
		@minimumCrew = 1
		!RESOURCE[ElectricCharge] {}
	}
	@MODULE[ModuleSAS]
	{
		standalone = True
		RESOURCE
		{
			name = ElectricCharge
			rate = 0.03
		}
	}
}

// Though the Itinerant resembles a half-capacity Hitchhiker, it feels too cramped and utilitarian to have an Entertainment value. Instead, it seems appropriate for it to have a CO2 scrubber. Also, the power output of its built-in RTG is cut proportionally to the stock RTG.
@PART[utilityCabin]:AFTER[NearFutureSpacecraft]:NEEDS[NearFutureSpacecraft]
{
	RESOURCE
	{
		name = CO2
		amount = 0.0
		maxAmount = 2.0
	}
	MODULE
	{
		name = Scrubber
		ec_rate = 0.02
		co2_rate = 0.0000926
	}
	@MODULE[ModuleGenerator]
	{
		@OUTPUT_RESOURCE[ElectricCharge]
		{
			@rate = 0.2
		}
	}
	@MODULE[ModuleRadioisotopeGenerator]
	{
		@BasePower = 0.2
	}
}

CryoTanks:

// Power requirements for ZBO (zero boil off) tanks cut to 25%
@PART[*]:HAS[@MODULE[ModuleCryoTank]]:AFTER[zzz_CryoTanks]:NEEDS[zzz_CryoTanks]
{
	@MODULE[ModuleCryoTank]
	{
		@CoolingCost *= 0.25
	}
}

KerbalAtomics:

// Nuclear rockets cut to 25% power generation
@PART[ntr-*]:HAS[@MODULE[ModuleGenerator]]:AFTER[KerbalAtomics]:NEEDS[KerbalAtomics]
{
	@MODULE[ModuleGenerator]
	{
		@OUTPUT_RESOURCE[ElectricCharge]
		{
			@rate *= 0.25
		}
	}
}

 

Edited May 4, 2016 by Fraz86
Changed CryoTanks to zzz_CryoTanks