khyperia

I believe this is due to a longstanding bug in the lander, where after teleporting, some frame of reference is incorrect and KSP's velocity calculation is off. I think that the velocity of the ship is calculated in an orbital reference frame, whereas the surface is in the surface reference frame. An interesting case is that the navball states a surface velocity of near-zero, but quite clearly there's a movement >50m/s over the ground. That reference frame mismatch causes rapid translation of the vessel over longitude in unpredictable but consistent ways before OrbitPhysicsManager.HoldVesselUnpack times out and "normal" physics kicks in - in this case, going straight into the side of a hill. This is why the PQS GetSurfaceHeight is "incorrect" - you're not actually at that lat/lon anymore due to the translation. I've attempted to fix this multiple times in the past and have never been able to find the source of the mismatch.

There's been a prebuilt version for a while now, available on http://www.kerbaltek.com/hyperedit the Beta2.dll You're also free to clone and build it yourself, I tried to make it as easy as possible to build.

Yeah, I just pushed. Also includes the button for "vessel up is up". https://github.com/Ezriilc/HyperEdit/blob/2c392d8481f6b4734f8f614533d76620e0ba4aed/Model/Lander.cs#L392 Relevant code (extracted) is: var oldUp = vessel.orbit.pos.xzy.normalized; // can also be vessel.vesselTransform.position, I think var newUp = teleportPosition.xzy.normalized; // teleportPosition is the orbitspace location (note the .xzy) var rotation = Quaternion.FromToRotation(oldUp, newUp)*vessel.vesselTransform.rotation; vessel.SetRotation(rotation);

