Alarm Clock Usage Discussion

[linuxgurugamer]

This is meant for people to discuss the new Alarm Clock app, and tricks on how to use it.

Edited July 3, 2021 by linuxgurugamer

[Dominiquini]

I find a bug in the native Alarm Clock that alarms from maneuver nodes don't work on unfocused vessels!

But if you deselect the option to include the Burn Time, the alarm works!

[LordFerret]

1 hour ago, Dominiquini said:

if you deselect the option to include the Burn Time, the alarm works!

I will give this a try right now.

I have Ap/Pe alarms that have gone missing, and maneuver nodes, if not focused on the vessel in question.

I can confirm this! I will continue using it/testing it as such to see what else goes on with other functions (SOI changes, Ap/Pe, etc).
Thanks, good tip.

Edited July 1, 2021 by LordFerret
test completed

[Dominiquini]

51 minutes ago, LordFerret said:

I will give this a try right now.

I have Ap/Pe alarms that have gone missing, and maneuver nodes, if not focused on the vessel in question.

I can confirm this! I will continue using it/testing it as such to see what else goes on with other functions (SOI changes, Ap/Pe, etc).
Thanks, good tip.

@LordFerret I don't test alarms for Ap/Pe or SOI changes. It's working?

[micha]

To all modders:  Can we please coordinate on some common alarm types which the stock alarm clock does not yet have?

From my perspective that is primarily science alarms which are in KAC but not SAC.  It would be very user unfriendly if every science mod adds its own science alarm. For example, DMagic Science Alarm, Nehemiah Science Alarm, etc.  Ideally SAC would add all the alarm types (whether or not they are actually active without mod support) which KAC already has as a basis along with offering the plugin system.

[LordFerret]

16 hours ago, Dominiquini said:

@LordFerret I don't test alarms for Ap/Pe or SOI changes. It's working?

Yes, by doing what you've suggested, it is.

[Dominiquini]

42 minutes ago, LordFerret said:

Yes, by doing what you've suggested, it is.

@LordFerret But alarms to Ap/Pe and SOI have a option "Ignore BurnTime"?

[djr5899]

Here are the issues that I am seeing:

1.  Setting a Apoapsis Node alarm - I had a satellite in Kerbol orbit, and I wanted to circularize the orbit when it hit Apoapsis.  I clicked on the Apoapsis which showed the Alarm Clock symbol to set an alarm.  I set the alarm, which was roughly 192 days away.  Through jumping to other vessels, or saving the game and coming back later, the next time I checked the alarm, it showed +37 days, meaning that I overshot the alarm by 37 days.  I did not advance time.  If I delete the alarm and recreate it, it would go back to the 192 days till alarm.
2.  Alarms via Transfer/Maneuver Tool - I used the Transfer Tool to set to alarms for optimal transfer window burns, one for Moho and one for Eeloo.  I also had the Apoapsis alarm above set, so 3 Alarms in total.  In addition to the Apoapsis alarm suddenly showing the alarm had passed, if I did try to time warp forward, one of the 2 Transfer alarms would not move.  It didn't count down or up the time, it stayed at a constant time and would not budge.
3.  Transfer Alarm collision - This is probably more of a problem with the Transfer tool, but, I tested one of the transfer node alarms.  I would choose what celestial body I wanted to visit (Moho in this case), and it would create the maneuver node and set the alarm for the optimal transfer time.  I fast forwarded to the appropriate time, lit the engines and off I went...straight into the Mun.  I kind of don't think that was an optimal transfer window, giving me a maneuver node that slammed me into the Mun.

I just tested #1 again while typing this.  I loaded my game, I still had the +37 day alarm.  I deleted it and recreated.  I went back to KSC.  I switched to a different vehicle, and back...still showing correct time to Apoapsis.  I saved the game, quit, and came back...still showing the correct time.  So at the moment, it seems ok.  But, I am still seeing problem #2.  And I just verified but deleting the stale transfer maneuver, and recreated it.  That new maneuver is now working properly, but the 2nd transfer maneuver is now not advancing time.  So it seems like you can only have one maneuver node alarm set at a time, otherwise they don't advance/work properly.

[djr5899]

And just to add to issue #3, it looks like this is more of an issue with the Transfer tool.  From testing this again right now, when trying to set optimal maneuver nodes to other celestial bodies, The Mun is the first in the list.   What I am seeing is, if I pick something like Eeloo, which is last in the list, it will calculate the transfer node but, after about 5 seconds, it jumps back to The Mun, and changes the transfer node to the Mun.  Seems like this happens about 80% of the time for me.

