RELEASED EnhancedTemperature 1.3.2 reup

If you're doing a rewrite - I'd like to point out a few things that might be worthy of consideration(even if rejected ultimately). SInce this is going to be a long post, I'll do everyone a favor and use spoiler tags to collapse it all.

steamcommunity.com/sharedfiles/filedetails/?id=876362250
The shield bar api might be of use, where you can display a bar that says we need to warm up or cool down. I haven't looked at it closely yet. But it might interest you. If it doesn't use "localAnimator" then a modified version could - so that the bar doesn't display for anyone but the player it affects.

Another - maybe - possibility. I haven't looked at how hard-coded the player GUI is - the area with the portrait, health, energy, and hunger bars. I know some GUI mods exist that change the appearance of this. I don't know if it can be scripted etc. I DO know from failed attempts that the inventory interface cannot be and the engine just ignores my script. Other things - like containers - can be scripted even though they aren't that way originally. But that area might also be a nice place for a temperature bar(that resembles a thermometer) where as the bar expands out from the middle towards hot or cold.

While making an old mod ship compatible with current builds, I encountered some of the old objects that heated you up when near. They worked like this(from a torch).

Code:

  "statusEffects" : [
    {
      "kind" : "Warmth",
      "amount" : 8,
      "range" : 4
    }
  ],

Now that doesn't work anymore... or so I thought. I had to play around with this(of course) and got errors along the line of "no 'stat' in map:get()" etc. Something like that.

Code:

  "statusEffects" : [
    {
      //"kind" : "Warmth",
      "stat" : "nude",  //easy to see proof of concept
      "amount" : 1,
      "range" : 1
    }
  ],

So I guessed correctly that it wanted within the JSON object a "stat" key rather than "kind". IT WORKS. The implementation has changed and vanilla makes NO USE of this at all, but it is still supported.

But the reason this is huge would be not only the simplicity of stat-based warming/cooling(combined with having a player "resource" for body heat), but the performance would be much better. Letting the base engine determine that the player is in range and so applying the status is going to be faster than doing this through the usual LUA methods. You could even do tiered warming/cooling statuses based on proximity(get closer to the fire, warm faster) because "statusEffects" is an array and can have more than one status object each with their own data - "warm_10", "warm_15", etc.

You could also have some "invisible" statuses doing specialized checks. I believe each status can have its own scriptDelta so you can distribute the work load while reducing how many calls are made for things you don't need as often.

less often:
*daytime check - world.skyTime() probably but you also have things like world.time(), world.timeOfDay(), world.dayLength()
*if the player is in a built structure etc(perhaps recycling some colony deed code, rather intensive so call infrequently), More notes on this below
*wind - via world.windLevel(`Vec2F` position)
*layers - world.underground(`Vec2F` position), world.inSurfaceLayer(`Vec2I` position)
*light at location? That could indicate a shaded area(when not in a structure), but the documentation states this has a heavy performance penalty. Maybe better to avoid.

more often:
*Checking for liquid immersion
*A sort of master status checking the boolean state of other statuses. Besides this mod's own statuses, it might also check for "bed1" etc because covers(or sleeping bags) add insulation.
*a passive "warmBlooded" status (maybe only for warm-blooded species?) that moves the temperature towards the optimal value(or range) at a certain slow rate. Does not consider insulation factor but is more effective with insulation.
*Possible expansion - In the event that "warmBlooded" status needs to cool you, energy regeneration could be reduced(heat exhaustion) and likewise hunger rate reduced. I suppose you'd get hungry faster when really cold.

And a simple trick if you want to stagger the status script calls across different tics

*the status defines the scriptDelta to be 1(every tic)
*update has only a small timer that counts down a set number of tics. The exact count is different for each status.
*the timer runs out and update calls script.setUpdateDelta(dt)
**the dt argument is time in seconds
**to translate tics to seconds use desiredTics / 60

Code:

update = realUpdate

where as realUpdate is the real function intended to be used, initially defined under that nameSpace.

