Jump to content

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


TriggerAu

Recommended Posts

Is there anyway to move the button at all? It overlaps my clock/time control (likely because I bumped up the interface size).

Not sure about making it draggable-it uses different functions to a draggable window, but maybe I can read the interface size and move it accordingly. Will look into it

Link to comment
Share on other sites

On linux I had to move some files across to PluginData/kerbalalarmclock/ to work. Case sensitive filesystem.

Thanks Babalas, I can change that in future releases. Just so I'm clear for it can you PM me a copy of the dir structure that works for you, ie. is it just renaming the PluginData/KerbalAlarmClock/ to PluginData/kerbalalarmclock/ or something bigger?

Link to comment
Share on other sites

This is probably the mod I'm manually using the most often, as it's completely revolutionized the way I play, and I'd like to thank you for it.

One request for alarms: Could you possibly add a "Closest Approach to Targeted Object" preset and "Restore targeting on switch to vessel" option?

Link to comment
Share on other sites

One request for alarms: Could you possibly add a "Closest Approach to Targeted Object" preset and "Restore targeting on switch to vessel" option?

I captured this idea before the forum smash and found some code objects that may help, its on my list of things to investigate. maybe something like "closest approach in x orbits which is y secs"

Link to comment
Share on other sites

A question, if I may, sort of inbetween a noob orbital mechanics question and a specific one regarding the data Kerbal Alarm Clock gives you...

What is the moment in time that is denoted by the transfer window alarms?

That is, assume I want to launch from Kerbin and straight into escape path towards Jool. I have set up a Kerbin-Jool transfer alarm using KAC.

When exactly should I launch based on the alarm time, and just how wide are transfer windows in practice?

Link to comment
Share on other sites

I captured this idea before the forum smash and found some code objects that may help, its on my list of things to investigate. maybe something like "closest approach in x orbits which is y secs"

This would be a nice feature, hopefully it works out. Anyways, I really came here to let you know that you seem to have forgotten to update the "latest version" on whatever server the plugin is checking for updates... so KAC thinks it's out of date.

o5HqCnR.png

Seeing as it's my first time poking my head into this thread, you have my compliments! This is a very useful plugin and it's great that you're continuing to develop it. :)

Link to comment
Share on other sites

This would be a nice feature, hopefully it works out. Anyways, I really came here to let you know that you seem to have forgotten to update the "latest version" on whatever server the plugin is checking for updates... so KAC thinks it's out of date.

Seeing as it's my first time poking my head into this thread, you have my compliments! This is a very useful plugin and it's great that you're continuing to develop it. :)

Thanks for the feedback and info Yasutaka, haven't seen that behaviour before, but I think I understand whats happening.

You can see the version check page was changed here : https://kerbalalarmclock.codeplex.com/wikipage?title=LatestVersion, but it does only check once a day, or in the case of your screenshot (where the daily check is disabled), when you click the button. I think I'll change it so it only shows up the message when the web version is newer to avoid this incorrect warning.

Thanks again for the info.

Link to comment
Share on other sites

A question, if I may, sort of inbetween a noob orbital mechanics question and a specific one regarding the data Kerbal Alarm Clock gives you...

What is the moment in time that is denoted by the transfer window alarms?

That is, assume I want to launch from Kerbin and straight into escape path towards Jool. I have set up a Kerbin-Jool transfer alarm using KAC.

When exactly should I launch based on the alarm time, and just how wide are transfer windows in practice?

I'll start off by saying that I am by no means an expert in orbital mechanics, but here goes...

The idea of the Transfer alarms is that these are the "optimum" times to begin a hohmann transfer between two bodies - or think of it being the time to leave that will use the least amount of fuel. The method I use is, have my ship ready and in orbit around my starting planet before the alarm fires, and then try and depart as close to the optimum time as possible, it doesn't have to be exactly on the alarm, and in fact typically can't be as you need to leave the orbit in the right direction.

So your most efficient time to travel from Kerbin to Jool is when the alarm fires - you should get your ship into orbit ready to go and then try and leave as close to the time of the alarm to use the least fuel, and have the best chance of success in arriving at the position Jool will reach at the same time.

For extra/background info...

To generate these optimum times in the KAC I have used two methods -

  1. Formula - based on circular orbits - watches the angel between the planets and tells you when that best angle occurs - as orbits aren't normally circular these are approximations. Same maths that's behind Olex's calculator
  2. Modelled - voneiden built a whole toolset to model the system and work out these best times - and these are more accurate times to depart as they use the real elliptical orbits

The length of the windows is the one I have the least personal knowledge about, but maybe the right way to put it is that there are a number of days (I'm pretty sure that's right) where it is possible to successfully transfer between planets, but the amount of fuel you will need to be successful will be significantly greater if you miss that "optimum" time. I remember someone's math from before the forum crash that showed a porkchop plot (yes that's the right term :) ) of one transfer and it showed about 10 days where it was possible to make the transfer and the variations in fuel required for that example.

There are heaps of good tutorials on hohmann transfers and how to's on the forum, and real world info too:

Link to comment
Share on other sites