Still holds true that I only seem to be able to have one maneuver node at a time.  I've deleted one and added it back, deleted both and added both, etc.  Only 1 maneuver node alarm will properly advance time.

[LordFerret]

6 hours ago, Dominiquini said:

@LordFerret But alarms to Ap/Pe and SOI have a option "Ignore BurnTime"?

No, they don't. But the experience I was having, I had several alarms set for 5 different vessels; 1 had an SOI change (transfer vessel), 2 had Ap/Pe alarms (for which I initiated manual burns, circularization), and the other 2 had set maneuver nodes (positioning)... all relay probes around Mun. I forget which vessel was active, but because of the issue all except the active had their timers go inactive... and were missed / resultin in timing all mucked up.

As for djr5899's comments above; I found my Mun manual transfer days earlier and cheaper (time/dV). Maybe I used the app wrong?

[Dominiquini]

2 hours ago, djr5899 said:

Here are the issues that I am seeing:

1.  Setting a Apoapsis Node alarm - I had a satellite in Kerbol orbit, and I wanted to circularize the orbit when it hit Apoapsis.  I clicked on the Apoapsis which showed the Alarm Clock symbol to set an alarm.  I set the alarm, which was roughly 192 days away.  Through jumping to other vessels, or saving the game and coming back later, the next time I checked the alarm, it showed +37 days, meaning that I overshot the alarm by 37 days.  I did not advance time.  If I delete the alarm and recreate it, it would go back to the 192 days till alarm.
2.  Alarms via Transfer/Maneuver Tool - I used the Transfer Tool to set to alarms for optimal transfer window burns, one for Moho and one for Eeloo.  I also had the Apoapsis alarm above set, so 3 Alarms in total.  In addition to the Apoapsis alarm suddenly showing the alarm had passed, if I did try to time warp forward, one of the 2 Transfer alarms would not move.  It didn't count down or up the time, it stayed at a constant time and would not budge.
3.  Transfer Alarm collision - This is probably more of a problem with the Transfer tool, but, I tested one of the transfer node alarms.  I would choose what celestial body I wanted to visit (Moho in this case), and it would create the maneuver node and set the alarm for the optimal transfer time.  I fast forwarded to the appropriate time, lit the engines and off I went...straight into the Mun.  I kind of don't think that was an optimal transfer window, giving me a maneuver node that slammed me into the Mun.

I just tested #1 again while typing this.  I loaded my game, I still had the +37 day alarm.  I deleted it and recreated.  I went back to KSC.  I switched to a different vehicle, and back...still showing correct time to Apoapsis.  I saved the game, quit, and came back...still showing the correct time.  So at the moment, it seems ok.  But, I am still seeing problem #2.  And I just verified but deleting the stale transfer maneuver, and recreated it.  That new maneuver is now working properly, but the 2nd transfer maneuver is now not advancing time.  So it seems like you can only have one maneuver node alarm set at a time, otherwise they don't advance/work properly.

Register this bug on the KSP Bugtracker! And let's hope they get fixed!

[djr5899]

19 hours ago, Dominiquini said:

Register this bug on the KSP Bugtracker! And let's hope they get fixed!

I'll take another look to see if there is one already listed.  I went out to the bug tracker a few days ago and there are multiple bugs logged for the Alarm Clock already, although, many of them seemed to be lacking lots of details.

[Dominiquini]

I don't know if it's related, but I'm having a problem with a career mode game. This is my first career game!
I got some contracts that ask me to put a satellite into orbit but don't specify altitude. When I go to the Track Station or Map View on a flight and hover the mouse over the orbit drawn on the map (Ap/Pe), the game doesn't show anything, it just throws a NullPointerException!
I'm testing this without any mod!

I think that maybe is related to the alarm because of this:

[EXC 00:21:29.156] NullReferenceException: Object reference not set to an instance of an object
	AlarmTypePeriapsis.ShowAlarmMapObject (MapObject mapObject) (at <a5c262f7fe724eb9918d4487db8b635e>:0)
	AlarmClockScenario.ShowAlarmMapButton (MapObject mapObject) (at <a5c262f7fe724eb9918d4487db8b635e>:0)
	KSP.UI.Screens.Mapview.MapNode.OnPointerEnter (UnityEngine.EventSystems.PointerEventData eventData) (at <a5c262f7fe724eb9918d4487db8b635e>:0)
	UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerEnterHandler handler, UnityEngine.EventSystems.BaseEventData eventData) (at <9f35cb25d6a4409c8c02e911403f3f7f>:0)
	UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) (at <9f35cb25d6a4409c8c02e911403f3f7f>:0)
	UnityEngine.EventSystems.EventSystem:Update()