I don't think it should be an assumed "cooling" source even without accounting for lava. Liquid doesn't cool, but generally facilitates faster thermal transfer. You can get cold fast in water, but that depends upon the water being colder than your body temperature. If the water is warmer than your body temperature, it will heat you of course.

Where game play is concerned, it is best to assume that the liquids(aside from lava) are the same temperature as where it is located. So if you are somewhere cold - and loosing heat at a certain rate - being immersed in liquid would probably be a multiplier to the amount of heat your are loosing. Likewise when the player is heating up, it would accelerate you heating up. For most armors(except the air-tight variety), it would probably also nullify any insulation factor.

Different liquids could indeed have different properties regarding this. For example I believe water is a better thermal conductor than oil. And for unsupported liquids, you would want a default value - if even bothering to this degree. That's probably overkill.

Above i mention calculating if the player is in an enclosed structure. I think it is safe to assume that any heating/cooling object is much more effective in an enclosed structure and will affect the entire area. So if it has been determined the player is in an enclosed structure, only then scan for objects that would heat/cool you (as you do now all the time) and if found apply a degree of heating/cooling to the player.

If not in an enclosed structure, these objects can still provide some benefit per the "statusEffects" in the object's JSON (I spoke of earlier). The player then needs to get much closer to them of course (and it makes sense).

After detecting the objects, you probably don't need to scan for them again... until the player has left and re-entered a structure? Or at least not without a large countdown. Save some CPU cycles there.

Also where I mention recycling colony deed code, it could definitely be improved upon for this application. For example the colony deeds try to complete a "loop" and accept a door being present in the space as sufficient(open or closed) to satisfy this. It calls upon the door's own functions (inefficient functions at that) to return in the door is present at a world location or not.

But actually you can make that easier and quicker by simply looking for a tile there - any tile really except platforms. Closed doors create a "metamaterial:door" tile (that provides the collision itself). Open doors do not have tiles, but open doors also let the outside air in thus it works well to just check for tiles and ignore doors themselves.

Since I'm digging into old things, here's some stuff from Enraged Koala's player.config

Code:

  // 50mins @ 5C = 15000sec/1C
  "warmthTransferRate" : 1000.0,
  "warmthTransferRateCap" : 1000.0,
  "comfortRegen" : 2.0,
  "bodyTemperatureRangeLow" : [5, 99999],
  "windChillFactor" : 10,
  "idealTemperature" : 25,

  "maxOverlayPercent" : 0.8,
  "freezeOverlayColor" : [175, 175, 255],

Biomes had stuff like this(from jungle surface biome).

Code:

  "statusParameters" : {
  "temperatureBounds" : [30, 50],
  "dayNightTemperatureVariability" : 15,
  "temperatureVariability" : 10
  }

That leads me into the next thing.

While you certainly can do things like patching the biomes, I was thinking how cool it would be to somehow get the temperature into integrated into the generation(like how gravity can be made vary within a range), so that you have some variability but in ways that makes sense.

What's more you have mods like Truespace that put hotter biomes closer to starts, colder biomes further from them. The range also varies by star class(as some are hotter than others). A temperature range variance that is different for different orbits... would be possible if first getting the info into the biome generation itself. And while this is a natural fit for TS, you need not limit it to TS systems or require TS to do this.

The system generation is fairly versatile. You can put attributes for a world class, later to have those attributes overwritten by the biome. Likewise the planet sizes have their own attributes attached, which can later be over-written in the same manor. There is a hierarchy where attributes between celestial.config, terrestrial.config, and individual biomes are merged.

If you made a silly "black hole" star, that could define all the planets (despite their defined attributes in another file) have crushing levels of gravity. But maybe they have a crazy high-tech planet(a possible selection choice anyhow) that can normalize the gravity. Such things are possible. So with that in mind, I was thinking something like

