[Public Test] Improved temperature calculation

Tysek shared this feedback 2 years ago
Submitted

Welcome!

Recently I report 'warm' temperature detection at north pole as a bug. @Petr Minařík clarify that temperature is calucating only from:

1. Side of the planet you are on (day or night)

2. Height on the planet

3. Oxygen density

and it doesnt depends on material that you standing on.

So firstly I would like to propose displaing temperature in numbers [Celcius] it will be important later.

Next thing is new parameter for calculating temperature on planets. It could be definited in similar way that planet's sufrace is - some sort of RGB channels.

5bd835b69c6b0bde492e97b3c4388555

For ex. red channel define temperature spreaded gradiently on all of the planet's surface. ChannelValue=0 is 0K (-273Celcius), and value=255 is 546K (+273Celcius), thats the primary parameter. Value 127,5 = 0C (because 255/2), 0,467value is equal to +/-1K or 1C change.

Second channel - green - define changes during the day-night cycle. This is secondary parameter, which modify primary one. Example: ChannelValue=0 - no changes, ChannelValue=10 - means change: +/-10K durig the day/at night. Its dynamic parameter - addition and loss of temperature occurs gradiently durig day and night.

Third (not necessarily) channel - blue - define air humidity (wetness) and it is consist durig day cycle at certain place. This parameter is secondary to GreenChannel - it's modyfing second parameter. ChannelValue=0 means 0% humidity and its modifier=x1,0; channelvalue=255 means 100% humidity and its modifier=x2,0. So if is 100% humidity then previously set parameter (changes durig day cycle) is doubled; if it's 0% - second parameter doesnt change. Value 127,5 = x1,5, because 255/2 is 127,5.

Example 1: equator, desert: 1st. parameter=138 (~20C), 2nd. parameter=25, 3rd. parameter=0 (x1,0). At hottest moment of the day 20C+(25Cx1,0) = 45C, at cold midnight: 20C-(25Cx1,0) = -5C (so how it really is on desert).

Example 2: north pole: 1st parameter=112 (~-30C), 2nd. parameter=15, 3rd. parameter=64 (~x1,25). So at 'hottest' point of the day: -30C+(15Cx1,25) = -11C, at coldest: -30C-(15Cx1,25) = -48C.

Example 3: pole on Mars: 1st. parameter=81 (~-100), 2nd. parameter=20 3rd. parameter=0 (x1,0). Hottest: -100C+(20Cx1,0)= -80C, at coldest: -100C-(20x1,0) = -120C

Example 4: 'rainforest': 1st parameter=144 (~35C), 2nd. parameter= 5, 3rd. parameter=255 (x2,0). Hottest: 35C+(5Cx2,0)= 45C, at coldest: 35C-(5Cx2,0) = 25C.

Overall for this part: this featrue could force players to find proper place to stay and build a base. In addition surface restriction like that might occurs together with diversity of minerals placement. You want more crucial resources? No problem - prepare for harm environment. Moreover if helmet is open astronaut could get damage at extreme temperatures. Moving further if O2 is high, you dont have any oxygen bootle in backpack and temerature is extreme so you have to keep your helmet closed then your suit should have exta enegry consumption for heating/coolig air from environment.

Thats some of my quick ideas for survival feature. In my opinion environmental parameters are crucial to update.

Let me know what you think.

Comments (3)

photo
2

Values of each channels might be placed as on picture (I know that is not how RGB looks like).72ba27a47d8e75e491b8f8f48646cf31

photo
2

Actually this could also be used to define wind patterns since they are basically defined by thermal layers (altitude and pressure) and the relative humidity and temperature between the layers...

photo
1

I thought about define wind 'speed' by blue channel as well as humidity but with different transcription of channelvalue. I am not sure if its possible but great thing would be dynamic RGB map. I mean something like sequence of a few RGB maps (each with different channelvalues) which are changing every 5 or 10 day cycles. This way you might expirenced 'windy sunny season' for week (in game), you can charge your batteries etc. and then you have two weeks of cold time with barely detectable wind. Next RGBmap with wind speed somewhere in between, next without wind again, next maximum wind speed etc....

This mechanics (if it is possible) could involve green and/or red channel. "Winter", "spring", "summer", "autumn" - all of this in SE :D

According to my pervious comment:

4961924e1e7c4e51528ed07864263849