esd

Perhaps then a "no control surfaces" category? The Kerbal equivalent of a paper plan with a rubber-band motor. Not because I'm the leader (by virtue of being the only entrant) of such a category, of course! *whistles*

That is pretty awesome, almost like a rickshaw! Also reminds me of Robot Wars. Not sure why! Definitely a valid claim for the Duna Cup!

Here's my pitiful attempt, using no control surfaces... but I noticed you didn't ban SAS or rover wheels, so I used the SAS to try and get some control (failed) and the wheels to kickstart the plan (success!) Yup, that's a WHOPPING 81m. Enough panels to go forever, had it not chosen to eat turf.

That deserves a round of applause! Brilliant!

Landing gear is just fine, as long as it still has powered wheels for roving (which you have). So far you're both the lightest and the heaviest, so we'll have to wait until some more show up to see where it actually ranks, but that's certainly an Ev-ervescent award!

Nice tries! Love the dual-glider thing, especially trying to control them both (keeping them within 2km of each other would be very hard). The monoprop aboard each one - that for balance, or is there a sneaky RCS thruster on there...? I didn't even think of a tricycle rover using a landing gear for the third wheel. "You can't land with rover wheels" - Oh yes you can! (See screenshots above!) You just have to land very... slowly (one of the reasons my run used Eve. I think the maximum horizontal speed on those wheels is around 60m/s before they break). Planning on going extra-Kerbin?

