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

[TriggerAu]

Quick question, which calculation mode should I use? Model, or Formula?

Is really up to you, basically the formula choice uses the circular orbital formula's used in a few places/plugins - Olex's calculator web site, mechjeb, etc. The Model version uses precalculated times from data done by one of the forum members (voneiden) - its difference is that it takes into account the elliptical nature of orbits and the inclinations.

The tutorial I read and helped me best was this one http://forum.kerbalspaceprogram.com/showthread.php/27236-Tutorial-Step-by-step-Interplanetary-Hohmann-transfer-guide-and-tips

and theres a bunch more on the Drawing Board forum post that can help as well: http://forum.kerbalspaceprogram.com/showthread.php/28352-The-Drawing-Board-A-library-of-tutorials-and-other-useful-information?highlight=voneiden

[sadron]

See I'm planning a few missions, and our trip to Moho was originally scheduled 16 days from the 20th day of year one, but as we got closer and I started making maneuver nodes with mechjeb I saw that we were actually a ways off from where the descending/ascending (whichever) node would be in relation to Kerbin's orbit to Moho's. KAC's recalculated Moho's rendezvous a couple times, and now its timer is below all the other ones on my clock ;p ah well, rather get the mission right than wrong.

[TriggerAu]

See I'm planning a few missions, and our trip to Moho was originally scheduled 16 days from the 20th day of year one, but as we got closer and I started making maneuver nodes with mechjeb I saw that we were actually a ways off from where the descending/ascending (whichever) node would be in relation to Kerbin's orbit to Moho's. KAC's recalculated Moho's rendezvous a couple times, and now its timer is below all the other ones on my clock ;p ah well, rather get the mission right than wrong.

The formula based ones will "move" as the orbits are elliptical and the time to window is based on how fast the phase angle is changing to get to the target - all the code that uses this math will change. Best bet IMO is to pick how far in front of the "optimum" time you need to stop and get things set up - couple of hours/days - set an alarm and then come back to it then. The Transfers can occur around a large window - just requires more than the optimal fuels so you don't have to leave right on the time.

A good way to visualize this is show in whats called porkchop plots that show how much DV is required when you leave, and alexmun has built this really impressive web page http://forum.kerbalspaceprogram.com/showthread.php/33023-WEB-APP-Launch-Window-Planner. Taking that another step further, another method for a transfer alarm might be to use the web page and then enter a Raw Time Alarm in the alarm clock, based on the date from Alex's page. This then will not adjust, and you can plan specific times - and know how "wide" the optimum window is.

PS. Here's a tutorial on using Alex's web page - http://forum.kerbalspaceprogram.com/showthread.php/33547-Non-Hohmann-Interplanetary-Transfers

Edited June 2, 2013 by TriggerAu
extra transfer

[John FX]

I am still having the problem where when I switch ships any auto added alarms for SOI changes are forgotten and only the SOI change for che current ship is shown. I am grateful for your efforts in this area and I can see you have put work into resolving the issue but as my main use is for alarm clock to generate auto SOI alarms for multiple ships I am reverting to 1.4.1.0 just for that functionality. Thank you again for such a useful addon that I can`t do without it now that I have used it.

Edited June 2, 2013 by John FX

[sadron]

Odd, the calculator actually gives us a fairly low (blue) delta V for going to Moho at the present time.

[TriggerAu]

I am still having the problem where when I switch ships any auto added alarms for SOI changes are forgotten and only the SOI change for che current ship is shown. I am grateful for your efforts in this area and I can see you have put work into resolving the issue but as my main use is for alarm clock to generate auto SOI alarms for multiple ships I am reverting to 1.4.1.0 just for that functionality. Thank you again for such a useful addon that I can`t do without it now that I have used it.

Sad to hear its not fixed, will PM you to get some more details... I really would like to get to the bottom of it.

[TriggerAu]

