Thomas changed the topic of #kspmodding to: Welcome to #kspmodding - the channel for discussing, and learning about, modding Kerbal Space Program. Code of Conduct: https://git.io/vSQh6 | Always provide logs (do !support for help). | *** PSA: https://kerbalspaceprogram.com/api/index.html | <Red5> Guy was asked for a log file, he gave this link: http://pastebin.com/wfVarZPf
<taniwha>
however, there's a very good reason Kethane uses a hex-grid
<taniwha>
no issues at the poles :)
<taniwha>
(also, it's why PQS is actually a cube)
<riocrokite>
cube system is nice however implementation has sever performance issues so for me it's not feasible to use kethane atm
<riocrokite>
RD stock system is nice since it only set values to depletion node when you mine and deplete stuff so you don't need to load thousands / millions of nodes but only those you created by your activity
<riocrokite>
thus allowing very good depletion resolution i.e. very small depletion node
<riocrokite>
size
<taniwha>
does the stock system let you choose the location of the depletion nodes?
<riocrokite>
currently it's not finished and borked
* taniwha
is shocked. shocked, I tell you
<riocrokite>
I want it to create depletion node based on your latitude/longitude rounded to 0.0 or 0.00 or 0.000
<riocrokite>
depending on planet/moon size
<Sigma88>
question: where can I find reliable numbers about orbital periods of planets in the solar system?
<taniwha>
I'd use the body-relative radial normal vector instead
<Sigma88>
I tried jpl horizons
<taniwha>
Sigma88: possibly not public knowledge
<Sigma88>
but it gives me two numbers that are not consistent with eachother
<taniwha>
also, you need to check the dates of those numbers
<Sigma88>
it's in the same sheet
<taniwha>
iirc, they use keplerian parameters with an epoch because the parameters constantly change
<taniwha>
you sure you're interpreting them correctly?
<Sigma88>
they give you orbital period in days and in years
<Sigma88>
if I take mars parameters (for example)
<Sigma88>
and divide them by earth parameters
<Sigma88>
so rotation period of mars / rotation period of earth
<Sigma88>
revolution*
<Sigma88>
if I compare the values expressed in years I get a different number than I get with days
<taniwha>
could they be using martial days for the martian year?
<Sigma88>
mars orbital period = (1.88081578 years OR 686.98 days)
<Sigma88>
I don't think so, let me check with venus
<taniwha>
>>> 1.88081579 * 365.25
<taniwha>
686.9679672975
<taniwha>
looks like 686.98 to me
<Sigma88>
venus orbital period 0.61519726 y
<Sigma88>
taniwha: earth orbital period is not 365.25 according to jpl
<Sigma88>
365.25636
<taniwha>
>>> 1.88081579 * 365.25636
<taniwha>
686.9799292859243
<Sigma88>
admittedly the difference is not much
<Sigma88>
:D
<taniwha>
not a lot of difference
<Sigma88>
1.000017508 this is the ratio
<Sigma88>
I guess I have to be happy with that
<Sigma88>
:D
<Sigma88>
!wa mars orbital period / earth orbital period
<Qboid>
Sigma88: Mars | orbital period/Earth | orbital period: 1.8808149
<Sigma88>
jpl give me either 1.880783054 or 1.880815984
<Sigma88>
so basically it's accurate to the fourth decimal digit
<Sigma88>
btw, they are earth days
<Sigma88>
probably 24h days
<taniwha>
probably
<taniwha>
which means solar days
<taniwha>
(rather than sidereal)
<Sigma88>
still it shouldn't matter, since I use the ratio
<taniwha>
true
<taniwha>
but useful for double checking
<Sigma88>
I wasn't sure what was going on, since I assumed those numbers were printed starting from the same "time"
<Sigma88>
so just divide the orbital period expressed in seconds by the time unit you choose
<Sigma88>
but it's probably a different process
<riocrokite>
oh man imagine what if I could create depletion every geographical second
<riocrokite>
this means new node every 35m on mun :P
<riocrokite>
I wonder if engine can handle that
<riocrokite>
that would prevent people driving in harvesting in circles :P
Pap has quit [Quit: Leaving]
<Sigma88>
do you need to have all surface covered in nodes at all times?
<taniwha>
riocrokite: what? no regolith circles? ;)
<taniwha>
(instead of crop circles)
<riocrokite>
lol
<riocrokite>
Sigma88: that nice thing is that I create depletion node only in places I mine
<Sigma88>
ah ok
<riocrokite>
so if I don't do anything there are literally 0 depletion nodes in memory
<Sigma88>
yes that's what I was thinking
<Sigma88>
you just save lat-long and radius
<taniwha>
riocrokite: any reason to not use kethane?
Pap has joined #kspmodding
<riocrokite>
radius?
<Sigma88>
well, I guess you will need to define how "large" the area is
<riocrokite>
taniwha: I need super granutality of nodes
<Sigma88>
otherwise you move 1 cm and create a new node
<taniwha>
there's no reason you couldn't have sub-cell sized data in a cell
<riocrokite>
and kethane loads everything for every resource and planets at once
<riocrokite>
so with even couple resources and smaller nodes game slows down dramatically
<riocrokite>
changing scenes takes forever etc
<taniwha>
memory that's not accessed does not slow down the game
<riocrokite>
dunno, performed a quick test awhile ago and i wasn't happy, the game was very slow on my fast cpu
<taniwha>
hmm, you sure it's the data and not the mesh creation?
<taniwha>
kethane seems to pose no slowdown for me
<riocrokite>
dunno exactly I think it's not only mesh
<taniwha>
(and loading is just a 10kbit mask)
<riocrokite>
I think the sheer number of nodes for planets make computer and engine chug
<taniwha>
so 1.25kB, but mime64 encoded
<taniwha>
kethane has something like 20 nodes per planet
<taniwha>
that are just depletion data (the rest is generated from the seed)
<riocrokite>
maybe I'll test it again in future, for now working on stock
<taniwha>
(now, generating the deposits might take some time)
<riocrokite>
try 10 times smaller nodes and more resource patches instead of 20 get like 200 or 400 patches
<riocrokite>
then it slows down
<taniwha>
well, yeah, each subdivision quadruples the number of cells
<taniwha>
my suggestion is to use the (currently not used) cell-based "generator" and create your own sub-cell data
<taniwha>
gives you control over loading, too
<riocrokite>
well I haven't even make stock depletion run so it may also be slow, we shall see :)
<riocrokite>
creating cell/sub-cell stuff is currently beyond my skill set
<taniwha>
well, we know that kethane at least /works/ :)
<riocrokite>
copy paste / tweaking existing simple values is all I can do
<riocrokite>
I love how kethane works but yah we shall see
<taniwha>
I need to get in there and clean up the linq, though
<riocrokite>
also depletion is already largely implemented in stock game so that's one less dependency for my mod
<riocrokite>
'to a large extend
<taniwha>
kethane probably spews garbage left, right and center
<riocrokite>
extent
<taniwha>
trouble is, the stock resource system is terribly... uninvolved
<riocrokite>
I intend to change it :P
<taniwha>
I'm seriously considering nuking it via MM
<riocrokite>
for kethane mod? probably makes sense
Thomas|AWAY is now known as Thomas
Ezriilc has joined #kspmodding
<xShadowx>
taniwha: im assuming kethane hasnt had major changes since, but just about 2 years back, i tries to have kethane put 10 resources per planet for mining, game performance tanked :(
<xShadowx>
so somethin was happening
<riocrokite>
yah same experience here
<riocrokite>
even with one resource but with more resource islands
<xShadowx>
shame regolith is buggy though >.<
<xShadowx>
neither system is perfect
<riocrokite>
what bugs are you talking about?
<xShadowx>
every ksp update i try depletion using stock/regolith, even checking with rover and being told everything was right, didnt deplete ;p
<riocrokite>
I know where the problem is xShadowx
<xShadowx>
ya rover's head :)
<riocrokite>
nah, he almost finished it
<xShadowx>
o.O
<riocrokite>
I know how to fix it but there is one big BUT
<xShadowx>
i dont like big buts
<riocrokite>
can't easily modify classes that are responsible for depletion nodes
<riocrokite>
they are referencing other classes with private members etc which are used for scanning and god knows what else
* xShadowx
claps slowly
<riocrokite>
and I don't know coding enough to override / inherit from everything since this is embedded with other classes etc
<riocrokite>
what i'm saying is that the system is good but hard to modify
<Thomas>
fork, rewrite, make pr? :D
<riocrokite>
1. minor problem is that depletion works but mining drills don't read it
<riocrokite>
2. major problem is that there are only like 8 depletion nodes max per body
<riocrokite>
because of typo (converting and rounding latitude and longitude to int radian)
<riocrokite>
+clamping
<riocrokite>
so there are only 3 values for depletionnode.x and .y = > 0,1,2
<riocrokite>
it's in stock code Thomas cannot fork it
<Thomas>
meh
<Thomas>
#openSourceKSP
<riocrokite>
it won't happen, have to find some workaround, code is really complicated for me
riocrokite is now known as rio_away
<Thomas>
make a ticket on the bugtracker?
<rio_away>
won't do anything
<rio_away>
there are no requests nor needs for depletion mechanics
<rio_away>
people like unlimited stuff
<rio_away>
besides ultimately I need custom code for my mod so will need to somehow fix it anyway
<rio_away>
from what I analyzed the depletion mechanics are cpu and memory efficient
* xShadowx
wanted depletion to work and minly used kethane because of it
ferram4 has joined #kspmodding
stratochief|away is now known as stratochief|remote
TheAmazingSpiderPig has joined #kspmodding
TheAmazingSpiderPig is now known as CragnatharTheDestroyer
regex has joined #kspmodding
riocrokite has joined #kspmodding
<egg|zzz|egg>
Thomas: nah, just keep going the principia way
<egg|zzz|egg>
eventually we won't need KSP and we'll just have a curses interface or something :D
SirKeplan is now known as SirKeplan|AFK
BasharMilesTeg has quit [Read error: Connection reset by peer]
BasharMilesTeg has joined #kspmodding
<Virindi>
depletion doesn't fit the level of abstraction already present in mining, where you just shove some 2 meter long drill slightly below the surface and suck up tons of material
<Virindi>
if you wanted depletion it would really only make sense in a gameplay sense to be able to build large mines
<Virindi>
I mean who cares if the top 10cm of material is "exhausted" :D
<VanDisaster>
people who can only carry 2m drills, obviously
<VanDisaster>
the answer is then to have layered depletion :p
<VanDisaster>
or be able to dig holes
hashashin has quit [Remote host closed the connection]
hashashin has joined #kspmodding
SirKeplan|AFK is now known as SirKeplan
<riocrokite>
it has a lot of sense when you mine i.e. for he3 content VanDisaster
<riocrokite>
then you're interested in the very top layer of the regolith
<riocrokite>
using surface mining bucket drum
CragnatharTheDestroyer has quit [Quit: Leaving]
<riocrokite>
deep core mining is completely different stuff I intend to work on after I finish present mod