FEATURE: setViewArea()

Developer discussion regarding MapTool 1.4

Moderators: dorpond, trevor, Azhrei

Forum rules
Posting now open to all registered forum users.
User avatar
Jagged
Great Wyrm
Posts: 1306
Joined: Mon Sep 15, 2008 9:27 am
Location: Bristol, UK

FEATURE: setViewArea()

Post by Jagged »

Edit by moderator: topic split off in a seperate topic (http://forums.rptools.net/viewtopic.php?f=86&t=25958)

I've been thinking about the setZoom function and was wondering if it is what is really wanted?

Isn't what we actually want something more like setViewArea(x1, y1, x2, y2) ? Especially when you think about different players PCs etc. etc.

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: FEATURE: updateView()

Post by Craig »

Jagged wrote:I've been thinking about the setZoom function and was wondering if it is what is really wanted?

Isn't what we actually want something more like setViewArea(x1, y1, x2, y2) ? Especially when you think about different players PCs etc. etc.
Correct

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: FEATURE: updateView()

Post by wolph42 »

Craig wrote:
Jagged wrote:I've been thinking about the setZoom function and was wondering if it is what is really wanted?

Isn't what we actually want something more like setViewArea(x1, y1, x2, y2) ? Especially when you think about different players PCs etc. etc.
Correct
but this sounds like a whole lot more work. E.g. what exactly do you do when it does not fit? e.g. (0,0,1,100) fairly certain no screen is that size, so then what?

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: FEATURE: updateView()

Post by Craig »

wolph42 wrote:
Craig wrote:
Jagged wrote:I've been thinking about the setZoom function and was wondering if it is what is really wanted?

Isn't what we actually want something more like setViewArea(x1, y1, x2, y2) ? Especially when you think about different players PCs etc. etc.
Correct
but this sounds like a whole lot more work. E.g. what exactly do you do when it does not fit? e.g. (0,0,1,100) fairly certain no screen is that size, so then what?
I was not thinking completely, I change my answer to still correct but...

setViewArea() would take dimensions in world space and map them to the screen viewport. If we had independent x and y scaling then its easy. But since we don't there is a bit more thought involved.

So if you had setViewArea(0,0,100, 100) if you had independent x and y scaling and your map window was 640, by 400 the x scale factor would be 6.4 and y 4. Since we only have one scale factor (zoom level) then setViewArea would need to do something slightly different. I think the "most correct" answer would be to zoom to the level that guarantees that everything in the view area is displayed on the screen (even if that means a bit extra is displayed in one of the dimensions) so it would take the smallest scaling factor after working out y/x scaling factors and use that to calculate the zoom level. This means that people who have map windows 1920x1080 will see the same map as people with map windows 960x540 after setViewArea has run, just one will be more zoomed in than the other to achieve that effect.

User avatar
Jagged
Great Wyrm
Posts: 1306
Joined: Mon Sep 15, 2008 9:27 am
Location: Bristol, UK

Re: FEATURE: updateView()

Post by Jagged »

wolph42 wrote: but this sounds like a whole lot more work. E.g. what exactly do you do when it does not fit? e.g. (0,0,1,100) fairly certain no screen is that size, so then what?
A setViewArea would have an implied zoom. You would not have a separate scaling for x and y, but would calculate the scaling factor necessary to fit (in your example) 100 cells into your y dimension and set the screen accordingly. So given a 1000,800 screen size and a grid size of 50, 800/100/50 gives you your scaling factor (I think ;) )

Happy to do some testing to see if this is possible.
Last edited by Jagged on Fri May 01, 2015 4:17 am, edited 1 time in total.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: FEATURE: updateView()

Post by wolph42 »

note that I edited my earlier post (quite a bit). Let me repost that part:

Also on the scripting side: the zoom/pan is a LOT less intuitive to to use for a pan and zoom and a lot more work to implement. Granted you have more control over what each client shows, but at the price of way to much hassle too set it up.
E.g. lets take a castle at which you want to 'zoom in' as animated effect. Its either;

Code: Select all

goto(xCastle, yCastle)
setZoom(0.1)
loop(x=1 to 90): setZoom(getZoom()+x/100); updateView(); delay(10)
or...

you tell me. (well I know what needs to be done, but it requires waay more thinking)

edit: note that I'm not against extra functionality and this function certainly has its merits I'm just discussing the 'is it what we really want' part.

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: FEATURE: updateView()

Post by Craig »

wolph42 wrote:note that I edited my earlier post (quite a bit). Let me repost that part:

Also on the scripting side: the zoom/pan is a LOT less intuitive to to use for a pan and zoom and a lot more work to implement. Granted you have more control over what each client shows, but at the price of way to much hassle too set it up.
E.g. lets take a castle at which you want to 'zoom in' as animated effect. Its either;

