Addle

The working version for the latest KSP is a pre-release. It should show up once the proper release is done. The previous release wouldn't work with KSP 1.1.x, and so won't show. Hopefully, I will have time to devote to that around the weekend.

Odd, I haven't noticed the iron duplicating, though it's been mentioned. But only did some simple testing. I'll try and get that to replicate and see if I can fix it. If you know what you did when it duplicates, let me know. Granted, if you have 5, I probably will be able to make it happen. heh

Hey mrenigma03! Good to see you here. Thanks for the compliment! Let me know if you ever want to hop back into Protractor development. XD So, folks, any feedback on the pre-release? Any bugs you've found? I do seem to get an error in the log relating to the GUI, but it doesn't seem to be breaking anything. On my end, not found anyone to fix the model yet, alas. Not quite sure if I even have the original model to fix or not. I think it might be the model.mdl file, but I am quite ignorant when it comes to modelling. If I must deprecate it, perhaps there's a way to hide it in the part list without removing the part. Then after some time, it could be removed with some advance warning. Best case is obviously to get it fixed. If anyone here has modelling experience and knows how to do this, do tell! All the files I have are in the Github.

A new version is now up on my Github as a pre-release. Seems to work acceptably so far, but there may certainly be issues. For one, the colliders seem to need updating. But you no longer need to put the parts on your vessels, and I suggest you not add them, at least until I can get them fixed. You may find it here: https://github.com/RealGrep/protractor/releases/tag/v2.8.1pre1 Please report any issues to me! And, of course, big thanks should go out to Z-Key Aerospace who did the update work to KSP 1.1.3! And I know I technically don't need to apologise for taking a while to get this done, but I'm Canadian, so sorry it took so long! I'm mostly waiting to fix the colliders before I make a full release, but I would also like to find and zap any other issues found. There was major surgery performed on it when I refactored it. It should now be more easy to make it work in the tracking station and other places in which it makes sense, which is part of the reason I did all that refactoring (other than it really needed it, generally). That isn't in yet, but is something I have in mind for the future.

Ugh, you're right about that. Well, maybe I can find someone to fix it for me, or figure out how to fix it.

Interesting, yet annoying. lol Ok, I'll take a look after I get other things going to my satisfaction. I don't know much about the models or updating colliders, honestly. But the easy solution may be one I sentimentally didn't want to do: Remove the useless parts entirely. It's partless now, anyway, it doesn't need them. But I do love that TI calculator strapped on with duct tape. heh

Thanks for keeping this going, Z-Key Aerospace! Though I won't have time for another little bit to do much, what I *can* do is keep a close eye on my Github for pull requests, so feel free. We can work off that repo if you like. Though I'd rather not fracture it, but of course, the license is permissive and you won't hear any complaints if you release your own version. Just make sure to change the name in some way to avoid confusion. But much better to just join forces and collaborate.

I do, yes. Sorry, haven't really had the time to do much yet, although I do have some changes waiting to be released. I'll start porting it to 1.1 fairly soon, I hope. But yes, I don't intend to let it die.

[quote name='Fwiffo']I've been using this mod just fine in 1.0.4. Has anyone tried it yet in 1.0.5 and can you confirm whether it works?[/QUOTE] Haven't tested it extensively, but it seems to work fine.

Wow, that's rather interesting. The only time I ever save the settings is when KSP tells me to by calling my OnSave method. So KSP seems to be sending a ton of save messages. Not sure what I can do about that. :/ Yes, that's where it saves its settings, so it's interesting if it hasn't been modified recently. Not sure if it'll actually write the new data if nothing has changed, though. I'd have to test that. Still, even moving the window around would be enough. Wonder if it's trying repeatedly to save, but can't, for some reason. That part of Protractor is mostly unchanged from way back, so surprising to see an issue there. Are there other ships in physics range at that time? I've seen some strange behaviour in that department before. Might help me replicate it, though, if so. woot, any clues as to what is giving "input on null" errors? Relevant log entries and such? That I might be able to do something about, if it's related to Protractor. Anyway, sorry for the slow response. On a bit of a KSP break. But I'll keep an eye out on the logs and see if I can replicate that. I'd guess something's wonky with KSP, there, though. Like I said, I just save them when KSP calls my OnSave method. The rest is up to KSP. But if I can replicate that, perhaps I can either pinpoint the issue or at least file a bug report on that behaviour. Or perhaps it'll fix itself with the new version (which I rather need to put more work into). It's now partless and that stuff might improve. And, of course, if there's any other relevant info you find that can help track down the issue, let me know. Thanks for the bug reports, folks.

