 |
Note: in the same thread, it has been indicated that you can use the arrow keys to move each slider by 0.01. Nice. So barring any problem with that or desire to take this further, this can probably be closed as a documentation issue. Thoughts? |
 |
From looking at the code, the precision is hardcoded at 0.01. The large threshold values when moving the sliders with the mouse seems to be out of our control, so I agree that this is more a documentation issue. |
 |
The current situation is really horrible from a users point of view :( Here are the issues I have with it (beware long :) * saving the map does not save the background image, so every time you reload your map, you need to fiddle again with the background image * just reloading the same map (or an old version) while having a background image, throws the background off by moving it (or the xy view?) around * the zoom/offset sliders are way to imprecise with the mouse, and even with the keyboard the steps are way to big. I think these controls should be changed to controls just like the H/V offsets on textures * the zoom steps (!) of the image and the zoom steps (!) of the XY view (via mousewheel) are not in sync plus the zoom steps of the XY view are quite big. This means it can take a looong time to find that magic setting where you image and the XY actualy line up again * the same goes for the offset, although mouse dragging the XY view around makes this much easier as you can just align the view with the image, not the other way round * the "lock pan" and "lock zoom" settings actually MOVE the background image, making your precious alignment moot - and after you clicked for instance "pan with image" you can no longer use the mouse to pan, but must use the fiddle controls - which are to imprecise for correct line up * it would be nice to tell DR that the background image should only be used on one dialog (like the XY side view) but not on top view * the background image dialog is some sort of modal dialog, but it doesn't stay on top of all the other dialogs, making it sometimes vanish behind DR. (luckily it appears in the list of windows on ALT-TAB) Basically, yesterday, I used a background image to build a bit of geometry, and then DR crashed. After restarting I have only be mildly successfully after about 10min to get them to align again, so I modified parts of my geometry. Only to find out this morning I have to do it all over again :( Making the "pan image with view" and "zoom image with view" NT to "jump" around the background image when enabled, and then saving the background image with the map would go a long way towards making it easier as you would only need to adjust the background once and then would forever have it drag/zoom along with the view. I hope this dialog can be improved :) |
|
|
Please don't push several separate issues into the comment of one single bug report, this makes it hard to keep track of what is fixed and what is not. Especially crashes should attempted to be reproduced and tracked separately, as these of course prevent settings from being saved. > I hope this dialog can be improved :) That's for sure - now we only need to find somebody to do it. :) |
|
|
There is only one issue: it is almost impossible to use the "background image" feature right now, as it is not really possible to get it align properly, no matter what the user does. As for the crash, sorry for being unclear, this crash was unrelated. It just caused me to lose the background image alignment as this isn't saved with the map. Anyway, if you want, I can open new bug reports for each of the problems of the background image dialog, but as these actually are all depending on each other...well your choice - just tell me what to do :) |
|
|
Hm, no one ever complained about the feature being almost impossible to use. I also used it myself and didn't experience it as you describe. Anyway, part of the stuff you reported is feature request (save background image per map) which has to be discussed, as this would mean: more stuff being saved into the worldspawn entity or to the XMLRegistry. Another part is tweaking request (like the control precision), which is probably trivial to do or at least easy. And the third part is an actual bug report (if the image doesn't behave as intended by the settings in the dialog, for instance). So, it's probably best to track them separately to make it easy for us developers to work with the reports. The best thing of course would be if you could look into these issues yourself. :) |
- Anonymous
