[1.2-1.6] Draggable Altimeter v1.0.1 (2016-12-03)

[Error_Sophius]

Draggable Altimeter By request of Smart Parts Wanter. This does exactly the same thing as Draggable Navball, but for the altimeter control cluster: it lets you drag it somewhere else. As with DN, it's most useful for a multi-monitor setup.   Changelog [1.0.1] - 2016-12-03 Altimeter position no longer resets on scene changes or IVA. Fix by linuxgurugamer. [1.0.0] - 2016-11-19 Initial release   Downloads License: MIT Spacedock download Github release Source code Available on CKAN

 

Edited January 4, 2019 by Error_Sophius
Update supported versions

[Stone Blue]

AWESOME SAUCE!
As a laptop user, screen realestate is valuable, and the stock layout is not really optimal for small screens...
THANK YOU!

[RealGecko]

 

[Error_Sophius]

Looks like this has hit CKAN rather faster than the navball one did, for those that install that way. Woo.

[linuxgurugamer]

Would you like me to do the code to save the position for you?

[Johnny2000]

9 minutes ago, linuxgurugamer said:

Would you like me to do the code to save the position for you?

YES! I would like you to do it for him

This mod has a huge potential, but it is too annoying that it resets for every scene change.

[linuxgurugamer]

Not too difficult.  I'll add some code which simply saves the position somewhere, and updates it during the update (or maybe just the scene changes).  The only think I need to decide is whether this will be per-save specific, or global

Edited December 1, 2016 by linuxgurugamer

[Error_Sophius]

Sure, if you want. The position is technically saved, it just doesn't enforce itself so it always ends up getting saved as zero (I think). My first impulse for fixing the problem was to listen for the relevant scene-change events and re-set the position in response...but I don't know what event to listen for.

The problem seems to be that I don't know the "right" way to define its position; I can move the control cluster's object, but what I really should be changing is whatever value the UI uses to initially place it. I *could* re-set its position in every Update(), but would rather not; that's a bit like killing a spider with a sledgehammer. I would rather find its intended knob and set that. I just haven't put much time into searching because I don't personally have much need for it; this was a request in response to Draggable Navball.

Contributions by github PR are preferable, but I'll take diff patches too. I'm on IRC as ehs if you need to ask questions, though I don't promise to answer quickly.

[linuxgurugamer]

Just now, Error_Sophius said:

Sure, if you want. The position is technically saved, it just doesn't enforce itself so it always ends up getting saved as zero (I think). My first impulse for fixing the problem was to listen for the relevant scene-change events and re-set the position in response...but I don't know what event to listen for.

The problem seems to be that I don't know the "right" way to define its position; I can move the control cluster's object, but what I really should be changing is whatever value the UI uses to initially place it. I *could* re-set its position in every Update(), but would rather not; that's a bit like killing a spider with a sledgehammer. I would rather find its intended knob and set that. I just haven't put much time into searching because I don't personally have much need for it; this was a request in response to Draggable Navball.

Contributions by github PR are preferable, but I'll take diff patches too. I'm on IRC as ehs if you need to ask questions, though I don't promise to answer quickly.

Essentially, it will set the position when responding to scene changes (there are some events for that), and will save the position when done dragging

[Error_Sophius]

Okay. Gotcha warning: Test whatever you do against IVA, EVA, and mapview toggling too. All three tried to trip me up when I was making this.