The game throws this every time I hover over the drawn orbit!

Does anyone else have this problem?

Thanks.

[TanDeeJay]

I have multiple alarms set.  I'm currently in the process of getting a set of sentinal scanner satelites up, one to each planet, and I have set alarms for each of their maneouver nodes. (some have one maneouver node left others have 2 or 3.  I also have a couple of ships in orbit waiting for their transfer maneouver which was calculated using the new alarm clock.  I've noticed that only some of the alarms are counting down, and it seems like it if I visit the vessel of an alarm that is not counting down, the countdown starts, but one of the others stops.  I also had an incident where while I was flipping between ships using the new alarm clock interface, the game crashed, and left a half saved save file.  I was only able to recover the save by creating a new save, and copying the save directory, and the VAB, and SPH directories from the broken save to the new save, and then loading one of the persistent backups.  Didn't think to go looking for any logs at the time though.

Note, I also have KAC installed with the same set of alarms, not yet ready to trust the new alarm clock.  Is it possible that the new alarm clock and KAC clash?

[TanDeeJay]

I've just been exploring my alarms, and have found that turning off the "Add Burn time to" option on a maneuver node alarm, it does start counting down.  It seems that when I have more than 1 maneuver alarm defined,  only the 1st maneuver alarm counts down.  All other maneuver alarms seem to be frozen unless the relevant vessel is active.  Disabling the "Add Burn time to" option seems to be a viable workaround, you just need to factor that in and add sufficient time to the event margin.

Manual alarms and planetary transfer window alarms don't seem to be affected by this issue. (Haven't tested other alarm types...)

I love using manual alarms when I start a particularly long burn... set an alarm to about 1 minute before the burn is supposed to end choosing to pause the game, and you can get distracted onto other things and not have to worry about burning for too long as the game will pause  once you are near the end of your burn... REALLY useful when you have a 2+ hour burn of your IX-6315 to get your satellite out to a Jool orbit.

Edited July 5, 2021 by TanDeeJay

[ReactionWings]

2 hours ago, TanDeeJay said:

I've just been exploring my alarms, and have found that turning off the "Add Burn time to" option on a maneuver node alarm, it does start counting down.  It seems that when I have more than 1 maneuver alarm defined,  only the 1st maneuver alarm counts down.  All other maneuver alarms seem to be frozen unless the relevant vessel is active.  Disabling the "Add Burn time to" option seems to be a viable workaround, you just need to factor that in and add sufficient time to the event margin.

Hello,

Thanks for the solution, it seems to work. While waiting for a possible correction we will do like that.

Thank you.

[Dominiquini]

Is anyone having this problem in career mode?
In Track Station or Map View, when I hover over orbits proposed by contract, I get a NullPointerException and no information about the orbit! With multiple satellite contracts, I can't tell which orbit is referring to which contract!

I posted in this group because I saw this in the log:

