nuclearping

Thanks. Works.

Same here. KSP 0.24.2 Kethane 0.8.8

Awww, thanks. That was the problem. Didn't scan for Ore. I was thinking that a Kethane hex is also an Ore hex. Works now.

Is there any tutorial or "How To" for the Mining / Smelting / ... part? I watched an old video from Scott Manley where he brings a Smelter with an Auger, Solar Panels, etc. to the Mun, landed it on a Kethane field and started mining. But when I do the same the Auger does not extract any Ore. It is attached directly to the Smelter, it has plenty Energy and the Auger goes into the ground. I already tried Baha's drills, same result. What I'm doing wrong?

I can't download the patch from my Account Page at KerbalSpaceProgram.com Getting the error: Warning: session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /host/www.kerbalspaceprogram.com/htdocs/lib/config.php on line 9 Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /host/www.kerbalspaceprogram.com/htdocs/lib/config.php:9) in /host/www.kerbalspaceprogram.com/htdocs/lib/config.php on line 9 Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /host/www.kerbalspaceprogram.com/htdocs/lib/config.php:9) in /host/www.kerbalspaceprogram.com/htdocs/lib/config.php on line 9 Warning: Cannot modify header information - headers already sent by (output started at /host/www.kerbalspaceprogram.com/htdocs/lib/config.php:9) in /host/www.kerbalspaceprogram.com/htdocs/lib/multiplayDwn.php on line 11 Invalid Token Edit Actually it seems that no download is working at the moment. Edit 2 Works again.

Oh. Thanks for the quick reply. Didn't know 0.23.5 was out and causing the issue. Will use the v2.1 instead. Thanks.