(IVA still resets it in DN despite my efforts, so if you can solve that one then I'll probably steal the technique.)

[linuxgurugamer]

1 hour ago, Error_Sophius said:

Okay. Gotcha warning: Test whatever you do against IVA, EVA, and mapview toggling too. All three tried to trip me up when I was making this.

(IVA still resets it in DN despite my efforts, so if you can solve that one then I'll probably steal the technique.)

Ok, thanks for the heads-up.  Have you thought about merging the two mods?  The solution I'm probably going to do will be the same for both.

Edited December 1, 2016 by linuxgurugamer

[Error_Sophius]

I thought about it at the time but decided it wasn't worth the effort. If other players are like me, they'll probably be googling something like 'ksp drag <whatever>', and matching <whatever> in the mod name makes life easy for them. Besides, I didn't want to release something and then a few days later say "oh, never mind, use this instead".

I don't object to merging the two in principle, though. There's a decent argument for a more general draggable-ui-elements mod, particularly if people express an interest in moving more than just those two panels.

[linuxgurugamer]

@Error_Sophius

I noticed that your file "Draggablealtimeter.cfg" is stored in the same directory as the dll.  This can be a problem because every time the game loads, it sees the cfg file and loads it, if the file has changed then ModuleManager will see that and rebuild everything.  

I'm going to move it into a data directory (PluginData), which gets ignored by the game at load time

I just saw in your Makefile that you already do this

Edited December 2, 2016 by linuxgurugamer

[linuxgurugamer]

So I have it working, it was actually a one line change to fix a bug.

That being said, I did make a couple of other minor changes, as well as creating the necessary support files for a VisualStudio compile.Would you like just he c# file, or the whole thing?

 

[Error_Sophius]

A pull request or diff -u would be best, but I can work with just the C# file as long as you didn't move large chunks around (i.e. if I can get a useful diff myself).

I'm not sure about the VS scaffolding. If it's a single plaintext project file that can go in next to the makefile, I might take it for the sake of others' convenience. If it's a whole folder tree or contains binary goo, I won't. Either way it should be a separate PR/commit/patch/whatever.

[linuxgurugamer]

Ok, this is what I'll do:

I'll do a PR in a few minutes of just the code file.  Once that's been merged, I'll do another PR of everything else, you can decide at that point whether to keep it or not.

[Error_Sophius]

Perfect. I'm off today so I should be able to test + release this afternoon.

[Error_Sophius]

Wow. That really is a one line fix. Frustrating Somewhat embarrassing. :-(

Scenechange/map/eva/iva all work. Looks like IVA still tries to re-center the altimeter but it just gets moved right back in Update(), which is good enough. I'd forgotten that I ended up taking the sledgehammer approach on this one. I still wish I knew where IVA et al are getting the 'centered' position from so I can just turn that knob myself.

Moving the save process to OnEndDrag doesn't seem necessary, but I'm going to keep it anyway. I'm pretty sure Destroy() doesn't get called if the game crashes, and that happens often enough. I did split it into a separate commit. I also cleaned up some (accidental, I think) whitespace changes. Final changeset here.

I'm not sure what the convention is for new versions on the forum. Am I supposed to make a new thread, or update the first post in this one?

Edited December 3, 2016 by Error_Sophius

[linuxgurugamer]

On 12/3/2016 at 2:39 PM, Error_Sophius said:

Wow. That really is a one line fix. Frustrating Somewhat embarrassing. :-(

Scenechange/map/eva/iva all work. Looks like IVA still tries to re-center the altimeter but it just gets moved right back in Update(), which is good enough. I'd forgotten that I ended up taking the sledgehammer approach on this one. I still wish I knew where IVA et al are getting the 'centered' position from so I can just turn that knob myself.

Moving the save process to OnEndDrag doesn't seem necessary, but I'm going to keep it anyway. I'm pretty sure Destroy() doesn't get called if the game crashes, and that happens often enough. I did split it into a separate commit. I also cleaned up some (accidental, I think) whitespace changes. Final changeset here.

I'm not sure what the convention is for new versions on the forum. Am I supposed to make a new thread, or update the first post in this one?

Update the first post

I'm pretty sure the IVA is initially hard-coded, which is why it can't be fixed in a  more permanent manner

 

[Error_Sophius]

3 hours ago, linuxgurugamer said:

Update the first post

Done. Thanks.

Quote

I'm pretty sure the IVA is initially hard-coded, which is why it can't be fixed in a more permanent manner

Joy. Well, I'll take what I can get, I suppose.

[linuxgurugamer]

Is this (and the draggable navball) ok for 1.2.2?  If so, could you get Spacedock updated with the version, right now it says they are only for 1.2.1

Thanks

[Error_Sophius]

I'd be kind of surprised if 1.2.2 broke it. I'll check it tomorrow to be sure, and then update spacedock/ckan. Thanks for the heads up.

[Error_Sophius]

Okay, both mods are updated for 1.2.2, and I fixed IVA on dragnav while I was at it. Thanks.

[a__gun]

On 01/12/2016 at 11:19 PM, Error_Sophius said:

There's a decent argument for a more general draggable-ui-elements mod, particularly if people express an interest in moving more than just those two panels.

I'd definitely be interested in this. I hate how spread out and bitty the stock UI is - being able to move the panels around would be a great help.

[glibbo]

V1.0.1 seems to be working ok in !.3