[1.12.x] Kerbal Alarm Clock v3.13.0.0 (April 10)

[BigD145]

Zero problems with Toolbar and Alarm Clock here. Are you sure you don't have multiple copies of either mod buried in some other mod folder? Different versions perhaps? Are you trying to use the modded 64bit KSP which does not work with all sorts of mods?

[jrandom]

I too have no problems whatsoever with Toolbar and KAC.

[Agathorn]

Well this was a fresh brand new install of everything, so I have trouble believing I have conflicts, but i'll double check when I get home.

[TriggerAu]

Wowsers thats a few posts

...

One other very minor thing that has always bugged me is when you set a raw alarm and select Date for the time type - why can't it automatically set the current date/time?

...

Edit2: could there be an additional option for the TS screen when an alarm pings for you to select the vessel in question?

...

Edit3: one more veery minor UI thing - the coloration of the Ap/Pe and SOI icons are a bit too close, so when viewed in the alarms list it can at first be hard to tell the difference. I am of course talking about when you are bleary-eyed in the wee hours of the morning as I'm sure most KSP players are

...

Edit4: Yup something else So I discovered how to plot asteroid intercepts into the far future. The ones I've discovered so far are 47 and 23 earth years out so don't really mean much. But it did bring up an issue in that KAC only seems to look for an SOI change in the current orbit, not within the current maneuver node. It's assuming therefore that all craft transferring from one SOI to another would do so in one orbit. I think this assumption makes perfect sense. But it would still be nice to be able to add an SOI change if one is detected via maneuver node several orbits ahead

So for 1) It could but I didnt think of it and no-one has asked before Now here.

2) I can look at that, but TBH the TS screen has very limited API access currently

3) The colors of those are the colors from the game, so I dont wanna change em. I do have to convert all the images to tga files though which clears up the blurring that you can see at times. Hopefully that will help

4) Detecting things after maneuver nodes is "interesting" as if you dont get the burn exactly right the time wont align (remembering that the alarms are all time based, not actual path objects. I'll have a look at this one too when I get some time

In my full install, it works as well. It's only in my full install + RemoteTech 1.4.0 that I'm seeing the errors. I guess I'll poke around RemoteTech and see if I can figure out why.

I'd guess the orbits are changing minorly at some point and thus you dont end up at the same spot. This can happen with high warp rate changes, so maybe see if thats anything, but I guess if you consistently see it with remotetech and not when its not there then it could be that. If I can help in any way then let me know

...

I've noticed lately that the transfer alarms are off, like way off. I am in year 1, day 66 of career mode, and when I make an alarm for a Kerbin-Moho transfer it tells me it's x days out - (I'm not at my KSP computer, so I don't recall the day exactly). So I set the alarm for 6 hours ahead of the KAC determined transfer window and launch. When I set my maneuver node for the transfer the closest approach way off on Moho's orbit. So I set another alarm for the transfer window, and it shows another 10 days out - and the closest approach is still quite a ways off. And I set another alarm and it's showing x days out again.

...

A couple of questions - Are you using the formula or model data for the transfer? and if your using the formula method do you have the option turned on that recalcs the time as it goes? It sounds like it is setting up a formula alarm (which is based on unrealistic circular orbits) and not recalcing as it goes, so when you get to the original time its not yet at the right phase angle

Well this was a fresh brand new install of everything, so I have trouble believing I have conflicts, but i'll double check when I get home.

Most likely cause of these kind of things is the install location is not exactly right. Have a look at the installation page on the manual site and also look in the log and search for KerbalAlarmClock

[MOARdV]

I'd guess the orbits are changing minorly at some point and thus you dont end up at the same spot. This can happen with high warp rate changes, so maybe see if thats anything, but I guess if you consistently see it with remotetech and not when its not there then it could be that. If I can help in any way then let me know

More time poking at it with a sharp stick ... I set it up again in my Remote Tech install (identical to the main install, only adding RT), and I replicated the bug. It does not happen if RT is not installed.

Before I started warping this time, I watched KAC's closest approach info. It continued updating after thrust was shut off, for a number of seconds. One thing you did in 2.7.5 was to use a background process of some sort to update some alarms - I think RT is also using co-routines (or whatever C#/Unity calls them), and I think MechJeb may also use them. My CPU usage is higher than a single core, but well below 2 cores fully utilized, which makes me wonder if RT's background updaters are hogging cycles, causing a delay in when KAC update results are available? I haven't looked into how these things are implemented in C#/Unity, so maybe that's entirely off base - but, if the various background updaters aren't in their own full threads, and they're time-sharing another thread, that could explain it.

[Drew Kerman]

3) The colors of those are the colors from the game, so I dont wanna change em. I do have to convert all the images to tga files though which clears up the blurring that you can see at times. Hopefully that will help

