<awang>
Q: "What are your favourite examples of people using Excel for unusual things?"
<awang>
A: "One of my favorites support requests contained a business justification of "this issue is delaying the space shuttle launch". -Ben[Microsoft]"
<UmbralRaptor>
Hah AAAAAAAAAAAA
<Bornholio>
acdc in excel...
<Bornholio>
not quite as bad as watching asci youtube videos in a terminal window
ProjectThoth has quit [Ping timeout: 200 seconds]
ProjectThoth has joined #RO
awang has quit [Quit: leaving]
xShadowx|2 has joined #RO
xShadowx has quit [Ping timeout: 383 seconds]
wb99999999 has joined #RO
<wb99999999>
someone got to figure out how to do a 1.5 stage simply and elegantly
<ProjectThoth>
wb99999999: Have you heard of Atlas?
ferram4__ has joined #RO
ferram4_ has quit [Ping timeout: 383 seconds]
ferram4__ is now known as ferram4
blowfish has joined #RO
<blowfish>
evening
<Qboid>
blowfish: awang left a message for you in #RO [18.10.2017 19:08:22]: "Might it be possible to create subsections of the database so you don't have to iterate over all parts for RO-style patches?"
<Qboid>
blowfish: awang left a message for you in #RO [18.10.2017 19:08:55]: "like a mini-database for just the engines?"
<Qboid>
blowfish: awang left a message for you in #RO [18.10.2017 19:15:53]: "I intended to !tell you that I was trying the new DLL earlier, but looks like I hit ~ isntead of !"
<Qboid>
blowfish: awang left a message for you in #RO [18.10.2017 19:36:51]: "Cache created in 899.190s. 142634 patches applied."
<blowfish>
awang: cool, so definitely an improvement
<blowfish>
I've definitely thought about doing some sort of "indexing" on the game database, so that e.g. a specific part can be accessed quicker
<blowfish>
it would not be trivial to implement though
<blowfish>
and probably a lot of refactoring has to happen before it too
<blowfish>
e.g. it has to distinguish between wildcards and non-wildcards and access the game database in a different way depending
<xShadowx|2>
MM changes to be faster?:D
<blowfish>
a bit, not as much as I hoped
<xShadowx|2>
blowfish: the above reminded me of the one convo that happened to have MM patches skip over MM patch config nodes during the iteration
<xShadowx|2>
no clue if MM got that far yet :|
<blowfish>
?
<blowfish>
I'm not sure I follow
<xShadowx|2>
was like a year ago, a convo happened that when MM went to apply patches, it would iterate over all confignodes loaded, to check if it should apply to that node
<xShadowx|2>
but that list contained MM patches, not just parts etc
<xShadowx|2>
thus slowing the iteration
<blowfish>
that's something I addressed
<xShadowx|2>
k :D woo
<blowfish>
patches are extracted from the game database and sorted into their respective passes before the patching happens
<blowfish>
saves a bit of time definitely
<xShadowx|2>
\o/
<xShadowx|2>
only for first run though isnt it? b/c cache
<blowfish>
that wouldn't matter when loading from cache, no
<xShadowx|2>
my first runs hit >30 min at some point so <3
<blowfish>
wow, worse than awang's
<xShadowx|2>
lol
<xShadowx|2>
its all you guys's fault :(
<xShadowx|2>
makin lovely toys i need to cram in
<xShadowx|2>
i got to the point id start ksp at night before i goto bed, minimize in morning, and be ready when i played ;p
<xShadowx|2>
blowfish: any multithreading bits?
<blowfish>
sort of
<blowfish>
patching happens on a separate thread, which passes log messages to the main thread
<xShadowx|2>
one hand was curious, other hand scarey to think of applying patches over multiple threads :|
<blowfish>
turns out logging takes a lot of time
<xShadowx|2>
heh
<blowfish>
to the point where for some patches, MM can apply them to every part in the database faster than KSP can output the log messages
<ProjectThoth>
blowfish: I am not nearly skilled enough. :P
<xShadowx|2>
the kinda crappy way that im forced to use at work, is a string array is made, other thread inserters into array, and main thread checks if the slot is still empty > print log / come back later, if an issue happens some log stuf can be missed, but its supposedly minimal load for sending it to the other thread -.-
<wb99999999>
nah I meant in KSP
<wb99999999>
it's hard to do makeshift 1.5 stage and still look nice
<ProjectThoth>
wb99999999: Fairings are your friend?
<ProjectThoth>
I knocked together an Atlas (in stock) that used a fairing as part of the half stage, one moment...
<xShadowx|2>
blowfish: perhaps disable the logging / make it an optional thing
<blowfish>
with the new changes I don't think there's so much overhead from logging
<xShadowx|2>
:)
<ProjectThoth>
wb99999999: Gonna grab some screenshots.
<blowfish>
meh, I tend to prefer separating out the booster tanks and decoupling them with the engines
<wb99999999>
well...this is as far as normal effort will go
<wb99999999>
but I kinda wanted an thrust structure that fall off in one piece
<wb99999999>
someone did do a one-piece fairing
<wb99999999>
but that involves a lot of manually align stuff togeather
<ProjectThoth>
Yeah, this was just me screwing around one afternoon.
TM1978m has quit [Remote host closed the connection]
<wb99999999>
I am genuinely hatting college now...
<wb99999999>
hating
<wb99999999>
*
<wb99999999>
wait which one is the -ing for hate...
<wb99999999>
my head is so fucked
<ProjectThoth>
Hating.
<ProjectThoth>
wb99999999: tbf, I dislike college strongly.
awang has joined #RO
<awang>
\o
<blowfish>
ah heh, the one time you're not actually here
<blowfish>
<blowfish> awang: cool, so definitely an improvement
<blowfish>
<blowfish> I've definitely thought about doing some sort of "indexing" on the game database, so that e.g. a specific part can be accessed quicker
<blowfish>
<blowfish> it would not be trivial to implement though
<blowfish>
<blowfish> and probably a lot of refactoring has to happen before it too
<blowfish>
<blowfish> e.g. it has to distinguish between wildcards and non-wildcards and access the game database in a different way depending
aradapilot has quit [Remote host closed the connection]
aradapilot has joined #RO
ProjectThoth has quit [Quit: +++out of cheese error+++]
<taniwha>
blowfish: accessing a specific part quickly: dictionary
<blowfish>
yeah
<blowfish>
still not trivial to implement though
<taniwha>
the time to build the dictionary would be trivial compared to the time spent searching the lists
<blowfish>
time to build a dictionary is not an issue
<taniwha>
and you have to trawl the lists at least once anyway, so might as well build the dictionary during the first pass
<blowfish>
I think the tricky part would be maintaining it as patches are applied
<taniwha>
not really
<taniwha>
it's not often that a patch changes a part name without cloning it first
<blowfish>
it
<blowfish>
sure it's not often, but it happens
<blowfish>
or at least it's not disallowed
<taniwha>
and even then, it's easy to see when the patch changes the name
<taniwha>
remove old name, add new one
<taniwha>
and cloning without changing the name is pretty meaningless in the long run
<xShadowx|2>
but how many patches go by name >.> so many wildcard / apply if module
<blowfish>
there's already code that prevents you from cloning without changing the name
<blowfish>
although there's nothing to stop you from having duplicate part names to begin with
<blowfish>
there's also weird stuff like the * operator, which can modify a node you're not even it
<taniwha>
I'd say don't worry about dups
<taniwha>
sorry, that last bit doesn't parse
<blowfish>
you can do *@PART[abc]/name = def inside a completely different patch
<blowfish>
not that anyone does that
* xShadowx|2
does
<blowfish>
but the index only works if I have 100% cofidence in it
<taniwha>
blowfish: maybe disallow that?
<blowfish>
to disallow it, I would have to reach inside the guts of ModuleManager's biggest, messiest method and hope I don't break anything
<blowfish>
as part of this work I have been refactoring and adding unit tests to everything, it's the only reasonable assurance I have that I'm not breaking stuff
<xShadowx|2>
taniwha: its a nice feature, lets me count how many experiments installed > auto adjust science rewards based on number, ie i can install 500 science mods and not "woohoo tech tree done without leaving ksc"
<blowfish>
also indexing wouldn't help everything
<taniwha>
create index based on matches
<blowfish>
e.g. RO engine configs are written as @PART:HAS[#engineType[LR-79]]
<taniwha>
indexes
<blowfish>
easy to say, hard to write a bulletproof implementation of
<taniwha>
expecting programming to be easy is setting oneself up for failure
<blowfish>
taniwha: you're the one who was saying this was trivial
<xShadowx|2>
whoa whoa..programming is easy...see the "Hello world!" program ;3
<taniwha>
trivial doesn't mean easy :)
<blowfish>
I think to do this I would basically have to wrap every read and write from the game database in a way that handled the indices
<taniwha>
hmm, actually, here's an idea
qwertyy__ has joined #RO
<taniwha>
build a set of "programs" that modify configs based on matches, maybe with a dependencies db
qwertyy_ has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
<taniwha>
the you go though the config DB feeding each config into the set of programs
<taniwha>
should be able to get away with trawling the configs only the once
wb99999999 has quit [Ping timeout: 180 seconds]
<xShadowx|2>
what about spit off another thread, which searches / fills a new temp list with the confignodes for the next patch? then while the patch is applying on main thread, it makes the next new list?
<xShadowx|2>
eh....but then search could be invalid if changes nvm -.-
<taniwha>
blowfish: using that idea, cloned parts would get put on the queue of patches to be processed
Rokker has quit [Quit: Connection closed for inactivity]
<xShadowx|2>
accually.....isnt that doing it backwards? take part > iterate patches to see if applies > apply to that part?
<taniwha>
the point is to reduce the number of passes through the config db as much as possible
<xShadowx|2>
that could be threaded without race conditions no?
<taniwha>
xShadowx|2: quite often, doing things backwards is the way to speed things up
<xShadowx|2>
.net parallel loops :) 1 thread for each core, grab a part > patch > grab next part etc
<blowfish>
not quite, since each of those patches might change the part in a way that would make following patches not be valid for it
<taniwha>
eg, finding the closest point on an ellipse to an arbitrary point: need to solve a quadric (nasty)
<taniwha>
finding the points to which a point on an ellipse is the closest: any point in the plane defined by the point on the ellipse and the ellipse's tangent at that point
<xShadowx|2>
right, but you check the next patch in the order
<taniwha>
blowfish: the the dependencies
<xShadowx|2>
so just treat it as a db of 1 part ;p patch patch patch next part
<taniwha>
blowfish: not saying that idea would be trivial, but it sure would speed things up
<blowfish>
xShadowx|2: I also don't see why that would be any faster, it's still O(n*m)
<taniwha>
blowfish: I suspect that right now, you are not O(n*m), but worse
<blowfish>
I'm pretty sure it's O(n*m), but feel free to read the code and say otherwise
<taniwha>
I've got my own yak to shave
<taniwha>
(sorry)
<xShadowx|2>
O(n) i get, each part > patch, whats m :P
<taniwha>
n = patches, m = config nodes
<blowfish>
^
<taniwha>
blowfish: another thing to do would be to build dictionaries for config node nodes/values
<taniwha>
you're probably spending a lot of time trawling the lists within each node
<xShadowx|2>
wouldnt what i desc be O(n*m/t)? t=threads
<taniwha>
there will be a little bit of trickery since nodes allow multiple values of the same name
<taniwha>
xShadowx|2: most things don't thread well, and blowfish is implying that this won't due to dependencies
<xShadowx|2>
since each part applies patches to itself at its own rate, threading can run as many as there are cores? without race conditions as patches are still in order
<taniwha>
also, big-O doesn't allow for threads :)
<xShadowx|2>
what dependancies?>.<
<taniwha>
(ie, even with infinite threads O() doesn't change)
<xShadowx|2>
meh ;p
<taniwha>
the /time/ might go down, the but O doesn't
<xShadowx|2>
i can see 1 thread per part breaking the *@PART[*]/zzz=1 (changing outside your part node) thing breaking though
<blowfish>
indeed
<blowfish>
have to consider the edge cases here
<xShadowx|2>
but given my 20 cores, 20 threads patching their own part at a time, potentially 20x speed? diff for everyone obviously but :|
<xShadowx|2>
if thats the only loss id take it lol
<blowfish>
generally performance improvements aren't that linear
<xShadowx|2>
i havent tried, does mono have the whole .net parallel loops bits?
<xShadowx|2>
think that started at .net 3.0?
<blowfish>
Parallel class is .NET 4
<xShadowx|2>
but ya the more cores, the less perf gain per core :| esp when last job is shit slow, oh god that annoyed me so many times
<xShadowx|2>
4?>.> i coulda sworn that was sooner, eesh
<xShadowx|2>
not that it matters, was just stapling together things that already existed heh
<taniwha>
btw, mono does have all these things
<taniwha>
just not unity :P
<blowfish>
^ just not Unity 5
<blowfish>
although .NET 4+ is still experimental on Unity 2017 I think
<xShadowx|2>
assuming ksp goes to it
<xShadowx|2>
:)
<blowfish>
I am more inclined to assume that is not happening than assuming it is
<xShadowx|2>
same
<xShadowx|2>
esp after the exodus ;x
<xShadowx|2>
wonder when a ksp would get made heh
<xShadowx|2>
er ksp 2
blowfish has quit [Quit: Leaving]
egg|zzz|egg is now known as egg|afk|egg
Jack-o-Melon has quit [Ping timeout: 183 seconds]
egg|work|egg has quit [Ping timeout: 180 seconds]
egg|work|egg has joined #RO
Rokker has joined #RO
probus_ has joined #RO
Probus has quit [Read error: Connection reset by peer]
Rokker has quit [Quit: Connection closed for inactivity]
aradapilot has quit [Remote host closed the connection]
aradapilot has joined #RO
rsparkyc has joined #RO
Rokker has joined #RO
probus_ has quit [Ping timeout: 198 seconds]
Senshi has joined #RO
TM1978m has joined #RO
Rokker has quit [Quit: Connection closed for inactivity]
Hypergolic_Skunk has joined #RO
Probus has joined #RO
egg|afk|egg is now known as egg
UmbralRaptor is now known as NomalRaptor
Rokker has joined #RO
Hohman has joined #RO
<awang>
It looks like it's sort of like optimizing a self-modifying program
<awang>
It's not easy to see what optimizations are valid
<awang>
Maybe something like an uber-config that has every possible key, with every key having a list of all known values, and each of those values then mapping to the configs that actually contain that key/value pair
<awang>
Doubt it'll be easy to keep consistent, though
Theysen has joined #RO
<Theysen>
hello guys
<soundnfury>
awang: I feel like I ought to get involved with my superior compsci technology
<soundnfury>
(unfortunately I'm kinda busy atm)
<awang>
superior compsci technology?
<awang>
And I think at this point _everyone_ is kinda busy :P
Jack-o-Melon has joined #RO
qwertyy__ has quit [Ping timeout: 183 seconds]
Theysen has quit [Quit: Leaving]
qwertyy has joined #RO
Senshi has quit [Read error: Connection reset by peer]
awang has quit [Quit: leaving]
rsparkyc has quit [Quit: Leaving.]
awang has joined #RO
Hypergolic_Skunk has quit [Quit: Connection closed for inactivity]
Raidernick_ has quit [Read error: Connection reset by peer]