Error_Sophius

For those following this thread, Draggable Controls has been released, and supercedes both Draggable Navball and Draggable Altimeter. There's no pressing need to migrate if Navball/Altimeter suit your needs, but they will not receive further updates. Also, @HebaruSan, I didn't see your post until just now; thank you for reporting the versioning issue upstream (and that is a fantastic bug report, I wish all bug reports I got were that well-described). Shame that it doesn't seem to have gone anywhere, but it looks like spacedock's codebase may not be under development anymore. No non-bot commits to master in over a year. :-(

For those following this thread, Draggable Controls has been released, and supercedes both Draggable Navball and Draggable Altimeter. There's no pressing need to migrate if Navball/Altimeter suit your needs, but they will not receive further updates.

Following on to the last note above: LGG proposed making the navball vertically draggable. It's not something I ever thought to implement because I have no need for it myself, but I don't have a reason *not* to. I'm just figuring out the interface for it. Some possibilities: Add a settings toggle for it Make drag-with-rightclick 'unlock' the vertical position for the duration of the drag Double click on the navball to lock/unlock vertical drag Something else I haven't thought of. The other difficulty is snapping the nav cluster to the screen edges properly. My partially-implemented unlock just remembers the navball's vertical position at startup and snaps to that, but that doesn't work for the other screen edges. I can clamp an object's position to arbitrary values easily enough, but what I actually want to clamp is its *bounds relative to the screen*, and I'm not sure how to get those. If anyone knows how to do that, drop a line below. (there's also the thing where the width of the nav cluster changes depending on whether SAS is on or a maneuver is active...)

Draggable Controls I've always found the navball's default position irritating. It's directly under your rocket, often blocking a non-negligible chunk of whatever you're looking at. Vertical space is scarce on a widescreen, and the navball uses way too much of it. It should really be off to the side. So a few years back I made Draggable Navball, a mod that lets you drag it somewhere more convenient. While stock has added a settings slider for the navball position since then, it's still nice to be able to adjust it on the fly. Some others found the altimeter's position irritating, so I made a similar mod for that. Draggable Controls merges the two, and is intended to supercede them. It's mostly useful to people with a multi-monitor setup, where there's lots of empty space to use. Credit to LGG for the name and for staying on me to actually do this. Notes Draggable Controls is intended to supercede navball/altimeter. The latter probably won't receive any more updates. Not that they needed many in the first place, but still. v1.0.0 is intentionally feature-identical to navball+altimeter, to minimize migration surprises. Now (august 2022) is a good time to propose additional features. Not promising to implement anything, but the project is fresh in my head at the moment. In particular, while it's not supported yet because of the v1.0.0 note above, it's now technically possible to enable vertical dragging via a config file option. Not great, but functional. More in a sub-post. Downloads Best installed via CKAN, but if you want to do it manually, here are the appropriate links: Spacedock page Github release Source code

To spacedock and ckan -- though yeah, also github; the new repo is at https://github.com/andrew-vant/dragctrl. Thanks for reminding me of the exp branch in the navball repo, that can probably go away now. [edit: and it looks like ckan did the right thing with the version file on the first shot this time, woo. I'll make the 1.0 release and forum thread after work. And apparently more people are watching this thread than I thought; there were 19 downloads of the prerelease just overnight.]

A few moments ago I pushed a Draggable Controls v0.9.0 pre-release, subsuming Navball and Altimeter and (as far as I can tell) at parity with them. Once any ckan versioning funny business is worked out, I'll re-push it as v1.0.0 and make a separate forum thread for it. There's a couple new features I plan to add, but I wanted the first merged release to be as similar to the originals as possible. If anyone wants to try it in the meantime, it should be visible on ckan shortly. It's probably best to remove the old mods first.

Just in case anyone was wondering: Navball and Altimeter both have working version data now, so they should do the right thing for the indefinite future. As of a few minutes ago, I have a merged version that appears to work, but I need to test it more before releasing it. There may be some room to clean up the implementation in the process; I see some of my dumber bugfix kludges (like forcing a reposition every update) are missing from LGG's code, so he may have found solutions I missed. Will probably PM you with some questions tomorrow.

I've released a v1.1.0 of DraggableAltimeter that *should* permanently fix the thing where CKAN thinks it's incompatible with current KSP versions. There's been some discussion of merging it with DraggableNavball in the latter's thread, although I'm guessing that anyone likely to see this post is already aware.

Dragnav should work properly from CKAN again, hopefully permanently this time. It seems that CKAN reacts to an (intentionally) omitted KSP_MAX_VERSION by silently deferring to Spacedock's (crippled) versioning metadata. Which might not be insane, except that as far as I can tell, it's entirely undocumented behavior. Excuse me while I order a new desk to replace the one I just put my head through. Spacedock provides no way to allow for future patch-version updates, and the .version schema provides no way to explicitly specify either 'any version' or a right-open interval (e.g. ksp <1.13.0), so I kludged it by giving a max version of 1.12.99. The important part is that now everything will be fine forever. I'll do the same for Altimeter as soon as I can. I want to leave both in a usable and reasonably future-proof state, even if future updates go in a merged fork.

Actually, I lied, it will be longer before I can work this properly; I picked up a stomach bug somewhere and spent most of the night throwing up. Not in any condition to wrangle tech right now. Sorry.

Meh. CKAN picked up the new version, but thinks it requires KSP <= 1.12.3. I'm not sure where it's getting that from; it's definitely not in the .version file. Either CKAN isn't finding the file or it's not honoring the contents, I'm not sure which. Will try again tomorrow. At least it will allow it to install again for the time being.

I just pushed a v1.0.1.4 to Spacedock that *might* fix the issue where CKAN/Spacedock think dragnav isn't compatible with current versions of KSP. I'm not sure how soon to expect a CKAN refresh to pick it up, but I'll check in the morning. There are no code changes, so if your existing install works then there's no need to update. I'm having a look at LGG's changes but it will take a day or two to grok them. Yeah, Brigadier, I'm half-expecting a "oh yeah" moment when I look at the merge of the two, but I assume LGG tested his changes and I'm pretty sure "it doesn't work" wasn't the reason anyway.

Just for the record, I'm not actually dead, and I do get emailed by posts in this thread. ...or at least I used to and thought that was still the case. Looking at my email history, something might be wrong with the follow feature; I see no thread notifications newer than 2019-10-26, but I did get mail for LGG's PM. Not sure what's up with that. As far as I know the draggables still work in current KSP, no matter what spacedock/ckan say, but I'll double check that too, and take another shot at sorting out the metadata, and maybe merge the two per LGG's suggestion. I had some reason for not doing that before, but don't remember what it was.

Just to verify: You mean the current compile works fine, right? (and what about Draggable Navball?) If they need rebuilding, I can do that. Otherwise I might as well update the Spacedock metadata before I forget.

Not at the moment. In my first experiments with navball/altimeter dragging, I let them drag anywhere, but that caused issues. As an example, the rolldown-on-hover features did not play nice when placing them off their usual edges. The navball and altimeter UIs were designed with the top and bottom edges in mind; it was easier to snap them to their original edges than to modify their UIs. So that's what I did. (Technically, it's not really snapping to the top edge. The bit that responds to dragging just ignores the drag's Y offset.) It wouldn't be hard to make the snapping behavior toggleable, and I can do that if you really want it, but I don't think it will have quite the effect you intend.