I am still having the problem where when I switch ships any auto added alarms for SOI changes are forgotten and only the SOI change for che current ship is shown. I am grateful for your efforts in this area and I can see you have put work into resolving the issue but as my main use is for alarm clock to generate auto SOI alarms for multiple ships I am reverting to 1.4.1.0 just for that functionality. Thank you again for such a useful addon that I can`t do without it now that I have used it.

Sad to hear its not fixed, will PM you to get some more details... I really would like to get to the bottom of it.

Or not as you don't accept PM's... If you have the time I would really like to understand whats going wrong for you. So my understanding from your last post is:

• You have a bunch of ships flying around.
  
• You have the autogenerate SOI Alarms option turned on - and a bunch of ships are changing SOI so they have alarms
  
• You are flying one ship - with an SOI alarm already or not?
  
• And you switch to another ship - using the alarm, clock, haystack, [ or ], or tracking station? and does it have an SOI alarm?
  
• When the switch is complete all the SOI alarms disappear - or they just turn into one?
  

Can you adjust the above and correct any mistakes I have made in the process?

[John FX]

• You have a bunch of ships flying around. -YES
  
• You have the autogenerate SOI Alarms option turned on - and a bunch of ships are changing SOI so they have alarms YES
  
• You are flying one ship - with an SOI alarm already or not? YES alarm already present, auto set
  
• And you switch to another ship - using the alarm, clock, haystack, [ or ], or tracking station? and does it have an SOI alarm? Using map seemed ok until I switched using alarmclock - checking.
  
• When the switch is complete all the SOI alarms disappear - or they just turn into one? only alarm for current ship is shown.
  

Start KSP, go to alarm clock settings, turn on detect and add alarms for SOI changes. I have 2 (or more) ships. I set one to intercept an SOI in the future, an alarm is generated. Switch to other ship using the map. Usually I already have the second ship intercepting an SOI. First SOI alarm disappears, replaced by new alarm.

As I am unable to set two alarms I can`t see if they all get set to the same time again or they disappear. I`ll see i I have an old settings file or I could make one and test to see which it is. 1.4.1.0 works perfectly as far as this feature goes so I am fairly confident it is not a mod conflict. (My issue with the kethane mod debugger not working went away with the kethane update)

I`ll make a couple of test installations, install 1.4.1.0 on one to make a cfg file and test it in 2.1.1.0. Will report back in a few hours. Today for sure. I will turn on PM also...

EDIT: have made second installation, loaded alarm clock 2.1.1.0 and the alarms from 1.4.1.0. All auto added alarms are there I will now turn on auto add SOI alarms.

nothing changed. I will now switch ships using the map.

nothing changed. This is seeming odd. I will try and generate a fresh SOI alarm on another ship.

Nothing changed. I then tried to switch using alarm clock and now only the current ships alarm of the auto added alarms stay now whether I switch with alarm clock or the map.

I`ll try to nail this down a bit more and do a more detailed action list.

Reloading KSP with 2.1.1.0 and old alarms from 1.4.1.0. Will update.

Loaded KSP, went to tracking station, selected ship and selected fly ship. Auto added alarms present for all ships.

Change ship using map `switch to`. All alarms remain.

Change ship using alarm clock `jump to ship` to ship with SOI alarm. All alarms remain (Gah!)

change ship to ship that does not have alarm already set but is already on a SOI course. using map. All alarms remain, new SOI alarm added OK.

change to ship that has alarm set using alarmclock. one alarm vanishes (I think the one that just got set, not sure, will give ships unique names for next trial)

Change back to ship that has now no alarm using map. Alarm added again.

change to ship with maneuver point alarm set using alarm clock. all alarms stay.

change to ship with SOI alarm set using alarm clock. All alarms stay. (this is now quite confusing)

I will now go to a fresh ship and burn to intercept SOI to generate new SOI alarm. New alarm generated, all alarms remain.

Change to ship with SOI already set using map. Alarm that was just generated is gone. All other alarms remain.

switch back to ship that generated alarm using map. SOI alarm regenerated.

switch to ship with SOI set using alarm clock. Alarm that was just generated is gone. All other alarms remain.

can`t switch back to ship using alarm clock so will switch using map and make manual maneuver node to enable switching using alarm clock. SOI regenerated.

switch to ship with SOI set using alarm clock. ALL ALARMS REMAIN including the one just regenerated and the manual node. (Is alarm clock forgetting about a fresh SOI alarm when switching using alarm clock?)

switch back using alarm clock. all alarms remain. delete manual node

switch to ship with SOI set using alarm clock. all alarms remain.

This seems to suggest I was suffering not from all the alarms being replaced, but just the one I have recently made being forgotten.

I will now go to a fresh ship (using map) and burn to intercept SOI to generate new SOI alarm and then switch to a ship that has an SOI set already using alarm clock jump to ship function. all alarms remain. (damn, thought I had it)

I will now launch a new ship. Game crashed (I suspect the 791 part 2000T ship to be to blame)

I will now load KSP fresh and repeat the above. I will have to launch a new (less part heavy) ship.

reloaded KSP, all alarms remain. Launched new ship,burned to make new SOI. New SOI generated all alarms remain.

switch to ship with SOI already previously set using alarm clock. Alarm just set (from freshly launched ship) vanishes.

switch back to ship using map, alarm regenerated.

switch to ship with previousl set SOI alarm using map, all alarms remain.

switch to ship with SOI already previously set using alarm clock. All alarms remain.

delete alarm from freshly launched ship to regenerate. alarm regenerated all alarms remain.

switch to ship with SOI already previously set using alarm clock. Alarm just set (from freshly launched ship) vanishes.

gottit. this is the issue.

