Pontiac

I'd like to dissect that... That'd entirely depend on the wording in the licensing, and whether or not I already possess a previous version. I haven't read the EULA (Who has?) but just by effect, Squad has posted a link to 0.19.x right in their store. So I would say, by example of their lead, that that I've been given the right to play both 19 and 20, which (doesn't necessarily mean) that once Squad provides it on the store, and permits me to download it, then I'm justified in playing it. PREVIOUS versions to what is on the store, however, are not legally accessible, so unless I've already downloaded and installed it, and archived it somewhere for my own personal use, then no, I'm not entitled to it. Basically, if Squad has not ever, or, does not currently give it to you directly, you're not entitled. I also don't recall any mention on how many computers I can install and run it on. Literally, I have 6 computers in my household, 5 of which I own (One is my wifes, three of which the game is installed on) all that have the gonads play KSP. Does the license indicate that I can play on only one machine at a time, or, does it mean that I can only play on any machine I can access (Which opens me up to 2 more computers), or does it mean I can only play on any machine I gain access to at one time only, or does it mean that I can only play multiple versions of one game at one time on one computer? If its stipulated somewhere, great. If not, I'd say its open to interpretation, but then again, IANAL. Left of the comma, not true. Right side, true. For the left part, 0.19 is available on the store. But my next question is for the users who have transferred or purchased the Steam version. Inherently, I don't think Steam will allow you to go back in time to a previous version, so I wonder how these people would be affected?

Suggested headings: TL;DR: [standard/Non-Standard] Installation Method - If standard, link to the wiki page of how to install a Mod - Non-Standard should give direct instructions Full Description: Screen Shots (if applicable): I have noticed more on SpacePort that there is more and more junk just being pushed up. A lot of it is repeat uploads of the exact same thing, no compatibility version information, or anything. I just walk on by and started looking at the forum threads and subscribe to the ones I'm interested in or use.

LOL! "Lowly people"? hahaha. I'm in the same boat as you man. I'm still learning the nuances of C#.

Just include his license, then add your own. If you weren't going to pick it up, I was going to include his license and my license.

I can think of two reasons they've not plugged it in yet. A> They're busy doing other things B> This tool exists already, so, why plug it in when "A" exists?

If Fish doesn't want to, I will.

@DYJ> I think he messed up looking at your "Join Date" instead of your message archive.

Forgetting about this code in its entirety, pending a hardware failure of some sort, a computer will do only what it is told to do, so what happens in game is based on code, and how it interacts with each other, and what input it presented to it from the user, calculated, or external sources. Everything it does can be traced back and get a reason as to why it did what it did. To me, what you said sounded like the code is just making things up as it went along, but I know you didn't imply such a thing. The software will act only on certain inputs and conditions, and the conditions during your testing yielded the results you've come up with, which differed from mine, and my experiment was due to missing information. The testing I did didn't produce the same results you got when I ran my 8 scanner probe at 100x. What you're seeing at your end is happening for a particular reason due to the code, not because of some magic that is going on in the background. (Well, honestly, how computers work at all is still magic to me...) Majiir brought up something that I wasn't aware of which is going to cause me to cede defeat, and why it looked like my 8 scanner setup didn't work. What happened in my case was I started all the scanners at the same time, so, the events probably were firing at the same time, and I PROBABLY was hitting better than 1fps at 100x, so I was being blocked by the timer duration. Since each scanner operates on its own timer, yeah, I can see how you'd get the better resolution at faster speeds. Yep, I agree. With your comment about cycle times, I checked the code to see when specifically it hits and got slammed with grade 10 math. Staggering is the answer, but the issue that threw me for a loop was, as I mentioned, 1.2 second ping at 2x speed isn't going to equate to 0.6 seconds in real time. So if you hit 100x, the delay between the scans isn't going to be 0.012 seconds, but much MUCH closer to 1 second due to the Log function.

Shouldn't have. Try running a fuel line from the converter to the tank. IT WILL NOT WORK GOING FROM TANK TO CONVERTER.

<offtopic> Just for the record, I've only started diving into C# over the past couple of weeks, but I've been writing code since the Commodore Vic-20 days and have seen and worked in a LOT of languages. Previous to today (Last 12 hours as of this writing) I'd played in C# by debugging some other code for probably a maximum of 5 hours in total, and what I did was mostly "good guesses". Tonight is by FAR the longest I've spent looking at ANYTHING C#. The last time I touched anything that resembled C anything (Standard, +, ++) was over 15 years ago, probably closer to 20 now. I'm by no means anything of a professional at coding in this language as I'm still learning the nuances of this language, but once I understand the language construct, and what code does what when and where, then reading the code is second nature right after I go further to try understand how the author actually writes their code. Knowing what the language does is one thing, but how the author uses and writes the code is another. With the help of Kethane, SubAssemblyLoader, and ActionsOnTheFly, I'm getting the gist of what is going on, and I look forward to tearing into MechJeb, and writing a small mod of my own ground up. I'll also say that these three mods written by three different authors all have given three very different coding styles. </offtopic> Non-Technical: As the Kethane code sits as of about 12 hours ago, (Specifically in KethaneDetector.cs) if you're running multiple ships within the same Physics Area Of Effect (Henceforth PAOE), then yes, I'll grant you that you get better scans, but not for the reasons, or for the mechanics, you're implying in regards to multiple scanners on a single ship. Throwing more than one scanner onto one ship doesn't do anything more at any speed, 1x or otherwise, other than report back how much Kethane is at that geographical location. If you have 2, 4, 8, 16, 32, or 512 on a single ship, the call to update the map is done either once for all ships in the PAOE regardless of the number of scanners equipped per ship, or, once for as many scanners on the ships at that exact location at that time. Regardless of how many scanners you have, you're only in ONE location at each video or physics frame of time. The code specifically looks at the ships current long/lat. The code doesn't adjust left, right, forward or back by any degree. If you have a trailing ship, that ships scanner may update the map on your screen based on its own location if its in the same AOE, and that COULD give a different pixel. So yes, having a scanner on multiple ships within the PAOE might indeed update your map faster, depending on the differences in distance at that time, but going the other way and having multiple scanners on one ship in the PAOE will absolutely not provide any additional information. Technical: [[Just to keep things a bit clear, I'll bold Unity' update routines.]] Unity fires two events that are relevant to this discussion. The first is called Update. This is called every frame update, and then there is the FixedUpdate which is called every physics update. These two events fire at two very different times for very different reasons. The physical map updates are done during the unity event FixedUpdate, which is "...called once every physics time step." -- http://docs.unity3d.com/Documentation/ScriptReference/index.html -- Since physics 'is kind of' turned off during normal time acceleration, FixedUpdate probably gets called right after Update. This mods Update routine looks to be just updating the physical location of the "You are here" icon. Both of these events are called at some point, yes, but in which order, I'm not certain at this point, and I don't think it really matters. How things are handled under PHYSICAL acceleration could be a different story, but I don't think you hit 100x under Physical anyways, but then again, I wouldn't want to really since normal time acceleration yields the same results with less risk. In the situation with multiple scanners within the PAOE, I'm not sure how its handled as of yet. I know multiple MechJebs can do their automation work at the same time so long they're within the same PAOE at 1x. If these scanners work on the same kind of principals as MechJeb I would like to assume that there is one map for the orbiting body, and all scanners just make a call to the proper 'object' that is holding onto that map, and updates the map by drawing the appropriate pixel in memory, there by updating the map you see on screen if it is shown. As soon as I figure out how to write out log files (Which won't be hard I'm sure, I've just never done it in C#) I'll throw some debugging routines in it, have it write out an entry in a log file for each event, and I can tell you exactly what happens when and how often. I'll even throw in the locations scanned, and amount returned. But for now, I gotta get to bed so I can plug away at this particular plugin some more. :]

I figured that since I've got nothing else to do, other than play with Kethane on one of my saves, I'd download the source and see if I CAN apply this. I spent most of my night throwing my middle finger at the screen because I hadn't quite figured out how to create a new variable in C#, but eventually found a decent example, right within this mod. I have successfully managed to get the scanner to show different colors for 0-20% of max, 20-40%, 40-60%, 60-80% and 80%-100%. For 0-20% is uses RGB values of 0%, 100%, 0% and 20% increase in Alpha for each grade, then yellow for 100%. Looks pretty sharp, and its really clear on where to land. However, these are still hard-coded values, so, next step is to learn how to handle the config files.

@Honeybadga> Each location is of a certain radius, so, as long as you're within that radius, you'll be able to mine until its gone. @Sapphire> Having more than one is useless. I had 8 on my most recent, with enough RTGs to power a small city, then time accelerated to 100x, and still got the missing dots. This is around Kerbin and Mun.

What would be nice is to have the ability to change the colors of what is scanned instead of a shade of green. If we could define something either via the UI for amounts between 0-50k, 50-100k, then by 100k range after, it'd make it even more easier to decide where to go once you have a planet scanned. Right now, its white, green and gray. I can't tell though (Running at 100x and getting some pixels instead) if I'm looking at white within some green, or if the whole area is green. Or even with the existing, if we were able to change the grey, green, and white to say blue, bright red, and white, we'd CLEARLY see what is where. Excellent work none the less. :]

