elfindreams

Something is ... off ... a tad. Specifically, I am having this strange issue where switching from a ship to the space center then back to the ship, it fills back up its tanks. I noticed my munar mission had a lot more deltav than I had originally planned out when I got back. So what I did is created a stock ship with stock parts untweaked. Just a tank, rocket and capsule. Locked it in place with the support struts and burned off a quarter of the tank. Pressed escape, went to space center, then went to the tracking station, clicked on the ship and selected fly. It took me back to the ship still on the pad now with full fuel. I double checked I didn't have the infinite fuel cheat set and in case you are wondering this happens to ships not on the launchpad as well. I then removed tweakscale and repeated the whole process and when I came back to the ship it still had a quarter of its tank missing. This Link: https://docs.google.com/a/elfindreams.com/folderview?id=0B8a1K8EUgZmVSlIydkpIa1JYMVk&usp=drivesdk Has a quicksave with the ship on the pad, the log files both with and without tweakscale. If it matters, I am running the new 64 bit version.

Ah, that's a neat feature... I hadn't thought that was what it was... cool. Probably is working as intended then.

Huh, it must be conflicting with something, I just put out a craft with a couple of goo, a couple of materials labs a command module and a kerbal onto the runway where I know I have done no science whatsoever. No alerts. I then tried to run the experiments and got data from them all. EDIT: on a lark I disabled SCANsat Integration and everything is working including the munar EVA reports.

So I just decided to install the plugin (just found it) and got my first alert on a crew report available... awesome. But I also noticed I was getting no EVA reports despite having a bunch of EVA that needed to be done and after testing I was definitely passing over areas where EVA needed to be done. So I quit out, started up a new session, went to a ship that was in orbit over areas I needed to EVA time warped for a while, then saved and quit out. The KSP.log, output_log.txt, settings.cfg (from the plugin) and savefile are available: https://docs.google.com/a/elfindreams.com/folderview?id=0B8a1K8EUgZmVczBjZzNXc3JiQzg&usp=drivesdk So the plugin is definitely /working/ but just not on the EVAs.

Ok, false problem (sort of)... still not sure what caused it but here are the steps I took to diagnose (and ultimately "resolve") the issue in case someone else has the problem: First I did my normal remove related mods one by one until it works and then add the rest back in. Conclusion: I couldn't run Mechjeb (latest) with the Toolbar (latest) at the same time, either worked alone but not together. I then set up a new GameData directory with just SQUAD, NASAmission, Mechjeb and Toolbar Conclusion: They both worked. I then added in all the rest of the Mods (except the ones I knew didn't work) to the new GameData Conclusion: Everything worked. I then copied over all my config files from the old GameData into the new gamedata (resulting in what /should/ have been an exact copy of the old GameData in a round about way) Conclusion: Everything worked. So basically there must have been something borked about my old GameData but gods only knows what.