When an alarm has just been set, switching to a ship with an alarm already set using the alarm clock `jump to ship` function makes the first alarm vanish. Setting a manual node as well as the auto added node on the first ship stops this happening even if the manual node is deleted straight after creation.

Edited June 3, 2013 by John FX
Update

[John FX]

Now know why, when starting fresh with a new version of alarm clock, I couldn`t make any auto added SOI changs stay. It was always deleting the one just made. Maybe an internal register is not being set for auto added alarms which is being set for manual ones?

Must say on a positive note that it is good to be able to `jump to ship and restore node` properly now. It`s a great feature. As good as if KSP retained maneuver and SOI nodes natively.

[Mihara]

Now know why, when starting fresh with a new version of alarm clock, I couldn`t make any auto added SOI changs stay. It was always deleting the one just made. Maybe an internal register is not being set for auto added alarms which is being set for manual ones?

I think the default configuration file, which overwrites yours, has SOI change alarms simply turned off. This bit me several times by now in recent days.

[TriggerAu]

...

gottit. this is the issue.

When an alarm has just been set, switching to a ship with an alarm already set using the alarm clock `jump to ship` function makes the first alarm vanish. Setting a manual node as well as the auto added node on the first ship stops this happening even if the manual node is deleted straight after creation.

Thanks heaps for your persistence with this John FX, excellent step by step, and I really appreciate you going the extra distance. Will look into this one and hopefully nail down whats going on there.

I think the default configuration file, which overwrites yours, has SOI change alarms simply turned off. This bit me several times by now in recent days.

This is true, and why the instructions mention not replacing your config.xml if you want to keep your existing settings. Have written it to (hopefully - but obviously missed one thing from one of John FX's issues ) be backwards compatible for alarms and config files at each update. Once I split the alarms from the config they didn't get overwritten. Will review whats in the config.xml and maybe I can take that out of the plugin zip as well for future releases. Thanks for the info and idea.

[xZise]

Hey nice work! My list is always full of events I should work on This should be stock, as I'm easily can forget any important event

But I have a bug: Sometimes, I discovered only after entering another SoI, the periapsis alarm doesn't work, even when there is a periapsis visible. Later today I'll check if a previously it does work, after being captured by the Mun (and having a apoapsis).

This is how it looks like: http://ma.xzise.de/oog/albums/Fabian/KSP2/screenshot28_croped.png

And can you add something link the next two closest approaches which are also visible? Maybe also add an option to the other alarms to optionally restore target or next node. Is there a way to stop the alarms, which are in the past, from popping up, after loading a ship without deleting them?

Keep improving your awesome plugin.

Fabian

[TriggerAu]

But I have a bug: Sometimes, I discovered only after entering another SoI, the periapsis alarm doesn't work, even when there is a periapsis visible. Later today I'll check if a previously it does work, after being captured by the Mun (and having a apoapsis).

This is how it looks like: http://ma.xzise.de/oog/albums/Fabian/KSP2/screenshot28_croped.png

Will have a look at this tonight as I need to look at SOI's for John FX - I think I know whats happening for his one, but tis ones new

And the next bits a list

And can you add something link the next two closest approaches which are also visible? Maybe also add an option to the other alarms to optionally restore target or next node. Is there a way to stop the alarms, which are in the past, from popping up, after loading a ship without deleting them?

Fabian

• If you mean select a target and find the closest approach to it from your source vessel in the next few orbits - I have a POC that works, but the 0.20 changes have introduced some extra work I've had to do
  
• All the Target Based and Maneuver node alarms store the target/Nodes now - or do you mean to just randomly store nodes/targets without an attached alarm
  
• And here's a 0.20 special - in 0.20 on each gamestate change it reloads the dlls and alarm list - so before I could keep stuff in ram and know whats fired - I was pondering this yesterday and will need a solve for this. Thanks for the heads up.
  

C, I told you a list

[Honeybadga]

Hai, love your mod. Here's a suggestion.

When I wanna set an alarm at AN/DN, it says 'No AN/DN found on current plan', probably because I don't have a target selected.

Could you make it so that when I don't have a target selected, it sets an alarm for the equatorial AN/DN?

Keep up the good work.

Edited June 4, 2013 by Honeybadga

[TriggerAu]

Quick bug hunting update...

@John FX, Have found the source of this one - is due to the way the plugin is unloaded on ship change - have a fix in the works

@xZise, have found how to replicate the fault - now to work out a fix

@XZise, Have an idea for past alarms refiring on ship change - should be able to make it so only alarms that display will be for the one alarm that may have just fired and you have switched

Will get an updated version out as soon as I can for these and a couple of others

[John FX]

There is one more thing but it is very minor and cosmetic. I have quite long names for my craft (Like the IFS Minmus Texaco Holiday Inn Service Station) and this means that quite often an alarm is spread over two lines and so some alarms sort of drop off the bottom and only two alarms are visible at a time. Would it be easy to make the alarm window either a bit wider, a bit wider and taller, or ideally adjustable?

[TriggerAu]

There is one more thing but it is very minor and cosmetic. I have quite long names for my craft (Like the IFS Minmus Texaco Holiday Inn Service Station) and this means that quite often an alarm is spread over two lines and so some alarms sort of drop off the bottom and only two alarms are visible at a time. Would it be easy to make the alarm window either a bit wider, a bit wider and taller, or ideally adjustable?

I was playing with this to try and squeeze something into 2.0 for long names. I coded myself into a mess trying to sort it out and pulled what I had in frustration so I could get v2 out. I do plan to get back on to that one at some point

[TriggerAu]

... only two alarms are visible at a time. Would it be easy to make the alarm window either a bit wider, a bit wider and taller, or ideally adjustable?

In the interim, the height before the scrolling kicks in is controlled by the "Max Alarms Before Scrolling the list" option in the settings (this is in lines). So try increasing that to 20 or so and you should see more alarms, but they will still wrap.

[John FX]

Quick bug hunting update...

@John FX, Have found the source of this one - is due to the way the plugin is unloaded on ship change - have a fix in the works

@xZise, have found how to replicate the fault - now to work out a fix

@XZise, Have an idea for past alarms refiring on ship change - should be able to make it so only alarms that display will be for the one alarm that may have just fired and you have switched

Will get an updated version out as soon as I can for these and a couple of others

Thank you so much for your work. It really makes a difference just to be kept in the loop as to what is happening.

[John FX]

In the interim, the height before the scrolling kicks in is controlled by the "Max Alarms Before Scrolling the list" option in the settings (this is in lines). So try increasing that to 20 or so and you should see more alarms, but they will still wrap.

Of course, I forgot about that with the amount of times i have reinstalled alarm clock hehe. I`ll set it high and just miss a bit at the bottom.

