Ezriilc

Thanks to the MechJeb peeps! Loving the quick update. You guys rock! Now that both HyperEdit and MechJeb are working on the latest version, all is well once again in the Kerbin universe. NICE.

The update of HyperEdit to version 1.2.2 is complete! Downloads and information can always be found on our website at: www.Kerbaltek.com sirkut discovered that the KSP .dll files had changed, so we needed to re-reference them, and that seems to have fixed it. Please test it well and let us know if any new problems exist since the update. Forecaster has created some cool in-game Flags that are also included with the new download. You'll see them in the Flag list. Thanks again to sirkut for getting on this so fast, to Forecaster for the great flags, and to everyone else for caring about HyperEdit.

I should have the new version uploaded in just a few minutes. I'll repost here as soon as I do. Thanks to sirkut!

About the new update, I know that our coders are busy people, so I'm not going to pester anyone, but since I'm just not up to speed yet, I'm unable to do much without them. I will however at least make an attempt at it, and who knows, I might get lucky. Otherwise, I have no doubt that we'll get HyperEdit updated quickly. In the interim, let's try not to freak out too badly. I usually use HyperEdit and MechJeb on most flights, and I must admit that I feel completely naked without them, but today has been a fun return to the basics of flight control. MJ is a much better stick man than I. The error I see in the log, that only seems to show when the HyperEdit .dll is present, is: I found another thread here about the F-12 hotkey not working, that mentions this error, but that is the only hit Google offers, so there isn't much yet for me to work with.

That's on our list. You'll find a list of To-Do items and Frequently Asked Questions on our site.

Of course.

You're right; I never replied! Sorry about that - it's my intent to always provide some kind of response to every request. I've added this to our To-Do list which is now on our site. I have a hunch that there might be a way to disable physics temporarily on the entire craft, and then re-establish it in a controlled way after teleport. However, KSP vanilla doesn't seem to handle that very well on its own, so it may be more complicated than I'm picturing. Not being fluent in C# or Unity yet, I'd need to run it by a capable coder, but I'd start with Unity's Rigidbody physics component, or however KSP does it, and see if it can be removed/disabled and then replaced on the fly. A solid technique for doing this could prove useful. I also suspect this may be related to other weirdness on teleport, like engines/stages firing, RCS bursts, etc.. Again, I could be way off, 'cuz I'm a total noob.

Cool tool. Fixing/improving the number representations - including coords - is pretty high on my personal priority list, and I believe that SolarLiner is working on that already. That is, when I'm not slowing him down with endless questions about GitHub. If anyone wanted to tutor a complete noob in open source collaborative workflow concepts, I wouldn't refuse it . Did you have any specific issues in mind? I'll add them to our list. I've already submitted code changes to remove the F11 activation hotkey - which was easy enough that even I could do it. That will be included in the next release. I could release an update just for that, if anyone really wants it. The current version works great, and improvements will come; either when I learn C# well enough, or when someone else makes successful changes that: Don't screw up what The Creator built, include bug-fixes and features from our list of priorities, and produces an unquestionably better plugin. With no major issues to speak of currently, we haven't felt any rush to mess with The Creator's code, but I trust Team HyperEdit to step up if and when the need arises.

Thanks for the idea. At this point, I'll add it to the list, but I'm not sure how much of a priority it will be. Migration tools are notoriously difficult to maintain, as they tend to be one-off shots for each update, and we won't really be able to even start until each update comes.

My guess exactly.

I think it was finally moving the time forward that corrected it, but that's a guess. With the problem above, I was also unable to toggle the lights either.