Thanks! And Tontow, there's no export at the moment. One thing that should be possible is make a button to create a manoeuver node. MJ and the rest of the game would then see that. If so, I might also put in a checkbox to disable that from showing, in case it bothers someone. I shall see. For now, I'd like to do more refactoring of the code. I only split things up better, but it needs general cleanup. But I'll keep that in mind as I work. Exporting a KAC alarm wouldn't be a terrible idea, either.

That's because you're using an incredibly ancient version before I took up maintenance. The proper thread is here: http://forum.kerbalspaceprogram.com/threads/83173-1-0-x-Protractor-Continued-Rendezvous-Plugin-v2-5-1-%28May-15th-2015%29 That bug was fixed ages ago, as the version you must have pre-dates the introduction of Kerbin time. So it's assuming 24 hour days and so on. EDIT: Just realized the issue you're seeing is something else. It's because Protractor assumes circular orbits and estimates based on that. Which means elliptical orbits throw off the time estimates. When things reach zero, it's still time to burn, but the time/date estimate can be off leading up to that. Let's say Moho is on the long leg of its path, then it is going slower and it will take longer than the prediction, and vice-versa. Yes, I'm looking at fixing that, though not 100% sure what the best way is.

Not sure what you mean by the first question, but the second one, basically, yes. Protractor understands slingshots like moon->reference body->planet. For example, it will take into account the Oberth effect on a Mun->Kerbin->Duna slingshot. Click on the "?" button for instructions. It's ok, I love to hear it. XD Thanks That's exactly right. You can also get times instead of angles by clicking on the relevant column titles. The ejection angle (psi) can be adjusted for your burn time with the "Adjust Ψ" button. Basically, wait until the right time, and burn prograde until the closest approach is as close as you can make it. I generally then wait until the next ascending or descending node and do a plane change onto the plane of the target. Gets me there every time. Small tip: It's far more important to burn at the right ejection angle (psi) than the right phase angle. You have a fair amount of time during the transfer window to make the transfer, but you need to eject accurately. I like the "burn prograde" thing. It's more efficient than slavishly burning a node, and won't slam you into the planet for long burns. Progress report: Refactoring is doing very well. Tested it quite a lot last night, and will do so a bit more before I release. Probably should get some people to test it out for me as well. All checked into github.

Some major surgery has been done on Protractor, tonight. It will need some serious testing before I trust it, but I refactored the code quite a bit, splitting stuff out from the main file and isolating the logic and math and the data from the display code. The upside of this is I can now update the data at regular intervals instead of whenever there's a redraw. The data refresh interval is configurable in the settings. This should seriously reduce the computations done, and hopefully minimize any impact Protractor has on your game speed. I've also added AppLauncher support to replace the old venerable icon. Toolbar is still used if you have it. Things seem to work quite well so far! Anyway, just thought you'd all like to know what's coming. This will make further changes much easier. For example, I would really love RPM support so we can do transfers in IVA. Changes are in Github, but I will need to test it before I actually release this version. ETA depends on whether I find any bugs, and how much testing time I can find.

Thanks again, it's great to hear from people who enjoy the mod. Makes keeping it alive worthwhile. I'm planning some refactoring of the code soon, which should enable me to do some of the things I've been meaning to do with it. Until then, there was a change in the way the API reported engines I need to take into account for burn time calculations. That meant it was considering all engines on the ship and not just currently enabled and/or staged ones. Burn times were obviously wonky. I've corrected that and it should be giving its usual roughly accurate burn times once again. (I also need to get that fix in for NavHud. heh) So here's version 2.5.1, with burn time fix. As usual, available here: https://github.com/RealGrep/protractor/releases