Thank you.

[xZise]

First of all, thanks for the fast response. Looking forward to a newer version.

• All the Target Based and Maneuver node alarms store the target/Nodes now - or do you mean to just randomly store nodes/targets without an attached alarm
  

I wanted to attach the active target to an alarm. Okay maybe it isn't necessary in the future, but when I have a closest approach I create a standard alarm. And there would be a checkbox nice to say: “Store the active targetâ€Â, like AN or DN does.

And add one to the list: Can you add the feature, that the default margin for a node alarm is burntime/2+1 minute? Maybe you already added and my nodes are to short to notice. Or it get lost after the forum hickup.

Fabian

[TriggerAu]

And add one to the list: Can you add the feature, that the default margin for a node alarm is burntime/2+1 minute? Maybe you already added and my nodes are to short to notice. Or it get lost after the forum hickup.

I do recall someone mentioning that, but I didn't have it written down on my list. I'll add it, but can't tell you when that one might be done.

For the other maybe I can store any target/Nodes active for all alarms and work out how you can choose what to restore - I will have to change the alarm file for that one though - so it will take a little work.

[TriggerAu]

Hai, love your mod. Here's a suggestion.

When I wanna set an alarm at AN/DN, it says 'No AN/DN found on current plan', probably because I don't have a target selected.

Could you make it so that when I don't have a target selected, it sets an alarm for the equatorial AN/DN?

Keep up the good work.

Just to try and rephrase this one for my head to make sure I have it right, your talking about the Ascending Node in the diagram below yeah (replacing Celestial Body with your vessel obviously - so its where your vessels orbit crosses the celestial bodies plane of ref) ?

[TriggerAu]

v2.1.2.0 Released

Found and eradicated a few bugs

• Verified year calcs
  
• Adjusted Date Entry for Raw alarms and date displays to show Year 1, Day 1 based stuff so the clocks in tracking station, etc and the alarms all match display wise. Also means you can now create an alarm using the dates from external apps like the transfer pork chops without doing maths (Thanks Mr Shifty)
  
• Fixed bug where Pe Node was not detected if there was no Ap Node on the flight plan (xZise)
  
• Fixed bug with autogenerated and auto recalc alarms, by introducing save of the alarms file periodically and on alarm creation (can't rely on memory in 0.20) (John FX)
  
• Removed initial config.xml file from package (and added additional code) so upgrades should now maintain alarms AND settings (Mihara, John FX)
  

I still have to work on past alarms refiring on each ship change, but thnking further I may need to store more detail i the laarms file and might take the opportunity to change something there that has been bugging me. So I'll probably include that fix in the next larger update I do.

[Moleculor]

I don't s'pose you could move the mod folder into the root of the zip file? Having to dive down two directory levels just to find the folder I have to extract is not just annoying, but I've failed to notice that I have to do this, and I end up extracting the "Kerbal Alarm Clock" folder into GameData rather than "TriggerTech" or whatever it's called, which results in a non-functioning addon.