Using KSP 0.23. After installing the latest KJR from the SpacePort (http://kerbalspaceprogram.com/kerbal-joint-reinforcement/) I can't launch any craft anymore. What happens is that when I launch a simple craft (Pod -> Fuel -> Engine) the engine fires but the craft doesn't move an inch. When I launch another craft (Pod || -> SBS || Fuel || SBS -> Engine) the same happens. When I decouple the SBS (while still firing) they lift off, flying away. When I then decouple the Pod while the main Engine is still firing, they (Tank + Engine) go through the Pod and the Pod sticks in the air, not dropping down, nothing. When I open the Debug-Console (Alt+F2) I see alot of red "NullPointerReference" errors and in between some other exceptions saying "Could not load PartJoint", which is a reference to the KJR plugin. When I remove KJR everything works fine again. Thats my mod (directory) listing: 09.02.2014 10:00 <DIR> 000_Toolbar 13.02.2014 00:15 <DIR> ActionGroupManager 01.04.2014 23:52 <DIR> B9_Aerospace 31.01.2014 21:45 <DIR> BoJaN 02.04.2014 00:03 <DIR> BoulderCo 31.01.2014 21:45 <DIR> CrewManifest 01.02.2014 18:34 <DIR> DeadlyReentry 02.04.2014 22:04 <DIR> Engineer 06.02.2014 06:32 <DIR> EnhancedNavBall 01.02.2014 17:01 <DIR> EVALoading 01.04.2014 23:51 <DIR> ExsurgentEngineering 01.02.2014 16:23 <DIR> FerramAerospaceResearch 02.04.2014 00:03 <DIR> Firespitter 02.04.2014 00:00 <DIR> GenesisRage 01.02.2014 15:19 <DIR> HexCans 31.01.2014 21:46 <DIR> HrmHaystack 31.01.2014 21:51 <DIR> KAS 31.01.2014 21:46 <DIR> Keramzit 31.01.2014 21:40 <DIR> Kethane 01.04.2014 23:51 <DIR> KineTechAnimation 04.02.2014 01:09 <DIR> KSPCalendar 07.02.2014 01:53 <DIR> KWRocketry 08.02.2014 10:31 <DIR> MagicSmokeIndustries 23.02.2014 16:39 <DIR> Nereid 31.01.2014 21:46 <DIR> NewHorizons 31.01.2014 21:46 <DIR> RBR 07.02.2014 01:49 <DIR> RemoteTech2 01.04.2014 23:51 <DIR> ResGen 31.01.2014 21:46 <DIR> SelectRoot 31.01.2014 21:24 <DIR> Squad 31.01.2014 21:47 <DIR> StationScience 04.02.2014 23:08 <DIR> ThunderAerospace 01.02.2014 15:19 <DIR> TreeLoader 11.02.2014 19:20 <DIR> TriggerTech 31.01.2014 21:47 <DIR> UbioWeldingLtd 01.02.2014 16:46 <DIR> VNG 01.02.2014 15:19 <DIR> WarpPlugin Anyone any idea?

Ah, sorry for late response. Didn't think anybody is going to respond here anymore. @diomedea: Well, from the mathematical point of view it is a quick-change, sure. You only need to make the 11700s available to be changed by the user. But how does the user "visually" pick the zone for the timetracking? You know what I mean? The most simple (and user-unfriendly) way would be to offer another edit field where the user either puts the offset-seconds, a 360° digit or a longitude. But I don't like that idea since it is very unintuitive. You know the Landing AutoPilot from MechJeb? If you click "Pick Target on Map" you get into map view and can select the place to land with a nice crosshair. That would be great for the user. But I don't know the efforts (code-wise) to do that and I'm not sure if I want to figure that out at the moment. @mjukis: Thats a good point. @Gaiiden: Can you give more details on how you think a list of significant dates could have been integrated with the Final Frontiers mod? It would have been just a list of "Initial Dates" to pick from to set the Calendar's starting date. But you still can freely change the initial date in the settings window. No, it doesn't affect the game clock. But thats an idea I might try figuring out. And yea, you're right. I also don't know why Kerbin's revolution period is some 106 days, but the game clock counts 365 days ...

Good idea with the empty file. Will do that next time.

Because they told me I get Snacks when I do so. But they were not handed over yet ... Look here: http://forum.kerbalspaceprogram.com/threads/68270-0-23-Kerbin-Date-Calendar-%28Version-1-3%29?p=958721&viewfull=1#post958721 I don't want to relocate it yet because usually people who already use the Plugin will forget to delete the old DLL file from Plugins. And unless it works I don't see any problem. Do you?

Updated the Plugin with the latest changes. I tried to implement this but it doesn't work out very well. The text becomes very hard to read, kind of itchy in the eyes, if you put it in purple / pink colors. So I tried to put it in some yellow-colors, like Gold for the sunrise, Yellow for daytime, Orange for sunset and black for night. But you hardly see any difference in the colors, except from night. But at night when he is supposed to draw a black text he only draws a black text but without the window box around it. So it is only blank black text on the game screen. Weird ... So I reverted it. Friend says "You're welcome". Friend also found out about that the value in the Wiki was rounded. Thats also what caused the deviation. From the experimental point of view this is interessting, yes. But from the practical pov: Who would want to use this? Unless you want to "colonize" Kerbin or so ... Displaying the local time at KSC is what I wanted. So I'm fine for now. But feel free to use the code to experiment with it if you want.

We got it. Friend had a look, made a suggestion and voilá ... Formula works. He is always like that ... From my testings so far it is even daunting accurate. I Time Accelerated to 100'000 several times for several seconds and could even see the shadow of the night side moving on Kerbin and we still hit sunrise at 06:00 and sunset at 18:00. Pinpoint accuracy. The final formula is: dblUniversalTime = (dblUniversalTime + 11700.0 - ((21600.0 / 9203544.6) * dblUniversalTime)) * dblKerbinTimeScaleFactor The major issue was just rounding ... thats all. Friggin' rounding. With the .0 we tell the compiler that we always want to have floating point precission during the whole formula.

Ok, I did some quick tests. Summary: It doesn't matter what "correction time" (K) you use together with the formula. The more the game advances in time, the more inaccurate it still gets. I made an editable config field for the Correction time K (like for Kerbin factor). When I loaded my game I needed to correct the value to 23450 to have a sunrise at 06:00. Then 11 days later sunrise was at 06:47 so I had to change K to 22900 to be at 06:00 again. It seems like there is either some variable missing to balance this (you said 4° a day?) or a variable already too much.

Yes, it is not "non-important". Using Earth's calendar doesn't work here. Will be fun to program a calendar having 35 / 36 days. But that comes least. As I said: For the "simple 3.991" formula I used a fixed Initial Date / Time of ... 13:00:00 to get decent results. Although it should be covered by the 11700 seconds, I suspect that maybe the 13 hours should not be divided by 4 to get "Kerbin" 13 hours (11700s) but real 13 hours (46800s) instead. Because the previously used "hardcoded" 13:00:00 initial time was not influenced by the "Kerbin factor". And that would kinda explain the 13-hours offset we have now and maybe also the increasing offset each day. I gonna test it later. Sure, good idea.

It will. Sorry for the late response. Spend my freetime rather playing then thinking. I asked my buddy if he wants to have a look on this. Regarding the date and calendar: Yea, you're right (once more ). But "date" doesn't really matter at the moment, or at least it is not top-priority, as it shouldn't have any impact on the time. Main problem is to figure out where the time deviation comes from.

No, the 3.991 is just the initial value. He uses the value from the config, otherwise if he cannot convert it somehow he uses the 3.991 as fallback: try { dblKerbinTimeScaleFactor = Convert.ToDouble (strKerbinTimeScaleFactor); // <== Set in the config window } catch(InvalidCastException) { dblKerbinTimeScaleFactor = 3.991; //(24 / 6); // Fallback } So if you installed the plugin make sure you set "Kerbin factor" to 4 in the config window. Sure, you're welcome.

Remarkable. I just played around with the numbers and found that 3.991 is giving me the most accurate results, but for that I had to set the Initial Date to 01.01.1980 13:00:00, which probably also got rid of the ~13 hours offset we have now. However adding the 11700s should have kind of fixed that too ... So it is a bit confusing. Leap years are being handled by DateTime correctly, so that could explain the +/- 1 day, but as said before it shouldn't affect time in any way. I will ask a good friend of mine if he may want to have a look on this. He's really great and enthusiastic about mathematics. So I guess we could figure it out together. Here is the current WiP source: https://dl.dropboxusercontent.com/u/16274518/KSP-Calendar-1.2_WIP.zip The function of interesst is CalendarFunctions.cs private void getCurrentKerbinDateTime()

Hey, thanks for the clarification for point 3. I didn't think about that. The whole small thing becomes quite complex, but also quite interessting tho. I also don't know where the display-issue comes from. dtKerbinInitial is just the date from "Initial Date" which you can see in the settings window, "01.01.1980 00:00:00". So thats our "entry point" in the year. But after changing the code to subtract the fraction now and loading the savegame it looks like we are ... 1) like 13 1/2 hours off. I have sunset at 04:30 and sunrise at 16:30 ... 2) the more the game advances in time the more the offset grows. If I time-accelerate day by day to check the sunset / sunrise times, I'm at 4:55 sunset and 16:55 sunrise after 5-6 days or so. DateTime.AddSeconds handles the date and time by our real world calendar according to your regional and language settings. So if you initialize DateTime with 01.01.1980 00:00:00 for instance and execute DateTime.AddSeconds(3600) you will get 01.01.1980 01:00:00 as result, because you just added 3600 seconds = 1 hour, DateTime.AddSeconds(86400) will result in 02.01.1980 00:00:00 because we added 24 hours, etc. So the Date may vary a bit, but this shouldn't affect Time at all ...

