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

[TriggerAu]

Alright, I tried again with 2.6.4.0. Here is my KSP.log. I couldn't find any other log files anywhere in the KSP_linux directory, and that doesn't look very informative. There was no KSP_Data/output_log.txt file, and it seems like config.xml is not getting generated (it's not there either.)

If I run the 32-bit version of KSP on my 64-bit Linux install, everything works fine. Running 32-bit mode doesn't fix 64-bit mode though. I guess I'll run in 32-bit mode until you figure this one out. Is there a debugger we can attach to the game to see where it's crashing? This seems like a bug in KSP itself (mods shouldn't be able to crash games) should I post this to Squad's bug list?

So the output_log.txt file is the only debug log I've seen in KSP that we have access to, it has a bit more detailed info that the ksp.log file. Looking through the Linux Compatability Thread it looks like it is called Player.log on OSX and Linux and can be found in "/home/user/.config/unity3d/Squad/Kerbal Space Program" - sorry for the misleading filename.

If you can see if that file exists for an issue would be good, and if you have a chance to see if any older versions work, ie 2.5 or something. If its never worked that will be a different set of stuff for me to lok at than if its broken in a recent version.

Thanks

[TriggerAu]

Well after a quick headscratching session as too why Kerbal alarm clock wasnt working. I finally found that norton was removing kerbalalarmclock.dll as a poential threat. Silly norton.

Thats a bit funny and a bot annoying. Good find vetrox

[TriggerAu]

@ Trigger Au

First off, compliments for your mod. KAC is really my No.1 'must have', couldn't live without.

