TM1978m has joined #RO
ProjectThoth has joined #RO
awang has joined #RO
<awang> \o
<awang> Anyone see the Excel team AMA?
<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> Aerospace question for the smart people - would this even have been stable? http://www.nss.org/resources/library/shuttledecision/p208.jpg
<blowfish> build it in KSP and ask FAR >:)
<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
<blowfish> makes balloon tanks less necessary too
<ProjectThoth> wb99999999: https://imgur.com/a/5Lrmd
<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]
Raidernick has joined #RO
egg is now known as egg|zzz|egg
NomalRaptor is now known as UmbralRaptor
Mo-Zeroth has joined #RO
ProjectThoth has joined #RO