Thanks for the feedback and info Yasutaka, haven't seen that behaviour before, but I think I understand whats happening.

You can see the version check page was changed here : https://kerbalalarmclock.codeplex.com/wikipage?title=LatestVersion, but it does only check once a day, or in the case of your screenshot (where the daily check is disabled), when you click the button. I think I'll change it so it only shows up the message when the web version is newer to avoid this incorrect warning.

Thanks again for the info.

Oh, yes I see now, I'm a little disappointed in myself for missing that. I remember disabling the daily check, now, but I'm surprised my settings weren't overwritten when I installed the new version. Anyways, I'm happy I could help. :)

Link to comment
Share on other sites

I captured this idea before the forum smash and found some code objects that may help, its on my list of things to investigate. maybe something like "closest approach in x orbits which is y secs"

I'm no expert in the inner workings of KSP of course, but can't you read the times from KSP? KSP shows the closest approach with little flags on the current orbit. If you were to set an alarm at the first of those points, I think everyone would be quite happy with the feature. :) A closest approach that doesn't even show up in KSP is imho not usefull anyway. Right now I use mechjeb to set a maneuvering node at the closest point and then use kerbal alarm clock to set the actual alarm from that node.

Link to comment
Share on other sites

I'm no expert in the inner workings of KSP of course, but can't you read the times from KSP? KSP shows the closest approach with little flags on the current orbit. If you were to set an alarm at the first of those points, I think everyone would be quite happy with the feature. :) A closest approach that doesn't even show up in KSP is imho not usefull anyway. Right now I use mechjeb to set a maneuvering node at the closest point and then use kerbal alarm clock to set the actual alarm from that node.

I started looking at this after the last release, looked at the maths needed and also found a few api functions (I'd prefer to use what's in KSP than my own half baked math) - but am stuck on some of the params - http://forum.kerbalspaceprogram.com/showthread.php/28850-Closest-Point-between-two-orbits-Question . I did also look at MechJeb,protractor, source etc to see how they had used the KSP stuff, but they all use their own maths as well. If I can't get the API working I will write my own math, but will give it a few more goes first.

Regardless of the method I think I will implement the lookahead idea - past the current orbit - I did get that request, the coding's no harder and I can see a way people would use it (by just waiting for something to catch up over time, and not using fuel) - just need an option for how many orbits to look ahead, and people can choose how they use it.

Link to comment
Share on other sites

Good luck with it Trigger :)

I was thinking the other day, and maybe it's unattainable, but perhaps it's an idea to put KAC in the tracking station view... With a "fast forward, auto switch to, and restore node, to next alarm" button?

Link to comment
Share on other sites

I was thinking the other day, and maybe it's unattainable, but perhaps it's an idea to put KAC in the tracking station view... With a "fast forward, auto switch to, and restore node, to next alarm" button?

Awesome...That's one of the ideas I lost from the old forum page - I have some code to do with what screen is loaded, but I couldn't recall why I started looking at it. Thanks willow!

Link to comment
Share on other sites

Nice update, the new alarms are pretty useful.

Having a problem with the SOI change alarm though, at least twice, it missed the SOI change and I flew past it at high warp, which of course, changed my orbit. Nothing I couldn't recover from, but I thought it was strange. I'm using the default of one minute before SOI change alarm, and it seems to be off by at least 30 seconds, as it is still warping past the SOI change, then the alarm kicks in, and after I turn off the alarm the orbit is saying I have a new SOI change. Anyone else see this? I was on the way to Jool and a couple of my perfect encounters got messed up because I missed the SOI change.

Another thing I found, it would be handy to have an altitude alarm, is that possible? Right now, I'm putting a maneuver node at about the altitude I want and setting the alarm for that. But being able to enter a specific altitude for an alarm would come in handy.

Link to comment
Share on other sites

Another thing I found, it would be handy to have an altitude alarm, is that possible? Right now, I'm putting a maneuver node at about the altitude I want and setting the alarm for that. But being able to enter a specific altitude for an alarm would come in handy.

Thats a pretty cool idea, ironically creating/adding an alarm based on that should be relatively easy - the fun part will be working out how to estimate how far off it is and display it when all the current lists are time based. I'll certainly add it to the list and see what I can come up with.

Having a problem with the SOI change alarm though, at least twice, it missed the SOI change and I flew past it at high warp, which of course, changed my orbit. Nothing I couldn't recover from, but I thought it was strange. I'm using the default of one minute before SOI change alarm, and it seems to be off by at least 30 seconds, as it is still warping past the SOI change, then the alarm kicks in, and after I turn off the alarm the orbit is saying I have a new SOI change. Anyone else see this? I was on the way to Jool and a couple of my perfect encounters got messed up because I missed the SOI change.
Dweller, you need to give it more margin. at high warp, 1 min is GONE long before the Alarm clock can react.

