TriggerAu

Thanks for the thoughts/tests, I hadn't thought of Compression So basically the way the new loader is converting the files to textures adds some compression, and without any way to control that I'll need to go back to the previous method. Sound right?

Just to go back to this one as it has been bugging me - Have found that even at the highest quality there is some form of blurring occurring with the loading of the images via the gamedatabase. Have posted a separate thread to see if anyone knows why this might happen, but have also tested reverting to KSP.IO based loading in the new structure (which works and doesn't blur at any texture setting) and may end up having to revert that one piece of code. For those interested - http://forum.kerbalspaceprogram.com/showthread.php/35256-A-Question-about-Textures-and-0-20-blurring

Hi, In the Kerbal Alarm Clock I use a number of png's as textures for buttons. I noticed in the change the 0.20 and above that there appears to be some graphical blurring occuring in the textures. I have narrowed it down to the way the textures are loaded and have the below. I used to load the textures by reading the png contents to a Byte array and then using the Texture2D.LoadImage() function with the Byte Array When I use the pngs as loaded by the GameDatabase using GameDatabase.Instance.GetTexture("Texture1",false) I can see blurring occuring of the texture even when the game is set at the highest settings * Easier to see if you zoom in a bit, particularly on the left most image and the DN arrow. Does anybody have any idea about why this is occuring and if there is a way for me to get "unaffected" Textures to use for Buttons? (The pngs are all 24bit color, and pretty small)

Orbital Mechanics for me as well - and a scary amount of it

Thanks for the update SkyRender. This is great to know, and makes a lot more sense than some form of random hardware issue.

There was a pretty robust debate going on this recently http://forum.kerbalspaceprogram.com/showthread.php/32294-Attention-modders-If-you-could-please-standardize-your-uploads For me I did have the folders at the root initially - like 20 versions ago - but found this from the Capt'n http://forum.kerbalspaceprogram.com/showthread.php/11421-Packing-your-project-for-distribution and changed it to include a version folder. The instructions on the web site, Spaceport and the readme (as below) all cater to the Capt'n's guidelines Not everyone does it the same way though (eg. Romfarer does it this way for all his Lazor stuff, r4m0n did for Mechjeb1, but not for 2, others not at all), and now some people include the gamedata folder so you know thats where to start and others don't. I think I'll keep it how it is for now with the instructions, and wait for the dust to settle on 0.20. And I spent sooooo long on the instructions with the pics on the site too

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.

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) ?

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.

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.

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

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

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 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

I love this tool. It is soo useful and the graphic makes it easy to visualise the idea of it being a window to transfer and what the effect of missing it will be. Kudo's alexmun, many kudos.

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. 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.

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?

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.

Some indications from a number of people show that the new KSP loading system "may" be using this method for resource loading - So "maybe" this is the new default system, thus SkyRender's comments. For more you can read http://forum.kerbalspaceprogram.com/showthread.php/32897-Excessive-start-up-loading-times - most reports from these people show the same behavior seen in my first post. Yes, I know theres some assumptions here, that do need to be confirmed.

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

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

Went through and reviewed a bunch of the slow down stuff outside the code posted above, and ..... v2.1.1.0 is now on Spaceport Fixed an issue where Alarms that were set to Pause the game, would not slow down before hand and would just halt time after the alarm time had passed. These now slow down like the warp affecting ones (and as they used to in the past - no idea how I toasted that ) Thanks Bizz for the details that helped me find it, and let me know if this doesn't fix what you saw.

It "should" actually do this slow down already - expected behaviour is: every 1/4 of a sec it checks the UT and projects what the UT will be in 1/2 a sec at the current warp. If in that 1/2 a sec it will pass any alarm time it reduces the warp one step at a time, until when it passes the UT of the alarm it then displays the message and pauses if thats whats set. Double TimeNext = KACWorkerGameState.CurrentTime.UT + SecondsTillNextUpdate * 2; if (TimeNext > tmpAlarm.AlarmTime.UT) { tmpAlarm.WarpInfluence = true; KACWorkerGameState.CurrentlyUnderWarpInfluence = true; KACWorkerGameState.CurrentWarpInfluenceStartTime = DateTime.Now; TimeWarp w = TimeWarp.fetch; if (w.current_rate_index > 0) { DebugLogFormatted("Reducing Warp"); TimeWarp.SetRate(w.current_rate_index - 1, true); } } I could well have something wrong outside that piece of code though thats not right . Can you let me know what kind of alarm, what the action is for it, etc. Or even better you could PM me your save file and KAC config and alarms and I can hopefully see it first hand

How about an alternative to wildcarding. What if you made it so it could target based on other attributes. eg. @Part[VesselType=Probe] - then for example your remotetech cfg file could be much more compact. Would also help for say adding Flight Engineer to all commandpods, or other things like that. Just a suggestion/idea. BTW. This is a great mod and it has made installing things for me much easier. Thanks

Thanks Castun, I need to do a tweak for 0.20 soon so I'll adjust that then

I almost never dream of kerbals now either... I do like the idea, just need to visualise how to fit it in nicely