[EXC 00:20:12.450] NullReferenceException: Object reference not set to an instance of an object
	AlarmTypePeriapsis.ShowAlarmMapObject (MapObject mapObject) (at <a5c262f7fe724eb9918d4487db8b635e>:0)
	AlarmClockScenario.ShowAlarmMapButton (MapObject mapObject) (at <a5c262f7fe724eb9918d4487db8b635e>:0)
	KSP.UI.Screens.Mapview.MapNode.OnPointerEnter (UnityEngine.EventSystems.PointerEventData eventData) (at <a5c262f7fe724eb9918d4487db8b635e>:0)
	UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerEnterHandler handler, UnityEngine.EventSystems.BaseEventData eventData) (at <9f35cb25d6a4409c8c02e911403f3f7f>:0)
	UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) (at <9f35cb25d6a4409c8c02e911403f3f7f>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.EventSystems.EventSystem:Update()

I opened this bug: https://bugs.kerbalspaceprogram.com/issues/28185

Will they fix the open bugs now that the game is "finished"?

Thanks.

Edited July 6, 2021 by Dominiquini

[TanDeeJay]

8 hours ago, Dominiquini said:

Will they fix the open bugs now that the game is "finished"?

Well, they produced 1.12.1, and I thought I read somewhere that there would be bugfixes done after 1.12, so lets hope there aren't too many bugs so that they don't need to prioritize which ones get fixed, and our bugs get fixed in the next patch update  

[Emperoreddy]

I've noticed KAC and SAC are giving me different dates for optimal transfer windows for the same bodies. 

Something anyone else is seeing and if so know which clock is correct?

[linuxgurugamer]

8 hours ago, Emperoreddy said:

I've noticed KAC and SAC are giving me different dates for optimal transfer windows for the same bodies. 

Something anyone else is seeing and if so know which clock is correct?

Different calculations.  Compare them, see what differences they have

On 7/6/2021 at 7:31 AM, TanDeeJay said:

Well, they produced 1.12.1, and I thought I read somewhere that there would be bugfixes done after 1.12, so lets hope there aren't too many bugs so that they don't need to prioritize which ones get fixed, and our bugs get fixed in the next patch update  

There IS going to be a 1.12.2, which will fix the AC bugs

[DVQuill]

I posted this in a different thread in the modding section, but think it might be worthwhile to add here: 

So out of curiosity, I did a quick comparison of the stock Transfer Window Planner (TWP) and Kerbal Alarm Clock (KAC) implemented in 1.12, against the modded versions of the tools (also by TriggerAu). I figured some of you might be interested in the information, so I figured I would share. 

As expected, there is very little difference in the TWP tool from stock to modded. Granted, the modded version provides a bit more information and flexibility, but its great news to see the numbers line up. 

The KAC tool on the other hand, provided much more interesting results. While the modded version of the alarm tool provides a transfer window to Duna that matches those provided by the TWP tools, the stock version of KAC gave a departure date which was about 20-25 days sooner. Hmmm...

It's hard to tell what this means, given that we don't know if the tool has a preference for travel time or dV, but it stood out as being quite different when compared to the other 3 tools. Interesting to wonder what could be accounting for the difference here.

Edited July 9, 2021 by DVQuill

[Dominiquini]

Is anyone here having the same problem as me, when playing in career mode, do proposed orbits throw exception on TackStation when I hover over them?
In the logs, the exception seems to be related to the alarm feature!

Thanks.

[OHara]

3 hours ago, DVQuill said:

the stock version of KAC gave a departure date which was about 20-25 days sooner.

There is an informed suggestion, in the thread linked below, that the Alarm Clock App marks the beginning of the window, but we don't know how 'beginning' is defined. 

It looks like t could be the earliest departure that costs at most 50 m/s more fuel than the optimal departure.  I do not see how that is useful to players, but maybe someone else does.

 

I suggest that the most important feature to get working in the Alarm Clock App,  is to stop time-warp before the due-time of any alarm on any vessel.   (Stopping time-warp before any manoeuvre node, alarmed or not, would be even better, but probably out of scope.) A very common frustration reported on this forum is overshooting a manoeuvre or intercept with overly-aggressive time-warp. 

The mod Maneuver Queue would do this, and only this, but unfortunately could only stop time-warp in the Tracking Station, and unfortunately did not give a space for notes or a message on the alarm.   

Edited July 9, 2021 by OHara

[Feiwuzei]

Not sure if this is related to alarm clock skipping, sudden jumps in my orbit. It seems to happen when I hit fast forward. If I'm in map view it will kick me back to ship view and the stars or Mun  have changed position and my orbit numbers are changing rapidly. I hit X but doesmt seem to be my throttle is even on. But it seems to have happened the same number of times I've had alarm clocks skipped, 3 so far.

 

I only discovered the skips yesterday after methodically checking all flights. When I switch to the new ship the alarm pops up and a ghost entry in the alarm clock appears, grayed out, telling me how much time I'm past the maneuver. The other thing that alerted me of the skips was when I would go to the alarm clock click on the next one because I need give some time to my active duty of debris removal, and it takes to a ship that doesn't have a maneuver node at that time. Thus the reason for my starting a methodical checking of all my flights to see which one was suppose have it.

 

If uhe orbit jumps are related to other flights then I would think if I started any deep space, outside of Kerbin SOI that the orbit jumps might be proportionately bigger. So the orbit shifts have only been about 12 k meters different, usually my periaposis is dropped into the atmosphere from LKO since that is where most of the debris is. The last though also increased my apopsis up to 120k meters. The latest skipped ghost alarm  was for my largest orbit on the way to Minmus.

[Feiwuzei]

For rocket science, this game seems to depend more on timing like the bus schedule, which I just checked after writing the above. You will get there when you get there!