I have a suggestion. Sorry in case it was already considered (but I can't find about it in this thread).

KSP is very nice, lots of good features and such. But for one thing, that is closely connected with time: countdown to burn time. Yes, that value that appears to the right of the Navball and down when a node exists. Problem is, it is way too small and almost not noticeable. IMHO, such an important value should be put in full evidence, at least when the focus is on the relevant ship and the time-to-burn goes below a set threshold (say, 10 sec., but could be adjustable). I believe everything needed to set an 'alarm' at burntime-10sec. already exists in KAC, the only thing should be to create an action when that alarm goes off, that will display the countdown in a larger font, in a set position onscreen (I would initially set it just @ the center) and a set colour (I would initially make it dark red, to differentiate from other readings and provide a sense of urgency). At burntime = 0, or shortly after in case no burn was initiated, this additional display will disappear being no more relevant.

Being nothing more than a value to be properly displayed at the correct time (already known to KAC), I am under the impression that you could very easily implement this. Could you please be so kind to evaluate the feasability of such feature?

I have looked at burn time as a margin for an alarm before, but got lost trying to work out the vessel structure and maths. I am working on another small thing at the moment though that involves learning the vessel stuff, so if I understand it and the maths I do plan to add something about burn time to the maneuver node alarm in KAC.

Thanks for the feedback too

[TriggerAu]

I'm getting a very annoying bug where, in "unstable", for want of a better word, orbits (i.e., the path is shaking as you're baaarely skimming something's SOI), KAC generates many many auto-generated SOI-change alarms, spamming the alarm list and also popping up in the middle of the screen. Can you add some sort of a check when automatically generating alarms to see if another identical one has been generated very recently? Even if it were limited to something like 1/second that would be more manageable then the tens a second I have occasionally got.

Well that doesn't sound quite right, I thought the way I had it was that it would update the one alarm as its for the same SOI change, but obviously missed that scenario. I can do some testing with the alarm type and SOI 's and paths and see if I can repl it.

Actually if you are Ok with it, you could PM me a save file and I "should" be able to see the same thing you are seeing

[Frederf]

As I'm trying to add successfive 20m/s boosts to an escaping probe it dawns on me that I'd love if KAC would allow me to select the alarm actions completely independently of each other: Message, warp 1x, pause. Right now it's a radio button but if they were checkboxes I could have 1x warp without message, pause without message, etc. I use KAC as a "warp to x" often and I don't need to click "delete on close" and have a message. It's just been a few seconds since I created it and I don't need a reminder.

[diomedea]

I have looked at burn time as a margin for an alarm before, but got lost trying to work out the vessel structure and maths. I am working on another small thing at the moment though that involves learning the vessel stuff, so if I understand it and the maths I do plan to add something about burn time to the maneuver node alarm in KAC.

Thanks for your attention towards my proposal.

If I understand you correctly, you would like to implement a calculation of the burn duration (meaning to know mass of the ship, thrust of the engines and the speed change required). That would certainly be outstanding, as I see the KSP stock game itself being erratic in showing such value. If you can get a correct burn duration, then you can also implement correctly the countdown to the node (what I was asking, but probably I was not clear enough) as the time left before the node (current time minus time of the node, both perfectly known already to your mod) minus half the burn duration (this last term I have never seen considered in stock KSP countdown).

Now, if you are going to calculate the burn duration, you may also make this a perfect tool by including a warning that a split-manouever is required (another thing totally lacking in KSP). A split-manouever must be done whenever the burn duration is too long compared with the orbit period (generally the case with low-thrust engines) so that a single continued burn would also be applied at a wrong position; instead the total burn duration must be split to occur in a number of orbits, always at the same phase. In case of a split, the node must not be cleared until after the last portion of the burn, and possibly an alarm should be re-created after each partial burn to warn for the time of the next.

[Frederf]

In such a case it's probably best to remove the previous maneuver node and generate the next with the remainder of the maneuver until complete. The maneuver nodes require a definite epoc/orbit count and can't really span multiple orbits as designed.

Also long-duration burns split 50/50% before and after the impulse point is only a first order approximation. The optimized split might be 37/63% for example. It ultimately depends on the maneuver. It's a different solution for constant attitude as variable attitude as well.

[diomedea]

@ Frederf: You're pretty right. However, I can't really ask KAC to implement the perfect solution as it goes way beyond time calculations.

On split-manouevers, the correct solution requires to recalculate the orbital change with each single burn, and each burn to be applied so to consider the full time of the manoeuver and the end position of the intercept. However, nothing like the above can be asked from KAC, I have yet to find any of the navigation mods with KSP be able to consider a split-man, less so to solve it.

I would rather keep and update a single node for the whole manouever, instead of generating new ones, but this is only a matter of preference.

About long-durations, this is another aspect that KSP doesn't seem to me accurate enough. Speed should be integrated along the burn, while mass is decreasing with fuel expenditure and therefore acceleration increases. There is no simple solution to this navigation problem, integration over burntime is the way serious tools go. Instead the whole KSP model for calculating trajectories seems to me to account only for the end-result (final speed, final mass).

Lacking better tools with KSP, it would be enough for me that KAC provides for the approximate 50/50% before/after the node. That alone would be accurate enough for at least 90% of those manouevers where time of burn is really relevant.

[Frederf]

There might be a second order approximation which is short of a full numerical solution but for TWR > 0.05 or so the first order is plenty good.

[Andersenman]

Hello,

I have tried to find an answer in this thread, but it either isn't there or I failed to comprehend given info. Anyhow: Can KAC handle multiple nodes along the same ship's orbit, eg. a transfer and a mid-transfer plane change? If so, how do I save those subsequent nodes?

Thanks!

A.

[TriggerAu]

Hello,

I have tried to find an answer in this thread, but it either isn't there or I failed to comprehend given info. Anyhow: Can KAC handle multiple nodes along the same ship's orbit, eg. a transfer and a mid-transfer plane change? If so, how do I save those subsequent nodes?

Thanks!

A.

Hi Andersenman, When you create a ManeuverNode alarm the KAC will save all the nodes on the current flight plan, setting the alarm time to the time of the first maneuver. So if you set up your planned flight maneuvers and then create the alarm it will save the sequence for you with the reminder at the first one.

[TriggerAu]

As I'm trying to add successfive 20m/s boosts to an escaping probe it dawns on me that I'd love if KAC would allow me to select the alarm actions completely independently of each other: Message, warp 1x, pause. Right now it's a radio button but if they were checkboxes I could have 1x warp without message, pause without message, etc. I use KAC as a "warp to x" often and I don't need to click "delete on close" and have a message. It's just been a few seconds since I created it and I don't need a reminder.

This behaviuor should be easy enough, although a pause alarm without a message seems a bit weird, I'll certainly look at a killwarp with no message option. consider it added to the list

[TriggerAu]

Thanks for your attention towards my proposal.

If I understand you correctly, you would like to implement a calculation of the burn duration (meaning to know mass of the ship, thrust of the engines and the speed change required). That would certainly be outstanding, as I see the KSP stock game itself being erratic in showing such value. If you can get a correct burn duration, then you can also implement correctly the countdown to the node (what I was asking, but probably I was not clear enough) as the time left before the node (current time minus time of the node, both perfectly known already to your mod) minus half the burn duration (this last term I have never seen considered in stock KSP countdown).

Now, if you are going to calculate the burn duration, you may also make this a perfect tool by including a warning that a split-manouever is required (another thing totally lacking in KSP). A split-manouever must be done whenever the burn duration is too long compared with the orbit period (generally the case with low-thrust engines) so that a single continued burn would also be applied at a wrong position; instead the total burn duration must be split to occur in a number of orbits, always at the same phase. In case of a split, the node must not be cleared until after the last portion of the burn, and possibly an alarm should be re-created after each partial burn to warn for the time of the next.

The previous investigation, and what a few people asked for was the alarm margin to be set at "burntime/2 + a minute". I will work for that to start with, and then see how many variations are possible without cluttering the interface too much.

[Superfluous J]

The previous investigation, and what a few people asked for was the alarm margin to be set at "burntime/2 + a minute". I will work for that to start with, and then see how many variations are possible without cluttering the interface too much.

If I had to choose between a raw time of X (what we have now), burn time/2 + X (where X is settable in the same way that the raw time is settable now), and an option between both, I'd pick both first, then pick burn/2+X, and finally pick raw time as the least desirable. Raw time is not very useful when sometimes you have 2 second burns and sometimes you have 15 minute burns.

Could you just add a radial button, default off but changeable in the defaults, for maneuver alarms to change it from raw time X to burn/2+X ?

(And making sure you know that this is a suggestion to my most used and relied-upon mod, that I don't think I'd enjoy playing KSP nearly as much without. I'm only desiring more because I use KAC *so* *much*!)

[saskwach]

Player.log it is! Confusing that it's in a different place and it has a different name, but I guess that's why I couldn't find it. Anyway, this one has a seg fault and stack dump:

Stacktrace:

at (wrapper managed-to-native) UnityEngine.Texture2D.LoadImage (byte[]) <0x00069>

at (wrapper managed-to-native) UnityEngine.Texture2D.LoadImage (byte[]) <0x00069>

at KerbalAlarmClock.KACUtils.LoadImageIntoTexture (UnityEngine.Texture2D&,string) <0x0003f>

at KerbalAlarmClock.KACResources.loadGUIAssets () <0x00043>

at KerbalAlarmClock.KerbalAlarmClock.Awake () <0x00067>

at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0x00059>

at (wrapper managed-to-native) UnityEngine.GameObject.Internal_AddComponentWithType (System.Type) <0x00069>

at (wrapper managed-to-native) UnityEngine.GameObject.Internal_AddComponentWithType (System.Type) <0x00069>

at UnityEngine.GameObject.AddComponent (System.Type) <0x00017>

at AddonLoader.StartAddon (AssemblyLoader/LoadedAssembly,System.Type,KSPAddon,KSPAddon/Startup) <0x00203>

at AddonLoader.StartAddons (KSPAddon/Startup) <0x00237>

at AddonLoader.OnLevelWasLoaded (int) <0x00017>

at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___int (object,intptr,intptr,intptr) <0x00067>

Native stacktrace:

/home/nathan/ksp/KSP_linux/KSP_Data/Mono/x86_64/libmono.so(+0x92c92) [0x7f2996a84c92]

/home/nathan/ksp/KSP_linux/KSP_Data/Mono/x86_64/libmono.so(+0xd000d) [0x7f2996ac200d]

/lib/x86_64-linux-gnu/libpthread.so.0(+0xf210) [0x7f299ae7a210]

./KSP.x86_64() [0xbceca3]

[0x7fff6f38c9c0]

There's a bunch more info from gdb in the the full file. I'm pretty sure I've used older versions of KAC, but with older versions of KSP. Is there an easy way to get images for other (compatible with 0.22) KAC versions?

[TriggerAu]

Player.log it is! Confusing that it's in a different place and it has a different name, but I guess that's why I couldn't find it. Anyway, this one has a seg fault and stack dump:

There's a bunch more info from gdb in the the full file. I'm pretty sure I've used older versions of KAC, but with older versions of KSP. Is there an easy way to get images for other (compatible with 0.22) KAC versions?

Well thats Good and Bad. Good that we found it, bad that its KAC

I might ping you an edited version of KAC that has way more debugging in it and we can see if its one image in particular or just the UnityEngine.Texture2D function, or the byte array now that I think of it.

You can find old versions (including all the images) etc on the codeplex site - http://kerbalalarmclock.codeplex.com/releases/view/114542 .

[diomedea]

I have looked at burn time as a margin for an alarm before, but got lost trying to work out the vessel structure and maths. I am working on another small thing at the moment though that involves learning the vessel stuff, ....

Sorry if I get back on the above. I have no idea what "another small thing" you working on. But for all purposes related to burn time (unless I miss something), we only need to know TWR and mass, or the acceleration (from the previous two). Unless you want a finer degree of precision and also account for variable acceleration over time (due to diminishing mass, therefore need to know the rate of fuel consumption from the active tanks), all you need is actually calculated and displayed from tools like MechJeb, VOID or KER.

My question here is: wouldn't be possible to interface KAC with one or more of the above tools, so to extract acceleration from them and use that value to get burn time? Of course, checking the presence of one of those tools before, so this "added" precision benefit comes with the instalment of them?

[saskwach]

Well thats Good and Bad. Good that we found it, bad that its KAC

I might ping you an edited version of KAC that has way more debugging in it and we can see if its one image in particular or just the UnityEngine.Texture2D function, or the byte array now that I think of it.

You can find old versions (including all the images) etc on the codeplex site - http://kerbalalarmclock.codeplex.com/releases/view/114542 .

Great, I'll be around tonight (EST...probably morning your time) to try things.

By the way, I meant images in the sense of binary images, not graphics If you don't have anything new and more verbose for me to try, I'll start a binary search on old versions.

[TriggerAu]

Sorry if I get back on the above. I have no idea what "another small thing" you working on. But for all purposes related to burn time (unless I miss something), we only need to know TWR and mass, or the acceleration (from the previous two). Unless you want a finer degree of precision and also account for variable acceleration over time (due to diminishing mass, therefore need to know the rate of fuel consumption from the active tanks), all you need is actually calculated and displayed from tools like MechJeb, VOID or KER.

My question here is: wouldn't be possible to interface KAC with one or more of the above tools, so to extract acceleration from them and use that value to get burn time? Of course, checking the presence of one of those tools before, so this "added" precision benefit comes with the instalment of them?

It is possible to use other Mods - with whatever permission is needed of course - but I know that some people have very strong feelings about MechJeb, that I'd rather avoid getting in the middle of. That and I like a challenge

The other Mod I am working on is an alternate resource panel (ie the thing you get in the top right hand corner), to do that means I need to pull apart a vessel and understand staging, and that "should" provide me the framework to get all the values you mention above.

[TriggerAu]

Great, I'll be around tonight (EST...probably morning your time) to try things.

By the way, I meant images in the sense of binary images, not graphics If you don't have anything new and more verbose for me to try, I'll start a binary search on old versions.

Cool, you should have a PM with a link to a new dll

[diomedea]

It is possible to use other Mods - with whatever permission is needed of course - but I know that some people have very strong feelings about MechJeb, that I'd rather avoid getting in the middle of. That and I like a challenge

The other Mod I am working on is an alternate resource panel (ie the thing you get in the top right hand corner), to do that means I need to pull apart a vessel and understand staging, and that "should" provide me the framework to get all the values you mention above.

Well, thanks for your time and availability. I hope to see your new "alternate resource panel" soon, if that comes out as good as KAC is, it will definitely become a "must have".

Can understand your choice over some other mods. Feelings sometime make things for the worse.

[saskwach]

Cool, you should have a PM with a link to a new dll

pastebinned

[Andersenman]

KAC will save all the nodes on the current flight plan

Ohhh, thanks! I never even noticed!

Best,

A.

[Commander Zoom]

Just wanted to say that the 'restore node' feature makes an already great mod absolutely wonderful.

[Dweller_Benthos]

Had another of those wonky escape trajectories where Kerbin kept catching up and KAC kept adding new SOI change alarms. Here's the quick save file, go to the "Laythe Lander" ship. It's popping in and out of Kerbin SOI, or it should be, at the save point. Had a bit of a mishap with staging and messed up the escape plan.

http://www./download/pua5vhdajf7j37u/quicksave.zip

Mods loaded:

EnhancedNavBall

Innsewerants Space Agency

MechJeb2

Protractor

Romfarer

SCANsat

Squad

TriggerTech

VibraDyn

voneiden

Wayland_Corp

Though the only ones that should effect loading this ship are MechJeb, Protractor, VibraDyn, and SCANSat. I think. Vibradyn is a SCANSat alternative.