Hmm. I implemented something in the dev version, it will be included in the next release - when teleporting with the lander, orientation is preserved. That is, whatever was up (relative to the planet you're currently over) will still be up after you click "land", no matter where you teleport to. I'll likely also add some absolute orientation buttons by the time it releases (buttons such that vessel up is up, vessel forwards is up, etc.).

There is no good way! That's why it's not implemented in hyperedit. You could use Vessel.forwards (or whatever field it's called, don't have the api handy right now), but what if the ship is a plane, not a rocket? Then forwards would be up! There's no good way to determine which way a user intended a vessel to be rotated, so I said it's best to just let them deal with it.

I think this actually might be our fault and not another mod. I just uploaded HyperEdit_beta1.dll on kerbaltek.com, could you download that one (and replace HyperEdit.dll with it) and see if the NullReferenceException is fixed? I think it's due to a bug in the "land here" function, and me not updating it when I added the move-when-landing (ijkl) feature.

I'm not sure what you mean by "accurate", but it certainly still works. As to what it is relative to, I'm not entirely too sure - the KSP documentation doesn't say much (actually... nothing at all), but I'm guessing it's relative to the rotation that it was modeled/created in. That, of course, doesn't make much physical sense in-game - so it's probably best to play with that parameter while actually looking at the planet, to make sure it's in the right orientation.

Wow, super neat mod! Judging by people's reactions, this was something seriously lacking in hyperedit (although nobody ever requested it...). Kudos to you for implementing it!

Well that's dumb. You probably want to get that looked into and fixed. http://www.kerbaltek.com/_downloads/hyperedit/HyperEdit-1.4.1_for-KSP-1.0.zip

Oh boy... I've heard stories of this type of problem in the coding world, never actually encountered them myself. Kind of amazed I haven't run into something until now. However, I think the problem might not be related to your localization - in particular, there was a nasty bug related to saving and loading landing coordinates in the main release. Could you try out the "HyperEdit_hotfix.dll" linked at the bottom of this page? http://www.kerbaltek.com/hyperedit Simply rename it to "HyperEdit.dll" and replace the other downloaded dll with it. If you've already done that, then... hmm. I think I might know the problem, but I'm not sure. I'll look into it. In the meantime, could you make sure you're using the hotfix?

You appear to be un-checking "rotates" and checking "tidally locked". Tidally locked does not mean "does not rotate". You *need* to leave it checked when setting kerbin to be tidally locked - kerbin in general does not enjoy not rotating (other planets are fine, though). Works fine for me when rotates and tidally locked are both checked.

This was already requested a few pages ago - http://forum.kerbalspaceprogram.com/threads/37756-0-90-HyperEdit-v1-3-Dec-17-2014-Teleporter-Orbit-Planet-Editor-More/page70 basically, no, because doing so would turn the Simple menu into exactly what Complex is - so why not just tab over to Complex anyway? Simple should stay simple.

My apologies, I re-worked a lot of things and apparently forgot to test that one. I fixed both these problems, you can download the fixed dll here http://www.kerbaltek.com/hyperedit at the bottom, the hyperedit_hotfix.dll (I don't have access to the main download area, so I'll have to wait for Ezriilc to get on for that to be updated) Edit: Also fixed the planet persistence problem. (hey, at least that one wasn't my fault, Squad did weird things with their code)

Just a quick note, the reason that I made it this way (allow one to teleport high above the surface and slowly lower down) is because there's no good, easy way to rotate a vessel with KSP's API. Anything that I could hack together would likely be fairly explodey. Also, there's not really a good way to get the "up" of a ship - what if it's a rocket, then forwards on the cockpit is up, but if it's a spaceplane, then up on the cockpit is up! So sorry about the inconvenience, if you have suggestions on how to make it better I'd be happy to listen, but that's as good as I could come up with.

This makes absolutely zero sense whatsoever. Are you absolutely certain that HyperEdit is the cause of the issue, and it's not just a coincidence that uninstalling it "fixes" the issue? HyperEdit does not interface with maneuver nodes at all in the codebase, not even a mention of the word "maneuver", so I'm entirely baffled how hyperedit could be the issue. Edit: Tried to reproduce the issue myself, was unable to even with hyperedit installed. I guess if you're still having the issue, try both the current version of hyperedit as well as the beta located at the bottom of the page here - http://www.kerbaltek.com/hyperedit

So a few weeks ago, I hacked on a small project that translates .net cil to kOS assembly, which essentially allows you to write a subset of C# that will run on the kOS virtual CPU. There's still a lot of things that need implementing, but I'm wondering what the interest levels are for this and if I should continue working on it. Thoughts? (I intend it to be eventually opensource, but as it's a tiny very-broken bit of code right now, I haven't put it on github yet) Also, I have quite a few questions about kOS that I can't figure out by looking at the source code, so I would really appreciate it if a kOS dev member would poke me on irc (#kspmodders, I'm also khyperia on there).

Ah, yeah, that would make sense. Right now the only for-sure workaround requires more code in hyperedit from me, which might be getting done in the future. Although some people have reported that teleporting to a very high altitude around Kerbin works, and then lowering altitude to a sane level.

I've never encountered this problem before. Thanks for the detailed description, but the only thing I can think of is that you forgot to activate the first stage before/after teleporting - because when the first stage isn't active (normally when you're sitting on the pad), you can toggle RCS and such, but throttle doesn't work. If that doesn't fix it, try sending the .craft to me and I'll see if I can duplicate the problem on my side. - - - Updated - - - I haven't changed anything recently about teleporting... have you installed any mods lately, like DRE or similar? There's been some problems with that mod. Make sure you're on vanilla and the problem is still happening.

Could you send over a .craft, and share what you think might be key elements in it not working? It's hard for me to "fix" something without being able to encounter the problem myself - because it works fine for me for all the things I've tried (that's not to say there's not a problem, just maybe I haven't encountered it yet).

I am really confused by your description of the bug... do you mean all the sliders only affect mean anomaly? Or what? I'm not sure what you're saying. Have you tried the Complex editor as opposed to the Graphical one? Does that still fail (please describe the problem in lots of detail), or does it work? Have you tried uninstalling all other mods and just using hyperedit, and seeing if the problem still exists?

Well, if we add inclination, then we should probably also add LAN, and if we're going to add that might as well add eccentricity too because that's also a fairly useful thing, which means we need argument of periapsis as well... wait, that's the exact same thing as the Complex/Graphical editor.

Yes, there should be a "Save planet to config file" button on the bottom of the Planet Editor window. This creates a file in GameData/Kerbaltek/.../planetname.cfg that you can delete if you want to reset it back to default. This file saves the position/properties of the planets to be re-applied on game restart.

Well, does it happen *without* DMP? If yes, then it's obvious the problem is with hyperedit and I can probably fix it. If not, then we've got a serious problem that I wouldn't know where to start on. My advice would to set "lead time" on rendezvous to something large, so that you're farther than 5km or whatever the load distance is. Hopefully no zooming occurs (I'm guessing the cause of the zooming is loading of vessels and wonkyness on DMP's side), and then move closer somehow. Also how fast is "ridiculous"? It's actually a fairly important value - if it's <4km/s, then it might be due to orbital velocity changes not getting updated. If it's something insane (10Mm/s) then it might be due to calculating dV on a per-frame basis. There's a bunch of other values/reasons it could be happening.

Going through the commit list (like Ezriilc said), here's the things I came up with (I really should keep track of this): Land button now clearly is a toggle instead of just saying "Land/Release" Re-enable parsing of SI suffixes, so you can use them, but don't print things in SI format (so you'll never see them if you don't type them in) Massive GUI overhaul, lots of things changed internally here, but not much outwardly (except things like small X button instead of big close one) Integrated help system (hovering over labels shows text beneath the window, instead of having a huge help window). Help window got re-purposed to be the about window. Overhauled the teleportation system of the lander, hopefully less explodey. Made resources be individual sliders instead of "refill all" button. Ability to save planet locations (persists across restarts). - the following is in the Beta builds - Added a HyperEdit button to the top right (where the resources/etc stuff is), so you don't have to hit alt-h anymore (but alt-h is still enabled) Re-added the Copy To Kerbin planet editor button (it got lost in the giant UI overhaul). Save window positions after you close them, so they open in the same spot. Disallow multiple windows of the same type (after the UI overhaul, you could open 50 hyperedit windows, heh)

Thanks for the feature suggestions! Disabling in certain saves is a neat idea, I'll see if I can do it. I think the copy to kerbin button is accidentally gone, must have been eaten by the big rewrite I did. Thanks for pointing that out! As for holding persistent text fields, that may or may not get implemented in the future - but is there any reason why you can't save/load the coordinates?