I too am having a hairy problem with this one. On x32 it seems to work (I haven't loaded my savegame to be sure, but it gets to the main menu) On x64 it crashes prior to the main menu with a "KSP_x64.exe has stopped working." (no crash folder) The output_log.txt and KSP.log are here: https://docs.google.com/a/elfindreams.com/folderview?id=0B8a1K8EUgZmVTkRRVTRfYTgyaWc&usp=drivesdk Nothing jumps out at me. Disabling this mod and everything loads (with the inevitable soft errors for those mods that try to link to the toolbar .dlls). Probably a dependant mod but which one? (I do use a lot of mods )

It is already Kethane compatable... you can find Kethane and ore in asteroids with this mod.

Ooooh Tri-Hex struts, nice... can't wait to see them. Hexcan for all of its simplicity is one of my favorites.

It looks like he uses CCPL https://github.com/Greys0/HexCans/blob/master/LICENSE.txt Which I think means yes provided you take "reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work." Also I think the result needs to be CCPL as well but I am not 100% sure on that... I haven't had a chance to read through the license completely (you should before you post anything).

The key with the micro-gravity stack is it is a linear flow with no storage, so the auger breaks up the rock and draws it directly into the vaporization chamber which shoots the atomized ore into the vacuum condenser which then at the correct points can extract the raw metals and draw them directly to the fabricator as it needs it. It couldn't be one part with different efficiency because 2/3 of the stack wouldn't function outside of micro-gravity. As I understand it while low gravity has some challenges to the process, it simplifies certain material engineering tasks considerably or at least changes them. Where on earth a lot of the mining/smelting/refinement/production process is dependent on gravity as an element in the whole process. RE: the robotic foundry/fabricator, I was thinking of making it a base for a launchpad, so whatever launch pad you wanted to use would just mount on top of it so it would be fairly wide (when expanded) and have sloped/ramped sides so when you put the launchpad on the top you could drive off a rover (if the launchpad itself allows it). Since there are folks who have done excellent work on launchpads already I wasn't going to tackle that just the parts that seem to need the most love (everything else)

At some point I want to do a series of modules for mining/refining/etc... I just need to sit down and model some of them. My list so far is: Auger - A base shrouded auger that feeds into a centrifuge where the raw materials are ground down and sorted, venting any waste material and pulverizing the raw ore into a form that could be stored easily (consistency of coarse sand). This would be cheep energy wise but slow to mine since a lot of the material would be re-vented back out and would require ore storage to be attached. Micro-Gravity Auger - A shrouded auger that feeds into a chamber where a high-powered laser atomizes the source material... which is then fed into a vacuum condenser separating out the metals from the ore in an extremely efficient rate [venting any non-ore waste], which are then fed into a micro-gravity fabricator that churns out needed parts. This would need /a lot/ of energy to operate and generate a lot of waste heat but would get a near perfect conversion from ore -> metal -> rocket part (I am thinking around a 90%) but would only operate in a limited gravity (the micro-grav fabricators I have seen theorized require it as well as this specific method of "smelting") It would however be very fast as 3d printing of parts speeds up the rate of production a large amount. It would however by its nature be a single non-splittable stack and probably need at least 4 of the larger stock solar panels worth of energy to operate. Operating this one in the dark would take a lot of batteries and wouldn't last very long. High-powered Smelter - A liquid smelting system in a large compressed centrifuge that can operate in higher gravity environments. It would be smaller than a conventional industrial smelter but would be expensive and use a fair amount of energy (although not as much as the micro-grav one) it would take ore and convert to metal at a rate that is more around 60-80% (haven't decided where) and would be fairly slow. The output would be molten metal which could then be fed into a fabricator or stored in specialized tanks. Robotic Fabricator - Takes the molten metal and fabricates a series of standardized parts (creates robotic parts) and can work in any environment, however it is big and slow and due to the methods used in manufacturing there is a small amount of waste product (~90% conversion from metal -> part) I also have a couple of ideas on how the storage stuff should look. I just need to sit down and re-learn 3d modeling (it has been a while) and see if I can do the parts justice. Any thoughts?

Romfarer's Lazor system has a yellow lazer attachement that can do fuel transfers within certain ranges with line of sight. No Kerbal required.

How does time accel work in this case, I was going off of the assumption that instead of activating once ever .9 seconds it would effectively be activating once every 900s "real" time. If that is a case if each hex covers 2.3 degrees [as previously reported by someone in this thread], taking an orbit of 241.541km @ 83.14deg (orbital period ~2580) gives a rate of about .06 hex/sec or about 54hexes per accelerated activation period (if my assumption is correct). Which means you would need 54 of them to get full coverage at 1k acceleration, no? If that is correct, the above orbit should cross the equator in 159 distinct places (enough to cover the whole equator) over a period of 56h 58.8m or under 1k acceleration roughly 3.4m. Now there could be a lot wrong with the above, my maths are really really really rusty. [i haven't done any real math in over 2 decades and unlike riding a bike it doesn't come back easily...] And I am sure someone (anyone) will be able to poke a lot of holes in it, please do... I have been trying to noodle my way around it and keep getting into a twist.

I know I just loved the excessive nature of it... The 5min pass being so good is probably mostly due to the orbit not the number of scanners but I just love the look The unpaired one works when switching crafts.. (the radial singletons) It is just the rotating one that gets futzed up. 10k is excessive in this case as I have (eyeballing it) a > 80% coverage after 5 mins at 1k and it takes longer to launch and orbit the thing then it takes to get the map I posted above. Plus being that low means I get a good first pass ISA map out of it too. That is why I went with the smaller scanners because I could get into 1k time range and still be in their range and they use less power. I think my orbit height was ~244k with an 88 inclination IIRC but I will get the numbers when I get home. How long does yours take to get a near-complete map... my napkin math even with 7.0 indicated needing more than 10 of the mediums at 1k for a < 5min near-complete coverage (why I went overkill)

