Weywot8

There'd only be a handful of people around the forum really qualified go "Actually..." that like this guy http://forum.kerbalspaceprogram.com/threads/68502-WIP-Principia-N-Body-Gravitation-and-Better-Integrators-for-Kerbal-Space-Program. (Hint on who to ask next:wink:. Or bug Scott Manley? Pretty sure he has an astro-computer PhD background from the occasional lingo he uses) Came to the same conclusion as K^2 but figured you'd want to replicate and scale this. Data is locked in the file located here http://www.maia.ub.es/dsg/3body , assumed you've found it. However, scaling (heavier bodies, trying for longer orbital periods) would be computational as well because there isn't an underlying formula unlike Kepler's Law. The figure 8 is actually more stable than Laplace's equilateral triangle orbit. Also more robust cause m1=m2=m3 is not a strict requirement (orbit changes from ideal though). So less accurate numerical methods can be used and "actually..." KSP isn't "real" either. My two pence worth of help would be directions to Section 5 of this website: http://www.artcompsci.org/msa/web/vol_1/v1_web/node6.html and bumping across http://www.control.aau.dk/~jan/undervisning/MechanicsI/mechsys/chapter8 which is very followable. Hope it helps and leave the other 350 3-body orbits alone:sticktongue:

Sorry for not getting back to this sooner, been caught up trying (and failing) to create a contact binary star system in KSP. Was thinking along the lines of "no need to cool down to refuel" benefits automatic pulling of thorium from anywhere on the ship if a high-level engineer is present, engineer also lets reactor run for a longer time (number chosen to maintain gameplay balance) before needing to shutdown for refueling because of actinide buildup if high level engineer + ISRU present, actinides will not shutdown the reactor so it'll run forever as long as thorium is somewhere on the ship. Should keep balance intact and gives engineers something to do. Agree gas core with thorium would be complicated IRL but KSPI has antimatter harvesting running in grams. GRAMS!!!

see this post http://forum.kerbalspaceprogram.com/threads/91582-1-0-4-ESLD-Jump-Beacons-Dev-0-6a/page19. It's doable even without the mod that originally came up with and used Karborundum. In fact, the entire launch and harvester would work out cheaper.

A nice point from the literature not highlighted in the very cool diagram is that after self-sustaining fission is kick-started, it's a breeder reactor where one can top up new thorium and extract new 233U without shutdown. 1 unit of thorium produces enough 233U that can convert up to 1.07 units of new thorium to MOAR 233U . It's a bit low versus the potential 1.2x conversion for 235/238U in classical Uranium-Plutonium reactors but it's still >1. Looks like the batch nature of pyroprocessing means the equipment is also relatively small http://pnanson.angelfire.com/Pyroprocessing.html Also, nuclear engineers have looked into the burnup thing: a 233U-Th salt mix (the fission core can also run on 233U-Th instead of pure 233U, safer breeder design because less neutrons weaken the core-blanket wall and even less escape the blanket but complicates pyroprocessing though) appears to be more efficient/releases more energy versus 235U-Th burnup. Then things became rapidly complicated and I'll stop right here:P

Hadn't realised that, thought some nifty algorithm/good enough heuristic & rate of change measurement was incorporated in the life support mods for EC. Guess I'm only switching away from space stations while they are in the sun!

Thanks! Guessing that means stars can't be deformed or textured but I'll dig about in Kopernicus and Nemesis for that. Edit: Doesn't the power of MOAR math generate power curves in Kopernicus from a few starting variables? Let me know what you'd like in general (follow real life luminosity/mass or other specs) and I can give it a shot since there's Nemesis for reference Edit2: yeah, lots of "reference" in the Nemesis cfg....

Looking forward to the release of this pack. The forum posts are hilarious at times. I've gotten interested enough to try making star systems and was wondering if any dude here could let me have a look at some functioning cfgs for stars and their orbits so I can understand how the creation process works? Multiple examples would help me figure things out faster. Looking to get good enough to recreate this http://physics.open.ac.uk/~ajnorton/papers/wasp_quintuple.pdf Distances look reasonable for interstellar travel, planets and some really "outer" planets without needing a black hole. Kerbol can be something along the lines of a hard to visit tiny barycentric object if the Hill spheres of the two binary pairs are really large. (Does it even work that way in KSP/Kopernicus?) Clearly never done this before so I reckon that by the time I've understood the basics, making the double teardrop contact binary and figuring out variable lighting from its rapid rotation won't be that big a problem with further Kopernicus development/someone more capable works it out before I do:D. Thanks!