Nice treads. Where'd you get 'em?

I think I'm going to de-orbit my current gas station around Kerbin and rebuild with a couple of your concepts around Mun. I've been trying to launch gas tanks up from Mun after refining Kethane, but, I'm running a zero surplus by the time I lift off, get to orbit, align, and rendezvous. I've been using a lot of Quantum Struts to hold the gas tanks that are there in place, but I hadn't thought of using the Sr docking ports. Something to do when I get home. :]

I started to write a story about how the length of time should have been extended, but then I realized that I think you're right, its just hard to wrap my mind around after 10 hours doing a 12 hour shift at work. I'm seriously struggling over the math on how its done, but it kinda-sorta makes sense. I also don't know the methods you're using to calculate the inefficiencies. But working on my theory and numbers, the converter can only do so much work in total, but, each conversion process "probably" doesn't chew 100% of the work load the converter is capable of handling, which means that only a certain volume of Kethane is going to get converted per work cycle. So if we say that converting Kethane to Liquid Fuel or Oxidizer individually uses 95% of the available work load, that 5% becomes idle and a loss for that cycle. In order to keep the converter from over heating running multiple jobs, you have to reduce the amount of work each conversion process outputs in order to maintain the 100% efficiency. So work done for each would be 50% output. Now you're using 100% of processing capabilities, which means that each process gets an additional 2.5% of work. (Taking that extra 5% idle time and splitting it between the two processes). In other words you have 95% of the work load for a single job. When you introduce a second job, you half the 95% which becomes 47.5%. Since one full conversion cycle of Kethane can take more than 47.5% of the work load, we'd get an additional 2.5% work to bring that up to 50%, which means a net bonus to BOTH conversion jobs time wise. The converter is working now working at 100%, you're converting as much Kethane as possible running multiple jobs since now you're not idling the converter. You don't get more or less for your money, but, you do get it faster. Does that make sense?

