Addle

Members
  • Content Count

    108
  • Joined

  • Last visited

Everything posted by Addle

  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. Ugh, you're right about that. Well, maybe I can find someone to fix it for me, or figure out how to fix it.
  6. 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
  7. 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.
  8. 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.
  9. [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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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
  16. It'll need some modification, of course, since it doesn't have a ship for the calculations. So you'd mostly just get the phase angle/time to phase angle of 0. Really, I think it needs some serious refactoring to accommodate that sort of change. It really needs it. Definitely something I'm keeping in mind, though. No worries, I have definitely not forgotten. I'll also add a pointer to Malah's nice mod that allows it to work without the part, later today. It sort of solves that problem rather nicely. How great is module manager? heh
  17. Not without code, which is the next thing I plan to implement. So you can expect that to happen in the not too distant future. I figure it's better to fall back to that if Toolbar isn't there than that custom icon I currently have. Thanks for the input!
  18. Arch Linux. It's my favorite so far, and very nice, but not really for everybody. Mostly because updates are on the command line and sometimes require you to manually merge config files. The installation is also command line, but the docs are fantastic. On the other hand, it's a rolling release so there are no big upgrades to annoy you at regular intervals. None of those things bother me one bit, and the rest of the desktop and such is pretty much like any other distro. Worth checking out and maybe trying in a VM if you are curious, IMO.
  19. Ah, I see. Yeah, for moon transfers, the theta symbol (before that phi symbol) is what you want to look at. It won't be adjusted for delta-V, so you want to find out the length of the burn, divide it by 2, and start your burn that long before it hits 0. Click on the theta column header to swap to time, and the delta-V column header to see the estimated duration of the burn. But you have considerable latitude on the burn timing. Keep a close eye on the closest approach distance, and burn until that gets as close as you want it, or as close as it gets. If there's an inclination difference, get it as close as you can, and do a plane change during the flight to get it all the way close enough. Hope that's clear and helps you out. If not, well, you also know where you can often find me (on Twitch).
  20. I have no idea where you got this, but it is completely false. I mod the living heck out of it, and it never, ever crashes or bugs out on me. And yes, it exceeds 4GB. And that's not an isolated experience. I know many people running it with heavily modded installs exceeding 4GB who have no issues at all. I have maybe 2k hours with it over various versions, and I have had 3 crashes in all that time. The last time was a very long time ago. That's almost unheard of levels of stability. tl;dr 64 bit KSP for Linux is beautiful.
  21. Thanks for the kind words, everyone. They really are appreciated! <3
  22. Great! Well, I actually finished implementing it. But I won't complain. It literally took me 5 minutes (even worked the first shot!). lol I'm also implementing an option to hide things when you hit F2 to hide the UI. Following the principle of least surprise, it will default to hide it when you hide the UI, but there's a new toggle for it in the settings. I also put the settings into two columns since it was getting a little long. That'll give us more space for more toggles, if needed. Anyway, what I'll do is merge your changes to mine, and we can push that back to yours. It's just undergoing some testing before I check it in. Great news on the AppLauncher stuff, too. Next version will be nice. Oh yeah, and I'm also putting a wildcard into the max version of KSP supported (in the KSP-AVC .version file) so it won't complain for anything like 1.0.*. That will save us some headaches. It should not really break on 1.0.x versions. Anyway, everyone, shouldn't be too long before we release the next version. EDIT: Ok, Ninenium, code merged and pushed. Tested, and seems to all work well. Thanks!
  23. I mostly agree. It does what it does well, without a bunch of complication. Maybe two small things I'd change. Maybe some kind of simple interface to tweak the config values without editing a file. And the default values seem massively unbalanced. You accumulate far, far too much in funds and rep, IMO. So I'd probably dial that back a bit by default. That said, editing the file is simple, so these are not huge issues. Not sure I entirely like waiting to get the funds/rep. On the other hand, you really do get a lot of notifications. Maybe just a combined report in one batch, when you return? Thanks for a mod which really makes career a lot of fun for me. I appreciate it.
  24. Yeah, that's a high priority thing for me to fix, actually. I also have both showing, and it's rather unnecessary. Thanks for reminding me.
  25. Darnit, Blizzy, check IRC. XD The date calculation is wrong, but super easy to fix. In Extensions.cs, around line 61 in 'convertUTToHumanTime', in the year = line for KERBIN_TIME, you have a 24 in there which should be a 6. This is why it's correct for a while, but at some point, you'll be in year 2 and it will read year 1. Love this software. Much <3 to you, Blizzy!