Yea, thanks, I got it. Also implemented it. I drew a picture to see if I understood you correctly: Basically for one full "sidereal" rotation Kerbin needs 9'203'545 seconds and this causes an "additional" day per year, right? So to balance this in my calculation, I have to add a fraction of the passed "sidereal" day to the universal time, right? private void getCurrentKerbinDateTime() { double dblUniversalTime = Planetarium.GetUniversalTime(); // Get passed time in Universe since game started (in seconds) double dblKerbinTimeScaleFactor = 4; // 24 / 6 dtKerbinInitial = dtKerbinInitial.Date; // Strip time from Initial date since we add our own time dblUniversalTime = (dblUniversalTime + 11700 + ((21600 / 9203545) * dblUniversalTime)) * dblKerbinTimeScaleFactor; dtKerbinCurrent = dtKerbinInitial.AddSeconds (dblUniversalTime); } So what I now do here is: Kerbin_UT = (Passed_UT + 11700s + (21600s / 9203545s) * Passed_UT) * 4 Passed_UT = 3969694s (in my save game for instance, so we are like half a "sidereal" day in the game) 11700s = If you create a new game you start somewhat after noon, like 13:00. So we add 11700s (13 / 4 * 60 * 60) to midnight. (21600s / 9203545s) * Passed_UT = We need the fraction of the passed sidereal day. 4 = Kerbin's day (relative to Kerbol) is 6 hours, so the day passes (24 / 6) times faster. Kerbin_UT = (3969694 + 11700 + (21600 / 9203545) * 3969694) * 4 Kerbin_UT = 15'962'842s (rounded from 15962842.24486542957088817406771) Hence from calculations we should be somewhat at 184d 18h 7m 22s in the game. But as you can see in the screenshot we're still off ... The date is somehow correct, but the time is really screwed. It is like 22:30-23:00 at KSC, but the clock shows 07:46. I know the time automatically comes from all the other calculations. So the mistake must be somewhere out there ... Any idea? If you mean Infernal Robotics: Yea, I'm using it aswell but didn't encounter any sort of issues.

Thanks for your explanation. I would really love to try it. But sorry mate ... Can you explain it again in a way so that dumb people like me, who always had bad notes in Mathematics at school, can understand it?

I updated the Plugin. I found an issue in the "Kerbin time scale" calculation. In the long run the date & time go awfully inaccurate. Like it is late at night at KSC but Calendar shows ... 14:37. So my tests have shown that either Kerbin doesn't rotate exactly 4 times faster or there is some sort of (floating point) inaccuracy occuring in the long run. However I found that a fixed Time Scale factor of 3.991 does a pretty good job instead. So I added an option in the configuration window to let you play with it. But with an Initial Time of ... 13:00 and a Kerbin factor of 3.991 I'm getting quite accurate results. As I said, it is my first plugin / addon. I basically followed the tutorial at http://wiki.kerbalspaceprogram.com/wiki/Creating_your_first_module ... Had no idea that this is important? However, it works.

Alright. Thanks for the feedback.

Hello Squad! I'm writing this here because I tried to email support@kerbalspaceprogram.com and the mail bounced with the message: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: rob@squad.com.mx (ultimately generated from support@kerbalspaceprogram.com) SMTP error from remote mail server after RCPT TO:<rob@squad.com.mx>: host mx.squad.com.mx.cust.b.hostedemail.com [64.98.36.4]: 554 5.7.1 <rob@squad.com.mx>: Recipient address rejected: user rob@squad.com.mx does not exist There are two problems with Kerbal Space Port "My Add-ons": 1) When you create a new Add-on you will get an error message after submitting the form, even tho everything was filled in correctly. However, despite the error message the addon was still added to the database and published on the site. Thats also the reason why you see such a huge amount of the same addons when you browse the "New Addons" pages. 2) You cannot delete your own add-ons in the "My Add-ons" site. If you click "Delete" you get a message saying that the addon was deleted but after the page reloaded the add-on is still there. These problems occur regardles of the browser used. Thanks for investigation!

Actually it was a pretty good question. Because it gave me the idea to implement a "Kerbin time scale" feature into my plugin, by multiplying the KSP Universal Time by (24 / 6) = 4,333..... It looks like if you start a (new) game, you will be starting at noon. So if you set the initial date of the plugin to something like 1980/01/01 12:00:00 and enable the new "Kerbin time scale" feature you will have sunset at 18:00, sunrise at 6:00 and noon at 12:00. Pretty cool. Edit - Forgot to add: This also works with savegames, since the passed time since game was created (Universal Time) is added to the Initial Time of the Plugin.

Updated. Added.