MrOnak

Yay! Progress is alway awesome

thanks the for explanation... I thought something like that might be the case but I must admit I hadn't thought of the center of the planet Is there any way to convert the direction to something "sane"? I tried things like UP + R(p, y, r) or NORTH + R(p, y, r) but that doesn't seem to make any difference.

I can't seem to figure out the frame of reference (?) relative to which nearly all ship: vectors seem to be. For example, when I read the ship:facing:roll value in level flight, the number changes depending on whether I fly north/south/west/east. The same happens with ship:facing:pitch. ship:direction:* seems to behave identical to ship:facing:*. To be honest I'm running out of ideas how to put the numbers in a stable frame of reference that does not change depending on the planes' attitude (thats a bad way to put it - of course they change to the ships attitude - hope you know what I mean) but that always gives me numbers identical to what indicated by the center of the navball. Any clues? Thanks in advance.

Hey all. I have two things: 1) out of sync errors. I found a post saying this is probably a race condition. If you're still interested in log files / craft files / scripts, let me know. It seems to be quite reproducable in the craft / script I have. 2) How the hell can I display the pitch of a target vessel over the horizon? target:bearing / target:heading is easy enough for the compass reading to the target but I've tried verious things for the better part of yesterday and every value I've tried gives me some weird number, not the 80° / 70° / ... / 20° or whatever it is that is on the navball where the red target marker is that I expected. thanks in advance. P.S.: oh by the way if that hover craft guy is still around, this is an accurate calculation of the g-pull experienced by your craft: set G to 6.6738480e-11. lock vesselMass to ship:mass * 100. // must be converted to kg lock bodyMass to ship:body:mass. // is already in kg lock distance to ship:body:radius + ship:body:distance. // in meters lock bothMasses to vesselMass * bodyMass. lock distanceSquared to distance * distance. lock massesByDistance to bothMasses / distanceSquared. lock F to G * massesByDistance. lock vesselGPull to F / vesselMass. as you can see its broken up into many pieces for debugging purposes, you can probably condense it somewhat

Guess we're all doing it at some point... today was that day for me. I built the ISS

Thanks, that made my day Craft file here

I present, the luxury version of something small: Micro Minmus. It even has a full-blown capsule, batteries and solar panels! Seriously though, I see this being the heavy-weight of all things posted here but - it's a rocket, not some contraption with jet engines (not that that's a bad thing - 2 tons is darn impressive - but it ain't my thing) - it has loads of safety marigns - it handles like a charm - 17 tons is still not bad in my universe

Trust me, I'm in fullscreen

Thanks for the pointers. I'm running fullscreen though, so that leaves the red planet flicker open. Anyway, I'll probably try out the other settings in a day or two. GPU in question is a GTX 560 Ti btw.

This is really nice, it gave me a whole new experience in KSP. After one day of fun though, I uninstalled it again due to a few glitches and observations. Maybe these can be addressed at some time in the future so I thought I'd share: - the whole display becomes quite grainy, which is an issue for reading the glass cockpits provided with RasterPropMonitor - I noticed a weird glitch when in EVA or map view: Kerbins landmass turn an orangy-red at times. The oceans are unchanged. The whole of Mun / Minmus turns red as well. Whe whole affair seems to be dependent on where the camera is in relation to the Sun. - I've noticed several weird glitches / flicker events in conjunction with the EnvironmentalVisualEnhancements and Better Atmosphere package. Lastly, I know this is reaching into aesthetics which are always personal preference but something inside the Bloom settings seems to be killing the "nice" lighting of the Sun. the whole thing turns into a white & bleached-out blob. I tried various settings in the enbsettings.ini but couldn't really fix it. But as I said, the last thing is personal preference and not a glitch in itself

I decided to punish my comp with a whole set of new mods and KSI MFD was one of them. Holy mother... good show! I like how you organized the displays to be contextual, really works out well. A few things are missing for me though - or I'm too daft to find them, entirely possible - so I thought I'd share the thoughts: 1) The MFD Navball doesn't seem to have an overall velocity setting. Horizontal / Vertical is there but a total readout would be good. I know the other MFD pages has it but I tend to stare on the navball during various operations more than anything else. Maybe the current two-liner displays HORZ * m/s and VERT *m/s can be combined in a single four-liner VEL tot * m/s horz * m/s vert * m/s 2) the NFO > RES display could use a information about the delta-V remaining left in the stage. Furthermore, when I switch to TOTAL inside the resource display, the display seems to have three pages but pages 2 and 3 are blank? If there's unused space, that'd be a good spot IMO for an all-stage delta-V readout. The Orbit / Landing / Ascend pages also could use a delta-V display for the current stage, but if it's in the Resource display that'd do I think. As I said above it's entirely possible that the settings are there but I missed them somehow, if so, sorry for the confusion and, any pointers to where the data is would be great

I'm surprised Thorium-based nuclear reactors haven't been mentioned yet. That's where I'd put my money.

Yeah I noticed that. Had a few tries building something in the VAB but all designs turned out to be quite monstrous OR not having a suitable TWR. Anyway I don't want to hijack the challenge thread, thanks for confirming the dV I'll figure out a craft eventually.

Yikes Thanks for the quick answer.

*knock* *knock* Sorry for interrupting... You guys are clearly the right people to ask. The Wiki lists 11,500 m/s delta V required to get into orbit from Eve. This challenge requires a minimum of 8700 m/s for a craft to be valid but if I read some posts here correctly, less seems possible? Reason I'm asking is cause I have a stranded Kerbal on Eve which I'd very much like to bring home, trying to figure out the Eve ascend stage at the moment. Without cutting it razor thin (no "lightest Eve Lander" required, just getting the boy home), what dV would you aim for to get a single Kerbal back into orbit? There'll be a return vehicle in orbit ready to get him back to Kerbin. Thanks a lot