I've discovered a rather strange effect that appears to be caused by changing the time with HyperEdit. Problem: SAS can't be turned off, preventing the ship from being turned (tries to, but just wobbles), with all other functions working as expected, RCS, throttles, engines, power, etc. Cause: After changing the time from ??? to 18000 on Kerbin, with HyperEdit's "Misc Tools", the MET (Mission Elapsed Time) clock began to run backwards(!), with T+ counting DOWN. Fix: I reset the time (a few tries) to bring the MET closer to zero, and at some point it began to count UP again. Immediately after that, I was able to toggle SAS normally, and all seems well. EDIT: I've speculated that I may have moved the time back far enough and then forward again which ultimately fixed it, but it's just a guess, and I can't really remember. I didn't do much other testing, but it seems to be caused by some relationship between two or more time markers going from positive to negative or vice-verse, which is borking the SAS toggle function which seems to rely on the forward/upward count of time. As for what might be done in HyperEdit to deal with it, sadly I haven't a clue, so all I can do is report it, and put it on my list. Perhaps its just a matter of making the time set only move time forward and not backwards around the dial. This problem seems possible to explain some similar issues I've seen elsewhere with SAS getting stuck on, but I don't know if anyone has identified HyperEdit as a cause until now. Remember, knowing is half the battle! Hopefully, it helps someone stop pulling their hair out like it did for me today.

Actually, yes! That's something that even I can do (yay, I'm useful). I need to hear from the rest of our team to make sure that removing the F11 hotkey doesn't create any problems. I can't imagine that it would, but I'm rather new to the project and I can't make any decision alone. I think that a text-based configuration file is a good idea to allow easy changes to things like hotkeys and other behaviors. I'm adding this to my list.

Actually, yes! That's something that even I can do (yay, I'm useful). I need to hear from the rest of our team to make sure that removing the F11 hotkey doesn't create any problems. I can't imagine that it would, but I'm rather new to the project and I can't make any decision alone.

I just stumbled in here and saw this tool. I think it might be answering some questions for me that will help to improve HyperEdit. Feel free to post anything even remotely related to your use of HyperEdit into our thread. This is very interesting. Perhaps I could build something similar into our website.

Yea, I hear ya. I'm afraid I can't think in C# well enough yet to come up with a fix, or even know if one is possible really, but others might. I was thinking of doing it just prior to whenever you determine the fault is happening rather than after, but I'm not sure what it might tell us. A very strange thing, that. I'm taking notes, but I'm ****ed for ideas.

Oh, and have you tried jamming a save-exit-restart in between all those steps?

Tip: When using HyperEdit's Land feature, the ship falls very slowly until some part of it contacts the surface. Setting the Altitude higher will give you more time to right the ship with flight controls before it touches down. Thanks for all the detail! So, it's not the rover's panels but another ship's. Can you do a test in steps to isolate the moment the panels get broked? Land habitat, then check that panels are OK. Change scene to VAB/SPH or another ship, then right back again. Panels still OK? Change scene to get rover launched (using HyperEdit here?), then back again. Panels still OK? Change scene to put rover around Duna, then back again. Panels still OK? Change scene to land rover, then back again. Panels broked now? [*]Have you tried retracting the panels before leaving the habitat's flight scene? [*]Are any other parts affected, like ladders, legs, lights, etc? [*]Does it happen with panels on a habitat that was landed without HyperEdit? I know this takes a long time, but it might help.

Benie, Thanks for the report, and I'm sorry you're having trouble. First off, what do you mean by "HyperEdit a rover" specifically? Which HyperEdit feature are you using? What do you mean by "gone"? Are they removed entirely or just broken like from G forces? What is the exact sequence of steps required to recreate the issue, from starting the game to the problem? Have you tried a different rover-panel combination? Can you send us a copy of your .craft file? You can paste it into our Contact form on our website. Does it happen on other planets like Kerbin? Just a reminder. Solar panels must always be retracted before moving a ship, AFAIK. Even RCS docking maneuvers can break them off. I realize this probably doesn't help much, but it's a thing. I'm sorry I can't be more help at this time! I'm still more of an administrator than a real coding expert, but I'm learning. I have however put this on our list, and I'll make sure that somebody helps you, one way or another. I fully expect that someone else will jump in here and save me, like always. In the meantime, you may be the best one to do further testing on it. Please tell us if you learn anything more.

Wait, Kerbs can repair rover wheels?! NOW you tell me! (added to list)