Code: Select all

goto(xCastle, yCastle)
setZoom(0.1)
loop(x=1 to 90): setZoom(getZoom()+x/100); updateView(); delay(10)
or...

you tell me. (well I know what needs to be done, but it requires waay more thinking)

edit: note that I'm not against extra functionality and this function certainly has its merits I'm just discussing the 'is it what we really want' part.
It depends on what you are trying to achieve, If for example you wanted to shift the map to the above castle and display it large enough to take up most of the map you can do so with setViewArea() despite what the map windows dimensions are.

Any animation would really have to be part of the setZoom()/setViewArea() etc, a delay(x) macro will be problematic because delaying macros for 10 seconds would require pausing most of maptool for 10 seconds (I think that also includes gui responding).

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: FEATURE: updateView()

Post by wolph42 »

Craig wrote:It depends on what you are trying to achieve, If for example you wanted to shift the map to the above castle and display it large enough to take up most of the map you can do so with setViewArea() despite what the map windows dimensions are.

Any animation would really have to be part of the setZoom()/setViewArea() etc, a delay(x) macro will be problematic because delaying macros for 10 seconds would require pausing most of maptool for 10 seconds (I think that also includes gui responding).
1. true. which only strengthens my point: It *does* has its merits, especially in your example, but its certainly not *better*. Just different functionality for different purpose.
2. i would expect the delay to hold MT entirely and I don't mind, actually it would be quite useful. Again here too it would be nice to have some sort of delayThread() and delayAll() where you can choose between delaying just that thread or maptool entirely, but I'm guessing the former is close to impossible. For the animation though *ANY* delay function is welcome, whether it halts MT entirely or not.

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: FEATURE: updateView()

Post by Craig »

wolph42 wrote:[2. i would expect the delay to hold MT entirely and I don't mind, actually it would be quite useful. Again here too it would be nice to have some sort of delayThread() and delayAll() where you can choose between delaying just that thread or maptool entirely, but I'm guessing the former is close to impossible. For the animation though *ANY* delay function is welcome, whether it halts MT entirely or not.
If I remember correctly --and I may not-- it all runs on the GUI thread, so responding to windowing system events will pause, meaning the windowing system will put up those "MapTool is not responding" type messages :(
And sorry I wasn't suggesting this function instead of another one but as well as

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: FEATURE: updateView()

Post by wolph42 »

Craig wrote:
wolph42 wrote:[2. i would expect the delay to hold MT entirely and I don't mind, actually it would be quite useful. Again here too it would be nice to have some sort of delayThread() and delayAll() where you can choose between delaying just that thread or maptool entirely, but I'm guessing the former is close to impossible. For the animation though *ANY* delay function is welcome, whether it halts MT entirely or not.
If I remember correctly --and I may not-- it all runs on the GUI thread, so responding to windowing system events will pause, meaning the windowing system will put up those "MapTool is not responding" type messages :(
And sorry I wasn't suggesting this function instead of another one but as well as
no worries, I already have one in the BoT. Its also a 'nice to have' but when using the BoT its a present function (bot_delay(ms) IRC)

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: FEATURE: setViewArea()

Post by aliasmask »

I would be more interested in a deferred macro call delay. Ie call macroX in Y seconds. My current method is to get the current time, pass it to a recursive deferred macro along with the time to execute and macrolink. Having it as a part of execLink would more convenient and less complicated.

User avatar
Jagged
Great Wyrm
Posts: 1306
Joined: Mon Sep 15, 2008 9:27 am
Location: Bristol, UK

Re: FEATURE: setViewArea()

Post by Jagged »

After quickly diving into the code during my lunch time :oops: it looks as though this is essentially what the "Enforce GM view" function (ZoneRenderer.enforceView) does.

So in theory we could make a scripted version relatively easily. Hopefully I will have something for you to play with soon :mrgreen:

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: FEATURE: setViewArea()

Post by JamzTheMan »

Which is probably used by the Menu option, "Center Players on current view" under Tool menu.

So basically you are creating a macro function to emulate the menu function, no?
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
Jagged
Great Wyrm
Posts: 1306
Joined: Mon Sep 15, 2008 9:27 am
Location: Bristol, UK

Re: FEATURE: setViewArea()

Post by Jagged »

Sort of, it would only set the view of the client that ran the script. It would not force all clients to the same view.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: FEATURE: setViewArea()

Post by JamzTheMan »

Well, that's the next question, should we have a parameter for functions like these to automatically run on all connected clients?
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Post Reply

Return to “MapTool 1.4”