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

[TriggerAu]

9 hours ago, TheRagingIrishman said:

Sorry meant to ask this here and not on TWP: @TriggerAu could you point me to the .cs file where the calculations for transfer windows are done? I tried looking through the git repo but couldn't find anything that was obviously it.

So there's three ways this is done in KAC:

1. via a very simple circular orbit formula which uses a target phase angle between the source and destination planet you can find this in ethe TimeObjects.cs file under CalcPhaseAngleTarget()
2. A set of model data - basically a set of data built by someone for me ages ago using code similar to whats in the TWP - they basically number crunched the lambda plots to find the "best" times and stored those for 100 years or so, I encoded/compressed em down as much as possible and that's the "model" version
3. Use a TWP node and inject an alarm via API - only way that works for modded planet systems

I've always wanted to figure a better way to do 2) via a background caching tool/web service or similar so you only have to cache relevant data and if the universe changes - say modded then it can use that sorta data too, but is sorta complex

[TMS]

Quick question to everybody else... is anyone else noticing that the "Default Burn Node Margin (KER/VOID)" option isn't working?

Settings > Specifics > [Select] Maneuver Node Alarms > Default Burn Node Margin (KER/VOID)

You can change these options but get no corresponding change to node alarms in the alarm list window - even if you delete the alarm and have it re-detect the existing node.

I seem to recall this happening before after an update but I can't remember if it was a bug... or me not using the settings correctly???

EDIT

Ah... seems it was me who reported it last time!  Haha!  God, getting old sucks.

 

Edited June 7, 2017 by TMS

[razark]

1 hour ago, TMS said:

Quick question to everybody else... is anyone else noticing that the "Default Burn Node Margin (KER/VOID)" option isn't working?

So it's not my imagination, then.

[Anth]

Thanks for the update to KAC @TriggerAu

Much Appreciated

[scimas]

Is 3.8.5.0 compatible with ksp 1.2.2? I'm still using 1.2.2 and kac is showing that update is available..

[Wallygator]

@TriggerAu, does the daily version check compare against the live version of KSP currently running? As I'm running the version appropriate for KSP 1.2.2, I would prefer if the KAC warning did not fire when I'm starting up my stabile 1.2.2 RO/RSS install .  I currently find that to be quite annoying on several other mods.

i understand that this is an impossible request for legacy versions (So I must put up with it for the 1.2.2 compatible version), but going forward it makes sense (at least to me  )

Apologies if this has already been answered or addressed - or if it is impossible to implement. Many thanks in advance!

[TriggerAu]

43 minutes ago, scimas said:

Is 3.8.5.0 compatible with ksp 1.2.2? I'm still using 1.2.2 and kac is showing that update is available..

 

2 minutes ago, Wallygator said:

@TriggerAu, does the daily version check compare against the live version of KSP currently running? As I'm running the version appropriate for KSP 1.2.2, I would prefer if the KAC warning did not fire when I'm starting up my stabile 1.2.2 RO/RSS install .  I currently find that to be quite annoying on several other mods.

i understand that this is an impossible request for legacy versions (So I must put up with it for the 1.2.2 compatible version), but going forward it makes sense (at least to me  )

Apologies if this has already been answered or addressed - or if it is impossible to implement. Many thanks in advance!

No apologies necessary. It simply checks once a day for the latest version. If we move on to a new version of KSP and KAC, you can simply disable the daily check on the last tab in the settings and not have to worry about it.

[robson1000]

It looks like, this is a bug.

In flight press F2, then Esc, press Esc ones more, now ker window is hidden, and showing only if I press F2.

Spoiler

Alternate Resource Panel has that same problem.

Tested on 1.3.

[Drew Kerman]

that's been a somewhat annoying issue for a while now. Just do the reverse and you'll have them back with the rest of the stuff

[strudo76]

Got this alarm from the Kerbal Alarm Clock, where the alarm was made with this Transfer Window Planner.

Either this TWP isn't inserting carriage returns, or KAC isn't honoring them, or something else entirely. Posted in both forums.

[Aelfhe1m]

8 minutes ago, strudo76 said:

Either this TWP isn't inserting carriage returns, or KAC isn't honoring them, or something else entirely. Posted in both forums.

I'm pretty sure it's KAC's persistence.

If you look at the alarm in KAC immediately after you make it then the formatting looks fine

but one that was created several game sessions ago...

 

[KerbMav]