Ok my friend had another go for a few hours so here's my weekly bugreport - there's quite a few duplication issues. Mostly it seems to affect Kerbals going on a quick EVA for the biome reports, when timewarping quickly after reentering the capsule. It seems that if you wait a bit after going back "in" it's much less of a problem. My guess its to do with the time to propagate the "merging" of two vessels back to the server before entering timewarp but I'm sure godarklight can isolate that one better .). At one point I observed a duplication of my empty ascend stage after staging but that was just once. Usually it seems to work. I don't see any difference between that particular staging event and others that went fine. - My friend got disconnected from the server (happens quite a bit but thats not an issue, really) and after he reconnected all his science research was gone. The research facility was still open and accessible but all nodes he had researched were locked again. He still did have the 6 science points leftover that he has had before the d/c. We tried reconnecting, restarting both client and server but nothing helped. Even tried hacking the persistent.sfs file on his machine to get him the points back but the KMP Server seems to store this somewhere else as the points were not applied after restarting both client / server again. I even had a very brief look into the SQLite database but while I found the scenarios I couldn't find the science points. - I had my own disconnect oddity after which the research facility was closed and all science instrument yielded the usual "you're getting the suspicion you're not learning anything" messages and the like that you get when you try to do science in a Sandbox game. A client restart on my end fixed this however, my tech tree was still unlocked to where it should be and the instruments are yielding science again. - Ok I just had another thing that really annoys me. I have a probe in 200km / 1200km orbit around Jool which has 5 detachable probe landers. Once I detach one of these (small decoupler) thay end up in a random suborbital trajectory that always leads to their death. That's extremely annoying, especially considering how long it takes to get to Jool in the first place. My client and the server run on the same machine so I guess lag issues are not to be faulted here.

Turns out a couple of hours of sleep is all I needed. Stupid me didn't recognize that F is measured in Newtons which, of course, means that its effect is relative to mass. TheShadow brought the key to that lock Rep duely added. Thanks a bunch to everyone. Now back to my N-Body simulation code *sigh*

That'll help me a lot TheShadow... tomorrow Thanks a bunch

Physics is 20 years away so yeah.. I know where you're coming from. I think I understand what you're saying. Inertia comes to mind? The pull F is the same on both bodies but the smaller one is affected more due to lesss inertia? *scratches head*. It's late... I'll try that again tomorrow

I stumbled over something that I can't really wrap my head around... The wikipedia page for Newton's law of universal gravitation lists the following formula to calculate the gravitational pull: F = G * ((m1 * m2) / r^2) where G = gravitational constant m1 = mass of object 1 m2 = mass of object 2 r = distance between the centers of m1 and m2 That's fine at first glance. I understand what that means and it fit my understanding at first. But one thing is odd about that formula: It implies that the gravitational pull for m1 towards m2 is the same as the one for m2 towards m1, regardless of their mass ratio. That would mean that a very heavy m1 would move the same distance towards m2 as a very light m2 would move towards m1 in the same timeframe due to the gravitational pull? I'm almost 100% sure that's a misinterpretation on my part but the formula certainly hints that way. By the way the image with F1 = F2 = ... is more explicit if my example is hard to understand. Can anyone point out why my interpretation of that formula is wrong and keep my view of the world of physics intact? Thanks

I'm afraid this challenge has two "design flaws" which I discovered (big word there) thinking how I'd approach this. The first flaw involves the unlimited use of map view. Now I do realize that the spirit of the challenge is to fly as much of it in IVA as possible so don't get me wrong here but still, here we go: It is perfectly possible to fly the entire mission in map view except the final landing on the Mun surface on one hand and staging on the other. For staging it doesn't matter whether its IVA view or the craft view. For the final minute or so of the Mun landing all you need is the radar altimeter from IVA and you're done. Map view in fact is usually how I perform 99% of the time of my missions so there's no major change (for me at least). The mission parameters require the Mk 1 pod which has a window that is useless for landing (its not a lander capsule). But that means you have no way of knowing if your landing site is suitably flat or not until you do or do not tip over. The two points make the whole mission boil down to pure chance whether you hit a flat spot or not: Getting there in map view is trivial, landing safely is pure chance. For me anyways. I don't mean to sound harsh, just trying to get my point across. So I changed my own mission in a few ways: - Used the Mk 1 lander can, since it has a window that is useful for landing. Alternatively one could go to Minmus since the flats guarantee not toppling over. - Allowed map view only when engines are off which essentially restricts it to the times where you've left Kerbins atmosphere to set up the circularization, waiting for the transfer burn etc. It also means you need a watch or something since you can't see the remaining burn time from inside the cockpit. Just thought I point that out because I genuinely believe its a cool challenge idea but it suffers a bit from the details.

Jesus Christ that robot... *awestruck*

Sounds like a reasonable explanation actually. Guess the timing was more than unfortunate then. We'll try again tonight and get that boy back on solid ground.

One of the smallest without resorting to the *cough* improved *cough* ion engines and weightless parts: Micro Minmus, brings one Kerbal to Minmus and back just nicely. 36 parts, 17161kg launch weight, and a real pleasure to fly. Quite a bit of delta-V to spare makes it really safe. I'm sure I can shave off another 10% of the weight somehow but TBH this is nice as it is. And one of my more absurd derp-crafts, the "Pfffffff... I don't think so" landed on Minmus with its crew of three: 29 parts and a bit over 133 tons landing weight.

How about scientists names? Surely there's a astronomer / engineer / physicist for every letter in the alphabet.