Corax

What BACE needs now is an auto-levelling mechanism... who wants to sleep in an angled bed, even at only fractional gravity

No problem, it just wasn\'t completely clear... It looks as if somehow the IP address can not be resolved or interpreted correctly (and I\'m to blame for not making it fail gracefully). I doubt it, but maybe there is some more info in the ALT-F2 console in game.If you know the IP address of your network card, you could try that in the part.cfg. If all else fails you could try and download the outdated version and see if that works... best make a copy of a fresh installation of KSP and experiment off that.

There is no such thing as \'lastest\', it\'s either last or latest; in this case, the most recent file is the first of the four attachments. The last, i.e. fourth attachment, is outdated. Make sure you have the first, i.e. latest Sorry, can\'t make out anything on this site. That basically just confirms what you said in your first post, that you don\'t receive anything. It tries to go online, but apparently cannot find a receiver.Maybe you could edit the part.cfg from ipAddress = 127.0.0.1 to ipAddress = localhost and see if that helps... I think it shouldn\'t make a difference, but try starting the UDPReceiver (or ncat) before you activate the telemetry module.

Have you tried the included \'2-X Sounding Rocket\'? If you have built your own rocket, have you activated the module? In the VAB, pull the module\'s icon (it\'s the same as the tricoupler icon, so make sure you catch the right one) into the lowest stage so it gets activated right when you launch the rocket, or put it into its own dedicated stage and pull that all the way down. Please verify your firewall does not block localhost:54345 or 127.0.0.1:54345. A file called \'[tt]telemetry.data[/tt]\' should be created in the directory you launch UDPReceiver from. If it\'s there, what are its contents? Apart from that, check that you have the latest ([tt]2012-04-08-crxTelemetry.tgz[/tt]), not the last ([tt]OUTDATED-2012-03-19-crxTelemetry-OUTDATED.tgz[/tt]) file from the OP

$ md5sum mun.topography.csv b7f775ce9833df8fb3988b2d9b7bb8e5 mun.topography.csv $ file mun.topography.csv mun.topography.csv: ASCII text $ tail -n3 mun.topography.csv 29.799130050368;-21.1461536259711;1161.96 29.7992678454793;-21.1498722656562;1162.48 29.7994057233427;-21.1535906439191;1163.27 Everything seems to be in order; maybe try splitting the data into smaller chunks? If that doesn\'t help, here is another version with DOS line endings: $ md5sum mun.topography.dos.csv f296a2027024a9c3900f6dc5ca851542 mun.topography.dos.csv $ file mun.topography.dos.csv mun.topography.dos.csv: ASCII text, with CRLF line terminators $ tail -n3 mun.topography.dos.csv 29.799130050368;-21.1461536259711;1161.96 29.7992678454793;-21.1498722656562;1162.48 29.7994057233427;-21.1535906439191;1163.27 EDIT: Link to alternate data file

It might be an idea to put as many images as possible online somewhere, as an archive or as individual images, or both. I have no idea about the amount of data we\'re talking about, but just as an example, Dropbox offers 2 GB of free online storage. (Shameless plug: sign up by following this link and both of us get another 500MB as a bonus) Somebody is bound to make use of it. I mean, a high-resolution map of the Mun, who could possibly resist the temptation?!

One way might be to experiment with the centre of mass of the stages you want to eject - try to put the radial decoupler at a higher or lower point of the stack than where it is now, and optionally an additional strut at the top or bottom; this may help with how the ejected stage clears the stack. Another thing that may help is to experiment with throttle and delay; instead of decoupling under full thrust, try throttling down a bit before staging, and/or wait a second or two. It may also be worth considering to reduce the amount of overall radial staging - try to time the engines of a stage so they run out of fuel at the same time, and separate from the whole bundle at once.

Here\'s some 500MB (13M data points) of munar topography data from over three days of munar survey, orbiting at roughly 3100m, between ±30° of latitude. I think I got the transformation to the format ISA RAM is using (it has been downlinked using my telemetry module). Looking forward to some nice mun maps EDIT: On second thoughts, the method for measuring terrain altitude I\'m using differs a bit from InnSewerant\'s, so there may or may not be a noticeable difference in reported altitudes. Use with caution.

I\'ve re-added a link to the previous version for your convenience.

Make sure you have installed the telemetry plugin as well. Did you notice there has been an update to the plugin the other day? Although I don\'t actually think so, Elderberry might need some tweaking after that.

The data field for AGL is only in the most recent version of the plugin. With that, the actual position of the module doesn\'t matter, as you can simply subtract AGL from ASL and get true terrain elevation.But I concur, the main purpose of the telemetry plugin is not cartography, there is already one publicly available specialized module I know of, and who knows how many private ones It might be worth further developing them.

I agree, without seeing the animation it isn\'t quite that obvious. I didn\'t mean to sound demeaning or anything... Of course I had hoped my plugin would work for others as well, as I hadn\'t heard anything to the contrary.