Wasn't there an option to create alarms on background SOI changes?

[DStaal]

28 minutes ago, KerbMav said:

Wasn't there an option to create alarms on background SOI changes?

I don't think there's any options to create alarms on *background* events - you have to have the vessel focused to make an alarm for it.

But there is an option to make an alarm for SOI changes automatically.  So if you do a burn and end up with an SOI change in the future there will be an alarm for it.

[TriggerAu]

13 hours ago, KerbMav said:

Wasn't there an option to create alarms on background SOI changes?

There did used to be, but it was so wildly inaccurate that I pulled it - things kike some of teh changes never fired. It worked out better in testing with some people that the auto-SOI one woudl create the alarms as you changed vessels and catch you pretty well

[KerbMav]

5 hours ago, TriggerAu said:

There did used to be, but it was so wildly inaccurate that I pulled it - things kike some of teh changes never fired. It worked out better in testing with some people that the auto-SOI one woudl create the alarms as you changed vessels and catch you pretty well

Hah, knew it!

Hm, bummer - was most practical for catching eventual intercepts of e.g. probes whose orbits crossed that of moons or orbited on the same orbit as planets.

But I guess it also bit deep into processing power at some point?

[tomf]

Is there a reason why the Closest approach alarm only works for target vessels?

I have a probe in an elliptical orbit around eve that takes it out to Gilly's orbit. If Gilly were a craft I could use KAC to do a small burn at my AP that would ensure that there was a rendevous in say 7 orbits time.

As it is with stock tools I can only put a node at my AP in 6 orbits time which requires a large burn to ensure that I achieve my rendezvous on the 7th orbit.

The target distance mode in this case just seems to be constantly flickering with an alarm 59 seconds ago.

[TriggerAu]

On 6/30/2017 at 0:58 AM, KerbMav said:

Hah, knew it!

Hm, bummer - was most practical for catching eventual intercepts of e.g. probes whose orbits crossed that of moons or orbited on the same orbit as planets.

But I guess it also bit deep into processing power at some point?

When the vessels are in the background on rails the mod cant see when an SOI change might occur in teh future - only after it. So it was dragging the warp back from whatever it was at to nuffin immediately (which had some physics impact) and then depending on the warp rate you could already be 100000 seconds inside the SOI - or in glancing passes would mean the intercept never occured in that time so it never triggered. I put it in the too hard basket at that point

 

On 7/1/2017 at 8:29 PM, tomf said:

Is there a reason why the Closest approach alarm only works for target vessels?

I have a probe in an elliptical orbit around eve that takes it out to Gilly's orbit. If Gilly were a craft I could use KAC to do a small burn at my AP that would ensure that there was a rendevous in say 7 orbits time.

As it is with stock tools I can only put a node at my AP in 6 orbits time which requires a large burn to ensure that I achieve my rendezvous on the 7th orbit.

The target distance mode in this case just seems to be constantly flickering with an alarm 59 seconds ago.

Imma bet the reason is cause thats how I wrote it. ill look at the code and see if/how hard that woudl be to unlock cause the core of the thing is as long as your orbiting the same "root" body then it shoudl be possible

[SiCaRiO31]

hi!, I just installed Kerbal Alarm clock because I started playing with Construction Time and it was getting difficult to keep track of everything :p.

I noticed something trough. Usually I make a maneouver node, point the spacecraft to it, make an alarm and then leave to do more things. But when I get the alarm and get back to the ship, the ship is not pointing at the maneuver node, but somewhere else. Has anyone expierenced something like this? I dont have Constant rotation installed.

Also, something weird happened with my first lunar probe. I put it in a wrong parking orbit around kerbin so I had to wait 2 days for the moon to move to the correct place to make the transfer. I made the node, pointed the spacecraft and left it there. When I got back, the spacecraft not only was pointing at the wrong direction, it had run out of monopropelent and now I couldnt move it anymore. Was that because I left SAS enabled? I dont seem to recall ever experiencing something like this before.

[DStaal]

4 minutes ago, SiCaRiO31 said:

hi!, I just installed Kerbal Alarm clock because I started playing with Construction Time and it was getting difficult to keep track of everything :p.

I noticed something trough. Usually I make a maneouver node, point the spacecraft to it, make an alarm and then leave to do more things. But when I get the alarm and get back to the ship, the ship is not pointing at the maneuver node, but somewhere else. Has anyone expierenced something like this? I dont have Constant rotation installed.