Oh, I'm sorry I confused you. I'm good at that. However, I say so much in the hope you can pick out something useful, and you have, so good! But... no, silly. Don't write the coords down (caveman), use the "Save" and "Load" buttons. I expect there is a minimum resolution at the surface (known in the military as "clicks"). Meaning, that not all points on the surface can be teleported to, and so you'll snap to the point nearest the coords. This is only an hypothesis, and I haven't tested it at all. It could be that "Set to current position" is actually rounding out the numbers. MechJeb and other plugins can give you your exact position with fine precision, if I'm not mistaken. That might help you to refine your waypoint. This kind of thing is what I intend to iron out. I like an interface that people just "get", ya know? It should be intuitive and do what the user expects in as much as possible.

Oh yea. As you may know, you can press the "Set to current position" button to show and save a location. The notation of those values may give clues to the inner math, as could looking at the source. The default saved coordinates file, ".\GameData\Kerbaltek\PluginData\HyperEdit\landcoords.txt" contains these two locations: Airstrip Island - Wet,-1.498,-0.72088h KSC Runway Beach - Wet,-0.435d,-0.7439h You'll notice the lack of cardinal directions, the negative values, and the "h" and "d" suffixes, which seem to just confuse me. If (big if) the coordinates are mapped to a Merkator projection (rectangular atlas), then as you move away from the equator, the scale increases to infinity at the poles, which would drastically affect the meaning of these location values (and may not be possible, I'm just spit-balling). So, other coordinate system and projection would likely also make huge differences, so the seemingly bizarre results we see might be explained by the answer to which KSP uses. After all I've written, it'll be funny if the answer is just a one-liner.

I probably should wait until Devo, sirkut or another HyperEdit expert responds, before I say something stupid (too late! ), but I believe - and there's a short blurb on this in HyperEdit's "Help" screen - that all units are standard "Si units", and instead of degrees N/S/E/W, surf coords are represented as +/-, x/y. Now, I take that to mean: (N = x>0), (S = x<0), (E = y>0), (W = y<0), but I'm not confident about this. Also, the numbers have multiplier letters (d/h/etc., days/hours/mins?), and that's where I get lost because in my brain (not fluent in Si units), degrees should be in there somewhere, and none of the multiplier values I try for those, even from the Si list, seem to work out like I expect. While writing this book/post, I got to thinking about the various "projections" used to make a global atlas fit on a 2d map. So, question for the community: Which coordinate system does KSP use for planet surfaces? Is it one of those listed here?: http://en.wikipedia.org/wiki/Coordinate_system Admittedly, I haven't taken the time to study all this much, but I do think HyperEdit's interface could be more intuitive. "The Maker" (of HyperEdit) did the hard part for us, now I'd like to pimp it up a bit. Changing and/or clarifying the input units throughout HyperEdit is high on my personal priority list, but others may consider other tasks more important. On that note, setting up our task list priorities according to the community's priorities for each task is another task that's also high on our soon-to-be prioritized list of tasks. Someday, I'd like to add many more interface aids, options and go-fasters to all the features in HyperEdit -such as making "Refill resources" variable and tank/batt-specific, including and not limited to: sliders, up/dn/lf/rt incrementing via arrow keys and mouse, auto-complete/history buffers, customizable/trigger-able hot-keys and presets, and even GUIs where possible. Like if MechJeb's ascent path plot image were draggable. I'm not "qualified" as a coder yet, but I'm hoping that this type of thing isn't too difficult. Regardless, it's almost certainly pretty low on the priority list. In this particular case, the holy grail fix (IMO) would be a 3d graphical representation of the planet's sphere (is it possible to add another scene to KSP or mimic/use MechJeb's "Choose target on the surface" feature?), with an adjustable grid/scale, and one or more draggable pins to mark positions. Of course, with a readout/input to show/enter coords and make other tweaks like "Slew __ clicks N/S/E/W", "Snap-to-grid", "Nearest coast", and whatever else is awesome. It could even evolve into a waypoint based navigation system of some sort, even though I have no idea why that might be useful for a teleporter, but hey.

There is also a "Help" button in HyperEdit, that shows some useful info, and directs to external resources as well, like Wikipedia for orbital components. However, that info isn't very complete IMO, so I'm adding it to the list for fleshing out. I'm a big fan of comprehensive internal help systems.

I honestly have no clue, just heard of Unity, and know almost no C#, but since you're still waiting for a reply, and I'm interested, I'm going to investigate. Don't expect much. :|