(Crocodile Dundee Voice) You call that a satellite, that's not a satellite, this is a satellite (click for larger picture @ photobucket) Kerbin after ~5minutes @ 1k - It can run quite a bit of time in the dark and has IIRC 109 scanners, 1 ISA MapSat, A few green Lazor scanners for interfacing with Romfarer's KPS, Docking Clamp [for towing], Three solar panels from KOSMOS sized for the ISS Space Station (they crank 200 units/s each and take like a minute to deploy and get to full size) and four stupidly large batteries from some pack or another (you can use the large ones from hexcans as well). The ISA ideal orbits are actually sub-optimal for Kethane detection based on the relatively few distinct equatorial points they pass through due to the wider detection swath. I don't have my Kerbin ideal here (it is at home) but I will run the numbers for the planets when I get home and post 1k optimal Kethane orbits [basically you do what they did with the ISA ones but crank up the sidereal limits so you are passing over at least 255 distinct places at the equator. Or at least that is what I did.

Thats what I meant by fixing the memory issue... That isn't my problem in this case, but good info none-the-less.

Out of curiosity has anyone been running this on Linux 64-bit successfully? Since upgrading I have had KSP crash pretty much every mission. The Logs don't show anything except a metric ton of rendering bool, rendering rect lines [i mean /a lot/, is this related to the new Kethane?]... I am not at a point where I am declaring it Kethane and reporting a bug, but I just wanted to check in to see if anyone is using it on Linux 64bit successfully. I have already patched the memory issue and prior to this I had been running flawlessly even with ~80 or so mods running. I have a few more things to rule out tho and some tests to run.

I am using MJ2 fine with all of the above except Rubberband, Chatterer, and Aviation Lights so not sure on those three.

A modded part on Spaceport? BTW I am not sure your Hat exists or not... this is appropriate.

Random thing I have found useful the last week or so as I have added a bunch of Mods, I use a bash script (needs awk, grep and ModuleManger mod (http://forum.kerbalspaceprogram.com/showthread.php/31342-0-20-ModuleManager-1-3-for-all-your-stock-modding-needs) that goes through my Parts and GameData directories and creates a cfg file that adds the MechJeb module to every command module. [needs ModuleManager.dll to parse the cfg file] I just run it after every mod I install and boom, instance MechJeb http://pastebin.com/kEeGErYe I figured someone might find it useful. It runs fine in cygwin for you windows folks. I have a similar one for TacFuelBalancer and one that makes all my fuel tanks modular.

I created an Ubuntu partition on my SSD just for running KSP and am running the linux 64 bit version. Lots of memory for me

Hmm, almost all my vessels have both KAS and Lazor Systems on them... certainly several have been within 500m of each other (all my stations and orbital tugs have them after all)... Looking at your "Mods in Use" list the only ones on that list I don't use are: Boat Parts R3 Figaro GPS CaterpillarTreads Chatter IDstrongstruts Wayland corp(WT-51,freelance pods/rover/wheels) If it isn't up do date you can compare with my mods list https://docs.google.com/spreadsheet/ccc?key=0Asa1K8EUgZmVdElEZkhpQUo4ZUhzemtNdHotRlVBMEE&usp=sharing (currently running 83 mods so listing them here would get a bit long) BTW Your mods in use list started me down the path of finding mods a few weeks ago culminating in me needing a spreadsheet to keep track of them all... so thanks, I think

I suspect some of this has to do with the precision at those kinds of distances. When the burn required is <.1dV it can have a bit of an issue determining exactly where to burn, at least that seems to be my experience. Same thing with relatively small changes at far distances... so if you want to change (for example) where your "orbit" intersects with the ground by 1km from 1Mnm away, the change will be <.1dv and it can get a bit confused as to which direction to burn.

Reread again. I am getting a Mun encounter /after/ the Minmus encounter... It isn't keeping me from getting to Minmus at all, it isn't "in the way"... it is however using the wrong body to calculate some things.

1) It wasn't the latest yesterday when I was testing this. 2) Read again, the Mun isn't in the way... it intersects with the Mun /after/ hitting Minmus SOI. To re-iterate, I am not having problems using MechJeb or transferring to planets (look at my sig, those weren't using MechJeb) I am reporting a bug as to which body MechJeb is using to calculate something... To clarify even further... 1) Create a transfer from Kerbin to Minmus with Mun on the return path, refine so that it passes through both SOIs (Minmus First, then Mun) 2) Set Minmus as target 3) Use the function to refine distance to target to 100km 4) Notice that it refined the Mun's SOI to have a 100km Pe node even going so far as to remove the intersect with Minmus. 5) Remember that I said Minmus SOI first.