Probably easy for most, but I enjoyed doing this, so I'm throwing it out to see what others do with it. Build an unpowered re-entry glider that turns into a rover when it lands. Criteria: Must not have any engines (including RCS, ion, antigrav, whatever) when it enters the atmosphere. Must be flyable in the target atmosphere to select a suitable landing site. Once landed, lose it's flight ability to perform rover duties on rover wheels. Manned, unmanned, your choice (I did it unmanned). Should carry scientific instruments! No parachutes! (That's not gliding anyway) Mods allowed (I used Mechjeb), but say which you use! Pick a planet. I used Eve because of it's juicy atmosphere. How I did it: Built the glider, added a propulsion section and got that into orbit. Docked another propulsion module to the back of it, and flew the lot to Eve. Re-entered, found somewhere to land, landed on the rover wheels and then ejected the wings. Pics: Re-entry: Landing: Converted rover: Prizes... um, there's no physical prize. Sorry about that. Ev-ervescent First to complete on Eve. Claimed by SketchyGalore! Duna Cup First to complete on Duna. Claimed by Francesco! Lathe Trophy First to complete on Lathe. (Unclaimed) Thimble of Glory Least parts (but must have all 4 instruments and at least 1 ariel!) Thor's Goblet Biggest glider (by parts: (Unclaimed) by weight: (unclaimed)) Silly Stick Zaniest, silliest, glider/rover thing. Determined by "lol"s or "holy hell"s (unclaimed) (To claim the size parts/weights prizes, make sure you give the number of parts or mass of the glider (before roverfication on the surface)) Proof required: Just screenshots in a similar vein to mine. If there's any real dispute (unlikely), you can always post your .craft

Neither...

Just landed an 18t automatic rover with crew space on Minmus, then followed it up with a manned lander. However, when I reached where I left the rover, it was gone. It wasn't in the tracking station either. Only thing I can think of is it couldn't decide if the rover was landed or not; it's engines were still attached, on the map the ap/pe were jumping around and it took a few times pressing ESC before Space Center wasn't greyed out. Did the game decide it wasn't actually landed, but a ship that had just crashed..?

Ok, that *almost* works... the code compiled fine, but the results of HeadingDegrees are a tad odd: From actual bearings 0 - 180, HeadingDegrees goes from approx 0.055 to 0. When it crosses the 180 line on the navball, HeadingDegrees jumps to 360. Actual heading 180 - 359 makes HeadingDegrees go from 360 to 359.945. So it\'s going down when the actual heading goes up (easy enough to correct, just deduct from 360), Ok, got it working! Rad to Deg is *180/pi, but you were close enough to point me the right way! Bit of a chunk of text (though I imagine some of the other values used to derive this will be of use) Vector3d upUnit = (position - vessel.mainBody.position).normalized; Vector3d northUnit = Vector3d.Cross(upUnit, eastUnit); //north = up cross east Vector3d heading2 = (Vector3d)vessel.transform.up; double eastComponent = Vector3d.Dot(heading2, eastUnit); double northComponent = Vector3d.Dot(heading2, northUnit); double headingRadians = Math.Atan2(eastComponent, northComponent); double headingDegrees = headingRadians * 180.0 / Math.PI; headingDegrees = 180 - headingDegrees; if (headingDegrees > 360) headingDegrees -= 360; if (headingDegrees < 0) headingDegrees += 360.0; Vector3d eastUnit = vessel.mainBody.getRFrmVel(position).normalized; //uses the rotation of the body\'s frame to determine 'east' Looking to see what I can do to reduce it *edit* Ok, the other method I found was in the MechJeb source (so clearly credit to r4m0n). No idea what MoI is though... Vector3d CoM; Vector3d MoI; Vector3d up; Quaternion rotationSurface; Quaternion rotationVesselSurface; CoM = vessel.findWorldCenterOfMass(); MoI = vessel.findLocalMOI(CoM); up = (CoM - vessel.mainBody.position).normalized; Vector3d north = Vector3.Exclude(up, (vessel.mainBody.position + vessel.mainBody.transform.up * (float)vessel.mainBody.Radius) - CoM).normalized; rotationSurface = Quaternion.LookRotation(north, up); rotationVesselSurface = Quaternion.Inverse(Quaternion.Euler(90, 0, 0) * Quaternion.Inverse(vessel.transform.rotation) * rotationSurface); vesselHeading1 = rotationVesselSurface.eulerAngles.y; double vesselHeading1; Many thanks for your help -= you never know, I may be back!

I think I love you. *edit* Right, so.... //unit vectors in the up (normal to planet surface), east, and north (parallel to planet surface) directions Vector3d eastUnit = vessel.mainBody.getRFrmVel(position).normalized; //uses the rotation of the body\'s frame to determine 'east' Vector3d upUnit = (position - vessel.mainBody.position).normalized; Vector3d northUnit = Vector3d.Cross(upUnit, eastUnit); //north = up cross east ... //direction in which the ship currently points: Vector3d heading = (Vector3d)vessel.transform.up; How would I turn that into a heading (just like the text at the bottom of the Navball, but with a tad more precision)? I figure it\'s the likely the bottom one? And in KSP, which plane is up? y or z? (Used to C4D, where y is up, but others use z)

What I could REALLY use is a couple of code examples of applied maths: eg, deriving compass heading/yaw, pitch and roll, and velocity vectors in m/s (handy for landing) from available vectors/quads - a 'paste this in and you\'ll find it in the double \'YourHeading1\'' job. I know that MechJeb, for example, has such stuff in it\'s source, but separating it from the mechanics of MechJeb isn\'t easy for a c# novice (and I don\'t like to butcher others\' code without express permission!) - plus having such references in one labelled spot would also make it easier for us novices. I know I\'d appreciate it, anyway. Y\'know, if there\'s enough maths to do on the various parameters the game creates to make them 'player useful', there could even be a call for a maths library plugin...

Cheers! Question about your source - any objection to my butchering it to my own ends? Have reached a bit of a dead-end in hooking the values straight from the DLL, but know I can make it work using your plugin. Basically I want to re-jig the variables that get exported to more suit external flight instruments as opposed to telemetry logging. Any publications would naturally credit you on the code template

Cheers - I tried that, and couldn\'t get it to work (the code seemed ok, but getting the data into the form eluded me). Either I\'m missing something fundamental (likely. It\'s been many years (pre-C) since I did any coding) or what I\'m trying to do isn\'t possible. If anyone can show an example of it working, I would be eternally grateful - just getting the current ship name from into the textbox without using a KSP plugin would be enough for me to do what I need to.

I\'m well on the way to making the LCDStudio plugin... but I\'m having trouble getting my head around the three HDG figures. How do I convert those into a compass bearing? *edit* Hmm, well - the plugin is kinda done. It works to stream the telemetry data onto the screen of my gamepad (and will work on anyone\'s little LCD screen). Having some problems with the actual data though. The Pitch, roll, etc. They\'re all rates of change, right? What I really need is current yaw/heading/pitch figures for the current craft/telemetry module. Any chance..? Otherwise the flight instruments won\'t look right...

Actually it\'s a form program - I\'m trying to confirm the data\'s availability before I write the .dll for LCDStudio. It\'s the 'You\'re calling a non-static variable as though it were static. ' bit that has me stumped. How do I correct that?

(I could of sworn I posted... maybe I hit preview and closed it? It is late...) Ok, found loads of stuff in Assembly-CSharp.dll through the object browser (only looking for public ones). Don\'t seem to be able to get to any of it, though. What\'s wrong with this? using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using UnityEngine; namespace KSPexplore { public partial class Form1 : Form { public Form1() { InitializeComponent(); textBox1.Text = Convert.ToString(Vessel.vesselName); } } } It SHOULD put the vessel\'s name in the form\'s textbox, right...? Instead it tells me: And yes, I\'ve added references to the Assembly-CSharp and UnityEngine dlls.

I\'m looking at using this plugin as a pathway to grab data to put on my G13\'s LCD screen. I was originally hoping to hook the data direct. I\'m not much of a coder, but so far I\'ve managed to create a listener form-program. Getting there. Is there a way to make the telemetry always-on (eg, with a command-capsule telemetry part or a .5m part to sit atop the command-capsule, but preferably without any parts if possible) or even togglable? Where might I find this Elderberry Ni thing so I can have a peek at your source? (Sourcy, nudge, nudge) Also, and here\'s me exposing my star-nublet credentials... any chance of a whole-word explanation of the contents? I have no idea what Pstat, Pdyn, Pmult, UTC or MET mean. Cheers for this plugin. Looking forward to having a look under it\'s hood! {Edit: Realised 'tmp' referred to 'temperature'. Oops.}

I may as well be explicit... I\'m looking at creating a plugin for LCDStudio to put flight-data on my Logitech G13\'s screen (and let other people put flight data on any LCD that LCDStudio supports). I\'m not much of a coder, and I\'ve only made one plugin for LCDStudio previously (puts data from X³:TC onto the LCD, but this works by having an in-game script send the data to a log-file, and the plugin reads that). The reason I asked about hooking into the DLLs is that this seems to be the main way that LCDStudio plugins work (such as the RivaTuner one that\'ll post system temperature data). I\'ve no idea if that\'s done by TCP/UDP or what, really... Any advice or help appreciated. If this is moving towards an in-game plugin tho, I may as well ask for this thread to be moved.... can you? (Wouldn\'t a good solution all-round be a plugin that sends out all this data to anything that listens, so anyone can build on that plugin with external apps...?)

Wasn\'t entirely sure where to put this, as it\'s not for an addon or plugin for KSP itself, but for a companion program for something else... What I\'m looking to do is use a program to hook a game .dll and read various variables, such as attitude, altitude, orbit details, velocity, etc in realtime (or with at most a half-sec delay). Is there a .dll I can hook into to grab this information, or would I need a plugin to expose the data? Does MechJeb do that already...?

Seems the download link was broken by the forum migration (or something. It broke). Fixed now

And LOD system would be good, agreed - though I disagree that 24 edges are needed to make something look round in-game. Heck, given the amount of screen real-estate it actually uses, 12-18 is plenty, I think.

My LE weighs in at 1,208polys, including the collider - surprisingly high. I think one of the biggest culprits is actually the stock settings - a standard 1m tube has 24 sides! So just to make a slightly curved (3-step) engine cone, you're already at 72 polys, and that's only one surface! 24sides for a cylinder seems a tad excessive.

It did it to me when I forgot to replace 'x, y, z' with actual numbers when I pasted a bit of code in. If you post your edit, we can probably spot your mistake

Ah, you edited the old entry (for the wing) and turned it into a pack-part entry... which'd be why it was submitted to your repository 2days before I released the engine You can see why the confusion