<xShadowx>
i like how this documentary starts "the human race.....it shouldn't have survived. 200,000 years of nature being against it, countless plagues, wars, it has survived"
<xShadowx>
no mention of global warming screwing it globally tho :(
regex has quit [Remote host closed the connection]
<leudaimon>
xShadowx, just wait another couple centuries ;)
<xShadowx>
leudaimon: centuries? i dout it take that long ;p
<leudaimon>
I'm a little optimistic... and total annihilation takes a little longer than the collapse of civilization as we know it
Wetmelon has quit [Ping timeout: 201 seconds]
<soundnfury>
leudaimon: "there's a lot of ruin in a nation"
<leudaimon>
what documentary is that?
rsparkyc has joined #RO
<leudaimon>
hey rsparkyc! I added some comments to your proc. avionics spreadsheet. they are mostly suggestions
<rsparkyc>
awesome, i saw you put some in. I'm currently trying to rework some of the electric drain code
<rsparkyc>
i'm thinking a lot of the numbers we'll just need to fudge to get a somewhat realistic progression
<rsparkyc>
and i'm thinking of doubling the cost of the parts to pay for the fact that you're not using an "off the shelf" model
<leudaimon>
ah, ok... one of my questions that I think are more relevant is about the agena... do you mean that in the current setup it is not possible to achieve agena's mass efficiency?
<leudaimon>
this price idea looks strange to me... I think it would be more interesting to add something to the r&d price instead of per part. After all, you can mass produce the same procedural part, and then it is "off the shelf"
egg is now known as egg|zzz|egg
<rsparkyc>
yeah, as far as the agena, in the spreadsheet the controllable tonnage to mass ratio is negative
<rsparkyc>
this is because the empty mass of a part the same size of the agena is actually more than the agena itself
<rsparkyc>
i'm guessing that's just because of the procedural battery that's built into the part, which would be a pain to customize per tech node
<rsparkyc>
the problem with the R&D price (right now) is that it costs nothing to upgrade the part
<rsparkyc>
however, I think xShadowx said that there is some new stuff in ksp 1.2 that should help facilitate that
<leudaimon>
(currently don't have a working installation, so sorry if it would be obvious) but, couldn't R&D prices work like the unlocking of new RCS types?
<xShadowx>
you want what now
<rsparkyc>
haha, i don't want anything right now :)
* xShadowx
flushes rsparkyc out an airlock for waking me
<rsparkyc>
oOo, i have so much room out here :)
* xShadowx
cuts rsparkyc's air line
<rsparkyc>
leudaimon: that could work too, i'd have to investigate how that upgrade system works
<leudaimon>
about the agena, couldn't you reverse engineer the efficiency by getting a larger part and make it have the same proportional efficiency?
<xShadowx>
rsparkyc: another thing you can do is have values be floatcurves, so you can change ratio of power usage vs ability over its size
<xShadowx>
ie small stuff uses tiny tiny power, but 100x size uses 200x power
<xShadowx>
etc
<rsparkyc>
right now i was going to have small stuff use 50% of "normal" power, and large stuff use 150%
<xShadowx>
:)
BasharMilesTeg has quit [Ping timeout: 206 seconds]
<stratochief>
rsparkyc: not sure if I've failed at a logic check, but should the very starting procAvionic have a control limit of 1 tonne, no matter the size, mass, efficiency, etc?
<rsparkyc>
you should be able to adjust the tonnage slider
<rsparkyc>
if you make it a cylinder 1M x 0.15M, 50% utilization should give a control of 20 tons
<rsparkyc>
That should cost 300, and have a mass of .6T
<rsparkyc>
(which should be identical to the Guidance Unit (Starting), 1m
<stratochief>
ahh, I was just using the drag for Tonnage, which stays in a tight margin. but the arrows let me go much higher or lower. derp
<rsparkyc>
AND (which is what i'm working on now), if you do that, the power drain should be 3 kW
<rsparkyc>
the range for that size part should be 0-40T
<rsparkyc>
at 40T, it should cost 1200 credits
<xShadowx>
rsparkyc: you got the idea, but i was speaking more like consumption = curveMult.eval(tonnage) * baseconsumption
<xShadowx>
that way can change the range to be any direction
<xShadowx>
just suggestions :3
<rsparkyc>
yeah, i'm refactoring it to work more like that now
<stratochief>
1m diam, 150mm length limits to 15T, about 620 cred
<rsparkyc>
hmm
<rsparkyc>
that sounds wrong
<rsparkyc>
you playing in career?
<stratochief>
yep, career in 1.2
<rsparkyc>
and you're on the start tech node?
<stratochief>
the version from about 8 hours ago, in case you've changed something
<stratochief>
I have unlocked a few techs, so that could be it
<stratochief>
but I wouldn't expect the limit of control per unit volume to be lower with more tech
<rsparkyc>
aha, you've run into a problem i'm seeing :)
<xShadowx>
rsparkyc: you could even skip the multiplier, consumption = curve.eval(tons) and just leave the math to the MM config - though id prolly go with my former suggestion, and cfg default have baseconsumption = 1
<rsparkyc>
so….when trying to balance for the tech unlocked in a node, it turns out the tech we have may actually be LESS efficient than what we had already
<stratochief>
rsparkyc: what problem? I haven't read Git in ~6 hours
<rsparkyc>
in non procedural, we didn't really care, because we were just glad to have bigger parts
<stratochief>
rsparkyc: ahh. can it evaluate using multiple equations, and give you the best value?
<rsparkyc>
well, really it's a technode balancing problem
<leudaimon>
but at least early on, they mostly increase in efficiency
<stratochief>
yeah, fair enough
<stratochief>
needing to make it a bit larger is a little counter-intuitive, but as long as it is more mass efficient/higher control limit, that is fine I think
<leudaimon>
rsparkyc, maybe balancing based on a fixed size, mass and utilization part may be easier?
<stratochief>
leudaimon: but the balancing/logic has to hold through wide ranges of size, mass, and utilization. procedural is tricky business :)
<leudaimon>
sure... but thinking within each type of avionics, a 1m ring (for example) should be getting better anyway.
<rsparkyc>
right, but the whole "procedural" part of it means that size shouldn't be an issue
<xShadowx>
rsparkyc: suggestion - when in editor, hook into the gameevents.onvesselchange or partadded etc its called, and auto adjust the slider for current vessel tonnage :) and a button to toggle said auto tuning on/off
<stratochief>
the real issue people care about game balance wise is that it gets more cost efficient, more power efficient, and more mass efficient
<stratochief>
from a basic gameplay perspective, anybody will be thrilled they can scale the part to fit their craft
<rsparkyc>
xShadowx: we'd have to do some work if you had multiple procedural avionics units attached (booster vs probecore)
<leudaimon>
what I had in mind is that, once you establish the parameters for a base part with fixed parameters in a given tech node, how this scales with size, mass and utilization could be fixed throughout the tech tree, no?
<stratochief>
xShadowx: interesting idea. would that adjust the procAv properties if I go and adjust proctanks and increase or decrease the size?
<xShadowx>
stratochief: by default no, proc parts has a hook for tank size changing for that reason though
<xShadowx>
so 2 places to hook into :P
<rsparkyc>
leudaimon, if i understand you correctly, I think that's what we're trying to do, but i may not understand you correctly
<stratochief>
leudaimon: I also found that last statement hard to understand, but I agree with rsparkyc's response :)
<leudaimon>
I'll try to explain another way, I have no idea if it's much different than what you are doing, I just think it's a simple way to optimize
<stratochief>
ideally, the functions that govern the procAv parts will return similar costs, masses, etc. as their same-tier fixed counterparts
<leudaimon>
1) establish a base size and utilization for each avionics type. This one should be like the 1mx1m proctank.
<leudaimon>
2)for each tech node, establish what should be its parameters to match the best fixed part already in the game in that node
<rsparkyc>
ahh, that's one thing we're not doing: establishing a base size
<stratochief>
rsparkyc: is there any reasonable/logical way to display how much EC/s a given part will be consuming? can that be added the in VAB GUI for a part?
<rsparkyc>
stratochief: you read my mind, i was literally about to add that
<rsparkyc>
since it's not static, we need that
<stratochief>
rsparkyc: I believe he is just referring to the fixed size avionics parts we already have
<leudaimon>
3) have a fixed set of functions that scales these with size and utilization (mass) for all tech levels, it would be simpler than also changing the scaling
<stratochief>
rsparkyc: honestly, even not having that wouldn't be a game breaker, you really only care about it for upper stages and probes, and with those you will end up seeing it in testing
<leudaimon>
rsparkyc, I think a base size simplifies the balancing, because then you have less variables floating around
<stratochief>
if I wanted to get artistic, I could start shaping my avionics parts to look like engine mounts. now, if I could Art, I could actually create a texture to make them look more mount-y :P
<stratochief>
I forgot that without MechJeb, someone starting out can't SAS, even when they have control of a craft. can/should we allow users to use SAS from the start?
<stratochief>
I mean, I just use Smart ASS, and that doesn't make me superior, just a different way of accomplishing the same thing
<xShadowx>
mass = (size * multA) * (ec * multB) * (utilization * multC), or just formula, its a common formula used for balancing out costs in games, ever seen the stats on armor/weapons in RPGs? heh, each variable gets a multiplier for its 'weight' in the formula, the bigger trick is finding what the multipliers use for their value, wether or not itl fit to real life parts is another story :P
<xShadowx>
s/just/adjust
<Qboid>
xShadowx meant to say: mass = (size * multA) * (ec * multB) * (utilization * multC), or adjust formula, its a common formula used for balancing out costs in games, ever seen the stats on armor/weapons in RPGs? heh, each variable gets a multiplier for its 'weight' in the formula, the bigger trick is finding what the multipliers use for their value, wether or not itl fit to real life parts is anot
<Qboid>
her story :P
<rsparkyc>
stratochief: yeah, we need to add that in
<xShadowx>
whats wrong with MJ :P
<stratochief>
xShadowx: what's wrong with any MJ alternative, is my question
<xShadowx>
it isnt MJ
<xShadowx>
:)
<stratochief>
rsparkyc: so you agree, SAS from the start makes sense? someone else mentioned it on Git recently I think, maybe SirKeplan?
<SirKeplan>
yeah i mentioned it
<stratochief>
SirKeplan: ahh, good. I don't recall your opinion
<stratochief>
but you might know the fix :P
<rsparkyc>
feel free to make PRs too :)
<rsparkyc>
you can always target a PR at any branch
<leudaimon>
I think another justification to have SAS is that the other starting avionics from the Taerobee already has it
<SirKeplan>
yeah having SAS makes sense. do we do any porgrassion of the SAs elvel in RP-0 though?
<xShadowx>
i think RO should add warp drive, cuz this other mod has it :P
<SirKeplan>
progression* SAS* level*
<stratochief>
SirKeplan: I don't recally what the various SAS levels are. really, again I just use SmartASS from the very start with all features available
<SirKeplan>
stratochief: yeah i use SmartASS a lot
<SirKeplan>
rsparkyc: latest is always on the proceduralAvionics branch is it?
<SirKeplan>
on KSP-RO/RP-0 repo
<rsparkyc>
latest that i've pushed, yeah
<rsparkyc>
prob about to do another push in 30 mins or so
<rsparkyc>
just want to make sure it's not throwing exceptions first
<SirKeplan>
ahah :)
<stratochief>
good guy developer: tests his code before inflicting it on others
<xShadowx>
he didnt really say hes testing it :P
<rsparkyc>
^ correct
<stratochief>
xShadowx: I didn't necessarily say rsparkyc was a g.g. developer :P
<rsparkyc>
haha
<xShadowx>
real devs dont need to test!
<stratochief>
RealScotsman 1.2.3 for KSP 1.2.2
<xShadowx>
its all the plebs not testing that makes the real devs look bad :P
<rsparkyc>
someone want to tell me what i broke to my my avionics unit's default diameter be 252mm?
<rsparkyc>
it used to be 200
* xShadowx
deals with bad programmers at work and is rather biased in the direction of mass murder
<rsparkyc>
and i don't see 252 set in the ModuleManager.ConfigCache
blowfish has quit [Quit: Leaving]
<stratochief>
*shrug*
egg|zzz|egg is now known as egg|zzzz|egg
TonyC1 has joined #RO
TonyC has quit [Ping timeout: 204 seconds]
BasharMilesTeg has joined #RO
<rsparkyc>
ok, push up some more code (it took me longer than 30 mins)
HypergolicSkunk has quit [Quit: Connection closed for inactivity]
leudaimon has quit [Quit: Leaving]
rsparkyc has quit [Quit: Leaving.]
SirKeplan is now known as SirKeplan|zzzz
Probus has quit [Read error: Connection reset by peer]
Senshi has joined #RO
BasharMilesTeg has quit [Ping timeout: 206 seconds]
BasharMilesTeg has joined #RO
schnobs has joined #RO
SirKeplan|zzzz is now known as SirKeplan
egg|zzzz|egg is now known as egg|zzz|egg
Wetmelon has quit [Ping timeout: 206 seconds]
schnobs has quit [Ping timeout: 201 seconds]
waerloga has quit [Ping timeout: 206 seconds]
waerloga has joined #RO
egg|zzz|egg is now known as egg|principia|egg
HypergolicSkunk has joined #RO
schnobs has joined #RO
BasharMilesTeg has quit [Ping timeout: 180 seconds]
Probus has joined #RO
schnobs has quit [Ping timeout: 206 seconds]
Majiir is now known as Snoozee
leudaimon has joined #RO
egg|principia|egg is now known as egg|tea|egg
BasharMilesTeg has joined #RO
<stratochief>
my first orbital craft nearly went to the moon; Apo of 126,000 km
<leudaimon>
O.o slight overkill
<stratochief>
Explorer is tiny, like 14kg, but still
<Probus>
What did you use? A titan II?
<leudaimon>
if you get the first avionics and rocketry nodes it's doable... orbit is pretty easy with only one of these nodes, but 126Mm is huge anyway
<stratochief>
I used a Star 37 as my second stage, which I probably shouldn't have this early :P
<stratochief>
I turned on the "allow pressure and G limits to destroy parts", firing my Explorer's solid hit 51G, broke it :P
<Probus>
That happened to me the other day too
egg|tea|egg is now known as egg
<stratochief>
hmm, I don't see a property for that part, or any stock parts that sets a G limit
<stratochief>
xShadowx: ?
Wetmelon has joined #RO
* stratochief
puts some lead ballast in his pencil
<stratochief>
should the AJ10-104D really be infinitely re-startable, or did I goof something
<stratochief>
nope, that is right. pressure fed though, so heavy tankage
<stratochief>
I chose aerodynamics over perfect egg shape
<UmbralRaptor>
...do we know egg's c_l and c_d?
<egg>
ask ferram4
<leudaimon>
stratochief, are you using proc. avionics?
<stratochief>
leudaimon: affirmative. not the most recent code, the stuff from noonish yesterday
<leudaimon>
cool!
<stratochief>
leudaimon: I also want to give Orbital Decay a shake
<leudaimon>
orbital decay is nice, I used it in an earlier game. It's good that it solves the space junk issue quite well
<leudaimon>
idk how it is on 1.2.2 though, I didn't try to upgrade yet
riocrokite has joined #RO
<xShadowx>
stratochief: ?
<egg>
stratochief: note that orbital decay is incompatible with principia
Snoozee is now known as Majiir
<stratochief>
egg: good call. I'm fiddling in 1.2 though so no Principia to incompat with :P
<egg>
:-p
blowfish has joined #RO
<stratochief>
orbital decay mod looks neat. someone who understands/cares about geosats staying exactly where they want them to would have to vet that aspect
<stratochief>
I'll have to look under the hood and see why it things a satellite in a 190km x 10760km orbit won't decay though, that would stay up for less than a year, I think
<leudaimon>
stratochief, I also had this feeling that these highly eccentric orbits had too high decay times
<stratochief>
leudaimon: yeah, I'd have to look under the hood to see how it calculates them. ultimately, it will be the small fraction of an orbit spent below ~300km that causes substantial decay of an orbit, and that isn't crazy hard to estimate decently
<stratochief>
for computational reasons, it might not want to consider decay rates below a certain threshold, which is fine, I just want to know what that threshold is
<leudaimon>
yep, I had a look into what he takes into account, and the formulas and decay sources look crazily detailed and accurate. It's surprising that the results are counter-intuitive
<stratochief>
leudaimon: thanks, I'll poke around in there sometime
<leudaimon>
there is some info ingame also iirc
egg is now known as egg|nomz|egg
<stratochief>
yeah, a 200x300 orbit reported decaying in a reasonable amount of time, but when I bumped it to 200x1000, it got loopy
<stratochief>
I have a feeling his equation makes sense for circular orbits, but uses something like the average of Ap and Pe to estimate decay rate per orbit, which doesn't hold for ellipses
<stratochief>
I'll have to break down the math he uses
<leudaimon>
yeah, that was my fear
<stratochief>
yeah, it looks like it makes a bad assumption and creates an " EquivalentAltitude" for calculating drag when an orbit has Eccentricity > 0.085
<stratochief>
I'll fiddle more with his math later to confirm that is a bad estimation/assumption, but anway
stratochief is now known as stratochief|away
<leudaimon>
:/
<leudaimon>
he is highly responsive and open on the forum... if you explain it he should offer a solution
<stratochief|away>
leudaimon: I want to actually understand how the existing code works before I complain that it might not work how I want it to, and by then I'll be able to offer the solution :P
<stratochief|away>
but for now, I'm reading about skyhooks and native martians
<leudaimon>
:D even better
egg|nomz|egg is now known as egg
Majiir is now known as Snoozee
Snoozee is now known as Majiir
SirKeplan is now known as SirKeplan|afk
<Raidernick>
.tell stratochief I fixed the conflicts in RP0 can you please merge ALL of my pr's now before they break again they have been open for almost 8 months now
<Raidernick>
crap
<Raidernick>
anyone know the prefix for the bot?
<Probus>
Robo...?
<Raidernick>
is it !?
<Raidernick>
!tell stratochief I fixed the conflicts in RP0 can you please merge ALL of my pr's now before they break again they have been open for almost 8 months now
<Qboid>
Raidernick: I'll redirect this as soon as they are around.
<Raidernick>
yep
jbos has joined #RO
<Raidernick>
Probus, did you find out how to do rp0 configs
<Probus>
Yes. I talked to stratochief
<Raidernick>
k the only difficult thing is figuring out prices
<Raidernick>
which is not even related to the configs
<Probus>
he showed me a couple of tricks.
<Raidernick>
there is actually an open PR for rp0 for some of my stuff
<Raidernick>
so if you are going to do that compare first