Code:

  "variationParameters": [
    {
      "statusParameters" : {
        "temperatureBounds" : [30, 50],
        "dayNightTemperatureVariability" : 15,
       "temperatureVariability" : 10
      }
    },
    {
      "statusParameters" : {
        "temperatureBounds" : [35, 55],
        "dayNightTemperatureVariability" : 15,
       "temperatureVariability" : 10
      }
    }
  ]

Of course I just copied the old code that's in biome files. Probably the engine won't recognize it anymore. But that's not what I'm really after.

Where to use that? I guess it could go back into the biome files. But alternatively... within celestial.config you have some options. You know what... rather than that being under "variationParameters" a single value under "baseParameters" is better. You can place versions of that under the different "planetaryTypes" and "satelliteTypes" to have basis. Then in the class star definitions you have "orbitRegions" which is an array of objects. The objects look like

Code:

        {
          "regionName" : "Class K Warm Belt",
          "orbitRange" : [2, 3],
          "bodyProbability" : 0.66,
          "orbit_temperatureModifier" : 120,
          "planetaryTypes" : [
            {"weight" : 0.2, "item" : "HotPlanet"},
            {"weight" : 0.6, "item" : "WarmPlanet"},
            {"weight" : 0.1, "item" : "GasGiant"},
            {"weight" : 0.05, "item" : "AsteroidField"},
            {"weight" : 0.05, "item" : "WarmBarren"}
          ],
          "satelliteTypes" : [
            {"weight" : 0.55, "item" : "Moon"},
            {"weight" : 0.225, "item" : "WarmNSat"},
            {"weight" : 0.225, "item" : "MildNSat"}
          ]
        }

The idea being you add the "orbit_temperatureModifier" to whatever the temperature would be otherwise. As you get further out, that modifier drops (minimum of 0 because this is how much the star is heating the worlds in that orbit belt). Different star classes would also have a different range, but since "orbitRegions" is a part of the star class definitions, you don't need anything tricky to set the value right. A cooler star's first orbit region would be cooler than the same region from a hotter star.

If using that sort of modifier, you'd start the base(unmodified) temperature levels very low - often negative numbers - knowing that the modifier would be added to get the ultimate temperature ranges. And the result is that - for example - an asteroid field would normally be a very cold place. But asteroid fields that are really close to a star - especially a hot star - could be warm or even hot places. And semi-molten (probably also irradiated) asteroids would also be neat if dangerous idea for a biome. I might also think about making it brighter, but that's another matter.

And you must be thinking... "even if you do all this, how can it be USED effectively by the mod?" The game engine is probably going to ignore it, but... I "think" those attributes can be accessed by world.getProperty

Code:

local temperatureModifier = world.getProperty("orbit_temperatureModifier")
local statusParameters  = world.getProperty("statusParameters")

From that info you calculate the effective temperature range you could have, randomly choose a number from the range. Possibly having a weighted range and adding the modifier if you want to be fancy. Also the night time temperature etc. You then write this info back into the world. Lets say the calculated values are saved in a local table named baseParameters

Code:

world.setProperty("enhancedTemperature_surfaceParameters", baseParameters)

Your code would probably look for that property first, and if not present then calculating and inserting it into the world properties for future reference.

I also know you probably wouldn't utilize the "dayNightTemperatureVariability" in underground biomes. Really probably not the "orbit_temperatureModifier" either. Being as the underground is heated less by the stars than the surface would be. It might be a trick to figure out when you're at the core biome level(which is hot). But then again it might not be. Maybe you can pull information like this

Code:

getLayer = function()
  local layers = world.getProperty("layers")
  local pos = mController.position()
  local possibleLayers = {
    "space",
    "atmosphere",
    "surface",
    "subsurface",
    "underground1",
    "underground2",
    "underground3",
    "core"
  }
  --possibleLayers is ordered from top to bottom
  --therefore ipairs can be used for sequential list iteration
   
  for _, L in ipairs(possibleLayers) do
    if pos[2] >= layers[L]["layerLevel"] then
      return L
    end
  end

end

From the string returned, you know what layer you are in.