For clarity...The Alarm Clock SOI alarms work (ignoring the "catch background changes" option - I DONT recommend using this one, and will probably remove it at some point)by:

  • (you get via adding manually or using the auto add option in settings) is based on looking ahead along the flight plan, getting the SOI time that KSP defines and setting an alarm then (minus margin).
  • If recalc is on it will monitor the flight plan and adjust the alarm time until it is within 180 secs of the alarm - at which point its locked in regardless of recalc setting (it can do this for all the alarms, except raw obviously).
  • Lastly the Warp affecting works based on looking ahead to how far away the alarm is and slowing down before the event - so you shouldn't fly past the event, it should slow down before.

Now to the question :). I believe this behavior with missing the event is going to be related to the warp (and my math). When you warp the flight plan items become estimates, and if recalc is enabled then the SOI alarm becomes an estimate as soon as you start warping. So basically, once you start warping the alarm clock is slowing you down to meet the estimate under warp, not the actual time the alarm was set, and sometimes it will miss the precise event at the start - To be honest I didn't think of this till now.

D_B, for now a way to still have precision (assuming the SOI isnt actually changing as you get closer) would be to turn off the auto-SOI and SOI recalc options and set the SOI alarm manually while under no warp. Another alternative may be to use Fyrem's suggestion of a larger margin, then once you hit the 20 min(?) margin you could set a more precise one then.

Something for me is to maybe have an option so it only does recalcs while at 1x warp, will have a think about that one too

Link to comment
Share on other sites

OK, thanks for the explanation. I'm just going by how it worked in the last version I had, which never seemed to miss an SOI change that I noticed. The latest version seems to have the problem, and I'm just using the default settings, not even sure what this recalc setting is, I don't recall changing anything like that anyway. It looks to me that a setting of 2 or 3 minutes margin should be enough to allow it to slow down.

Link to comment
Share on other sites

Pretty sure the SOI code is still the same, but I will double-check that. I led you astray on the recalc option, it is different for SOI alarms - it does the recalc until it hits the threshold, but doesn't give you the option of disabling it, wasn't the intention, something else to add to fix :(

Link to comment
Share on other sites

I was watching it closely last night, and it seems that KSP is not running on rails when it's warping. At least that's what it looks like. The orbit was changing a bit the closer it got to the SOI change, it was a quick flash, but it looked like the predicted orbit line flickered a bit just before the ship hit SOI, maybe a few minutes out from it. I had the alarm set to 2 or 3 minutes ahead I think, and it still missed it. But I'm pretty sure the orbit also did something wonky, it happened so fast I can't be sure. This was just a changeover from Kerbin to solar SOI, so nothing strange was happening, just coasting away from the planet.

Link to comment
Share on other sites

So your most efficient time to travel from Kerbin to Jool is when the alarm fires - you should get your ship into orbit ready to go and then try and leave as close to the time of the alarm to use the least fuel, and have the best chance of success in arriving at the position Jool will reach at the same time.

Something might be a little off here then...

I've had a bunch of individual ships in parking orbit over Kerbin, waiting for the transfer window to Duna. I've set up an alarm 24 hours before the transfer window point. When that came up, MechJeb's 'transfer to another planet' maneuver node calculator insisted the optimal transfer time is still a week off for each of them.

I decided to tell MechJeb to shut up, and set up transfer nodes manually. None of them came particularly close, but surmising I'm just getting bitten by floating point, and there will still be a chance do corrections later, I went through with them anyway. That was a mistake, it turned out, because it took a lot of time to find nodes giving me capture points when they were finally out of Kerbin SOI, and all of these nodes ended up requiring far more delta V than I anticipated and far more than they should have. Thankfully, this mission took way more fuel than necessary in anticipation of multiple sub-optimal landings...

While they were flying to their destination, a transfer window to Jool came up and I sent a probe mission there. This time, I didn't rely on Kerbal Alarm Clock transfer window calculator, and instead, once the alarm came up, told MechJeb to schedule a transfer, which, once again, came several days later than the projected transfer time by Kerbal Alarm Clock.

This time I got a capture in a single burn.

Link to comment
Share on other sites

Something might be a little off here then...

Thanks for the feedback Mihara, would love to investigate further and see if I can see whats happening for you. Can you let me know whether you were using the "Model" or "Formula" times for the transfer window, when the transfer window was (i.e. the date), and also what version of Mechjeb. I can then compare them and see what the differences may be.

I do know that the "model" data will not agree with the Formula's used in Olex's calculator - which is the more common method, but the testing by the author of the data and myself seemed to work (there are almost 20,000 alarm points in the model though so its possible some are less than optimal). The test method was basically this (http://forum.kerbalspaceprogram.com/showthread.php/27236-Tutorial-Step-by-step-Interplanetary-Hohmann-transfer-guide-and-tips) - burn to set up correct apoapsis, then mid course to get a capture.

If your OK, getting me those details I'll crack on and test some things. Another thing you could try is to use the "other" mode of transfer windows and see how that goes.

Link to comment
Share on other sites

I've been using the "Model" times for the transfer window, MechJeb version is the current development snapshot from 8th of May, and the in-game date is somewhere in year 2. Assuming the UT value in the persistence file is the timestamp (I don't see any other likely candidates but can't boot up the game for a few more hours), UT = 50661738.8269381 and the transfer window was some 80 days ago.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...