ID:2344057
 
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
What we need
A proc that when someone right clicks, instead of calling the normal context menu, will give a list of all the objects they actually right clicked on. (where the appearance is)

Why we need it

This function isn't currently possible to do in the language because when someone right clicks on their screen, dream seeker takes into account the appearances of every object.

So if an object is shifted into the location where they right clicked, that object will be activated and an object shifted out of that location won't be, is the idea.

Use Case
In order to mimic byond's own context menu, we need to be able to get the right clicked objects that takes into account where the appearance is located. (ie pixel_x and pixel y) - then nifty custom features and behaviour can be added on top.

Thanks in advance.
+1
Are we not just talking about disabling show_popup_menus and filtering right-clicking with the Click() proc's params argument?

client/show_popup_menus = 0
client/Click(object,location,control,params)
params = params2list(params)
if("right" in params)
//do stuff here
In response to Spunky_Girl
Spunky_Girl wrote:
Are we not just talking about disabling show_popup_menus and filtering right-clicking with the Click() proc's params argument?

> client/show_popup_menus = 0
> client/Click(object,location,control,params)
> params = params2list(params)
> if("right" in params)
> //do stuff here
>

No.
What we're suggesting is there's a way to find out which tile a client clicked or otherwise, but you can't get all the objects a mouse is right clicking on; because an object can be pixel shifted in and not picked up or pixel shifted out and still be picked up. @Spunky_Girl
I think we're talking about a new variable (mouse proc argument? client read-only property?), a list of atoms currently under the mouse cursor.

The closest thing to it that I've done is calling bounds() on the mouse's world pixel coordinates, but that detects atoms using their physical bounds, not their appearance.
Pretty much exactly this ^; that's the problem and why this is a feature request. It'd be really cool to have custom right click UIs and such.
One problem here is that DS uses client-side data to determine what's on the tile that was clicked.
@Lummox - Sure, but it's not like the server doesn't know everything the client can see, or the client can't send back what it sees
In response to DrCelt
DrCelt wrote:
@Lummox - Sure, but it's not like the server doesn't know everything the client can see, or the client can't send back what it sees

That's not what he's talking about; you have to consider transforms, hittests with the pixels, etc.
In response to Somepotato
Somepotato wrote:
DrCelt wrote:
@Lummox - Sure, but it's not like the server doesn't know everything the client can see, or the client can't send back what it sees

That's not what he's talking about; you have to consider transforms, hittests with the pixels, etc.

See

Sure, but it's not like [...] the client can't send back what it sees

In response to MrStonedOne
MrStonedOne wrote:
Somepotato wrote:
DrCelt wrote:
@Lummox - Sure, but it's not like the server doesn't know everything the client can see, or the client can't send back what it sees

That's not what he's talking about; you have to consider transforms, hittests with the pixels, etc.

See

Sure, but it's not like [...] the client can't send back what it sees


And then you open up to a world of clients sending forged data, massive lists, etc.
You out of all people should know that such a world is already wide open in the protocol.
well I don't think there's any reason to make it worse
The server can validate almost every case that would lead to an atom being under a turf and it can do so with much less processing time than if it tried to calculate the list server side from scratch.

The only thing it couldn't easily handle is animate()ions, and even then, that could be fixed by making the server save more info relating to animate()ions

And i'm pretty sure the protocol already allows clients to send clicks events on items they can't see, how would this be any different?
In response to MrStonedOne
MrStonedOne wrote:
The server can validate almost every case that would lead to an atom being under a turf and it can do so with much less processing time than if it tried to calculate the list server side from scratch.

The only thing it couldn't easily handle is animate()ions, and even then, that could be fixed by making the server save more info relating to animate()ions

And i'm pretty sure the protocol already allows clients to send clicks events on items they can't see, how would this be any different?

"The server can validate" -- did you just miss the entire conversation about how this isn't feasible and how it requires the client so as to not also bog the server down with unnecessary calculations?

And yes, clients can send mousedowns but IIRC they have to be in view to call, which is MUCH cheaper to calculate, not to mention SIGNIFICANTLY less exploit potential because you're not sending a super massive list of click targets, just one.
calculating the list is expensive, yes. validating that each item in the list is valid to be in the list would be cheap.

you can extrapolate step or pixel x/y of the item's appearance, is it high enough to put the item near where the mouse clicked, even transforms are easy to validate, simple math.