What SpacePort needs is something that you can filter based on version numbers, show more than 9 items at a time, allow for revisions of files to indicate patches, and indicate when the last time the author was on and actively did something to ANY of the plugins they've posted. If the Author hasn't been on for a certain amount of time, any license agreement put into play regarding modifying and redistributing becomes null and void and an option for the public to submit bug fixes (With source code included somewhere) becomes an option, or, if the original Author wishes, allow for public fixes to be submitted at any time. If the original author does come back, they then would have the option to leave the public fixes in place, or, optionally put them in private mode so they can only look at them, then decide what to do from there. I'd be dumb enough to take that kind of project on. The author specifically stated that the current version is a Dev Build and NOT to be put on SpacePort until he's decided that this version is a completed version.

I use the Lazor system to transfer refined fuels to and from other vehicles. My current all-in-one refinery drinks electricity, and that is with something like 48 RTGs attached to it. I had to build a lander with batteries. With the Lazor system, I just need to be within 500m of my landing spot, and I can transfer what I need to the ship I need.

I went back to the beginning of this thread to find the root of my investigation here. Original thought: http://forum.kerbalspaceprogram.com/showthread.php/23979-Kethane-Pack-0-4-4-Compatible-with-0-20-2-plus-balancing-changes%21?p=334530&viewfull=1#post334530 From "the horses mouth": http://forum.kerbalspaceprogram.com/showthread.php/23979-Kethane-Pack-0-4-4-Compatible-with-0-20-2-plus-balancing-changes%21?p=336635&viewfull=1#post336635 Not a bug, working as intended. I wanted to test the theory of time spent. Personally, I would have figured that getting the inefficiency factor involved would have EXTENDED the time to refine everything at once, instead of reducing. THAT would have made more sense to me, especially when I'm hit with a more than 50% reduction. Now, what I have to do is study which is going to be more efficient. Haul the Kethane in large quantities to space, or, send the refined fuel up. Not exactly sure how I'm going to test the efficiency factor in that. I modified the gas tanks to have docking port jrs at each end of the tank, so I could setup a "train" of tanks, and ships can come by, dock (or I can throw a Lazor system at it as well).

