<soundnfury>
egg|zzz|egg: that's how I often fly konrad-guided burns, particularly if I don't have comms at the end of the burn
<soundnfury>
(basically 'pretending to use the RT flight computer' but not actually using it because it can't steer for toffee)
<soundnfury>
but then, konrad is _inherently_ inaccurate because its integrator is shite :)
awang has quit [Read error: Connection reset by peer]
awang has joined #RO
<awang>
What would you guys think of having RemoteTech take antenna orientation into account?
<awang>
I seem to remember something along those lines being a factor in Scott Manley's Interstellar serie
<awang>
*series
<awang>
So I know it's at least possible
<borntosleep>
wasn't that antena aim thing super processor heavy, RT is bad enoguh as it is
<awang>
I have no idea
<awang>
But if it's processor-heavy, then guess it isn't a good idea
<awang>
Didn't know RT was much of a processor drain in the first place
<blowfish>
awang: you're running RO on 1.3 right? Do you by chance have some time to help me test some ModuleManager changes?
<awang>
blowfish: Yep
<awang>
Sure, I can try
<blowfish>
okay cool, thank you so much
<awang>
What should I be looking for?
<borntosleep>
awang did you post your .dll's on the spreadsheet or forums?
<blowfish>
firstly, do you remember if the last time you started KSP, MM loaded from cache or not?
<awang>
borntosleep: The RO/RP-0 dlls?
<awang>
blowfish: MM didn't load from its cache, but then my computer crashed, so I don't know what it's going to do this time
<borntosleep>
yes anything to get the whole shebang in 1.3
<blowfish>
awang: if MM finished then it saved the cache
<awang>
borntosleep: I should have made PRs to the mods that have yet to be updated
<blowfish>
okay cool, could you open up KSP.log and search for "ran in"? That should take you to the line that says how long ModuleManager took
<awang>
blowfish: At least in my experience I've found that MM sometimes likes to reload the cache after a crash even if it succeeded
<borntosleep>
k, i'll do a sweep on sunday
<awang>
Uh
<blowfish>
awang: probably due to other changes. I recently helped the author of HyperEdit fix its settings invalidating MM's cache
<blowfish>
and there are probably other mods out there that have the same issue
<awang>
Ah, I see
<awang>
Well, KSP was actually in the process of restarting after rebooting :(
<awang>
So it'll be a bit until I can get you that number
<blowfish>
okay, no worries
<awang>
Looks like it thought the cache wasn't generated after all
<blowfish>
or was invalidated by something, that'll be in the log too
<awang>
Oh really?
<awang>
Handy
<blowfish>
If you search for a line like "[ModuleManager] Changes :" it should show you everything that was modified
<borntosleep>
!seen agathorn
<Qboid>
borntosleep: I haven't seen the user agathorn yet.
<blowfish>
a lot of being able to read logs is just knowing what to search for
<awang>
Too true
<awang>
Especially with the huge logs that come with having too many mods
<blowfish>
even the log for a stock install is fairly dense
<awang>
Alright, this boot MM loaded from cache
<awang>
Ran in 74.142s
<blowfish>
wait, but if it loaded from cache I don't think it would have taken that long
<awang>
141530 patches?
<borntosleep>
sounds normal for a big mod load
<borntosleep>
a MM build would be several minutes
<awang>
^
<blowfish>
oh, ouch
<borntosleep>
I try and stay under 70k patches for sanity sake, a cleanish RO/RP-0 dev build is 50-70k
<blowfish>
okay well, you just started KSP so you probably want to actually do stuff rather than doing what I'm about to ask, but this can happen any time when you've got some time
<awang>
Nah, it's fine
<blowfish>
I've got a dev build of MM with some potential performance improvements
<blowfish>
If you could delete MM's cache and then try loading with that
<blowfish>
I'm interested to know a couple of things
<awang>
So would you prefer timings building the cache from scratch?
<blowfish>
that was the idea, but if you don't have that info it's fine
<blowfish>
One other aspect of this build is that some previously silent errors are now loud
<awang>
Meh, I'm patient
<blowfish>
I know that RF has a couple of errors that I fixed, but I'm interested in seeing what other mods have those errors so that I can inform the authors before these changes are released
<awang>
I wasn't really planning on playing much, since I wanted to figure out some problem I have with Principia when I compile it myself
<awang>
Oh hey, looks like RemoteTech's PID is being worked on
<blowfish>
these errors won't cause MM to crash, but will cause it to print some messages on the loading screen and will prevent the cache from being created
<awang>
Uh
<awang>
I currently have KSP set to display exceptions/etc
<awang>
So I gte messages about missing textures, etc.
<awang>
Should I disable those?
<blowfish>
MM's error messages show up in a different place
<blowfish>
I would have tested myself if 1.2.2, but I haven't taken the time to upgrade my RO install
<borntosleep>
k i'll load it up in a bit
<awang>
blowfish: When generating a fresh cache, MM ran in 1037.933s
<blowfish>
damn
<blowfish>
>17 minutes
<blowfish>
that's gotta be rough
<awang>
Luckily it doesn't happen too frequently
<blowfish>
even so, the rest of KSP's load would take quite a while with that much stuff
<awang>
Yep
<blowfish>
maybe I should be thinking about how to make the cache load faster too...
<awang>
I mean, it's a bit over a minute in my case
<awang>
Not that bad
<awang>
Rest of the load dominates
<blowfish>
yeah, compared to everything else that doesn't sound too terrible
<borntosleep>
5004 patches, time to load 1:49 versus 2.81MM 4959 patches, time to load 1:50
<blowfish>
yeah, with that few patches I wouldn't expect a huge difference
<borntosleep>
not sure why the small diff in patch number, 'spose a log check is in order
<blowfish>
borntosleep: there's a slight difference there that is known
<blowfish>
current MM doesn't count deletes and copies as applied patches
<blowfish>
new builds do
<borntosleep>
k good to know
<blowfish>
my test install has 10k patches and it saves ~27% of total time
<blowfish>
if you run KSP off of an SSD it might not make that much difference though, since logs will be saved faster
<blowfish>
borntosleep: any errors other than RF?
Wrecker has quit [Quit: Web client closed]
<borntosleep>
yes running off ssd OS, Cache seperate and games on a third: log has no "Error", couple kpoernicus exceptions
<blowfish>
ok cool
<blowfish>
gotta go for a couple of hours
<blowfish>
awang - if you do complete that test, feel free to !tell me the results
<awang>
Will do!
<blowfish>
if there are a lot of errors feel free to just post the log and I'll look through it
<blowfish>
thank you!
<awang>
I'll probably end up Dropboxing it just in case
<awang>
No problem!
blowfish has quit [Ping timeout: 186 seconds]
<awang>
!tell blowfish Your DLL loaded my cache with 141530 patches in 66.101s
<Qboid>
awang: I'll redirect this as soon as they are around.
ProjectThoth has joined #RO
ProjectThoth has quit [Quit: +++out of cheese error+++]
smellypooh has joined #RO
smellypooh has quit [Excess Flood]
<awang>
!tell blowfish* ...Think I might have screwed something up. With your DLL, rebuilding the cache took 3747.267s. I'll upload the log, but I'm going to delete the cache and try again.
<Qboid>
awang: I'll redirect this as soon as they are around.
<awang>
!tell blowfish* I know KSP liks to go a bit slower when in the background, and I fell asleep during part of it, so I don't know whether it was in the foreground all the time
<Qboid>
awang: I'll redirect this as soon as they are around.
<awang>
!tell blowfish* ton of errors related to RP-0/RO/SXT cfgs. List of things actually scrolls off the bottom of the window. Nothing about RF. I am working off of a RF branch which ports the RP-0/newCryo changes to 1.3.0, though, so maybe that's it?
<Qboid>
awang: I'll redirect this as soon as they are around.
Rockwell has quit []
<awang>
!tell blowfish* Here's the KSP.log: https://www.dropbox.com/s/6x2hnyj136s9gyd/KSP.log?dl=0 . It's truncated, since KSP crashed due to some bug in the graphics driver ("Graphics hardware encountered an error and was reset" according to the crash popup)
<Qboid>
awang: I'll redirect this as soon as they are around.
<awang>
!tell blowfish* Should have said that your MM applied 141861 patches, with 121 errors
<Qboid>
awang: I'll redirect this as soon as they are around.
Probus has quit [Quit: Leaving]
<awang>
!tell blowfish* MM seems to be spending a LOT of time on TF stuff
<Qboid>
awang: I'll redirect this as soon as they are around.
<awang>
!tell blowfish* To be more specific, it seems that it's :BEFORE[ZTESTFLIGHT]. I think.
<Qboid>
awang: I'll redirect this as soon as they are around.
schnobs has quit [Ping timeout: 186 seconds]
<awang>
!blowfish: Second time generating the cache, ran in 2918.890s. Made sure KSP was in the foreground the vast majority of time. At least based on what I saw, it seemed to spend most of its time stuck on TF, but it's possible that that's just when I happened to look at it
<awang>
Dangit
<awang>
!tell blowfish* Second time generating the cache, ran in 2918.890s. Made sure
<Qboid>
awang: I'll redirect this as soon as they are around.
<awang>
KSP was in the foreground the vast majority of time. At least based on
<awang>
what I saw, it seemed to spend most of its time stuck on TF, but it's
<awang>
.....
<awang>
!tell blowfish* Second time generating the cache, ran in 2918.890s. Made sure KSP was in the foreground the vast majority of time. At least based on what I saw, it seemed to spend most of its time stuck on TF, but it's possible that that's just when I happened to look at it
<Qboid>
awang: I'll redirect this as soon as they are around.
Senshi has joined #RO
TM1978m has joined #RO
TM1978m has quit [Remote host closed the connection]
blowfish has joined #RO
<blowfish>
evening
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 02:19:22]: "Your DLL loaded my cache with 141530 patches in 66.101s"
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 03:39:07]: "...Think I might have screwed something up. With your DLL, rebuilding the cache took 3747.267s. I'll upload the log, but I'm going to delete the cache and try again."
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 03:39:40]: "I know KSP liks to go a bit slower when in the background, and I fell asleep during part of it, so I don't know whether it was in the foreground all the time"
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 03:43:31]: "ton of errors related to RP-0/RO/SXT cfgs. List of things actually scrolls off the bottom of the window. Nothing about RF. I am working off of a RF branch which ports the RP-0/newCryo changes to 1.3.0, though, so maybe that's it?"
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 03:45:38]: "Here's the KSP.log: https://www.dropbox.com/s/6x2hnyj136s9gyd/KSP.log?dl=0 . It's truncated, since KSP crashed due to some bug in the graphics driver ("Graphics hardware encountered an error and was reset" according to the crash popup)"
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 03:51:47]: "Should have said that your MM applied 141861 patches, with 121 errors"
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 04:38:30]: "MM seems to be spending a LOT of time on TF stuff"
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 04:42:59]: "To be more specific, it seems that it's :BEFORE[ZTESTFLIGHT]. I think."
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 04:48:38]: "Second time generating the cache, ran in 2918.890s. Made sure"
<Qboid>
blowfish: awang left a message for you in #RO [14.10.2017 04:49:11]: "Second time generating the cache, ran in 2918.890s. Made sure KSP was in the foreground the vast majority of time. At least based on what I saw, it seemed to spend most of its time stuck on TF, but it's possible that that's just when I happened to look at it"
<blowfish>
awang: so it's taking longer, that's interesting
<blowfish>
maybe I need an install with more patches to figure out what's taking so long
<blowfish>
ugh, I wish I could say I made a mistake but these errors are legitimate
ferram4 has quit [Ping timeout: 183 seconds]
<blowfish>
fortunately looks like only RP-0, RO, and SXT
<blowfish>
awang: thanks regardless, this is super useful
<awang>
blowfish: Would you like me to Dropbox you my install so you don't have to get something new set up?
<awang>
Only mac-specific things should be KSP itself and Principia
<awang>
Hi egg!
<awang>
blowfish: Did you try installing with TF?
<blowfish>
I did not
<blowfish>
it might not have actually been that pass if it was the last one
<awang>
Also, it appears that I no longer have proc avionics parts after startup
<awang>
Last one?
<blowfish>
ah never mind
<blowfish>
it can be deceptive because what MM reports it's doing is asyncrhronous from what it's actually doing now
<blowfish>
that pass took 15 minutes though, holy shit
<blowfish>
I'm perplexed as to what could have been so slow
<awang>
Any way to get profiling of some sort?
<blowfish>
it's something I'll have to look into
<blowfish>
ohh, actually I think I see exactly what's wronng
<blowfish>
*wrong
<awang>
What?
ferram4 has joined #RO
<blowfish>
previously MM converted the entire list of patches in the game database into an array once per pass
<blowfish>
I guess I changed that to happen once per patch
<awang>
Ouch
<awang>
Wait, why does that have to happen at all?
<awang>
Sounds like redundant work
<blowfish>
it doesn't
<blowfish>
yeah, each individual patch here applies to all the configs it affects in less than a second but then there's a gap of a couple of seconds between patches
<blowfish>
thank you, this is actually really useful
<blowfish>
might mean that I can make it even faster
<blowfish>
(or in your case, actually faster, rather than slower)
<awang>
Guessing the gap is converting the list to an array?
<awang>
It certainly matches my observations, which was something like a few patches, wait a few seconds, then more patches
<awang>
lamont: lol, MechJim?
<blowfish>
it's an entire tree structure that's being converted to an array
TM1978m has joined #RO
aradapilot has quit [Remote host closed the connection]
aradapilot has joined #RO
<taniwha>
wouldn't it be more efficient to just traverse the tree?
<blowfish>
taniwha: I think it's done for a couple of reasons
<blowfish>
1) it only cares about the leaf nodes
<blowfish>
2) it may add or remove leaf nodes
<blowfish>
but it's still unnecessary
<blowfish>
what it should do (and I'm looking at implementing now) is iterate through each node that contains leaf nodes, then modify the leaf nodes under it
<blowfish>
no need to convert anythign to an array
<taniwha>
yeah
TM1978m has quit [Remote host closed the connection]
<blowfish>
awang: I updated the DLL if you want to give it another try
<blowfish>
it no longer converts to an array at all
<blowfish>
(in that context)
<taniwha>
meanwhile, I'm adding hotplug support to my joystick interface
<awang>
blowfish: Same link?
<blowfish>
yup
Raidernick_ has quit [Read error: Connection reset by peer]
Raidernick has joined #RO
<awang>
blowfish: Still working on startup, but it seems to be taking a bit for :FOR[REALISMOVERHAUL]
<awang>
Just as a heads-up
<blowfish>
huh
<awang>
As a disclaimer, this is when I happened to look at it
<awang>
No guarantees I didn't miss something earlier
<awang>
:FOR[XXXRP0] might be a pass to look at too
<blowfish>
will do
<github>
[RP-0] blowfishpro opened pull request #776: Fix some MM issues (Developmental...FixMMIssues) https://git.io/vdX5t
<awang>
:BEFORE[ZTESTFLIGHT] appears to be taking a while too
<blowfish>
hopefully not as long as before
<awang>
Seems that the ZTESTFLIGHT pass was shorter than before
<awang>
idk for sure
Wetmelon has quit [Ping timeout: 183 seconds]
Raidernick_ has joined #RO
<awang>
Once the cache has been created (or not), does KSP.log contain all the important MM stuff?
<awang>
Or do I need to wait until KSP finishes loading?
<taniwha>
awang: in settings.cfg, set LOG_INSTANT_FLUSH to true
<taniwha>
then it will be up to date immediately
<blowfish>
awang: yes
<taniwha>
then you can do something like "tail -f KSP.log"
<taniwha>
(and have it be meaningful)
Raidernick has quit [Ping timeout: 186 seconds]
<taniwha>
(I don't know the windows equivalent)
<blowfish>
err, I think output_log.txt is updated immediately, KSP.log may not be
<taniwha>
blowfish: that's what LOG_INSTANT_FLUSH is for: updating KSP.log
<blowfish>
right
<taniwha>
and KSP.log is much much easier to read than output_log.txt
<taniwha>
(I actually tell people to /not/ send me output_log.txt)