ID:138339
 
I've been wondering for a while now whether you would consider giving turf/area/obj a pointer image, so that when the mouse enters them you can display a different pointer?

This would allow nice effects like a hand to open and close things. The current pointer state could also be used to select different click() events, rather than having to switch click modes with a variable.
On 10/24/00 5:10 am Al wrote:
I've been wondering for a while now whether you would consider giving turf/area/obj a pointer image, so that when the mouse enters them you can display a different pointer?

This would allow nice effects like a hand to open and close things. The current pointer state could also be used to select different click() events, rather than having to switch click modes with a variable.

That sounds like a clean way to organize the cursors. We could also have a world.cursor to act as the default so that people could set that directly.

Listed!
In response to Tom H.
That sounds like a clean way to organize the cursors. We could also have a world.cursor to act as the default so that people could set that directly.

How about a client.cursor instead? That would be largely client-side, wouldn't it?
In response to Spuzzum
How about a client.cursor instead? That would be largely client-side, wouldn't it?

Just as a side note... would that be a .cur cursor, or a .dmi cursor? I'd be much more supportive of .dmi, unless you gave us provisions to modify cursors.

(I can modify cursors in VC++, but, due to inability to find that in stores, I opted for the The Sims: Livin' Large Expansion instead. So I'd need a Dantom-provided utility more than ever. =)
In response to Spuzzum
On 10/24/00 12:48 pm Spuzzum wrote:
That sounds like a clean way to organize the cursors. We could also have a world.cursor to act as the default so that people could set that directly.

How about a client.cursor instead? That would be largely client-side, wouldn't it?


I love the idea of world.cursor for a default, and turf.cursor (and area.cursor!) for overriding the default.

However, I echo Spuzzum's concern -- it it's at all possibly to optimize the hell out of this to be client-side with updates being sent only if relevant things change...

Whatever it would take to not end up with stutters if you cross a batch of turfs with unique cursors...
In response to Deadron
On 10/24/00 2:03 pm Deadron wrote:

However, I echo Spuzzum's concern -- it it's at all possibly to optimize the hell out of this to be client-side with updates being sent only if relevant things change...

Whatever it would take to not end up with stutters if you cross a batch of turfs with unique cursors...

Regardless of the notation the cursors would have to be client-side, sent over with the object and subsequently only referenced on the client. Right now when you move over objects on the map you already get a very frequent refresh since the name generally gets changed (in the upper-left corner of the map); fortunately the work is all in the client-side redraw since the names of the various objects are already known. The situation would be identical for cursors.

Spuzz- to be consistent we would probably just support .bmp and .dmi cursors.

But let's not get ahead of ourselves! This is likely easy enough to do, but still qualifies as a less-than-essential-feature at this time, and we already added violated our pact in a minor way and a couple of those for 256! In due time...
In response to Tom H.
On 10/24/00 2:17 pm Tom H. wrote:
Right now when you move over objects on the map you already get a very frequent refresh since the name generally gets changed (in the upper-left corner of the map); fortunately the work is all in the client-side redraw since the name is already known; the same would hold true for cursors.

Good point -- using the same process as the name changes would be perfect.


But let's not get ahead of ourselves! This is likely easy enough to do, but still qualifies as a less-than-essential-feature at this time, and we already added violated our pact in a minor way and a couple of those for 256! In due time...

Yup! It's just such a cool feature that we can't help but get excited.

One thing that's different from displaying the name of the turf is that the cursor might be player-dependent. For example, a player who has gone into "building" mode might have a hammer cursor, while others would have something else cause they are not in building mode.

Just a thought.
In response to Deadron
One thing that's different from displaying the name of the turf is that the cursor might be player-dependent. For example, a player who has gone into "building" mode might have a hammer cursor, while others would have something else cause they are not in building mode.

Yup, that's what I meant. A client.cursor (and possibly a client.cursor_state...). Also, we should get a mouseover() proc at some point, so we can automatically execute things when a client moves their mouse over top of something... and the default behaviour would be to display the name of the object in the upper-left corner.

Not anything necessary, though. At least, not yet.
Hey, I asked for all this stuff months ago and got a negative response! Okay, so I didn't actually provide such a nice way to implement it as you did, but I did ask for it, I swear! I expect everyone to remember these things and say, "Z asked for this 6 months, 3 days and 18 hours ago, actually."

Please read the forum archives and study all the feature requests I've made over the past year. There will be a test on Friday.

Z
In response to Zilal
Please read the forum archives and study all the feature requests I've made over the past year. There will be a test on Friday.

I already have a test on Friday... could you bump it to Monday? =)
In response to Deadron
I love the idea of world.cursor for a default, and turf.cursor (and area.cursor!) for overriding the default.

After some cursory thought (ha!), I wonder if it would be necessary to offer built-in variables like turf.cursor or area.cursor. Once Spatz's client.cursor is supplied, it could be enough simply to offer a new built-in proc like client.CursorOver(). If you did want turf-based cursors, it would look something like this:

turf
var/cursor = 'turfCursor.dmi'

client
var/myCursorMode

New()
. = ..()
spawn MonitorCursor()

proc/MonitorCursor()
var/curObject
while(src)
curObject = CursorOver()
if(myCursorMode == "normal")
if(isturf(curObject) && cursor != curObject:cursor)
cursor = curObject:cursor
else if(myCursorMode == "grab")
cursor = 'grab.dmi'
sleep(3)
In response to Guy T.
On 10/24/00 8:00 pm Guy T. wrote:
I love the idea of world.cursor for a default, and turf.cursor (and area.cursor!) for overriding the default.

After some cursory thought (ha!), I wonder if it would be necessary to offer built-in variables like turf.cursor or area.cursor. Once Spatz's client.cursor is supplied, it could be enough simply to offer a new built-in proc like client.CursorOver().

This is a nice notation. Forcing the user to take responsiblity for the cursor call is a much better alternative than automating it, because we certainly wouldn't want to be doing server queries (to call a proc) every time the user moves the mouse!

The problem is that even in the manual case this kind of thing is subject to abuse. In your example, for instance, you could potentially be doing a lot of network calls on this ticker just to manage something that really should be client-side. This is why this is a touchy issue. The simple case of providing fixed (or mostly fixed) cursors to the world can be done quite efficiently, but adding in instantaneous updates that allow different people to get different results could be problematic, especially in a case like this in which quick updates are expected.