If you look at the animation in my post above, it\'s obviously being done from orbit. Because the previous version of the telemetry plugin didn\'t provide altitude above ground, togfox had to rely on a rover. The problem with doing it from orbit is the really limited range of the altimeter. You have to be very close to the surface for it to detect anything, which explains your observations. I don\'t think these issues are directly related. Measuring altitude above ground appears to be limited by how collision detection is handled in Unity; you have to be at the highest terrain LOD for the raycast ('altimeter') to detect anything, for me here that means at or below about 3km around the Mun, or 10km around Kerbin (which makes orbiting really difficult ). It might be that on different graphics settings, the LOD is handled differently, which would explain people falling through the surface. So while there may be a common denominator (the LOD model), the issues are still different ones; in one case, the LOD decreasing too fast for useful results, in the other case maybe the LOD increasing too late to allow a safe touchdown.I think both methods, orbiter and rover, have their justification: Orbital mapping for coarse resolution, wide area; and ground based surveying for high resolution, but limited area maps.

Basically, you take a capsule, put it on surface of the Mun, move it around, and record the height of terrain at your location onto a piece of parchment. Move a bit further, and repeat the process. That\'s really old style. Nowadays, we use tools to help us with that kind of task, such as rovers, and altimeters with radio transmitters... and a lot of patience and dedication.

Hi, just a little update: I\'m still in the midst of reworking the plugin, I will not announce another estimate... it\'ll be done when it\'s done. For now, here\'s a preview of some of the changes: [li]a new custom part. Same mass, but much shorter, to allow for more compact construction.[/li] [li]the data fields and their ordering will be configurable in the [tt]part.cfg[/tt], and will be persistent per craft. If you change the [tt]part.cfg[/tt], all new ships will use that, whereas existing ships will continue with their original configuration.[/li] [li]the data rate will be configurable, too.[/li] [li]a few new fields will be available, among them AGL ('above ground level') and rho ('?', atmospheric density)[/li] [li]some example gnuplot files will be included for data visualization (see spoiler for an example).[/li] [li]the transmitter itself will be a separate class, so other plugins can include a transmitter as well.[/li] And of course, a few teaser images: Mapping the Mun Topographic Map Just over two days into the mission; telemetry data accumulated: 0.6GB Surface Panorama on White Surface Panorama on Black Map Sheet on White Map Sheet on Black Refining the Data Points More Orbits!

Ok, that\'s what I meant with influences from the Mun or Kerbin.Thanks for clarifying, no more sleepless nights because of this

So, to reiterate, is it correct that: From a physics standpoint, any orbit outside an atmosphere and above the maximum terrain elevation around any body should be stable, no matter the altitude or inclination; what would mess it up would be inaccuracies in the simulation? Or, in other words: Theoretically I should be able to orbit the Mun just above the highest mountains, at any inclination, without the orbit being influenced from the outside in any way (Kerbin, the Mun itself, ...)? My admittedly limited knowledge of orbital mechanics says it would work that way, but I\'m still not convinced I\'ve got all my facts and formulae right

Let\'s keep this on topic, shall we?

Linux workstation, Win7 lapdogtop (though I haven\'t used that one since around KSP 0.11)

Seems there is more than just one way to deploy solar panels

It seems the forum move broke the attachments, and currently doesn\'t allow any new attachments. Here\'s a dropbox download for the time being. If you don\'t have a dropbox account (you don\'t need one to download), consider joining using this link. EDIT: Fixed attachments in OP.

Obviously this isn\'t about protecting the publisher\'s hard work and income, but about protecting some customers\' sense of achievement or entitlement.When the publisher decides not to do DRM, and people continue to demand DRM, something is fundamentally wrong. If you have bought KSP, as of course you should, you can rest on the knowledge you have done the right thing. There will always be people who try to get something for free, and guess what? They will always find a way. I\'d prefer Squad spend their time on improving the game, rather than implementing some pointless Restrictions Management. In fact, I think I\'ll just donate another few credits, the game is more than worth it. Especially without Steam or some other shit.

The only problem with that is you can\'t go on rails below 5km...

No SAS or ASAS, no autopilot, and no RCS except for the reboosts. Simulation running at 1x time factor.

I think I need some information regarding inclined orbits. I currently have a mission in an inclined munar orbit, swinging back and forth between around ±30° of latitude. I\'m aiming for an altitude of around 3km ±200m. There is not much margin for error - some ridges rise close to 3km... I haven\'t been able to keep the orbit stable for more than a few hours at best - several times now I have realigned apoapsis and periapsis to within some twenty meters. After a few orbits, they drift apart, I haven\'t been able to identify a pattern though. Sometimes AP appears to rise or fall; sometimes PE, other times both apsides change. Now there are a few unknowns for me - I haven\'t been in such low an orbit for such a long time before (at least without going on rails), and most of my orbits so far were either equatorial or polar. I was under the impression that as long as there is no atmospheric friction (and disregarding mass anomalies, solar wind, etc.), orbits would be stable no matter the inclination, but my understanding of orbit mechanics isn\'t firm enough to insist on it