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

[KerbMav]

Now to work out ohw to find the time to do it all

If I had anything to say, concentrate on usable transfer alarms and getting Kerbal days working. :D

Good luck, we expect much, you kept spoiling us with your mods!

[phoenix_ca]

If I had anything to say, concentrate on usable transfer alarms and getting Kerbal days working. :D

Good luck, we expect much, you kept spoiling us with your mods!

...What makes the transfer alarms unusable?

And the Kerbal days setting works just fine. o.O

[KerbMav]

Hm, maybe I am blind regarding the Kerbal days - but the transfers seem to be way off for me?

[phoenix_ca]

Hm, maybe I am blind regarding the Kerbal days - but the transfers seem to be way off for me?

There are two different options for them. You either use a mathematical formula to determine the correct time (which will be off because it doesn't take into account inclination), or a model of the system. The model is more accurate, and goes up to 100 years starting from Day 1.

Honestly I would only use them as a rough estimate anyway. Alexmoon's Launch Window Planner is far superior for accurate planning.

[Mokmo]

There are two different options for them. You either use a mathematical formula to determine the correct time (which will be off because it doesn't take into account inclination), or a model of the system. The model is more accurate, and goes up to 100 years starting from Day 1.

Honestly I would only use them as a rough estimate anyway. Alexmoon's Launch Window Planner is far superior for accurate planning.

AlexMoon's planner is pretty good. MechJeb will stick to transfer windows closer to the Formula.

[SirJodelstein]

not sure if this issue has been brought up before: Since alarms are now persistent anyway, the "Jump to ship and restore maneuver node" button now duplicates the maneuver node. I think the button can simply be removed since node persistence is now a stock feature anyway - or that function should do a check if the node already exists before creating the maneuver node

[TriggerAu]

not sure if this issue has been brought up before: Since alarms are now persistent anyway, the "Jump to ship and restore maneuver node" button now duplicates the maneuver node. I think the button can simply be removed since node persistence is now a stock feature anyway - or that function should do a check if the node already exists before creating the maneuver node

Hmm, it shouldnt duplicate the node thats for sure. I'll note that one down thanks.

I did consider removing it but if you consider the case of someone saving the alarm+node, and then doing stuff to the node (perhaps unintentionally), when they come back to the alarm for the saved node if I dont restore the one from the alarm then they get an alarm for one node and the edited node. That said with the alarms getting saved in the save file, perhaps not an issue either. Is certainly something I want to fiddle with in v3

[Taki117]

If I might make a feature request, I would like the ability to add alarms from the Space Center and/or tracking station.

[TriggerAu]

If I might make a feature request, I would like the ability to add alarms from the Space Center and/or tracking station.

I'd forgotten about that one Taki117, its on the issue list now. Thanks

[Taki117]

I'd forgotten about that one Taki117, its on the issue list now. Thanks

Welcome, and keep up the good work! (I can't tell you how many times I've wanted to add a transfer alarm from the space center)

[BudgetHedgehog]

I have a feature request: can it not spam the output log so much? It's ridiculous how many "KerbalAlarmClock,Saving Alarms-v3" are logged.. Can something be done about it?

Example:

[TriggerAu]

I have a feature request: can it not spam the output log so much? It's ridiculous how many "KerbalAlarmClock,Saving Alarms-v3" are logged.. Can something be done about it?

Example:

http://i.imgur.com/zvn1ZVO.png

Yeah thats not good - I'd guess thats the autosaving when there are recalc alarms happening - the whole block of code is removed in v3, I'll see how quickly I can turn it around in v2

[Drew Kerman]

while we're adding things to the list of features... how about an altitude alarm? Good for elliptical orbits where you're going after lo/hi science above a planet and want to accelerate to them. Hrm... not much else tho. Maybe not worth it

[SirJodelstein]

What i would find incredibly useful (now that the Alarm window can be used from the Tracking Station, is the option to add alarms from there. That would be useful for tracking incoming asteroids (click/track asteroid, add SOI alarm or raw time alarm to get notified when the asteroid gets closer) or adding missing alarms for other crafts.

[TriggerAu]

while we're adding things to the list of features... how about an altitude alarm? Good for elliptical orbits where you're going after lo/hi science above a planet and want to accelerate to them. Hrm... not much else tho. Maybe not worth it

You can add an altitude alarm through the distance type currently.. although maybe not as obvious as I had at first thought. Heres a screenshot... will that d what you want?

What i would find incredibly useful (now that the Alarm window can be used from the Tracking Station, is the option to add alarms from there. That would be useful for tracking incoming asteroids (click/track asteroid, add SOI alarm or raw time alarm to get notified when the asteroid gets closer) or adding missing alarms for other crafts.

This is by far the most requested thing to add, I'll get there

[Starwaster]

What i would find incredibly useful (now that the Alarm window can be used from the Tracking Station, is the option to add alarms from there. That would be useful for tracking incoming asteroids (click/track asteroid, add SOI alarm or raw time alarm to get notified when the asteroid gets closer) or adding missing alarms for other crafts.

With all the asteroid activity, it's going to be difficult to spot approaching ships.

[SergeantBlueforce]

Just a question, with transfer alarms, what is the difference between Model and Formula?

[BudgetHedgehog]

Model is based of the real positions of the planets and should be the more accurate. However, it only lasts I think 40 years. Formula is based off 'according to my calculations, the planet should be.. here' - it assumes zero eccentricity and possibly inclination so is less accurate but lasts longer than 40 years.

[TriggerAu]

Just a question, with transfer alarms, what is the difference between Model and Formula?

ObsessedWithKSP is on the money here. The Model option has 100 (earth) years of data that voneiden generated for me a while back, the formula version uses Olex's simple formula version that computes things based on circular orbits (http://ksp.olex.biz/)

I'd really like to be able to work out how to insert a lambda solver in the game and get something like http://alexmoon.github.io/ksp/ in there, but the maths is simply over my head, and I'm not sure whether thats taking an "alarm clock" a little too far. But maybe with the APIs I've started in v3 someone could inject the alarms. We'll see

[laggerd]

is there any mirrors of KAC that I could use because spaceport links just redirect to curse?

[BudgetHedgehog]

EDIT: it's already on Curse.

Edited June 3, 2014 by ObsessedWithKSP

[brusura]

Is Transfer Alarms Auto Recalc working? The issue is more evident on very long alarms, let's say I have added an alarm for Eeloo tansfer, at time T0 it says 400 days , after high warp at time T1 I add a second alarm for the same transfer to Eeloo, one would guess that both alarms ( with auto recalc for transfer on ) should have the same amount of days.

But what happen is that older alarm added at T0 says that there are still 50 days while new alarm added at T1 says that there are only 40 days.

is this behaviour a known bug or is just me?

EDIT: ok I think is related to the way transfer is calculated, by model or formula, it's not the high warp that mess up the transfer alarm but the positions of bodies recalculated via formula

Edited June 3, 2014 by brusura

[TriggerAu]

is there any mirrors of KAC that I could use because spaceport links just redirect to curse?

Yep, they are all on GitHub under releases - https://github.com/TriggerAu/KerbalAlarmClock/releases

I really gotta edit that front page

[BudgetHedgehog]

So regarding calculating transfer windows..

I was reading the wiki and saw this

That is the transfer window to Duna. As the orbits are on rails, the optimal phase angle (and hence transfer window) will repeat consistently and permanently using the synodic period between them, which is every 19645709 seconds. All that really needs to be done math wise is calculate the first transfer window (when UT=0, the phase angle is 135.51° so part way through the synodic period), but once that's done, it's a simple case of a repeating alarm once every 19645709 seconds.

This can be worked out for all the planets and moons using the data and equations here. Granted, that online transfer calculator can do this, but it can't set an alarm in game for you. It might be what Protractor already does (I don't use it), but to me, it's a bit odd that KAC has the ability to add alarms for transfer windows but no reliable way of calculating them (I say this because I never know which to trust - MJ, Model transfer calculation or Formula transfer calculator).

At least, I'm pretty sure what I just wrote makes sense.. I could be well off though.

[undercoveryankee]

So regarding calculating transfer windows..

I was reading the wiki and saw this

http://wiki.kerbalspaceprogram.com/w/images/math/d/d/4/dd4b207a406ab3c16a2520ea017ab2f0.png

That is the transfer window to Duna. As the orbits are on rails, the optimal phase angle (and hence transfer window) will repeat consistently and permanently using the synodic period between them, which is every 19645709 seconds. All that really needs to be done math wise is calculate the first transfer window (when UT=0, the phase angle is 135.51° so part way through the synodic period), but once that's done, it's a simple case of a repeating alarm once every 19645709 seconds.

This can be worked out for all the planets and moons using the data and equations here. Granted, that online transfer calculator can do this, but it can't set an alarm in game for you. It might be what Protractor already does (I don't use it), but to me, it's a bit odd that KAC has the ability to add alarms for transfer windows but no reliable way of calculating them (I say this because I never know which to trust - MJ, Model transfer calculation or Formula transfer calculator).

At least, I'm pretty sure what I just wrote makes sense.. I could be well off though.

Between two coplanar circular orbits, it is exactly that simple.

But when you add eccentricity and inclination, windows that happen on different parts of the orbit are no longer exactly equivalent. Transfer time changes depending on whether your intercepts are on the fast or slow parts of the orbit. Sometimes there's a delta-v advantage to an off-Hohmann transfer that has smaller plane changes or e.g. catches Moho at apoapsis.

A full solver like alexmoon or arrowstar takes into account all of the above. KAC's "Model" mode uses data that was generated based on at least some of those factors, so it's second best.

A calculator that assumes circular orbits (olex or KAC's "Formula" mode) is working at about the level of complexity that ObsessedWithKSP describes. There are a few possible approaches that are affected differently by eccentric orbits, but if you're concerned about the differences it's easiest to just switch to a calculator that doesn't use the circular-orbit approximation.