Also, something weird happened with my first lunar probe. I put it in a wrong parking orbit around kerbin so I had to wait 2 days for the moon to move to the correct place to make the transfer. I made the node, pointed the spacecraft and left it there. When I got back, the spacecraft not only was pointing at the wrong direction, it had run out of monopropelent and now I couldnt move it anymore. Was that because I left SAS enabled? I dont seem to recall ever experiencing something like this before.

Yep.  Both I'd consider fairly normal - with or without KAC.  (And yes, the latter would likely be because you left the thrusters running.)

[Loren Pechtel]

4 minutes ago, SiCaRiO31 said:

hi!, I just installed Kerbal Alarm clock because I started playing with Construction Time and it was getting difficult to keep track of everything :p.

I noticed something trough. Usually I make a maneouver node, point the spacecraft to it, make an alarm and then leave to do more things. But when I get the alarm and get back to the ship, the ship is not pointing at the maneuver node, but somewhere else. Has anyone expierenced something like this? I dont have Constant rotation installed.

Also, something weird happened with my first lunar probe. I put it in a wrong parking orbit around kerbin so I had to wait 2 days for the moon to move to the correct place to make the transfer. I made the node, pointed the spacecraft and left it there. When I got back, the spacecraft not only was pointing at the wrong direction, it had run out of monopropelent and now I couldnt move it anymore. Was that because I left SAS enabled? I dont seem to recall ever experiencing something like this before.

Your craft is pointing where you left it in absolute coordinates--the target moved.  For a really obvious case of it use MechJeb to launch something to say 150km up.  Note how wonky the aim is when it preps for the circularization burn--yet it's right when the engine lights.

[SiCaRiO31]

13 minutes ago, Loren Pechtel said:

Your craft is pointing where you left it in absolute coordinates--the target moved.  For a really obvious case of it use MechJeb to launch something to say 150km up.  Note how wonky the aim is when it preps for the circularization burn--yet it's right when the engine lights.

hm, weird. I was pointing at the blue marked, wich I always trough was absolute.

 

15 minutes ago, DStaal said:

Yep.  Both I'd consider fairly normal - with or without KAC.  (And yes, the latter would likely be because you left the thrusters running.)

Thank you, I trough it was that. After I noticed I manualy dissabled all the RCS's in all my probes just in case

[MCSquared]

For several patches I have been using Kerbal Transfer Window Planner, which I believe is made by the same developer as this mod.

Anyways, the Delta-V stats and phase angles that mod tells me to follow have always been correct assuming I complete the burns correctly.

I recently installed Kerbal Alarm Clock to supplement this and allow to fly multiple missions at once. What I discovered is that the transfer window time that KAC and KTWP show are often hundreds of days apart. Is there a way to prevent this from happening, or do I need to manually set up alarms based on the dates from the transfer planner?

[Loren Pechtel]

20 minutes ago, MCSquared said:

For several patches I have been using Kerbal Transfer Window Planner, which I believe is made by the same developer as this mod.

Anyways, the Delta-V stats and phase angles that mod tells me to follow have always been correct assuming I complete the burns correctly.

I recently installed Kerbal Alarm Clock to supplement this and allow to fly multiple missions at once. What I discovered is that the transfer window time that KAC and KTWP show are often hundreds of days apart. Is there a way to prevent this from happening, or do I need to manually set up alarms based on the dates from the transfer planner?

KAC normally picks up the next scheduled burn, or the next SOI transition if no burn is scheduled.

[Aelfhe1m]

2 hours ago, MCSquared said:

For several patches I have been using Kerbal Transfer Window Planner, which I believe is made by the same developer as this mod.

Anyways, the Delta-V stats and phase angles that mod tells me to follow have always been correct assuming I complete the burns correctly.

I recently installed Kerbal Alarm Clock to supplement this and allow to fly multiple missions at once. What I discovered is that the transfer window time that KAC and KTWP show are often hundreds of days apart. Is there a way to prevent this from happening, or do I need to manually set up alarms based on the dates from the transfer planner?

In TWP after finding a suitable transfer click on the Add KAC Alarm button in the bottom left corner and it will set up the alarm for you automatically.

[MCSquared]

28 minutes ago, Aelfhe1m said:

In TWP after finding a suitable transfer click on the Add KAC Alarm button in the bottom left corner and it will set up the alarm for you automatically.

Thanks so much!