Ah, hadn't realized they were stock graphics, but yea they are aren't they?

4) Detecting things after maneuver nodes is "interesting" as if you dont get the burn exactly right the time wont align (remembering that the alarms are all time based, not actual path objects. I'll have a look at this one too when I get some time

That's a good point. I was simply doing 0dV maneuver nodes to see what would happen on future orbits so didn't think of that when applied to an actual burn. But at least in the case of 0dV manuever nodes you know that's the way things'll happen thanks to the 1-body on-rails physics

[Agathorn]

Most likely cause of these kind of things is the install location is not exactly right. Have a look at the installation page on the manual site and also look in the log and search for KerbalAlarmClock

Yeah it was all me. I fracked it up.

[EdFred]

A couple of questions - Are you using the formula or model data for the transfer? and if your using the formula method do you have the option turned on that recalcs the time as it goes? It sounds like it is setting up a formula alarm (which is based on unrealistic circular orbits) and not recalcing as it goes, so when you get to the original time its not yet at the right phase angle

OK, so I am at Year 1, day 66, 0:30+/- (KSP time) I have KAC set up for KSP time, and the transfer windows show as follows:

Model: 84d 4h 19m

Formula: 71d 1h 6m (dpesn't seem to matter to change the math calcs/second, and toggleing Autorecalc of xfer points has no effect)

But https://alexmoon.github.io/ksp/ says the departure should be at year 1, day 269, 2h10m which is a transfer window 203 days out, so I'm confused.

Will uninstall a couple mods and see if that changes things.

Edit:

Uninstalled all mods, and the numbers remain the same.

Edited June 27, 2014 by EdFred

[Superfluous J]

OK, so I am at Year 1, day 66, 0:30+/- (KSP time) I have KAC set up for KSP time, and the transfer windows show as follows:

Model: 84d 4h 19m

Formula: 71d 1h 6m (dpesn't seem to matter to change the math calcs/second)

But https://alexmoon.github.io/ksp/ says the departure should be at year 1, day 269, 2h10m which is a transfer window 203 days out, so I'm confused.

I'd be curious which - if any - of those is the correct number. Did you try to do a transfer at each time and see which one got you one (or the best one)?

[TriggerAu]

More time poking at it with a sharp stick ... I set it up again in my Remote Tech install (identical to the main install, only adding RT), and I replicated the bug. It does not happen if RT is not installed.

Before I started warping this time, I watched KAC's closest approach info. It continued updating after thrust was shut off, for a number of seconds. One thing you did in 2.7.5 was to use a background process of some sort to update some alarms - I think RT is also using co-routines (or whatever C#/Unity calls them), and I think MechJeb may also use them. My CPU usage is higher than a single core, but well below 2 cores fully utilized, which makes me wonder if RT's background updaters are hogging cycles, causing a delay in when KAC update results are available? I haven't looked into how these things are implemented in C#/Unity, so maybe that's entirely off base - but, if the various background updaters aren't in their own full threads, and they're time-sharing another thread, that could explain it.

Unfortunately the only thing on the background thread stuff is the Version Update Check that happens once a day. If I find some time I'll install RT and have a play too, but I do have lots on at the moment.

[TriggerAu]

OK, so I am at Year 1, day 66, 0:30+/- (KSP time) I have KAC set up for KSP time, and the transfer windows show as follows:

Model: 84d 4h 19m

Formula: 71d 1h 6m (dpesn't seem to matter to change the math calcs/second, and toggleing Autorecalc of xfer points has no effect)

But https://alexmoon.github.io/ksp/ says the departure should be at year 1, day 269, 2h10m which is a transfer window 203 days out, so I'm confused.

Will uninstall a couple mods and see if that changes things.

Edit:

Uninstalled all mods, and the numbers remain the same.

You may have to forgive me as my orbital maths is not the greatest, but I think I can explain most of this. So using Alex's tool you will get a graph like the below:

You can see here the most dV effective transfer is at day 269. However using the same picture if you click in the blue grouping to the left of that one and click refine you will get this:

This is the best transfer around that time according to Alex's maths which is at Day 137 but if you look at the blue section and the date you can see that day 150 (the modelled value) is in that blue band and fiddling with it I can see the dV cost would be about 5300dV , which is only 350m/s dV greater than the optimal one at day 269.

Looking further through the model data source, the next window after day 150 that the model will give you is day 263 - which is pretty close to the best date in the original graph.

Basically you could depart at day 150 with 350 more m/s of dV required, or wait for day 269.

The last thing in here is the Formula value which I have skirted a bit here. So the way this works is that there is a target phase angle between the planets that this watches for. As the orbits are elliptical this does not move in a consistent fashion, so if you have the autorecalc option turned on then as the game progresses it will update the alarm time. so while that says 84 days to go at day 66, it may well fire the alarm at day 200 when the angle arrives.

TBH my order of preference for these things is:

1. Alex's tool - keeping in mind that the best value is not the only one and you need to look at all the blue areas then decide whether you want to use one of the less efficient times
   
2. The Model data one - which will give me good windows, but not as easy to see whats going on (and only 100 earth years of data)
   
3. The circular formula
   

[MOARdV]

Unfortunately the only thing on the background thread stuff is the Version Update Check that happens once a day. If I find some time I'll install RT and have a play too, but I do have lots on at the moment.

Drat ... I was hoping it was something simple like that. I've seen a few other odd things with the RT install, so I suspect that RT is the issue, and KAC is just exposing whatever it is. I'll also back-rev to KAC 2.7.4 - I may not have tried the closest approach alarm in that game with KAC 2.7.4, now that I think about it. It may not be a new issue.

[Drew Kerman]

window positions aren't saving

[vardicd]

For some reason with the latest update, I get massive framerate/lag in the tracking screen, but its fine everywhere else. Has anyone else seen this? I'm sure it must be a mod conflict somewhere? but I'm running 45 different mods right now so narrowing it down will be a beastly task.

I'm going to reinstall the latest update 1 more time to ensure I didn't do something wrong. maybe re-download too to ensure my dl wasn't corrupted.

Reinstalled 3 times with no change, make a post about it and reinstall 4th time. frame rate/ lag goes away. my computer obviously just wanted to embarrass me. disregard this post.

Edited June 29, 2014 by vardicd

[Drew Kerman]

I've not noticed any lag, even when viewing the TS with 260 asteroid orbits rendering. Well, ok a noticeable lag compared to an empty tracking screen but nothing beyond normal for that situation. You can cross-reference with the mods in my sig to eliminate possibilities

[JWag]

I really, really love this plugin; it makes having multiple simultaneous missions much less chaotic. Thanks!

I found a little bug (maybe?): I created an SOI alarm for an asteroid/Kerbin encounter, and then realized I wanted the alarm to fire a few days earlier. When I typed in "24" in the "hours" field in the alarm edit window, the alarm time changed correctly, but the "hours" field still said "0".

[TriggerAu]

Am flat out at the moment, but will look at the window positions, hours truncating and other bits as soon as I can. Thanks for the feedback peoples

[KerbMav]

While you are at it ...

Could KAC get its own subfolder like your ARP?

[Drew Kerman]

Am flat out at the moment, but will look at the window positions, hours truncating and other bits as soon as I can. Thanks for the feedback peoples

Breaks are good. No worries

[TriggerAu]

While you are at it ...

Could KAC get its own subfolder like your ARP?

Is in v3 - already coded. sorry for the slowness - I gotta get all the 2.7.5 stuff in to the v3 base next and then I think when we get 0.24 I'll try and make the change.

[TriggerAu]

Breaks are good. No worries

Thanks Gaiiden, a break woul dbe nice, but its more just sooo much on its hard to get a coding day

[Alshain]

Feature Suggestion. Add a folder in the game data for us to drop audio files (wav?) and let us pick them from a list as an alternative to a pop-up for the alarm. This would be a third option next to pause and kill warp. Playing audio would also kill warp though. This would be kind of like how Science Alert works, but it would be nice if we could choose different sounds for different alarms.

Edited July 4, 2014 by Alshain

[DaPatman]

it would be nice if we could choose different sounds for different alarms.

This would be nice, though what I'd really like is for someone with more coding know-how than me to create a script to make my blink(1) flash whenever an alarm triggers. (I fully admit this is wishful thinking on my part, and I don't expect Trigger to do this himself, but hey, if you don't ask... )

[TriggerAu]

Feature Suggestion. Add a folder in the game data for us to drop audio files (wav?) and let us pick them from a list as an alternative to a pop-up for the alarm. This would be a third option next to pause and kill warp. Playing audio would also kill warp though. This would be kind of like how Science Alert works, but it would be nice if we could choose different sounds for different alarms.

Audio alarms will be in v3 - I have the code in ARP already

This would be nice, though what I'd really like is for someone with more coding know-how than me to create a script to make my blink(1) flash whenever an alarm triggers. (I fully admit this is wishful thinking on my part, and I don't expect Trigger to do this himself, but hey, if you don't ask... )

v3 also has an API so someone should be able to leverage that for a blink(1) or any other stuff - I might have a crack at that for you once thats done

[The Jedi Master]

I think its time I grabbed this. This is amazing!