Is this post too long? Yes.
Did I put entirely too much thought into this? Certainly but I enjoy thinking about problems of this sort and got carried away.
Was I clear enough? Probably not.
Will most (if not all) my ideas be rejected? Probably.
Will I be offended? No.
Will anything in this post be useful anyways? Hopefully some inspiration will come of it.

 

Does that include FU support? The minute support for FU comes out I'm downloading

 

Take your time man, we'll all be here waiting for release. Thanks for your dedication.

 

hey, this has become a must have mod for me o7
if you ever need a pixel artist for this mod, other mod idea or anything just send me a pm ovo/

 

Invent a machine that works like Field Generator with the requirement of a Colony Deed where it will only work if the room is enclosed completely?
It sounds like it'll be taxing if the character itself has to check on whether if there are enclosed environment around when the character is moving around continuously.
I'm not sure what are you working on and how does it work so I'm just giving random suggestion.

 

After playing a long while with this I've some feedbacks / bug reports / misc suggestions to make.

Feedback
1) The energy penalty system is overlimiting.
Why :
This is especially true when you are going for extreme / endgame planets. I understand there are throwable weapons like darts and whatnot that can be used as substitute but the energy is simply too valuable to be the one that receives heavy penalty. Tech like morph balls and sprint use energy, and every single 2 handed weapon's alternate ability and every single gun uses energy. With something that limits your tremendously you're nothing more but a caveman who can only use melee weapon most of the time...and this hinders endgame progression way too much.
Suggestion :
- Make certain consumable items like food and drinks to recover energy and/or stop energy drainage when used. For now, even the energy zone from the staves are not going to regenerate your energy in any way.
- Perhaps exchange the energy drain effect to slower movement and push the energy drain / being stopped to level 2 and/or 3 only. It is natural for desert nomads to proceed slowly in desert to preserve energy / hydration since that hyperthermia is the one you haven't implement for movement penalty.

2) The pace of exposure change is too fast.
Why :
Most of the time when you want to get warm / cooldown the exposure change is rather slow. But when you're finally on a safe exposure and decides to move out, it only take half the time for you to be in hyperthermia or hypothermia again and this happens with EPP equipped even in normal Snowy / Desert planets where EPPs are not required, which if I read correctly that they will help in decreasing the change of exposure rate.
Suggestion :
- Just like 1), make certain consumable items to increase or decrease your exposure gradually / immediately for a duration of time like a buff.
- Tweak the exposure system a little more where it'll be at least 1:1 in duration to get from safe to hyper/hypothermia and vice-versa. Best if 1.5 or 2 : 1.

3) The damage being applied on yourself is too noisy.
Why :
Well, it is simply too noisy since it is one tick per second.
Suggestion :
Either make it to act like Heatwave / Cold Snap from Diverse Weather where your HP is constantly drained without any touch / elemental damage being applied on you or reduce the period of time between each tick, the former is better I guess. The S.A.I.L. notification is enough to warn the user.

Bug Report
1) The system will not start if you beam down to a planet with a mech. Other than that I've not encounter any bug.

Misc suggestion
1) The Heatwave / Cold Snap from the Diverse Weather will only takes effect when you're exposed to the sky directly, otherwise the effect will not trigger if there are roof / obstacles on top of your head which does not produce any lag, so maybe that can be of some use if you still want to use that on-the-fly feature.
2) Maybe make vehicle a hybrid source when you're riding one...though this seems to be needed to be tweaked individually for any modded vehicle like shuttlecraft to make use of that feature as the vanilla vehicles are all opened to the air...unless it can be applied generally to all vehicles.

 

Ah, that's good then.

 

This happens whenever the ash weather triggers, and when that happens I'm either kicked up back to ship or quit to main menu.

[Error] WorldServerThread exception caught: (StatusEffectDatabaseException) No such unique stat effect 'IB_EHT_ligthash'

 

Not sure if something is wrong but now your HP won't reduce by 1 per tick when energy is depleted on hyperthermia level 2. The 5 damage per tick for hyperthermia level 3 still occurs though.