Thanks for the fixes! Been staring at plots of the Karborundum costs for a long while and came away with the feeling that the curves are hand crafted? (tried to be cheeky with some calculus for potential min-maxing). Missed a few brackets on the traditional format but figured it out from the code. Hadn't realised the limitations of on-rails ship control in KSP. Guess that warping instantly leaves the beacon on rails so it can't be referenced to do something like the life support mods - record EC remaining, EC production/consumption, time of last update. Then when the next ship comes in physics range, the beacon gets updated from calculations based on current time vs. time of last update? (Inferred that's what life support mods do while browsing the sfs on a different issue, could be wrong) Current mechanics has it's own logic too so no complaints here.

There is a settings button in the top right hand corner (wrench) when KAClock is open. Click that and an additional submenu should appear. One of the buttons in the top row is for 'visibility' - make sure it's visible for fight mode and you are all set.

I do when running on OpenGL mode as one does when looking for performance hacks . Does nvcompress result in a smaller RAM footprint though? Knowing absolutely nothing about graphics and compression, can't help out but would be interested in providing testing feedback if you want any. Quick callout on what does and doesn't get's compressed - some visual enhancement mods appear to need certain formats for "volumetric clouds" and stuff. Might want to keep an eye out for that to avoid floods of reporting when everyone starts using your script.

Pink rings but only in OpenGL mode. Don't use ATM so not sure what's causing it. Will have to strip out some mods in exchange for OPM immersion or hope that Unity 5 works wonders if/when mods get updated for that instead.

Yup, most everything can be transferred between tanks via click, +Alt-click, +alt-click as many tanks as you like with the same resource containing capability. "In" will drain from all the other clicked tanks equally into the "in" tank, "out" distributes the tank contents to all other tanks.

Was going through my manual mod update (CKAN works great but then I'd still need to read up on the forums anyway, in case of significant changes) and have to say thanks for all the effort! To a certain extent, there comes a point where "realism" becomes a subjective human matter vs. Kerbal physiology, i.e. your artistic/modder vision. All things being equal physics-wise, if those huge Kerbal eyes have a wider dynamic range than humans/different power scaling, they would see the universe quite differently, as reflected in your KSP visuals. See https://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law - psychophysics affects everything from how NASA processes images to how supermarkets light their meat & fresh produce (and why makeup can go soooo badly wrong when leaving the house ).

Some pics of your problem would assist anyone trying to help. Edit: Ninja'd by everyone else. In general though, try to place the RCS ports symmetrically (4X typically) and as far away from the centre of mass to get the maximum benefit after they've been activated.

Stock contracts are auto-generated I think, so completely agree it's sad. That's being said, I've only ever encountered low-Kerbol orbit science contracts and the wiki doesn't list an atmos multiplier. http://wiki.kerbalspaceprogram.com/wiki/Science#Celestial_body_multipliers Happy to be corrected (and for a wiki update). Didn't realize that or I would have never tried this! Stripping out all the non-stock parts (which was the reason to do this in the first place, see http://forum.kerbalspaceprogram.com/threads/91582-24-2-ESLD-Jump-Beacons-Dev-0-1a ), I can actually get much closer as stock has higher heat tolerance. It can survive in very low circular orbit if hyperedited there but "realistically" drops in from around Moho orbit radius. 1.04 drag mechanics also results in good simulation of heat occlusion. True, radiators arranged this way won't work well in real life but it's all stock KSPInterstellar modifications to stock radiators are for a separate non-stock heat system and doesn't affect anything here [*]wide shallow fuel filled parts suffer from lots of radiative flux but have a high heat tolerance heat up slower than empty tanks provide occlusion for all the radiators, that have sufficient time to suck up and get rid of all the heat [*]and all the parts behind the tanks are still occluded up to a point - these also radiate heat [*]nose cones are amazing radiators so some radial attachment creativity there could work if anyone wants to try

There is the KAS/KIS mod for it's resource transfer parts - requires an engineer on EVA but if you are building a base, shouldn't be an issue. I gave up on using a Klawed refueling vehicle at things started acting really wierd, Klaw wouldn't release etc. http://forum.kerbalspaceprogram.com/threads/92514-1-0-2-Kerbal-Attachment-System-%28KAS%29-0-5-2

Many thanks! Will take sometime to digest the info provided. Skimmed your ramblings about solar harvesters - very good points. Was fooling around in Sandbox after my last post to really figure things out and came to similar conclusions. Documented in pics below. Minor issue while fiddling around - sometimes it doesn't warp after I confirm. Usually happens after I timewarp to get the red orbit indicator lined up. Also, is it possible to put an arrowhead/orbital indicators on the red line to show which direction the ship moves relative to the beacon after warping in? That improvement would be really helpful when AMU isn't used. I like the destroids approach but got rather obsessed with with min-maxing time-Karborundum production along the way + tendency to put big infrastructure into orbit/on planets. Last biggie project before restarting on 1.03+OPM was landing a "fuelspike" (24drills+IRSU+lotsa batteries and solar support+MKS logistic hub) at the best spots on Mun, Minimus, Duna and Ike.

I wondered about that a bit before checking the underlying physics. Basically, the radiator has to get hot enough to radiate out the amount of heat put into it, the hotter the radiator the more heat it can get rid of. So waste heat will build up asymptotically until it reaches a certain point when input = output. By analogy, imagine a tall tin can with a hole at the bottom. Pour in water from the top. If the hole is really big compared to the rate of water being poured in, no water collects. As the hole gets smaller, water collects until enough pressure builds up to force water through the hole at an equal rate it is poured in. Now change water = heat can volume = radiator and total craft waste heat storage hole = radiators ability to radiate heat (surface area, emissivity constant & all that jazz) pressure = radiator temperature I'll happily trust that FreeThinker has gotten waste heat storage "right" for all the radiator parts, i.e. all parts store enough waste heat to allow radiators to get to max operating temperature/max radiating ability before anything explodes from overheating. Most everything in KSPI-E sticks to some real world physics/counterpart as a basis although those gigantic black radiators are structurally very Kerbal IMO.

Just wanted to say I've discovered your mod and it's great! I've got the Outer Planet Mod (OPM) where travel can take decades - a functional colony on/around every planet is a real possibility now. The AMU is a nice touch as well, differentiates it from KSPI-E's warp drive in exchange for some initial travel time to the beacon. Still sandboxing at the moment and stuff works like as described. Very small matter with the minimal activation altitude displayed, the actual min altitude is higher by a smidgen (+1.5k around Jool but seen around Eve, Kerbol, Kerbin in varying amounts), probably a rounding/float to integer display thing? Some thoughts on balance vs. fun (CTT biased) - EC use at 3 stages instead of 2 in line with popular "SF logic". EC for initiation independent of K+ but influenced by beacon size and local gravity. Get stuff online, spinning up stabilizers, initial anchoring of space-time within the beacon separate from local gravity, etc. Bigger beacon's need moar EC as a result. Need lotsa EC, many tens of thousands for LB-100 at baseline gravitational tolerance limit. Engineers lower EC cost. From a gameplay mechanic, being able to harvest K+ from Eve/Eeloo in stock sorta means hauling a few extra Z-4Ks (3 Z-4Ks = 12k EC) with the beacon isn't that big a deal. And batteries all go into orbit fully charged anyway. EC for stand-by influenced only by local gravity. Have to keep those stabilizers spinning and isolating that slice of space-time. Engineers lower EC cost (sad to stick a Kerbal in the middle of nowhere but it gives people with life support mods something to think about) EC for transfer influenced by K+ used but EC per unit K+ reduces with beacon size in keeping with LB-100 logic (cue hand-waving and air quotes). EC's being used to contain and direct the K+ detonation, connect to and power destination beacon. Bigger beacons need less EC per K+ the same way a long plank needs less force to break it in the middle vs. a shorter one. Scientists reduce K+, engineers reduce EC, pilot reduces distance/speed penalty. Jeb/Val, Bob and Bill all get to do something for the trip! As for gameplay, allows choice between hauling up fewer solar panels and "trickle" recharge between jumps vs shorter intervals between big ship jumps. Further increase EC use near gravitational tolerance limit (see below) for balance/gameplay such as K+ harvesting near around Kerbol/Eve (affected by latest EC scaling on solar panels - one Gigantor produces 48.8EC/s at 175km around Eve) or choosing beacon location vs beacon infrastructure for planets far from Kerbol. Hauling a big space station docked with a fully equipped beacon, initiating then undocking the beacon and transferring the space station is still Kerbal-crazy do-able but the IB-1 becomes much more attractive as a goal/option. Using the GMU doesn't make much difference in minimum orbital height that can't be overcome with at most a few hundred m/s delta-V in planetary SOI and a bit more travel time. 25% gravitational tolerance looks big but the inverse square law means that's just a ~10% change in orbital SMA/~11-14% altitude reduction. Based on the charts, there are clear roles in mind for each beacon. Perhaps rescaling gravitational tolerances of beacons to in-SOI location/travel time can reinforce these roles? (no idea how to superscript, apologies for below) for instance LB-100 at 6mm/s2 putting the minimum altitude between Minimus-Mun (4-5 days travel), +GMU to 60mm/s2 between Kerbin-Mun. Around Kerbol, that translates to unaugmented-just under Kerbin orbit (access to outer planets only and big ships still have to planet-hop around to get to the other side of Kerbol) and +GMU gives a radius that's within Moho's orbit most of the time (inner planets + trans-Kerbol access). Adds a nice touch to delay heavy ships beaconing direct into Kerbol-Eve for K+ then LB-10 would be 0.6m/s2 (~1800km, an hour away from Kerbin) to +GMU 6m/s2 (160km altitude, just above 1.25r limit). Transferring from a minimum altitude LB-10 to LB-100 saves a big chunk of time and is a "must do" for big ships. Coming back in, an LB-10 based at LB-100 min altitude transferring all the way down to Kerbin saves the same amount of time. noticed that even without these changes, the underlying mechanics encourage linking two beacons together to eliminate a transfer step (outermost on your gravity chart) ... since it becomes a stop over, might add a science lab ...and some ore processing/refueling station ...and look, a station contract to finance the whole thing! thinking along these lines, any added parts to fulfill the EC suggestions from before don't impose much of a burden, but that's just me I suppose [*]LB-15 filling the gap with 60mm/s2 unaugmented, i.e. 0.06m/s2, to +GMU to 0.6m/s2. Small ships get to go to inner planets, use trans-kerbol path off the bat but still need to travel some distance to the beacon to begin with so LB-10 to LB-15 transfers are still useful. These tolerances also seem make sense around Duna, Jool too. the large suggested orbit differences from using the GMU provide a noticable gameplay change - the option of reducing K+ use in planetary SOI by direct travel. That's balanced against the fact that smaller orbits produce a larger range of velocity differences, potentially incurring a larger AMU K+ cost by those who really want to save time, keeping in line with your design principles for this mod could I see the underlying formulae for the various K+, EC, altitude reduction numbers? Rather curious, if you don't mind that is. Realized along the way that the best potential reward for hauling an asteroid is being able to beacon down into and out of the optimal Kerbol-Karborundum orbit for "free" with the right setup! Also the suggested +GMU 6m/s2 for LB-10 puts a ship at 180,100km above Kerbol, above the 150,000km optimal orbit. Makes getting a beacon there to begin with a nice career goal. Not game breaking - keeping the LB-10 under 1400C is difficult and will probably involve an asteroid anyway (imagining an ESLD contract pack right now that says put LB-10 into this tiny, tiny solar orbit with minimal deviation. Keep it there for 1 day. BOOM! Overheat before time is up ) Runner up is a 1.25r orbit around Eve (10.67m/s2). a Kerbin asteroid can save up to ~750m/s under the existing setup but from a gameplay perspective it's not much by the time the tech is unlocked and K+ is harvestable - i.e. 12,000m/s return from Eve or 8000m/s Low Eve Orbit. Maybe an added benefit could be a reduction in EC for initiation & standby (+/- transfer EC)? Based on the gravity "logic" an asteroided beacon would use less EC than an un-asteroided beacon at the same altitude. Would need EC curves rebalanced from initial min altitude to 1.25r so that it EC cost rapidly catches up and overtakes un-asteroided cost. (Haven't played with this bit yet, so perhaps it's already a feature). thinking about it, this becomes a big deal in the outer planets as lower EC cost-same altitude helps with EC generation issues; the deltaV to move stuff at that distance is actually really decent so hauling asteroids as an EC solution becomes a viable gameplay option. 10 long strutparts with 30 Gigantors will power that beacon on an asteroid around Eve a number of posts back. we laugh in the face of high initializing EC costs (see sat pic below) 80 ton pipe dream pics to spice up your thread. Pretty sure 4000 units of K+ from 2 hours around Kerbol can send it with velocity alignment to Jool/Sarnus-Eeloo/Neidon/Plock to top up some beacons and back to Kerbol for moar K+. Now to make it happen in career mode at some point.

I'm probably being slow today - can't seem to find the download link for the latest version (looked at OP, tried looking for github version). Could anyone give me a hint/directions please? Thanks in advance.

Was looking around to check out aerobreaking/capture strategies for Eve under the new drag mechanics - surprised there were problems reentering Kerbin from Mun/Minimus. Started as an engine placement/staging design quirk but found out that a wide fuel tank works to protect the craft on fast & hot re-entry. Jeb and Phoy (Jeb only rescues Kerbals with quirky names, the money was good too!) walked away unscathed. Note initial periapsis at ~30km but ended up on the surface "free-fall" return from 10,000km apoapsis orbit lost some energy before the pic (70km-34km), probably had a shallow reentry angle? parachutes on top of side tanks didn't burn up - thought those were gonners when things started glowing Hope this helps anyone looking to save on heatshield weight while getting back direct-to-Kerbin in one piece.

Haha - the challenge looked interesting and an OK amount of science given the effort, especially with easy repeatability. Was looking forward to an extra ~3200 science from Mun and Minimus but guess 1.0(2) might have broken it . Time to deprecate the feature if it can't be fixed?

Recently started KSP (1.02) and this mod is great! Facing an issue with impact science/accelerometers at the moment. sent 5 accelerometers to the Mun on one ship detached and landed at poles and 3 equatorial quadrant points - renamed each with A, B, C, D, E suffix. activated each landed accelerometer to record impact - pic of south pole transmitting base below switched to the impactor and rode it into the Mun Dr. Strangeglove style (600m/s): got the 'impact recorded' message CFG file shows 875 science (Yeah, moar SCIENCE!) writtenat = 6/22/2015 12:30:42 PM VESSEL_SEISMIC_PROBE_4fc0f745-2866-4795-878f-90e8743bb96a { is_active = True celestial_body = 2 } VESSEL_SEISMIC_PROBE_9826e8bf-2933-4c09-92aa-8df0b11e68fc { is_active = True celestial_body = 2 } VESSEL_SEISMIC_PROBE_bc4500b9-e40e-4e95-98d9-27a63f45060e { is_active = True celestial_body = 2 } VESSEL_SEISMIC_PROBE_bee1663b-167f-4a8c-b09d-78a9c9540391 { is_active = True celestial_body = 2 } VESSEL_SEISMIC_PROBE_45abb652-695c-489a-9237-710c0106d770 { is_active = True celestial_body = 2 } SEISMIC_SCIENCE_MUN { name = interstellarseismicarchive IMPACT_0c4e39e5-5150-45d4-95e8-2e7465732e4f { transmitted = False vesselname = Mun-Impactor1 Probe science = 875 number = 1 } IMPACT_837de4ed-4836-4df7-9da1-f9498c30a4f0 { transmitted = False vesselname = Mun-Impactor1 Probe science = 530.714327248554 number = 2 } IMPACT_87a4fabd-c920-4434-a9e6-343462a35756 { transmitted = False vesselname = Mun-Impactor1 Probe science = 321.894511025012 number = 3 } IMPACT_9e12ba67-c197-449d-8776-4b97e39aae5f { transmitted = False vesselname = Mun-Impactor1 Probe science = 195.238890129876 number = 4 } IMPACT_5d50e701-4ae6-44a7-8ee8-1859e8df9749 { transmitted = False vesselname = Mun-Impactor1 Probe science = 118.418372832036 number = 5 } } seems like different parts of the impactor got recorded as seperate experiments? ​ but all accelerometers don't have 'collect impact data' option - only the option to stop recording (GUI looks exactly like the pic, minus the notification/OK window). Has anyone come across this issue before and managed a fix? Not sure how other mods might only kill the collect impact data function and leave everything else working but a list provided below. Thanks in advance for any pointers! FilterExtensions Toolbar USI - MKS/OKS, Karbonite, Karbonite+ (and dependencies) EVE CapCom Chatterer CRP, CTT Contract Configurator + SCANSat, RemoteTech, GrandTour contract packs ContractWindow DistantObjectEnchancer DMagicOrbitalScience EngineLight KSPI 1.1.20 and dependencies KAS+KIS KJointReinforcement MechJeb NavHud NFT Solar PlanetShine RemoteTech SCANSat Scaterrer SolarScience StageRecovery SockBugFixModules SurfaceLights TACLS TextureReplacer Tweakscale UbioWelding - nothing on these ships were welded WaypointManager FinalFrontier ModuleManager 2.6.5

Recently started the game and really liking it. Some pics from late career mode so far. Not as great compared to some of the stuff in here - inspired to do more if RL permits.