I reran the numbers and I found that running all three at the same time has ZERO bearing on consumption. I ran this at 1x speed just to eliminate the chance of numbers being skewed. I did use 10,000x to fill the Kethane tank though which doesn't affect anything. Drills were turned off during this check, of course. Running a single conversion process used 8,881 units of Kethane. Running all three, started at the exact same time, with the assistance of ActionsOnTheFly, used 8,881 units as well. Capacity Stats for the refining ship: Liquid Fuel: 1400 Oxidizer: 1760 Monopropellent: 400 Kethane used to convert: Liquid Fuel: 3495 (Ratio of ~2.5:1 Kethane to Fuel). Oxidizer: 4445 (Ratio of ~2.53:1) Monopropellent: 941 (Ratio of ~2.35:1) Total: 8,881 When running all three at the same time, I was down to 44.2% efficiency on the converter. When Monopropellent was done, I got up to 82%, and the other two fuels were above 50% complete at this point. The Liquid Fuel and Oxidizer finished at just about the same time. One was ahead of the other by just a few seconds. So what this tells me is that the efficiency factor affects individual processing processing time, but the net result is a shorter time to refine all the fuels when working at once. It was a learning process, for sure. :] I'm all for the extreme consumption of electricity. If you think of it, it takes a LOT of energy to convert one thing into another. If I would have done some simple math, I could have figured the consumption rate of the 4 drills when in use, plus the consumption rate of the refinery, put those together to get a value. Take that number, divide by the power a single stock RTG provides, and slap that many, plus 1, on the hull, and this particular machine is pretty much a stand alone unit that can do mining and refining at the exact same time.

Quick Save and Quick Load are your friend. I had a situation where I had a ship in orbit, and was getting ready to burn for the Mun. It had 5 large orange tanks, 5 mainsails, 3 large RCS tanks on top of the center tank, and my payload. F5 for quick save. The window for transfer opened up, full throttle, BLAMO, the thing exploded. I said "WTF" in long format and out loud. Quick-Load, lined up, full throttle, no problems.

I found this bad boy online somewhere. I feel guilty for using it for a simple capsule though but Jeb insisted.

I'd still rather have wheels... But this is quite inventive. :]

At launch, head directly north or south. Once in orbit, adjust to the desired angle.

I've stopped leaving my computer at home, and lug this mammoth machine to work with me. I've stopped caring that Google Reader is going to be stopping services. I've stopped playing mind numbing games that don't offer anything other than action. However, all of my CPU cores are busy. 1 is playing KSP, the 1 is handling YouTube in Chrome, the other 6 are handling a Virtual Machine. I've filled my 12gig of memory with KSP and a new development virtual machine I've built for learning on how to make plugins and working with 3D models. KSP takes up one of my 4 monitors, 2 for the VM, the 4 used for general browsing, YouTube, and possibly a video while I'm trying to figure out why Debug.Log doesn't work and the rocket I just launched self destructed at 20km up.