ID:1338585
 
(See the best response by Jittai.)
Code:
client
Click(object,location,control,params)
var/list/p = params2list(params)

if(p["middle"])

//Warp
if(usr:warping)
if(usr.chi >= 4)
flick("Warp",usr)
usr.chi -= 4
spawn(3)
usr.loc = location
return
else return


Problem description:
Okay so I have a warp skill in my game that is triggered by clicking the middle mouse button. They mouse over a piece of turf and click it and that is suppose to teleport them to that spot. It was working great until I switched up some of my grass turfs.

Now my grass turfs are of varying sizes, but all greater than 32x32. Instead of warping people to the location they click, it warps them to the location of the turf on which they click. This makes warping very inacurate as it teleports them to the 1st x/y on which the turf begins. Does anyone have a workaround for this at all?

Well, a few questions.

One, why did you, and how did you change the grass sizes?

It seems to me that if you fix your turf's it will fix your problem. However, I would love a better explaltion
So here are a few examples of the grass icons, first of all:

http://puu.sh/3OWl4.png
http://puu.sh/3OWlM.png
http://puu.sh/3OWmH.png

Now on a new map file, this is the base turf. Just soil.

http://puu.sh/3OWs7.png

But when I start laying down grass tiles, it gives it a very smooth transition.

http://puu.sh/3OWBH.jpg

It also makes the turf seem less like a bunch of repetitive 32x32 tiles, and makes each piece of land a bit unique. This allows me to blend it with other turfs quite well.

http://puu.sh/3OWEA.jpg

I'm very fond of this effect, and I'd like to maintain it. There must be a way to make players actually warp to the location of the click, rather than the location of the turf on which you click.
Completely unrelated but that grass looks AWESOME.
I really need to learn how to make ground like that...

Anyway, it sounds like you want to teleport to the dirt tiles instead, since they line up with the grid, correct? Are the grass turfs being added as actual overlays, or is something else going on? As a test, set mouse_opacity = 0 for your grass turfs only, this way only the underlying dirt turfs should be clickable. Hopefully this works on turf overlays. I'm not sure if they are treated differently or not.
I just found out, that's not going to work with the map editor. Let me quote:

Lummox JR wrote:
When you stack turfs in the editor, the only turf that actually exists is the topmost one; the others all become underlays. Underlays, like overlays, are Appearances--none of them is an actual turf.

What this means is that the map editor does not stack turfs into overlays. If you wanted to achieve that effect you would have to do that at runtime. Another option is to use actual objects, but they use more resources. Sorry if this is confusing.

Edit:
One more workaround is to create a special turf only to serve the purpose of being clickable. After you are done mapping the regular turfs, you would have to make sure to always add this turf on top of them. It would be invisible and have mouse_opacity = 2, to force it to be clickable. This is quite a hacky method though, so I wouldn't really recommend it.
What do you mean do it at runtime?
Ironically enough, setting the mouse_opacity to 0 still seems to work O_o I'm curious as to why this is now.
In response to Khye
Khye wrote:
What do you mean do it at runtime?

Well, that's exactly what I mean really. The turfs would need to be automatically added as overlays at runtime. The problem is, the only turf you would see in the map editor is the dirt turf. Another option is to have your own runtime mapping system, if you really wanted to go that far. Ultimately this is a limitation of the map editor, not a BYOND limitation in any way. If the map editor had full support for overlays and underlays, we wouldn't have these kinds of problems.

Ironically enough, setting the mouse_opacity to 0 still seems to work O_o I'm curious as to why this is now.

Well, that's very strange, and it contradicts how the map editor does things. Maybe I'm not understanding exactly how you are mapping things in your game. I really don't see how that would work. I read someone discussing your exact problem, and essentially Lummox said that it's not going to work that way.

Read This
Well I'm defining mine in client/Click(). Perhaps it's taking the location of the area underneath then? I bet this person in the other post was defining turf/Click().
In response to Khye
Khye wrote:
Perhaps it's taking the location of the area underneath then?

That couldn't work either. By default, there is only a single instance of /area containing all the turfs on the map. Also, since the area most likely has no icon and its mouse_opacity is still the default it wouldn't be clickable anyway.

All I can guess is that since your turfs have lost their mouse_opacity, clicks are falling straight into the void of the map itself, as if there were no icons there. Can a default turf without an icon be clicked on the map? If so, then that could explain the functionality you are experiencing. Perhaps the tile grid of the map itself can be clicked? I don't recall anything like that happening though.
Either way. It's strange.
It's not strange it's built in functionality due to limitations of the engine.

The engine can only support icons as big as your icon_size, if you make bigger icons it emulates them, but to the game the icon is still 32x32. You can Click() the whole thing, but it's still just that one tile.

As for is it possible, yes, just track where the mouse is, I'd recommend checking this out.
Not the 32x32 thing. The fact that I'm clicking through the turfs, yet it's still accurately taking me to the right tile. I'm just curious as to what it's taking as the object argument in the click.

This libary does look very useful though. Thank you.
Rushnut wrote:
Stuff about engine limitations, and how mouse tracking is the solution for big icons.

That's exactly the sort of thing you want to avoid if at all possible. When implementing a feature, it's always best if it can be done in a way that preserves the native functionality. In this case, as long as you just need to click the tile grid, the native Click() function should always be sufficient to achieve this. Adding a bunch of mouse tracking will add a bunch of overhead that you most likely don't want. Also, that JavaScript solution won't work for clients that have it disabled. Now, if you want to actually click outside the tile grid, in a way that works with pixel movement, then mouse tracking can be useful. You can also check out Forum_account's completely BYOND native implementation here.
To be clear, any client procs don't really cause overhead for the server, correct?
ALL client procs cause overhead for the server. Almost ALL of the processing is done entirely on the server. BYOND's client is very thin. It just grabs the necessary information, then sends it to the server, where the real processing is done. Right now, you can think of DM as a server-side language. Hopefully that will change in the future.
Also, this is a bit strange, but you can directly dump the arguments of client/Click()!
client/Click()
src << "Click!"
for(var/a in args)
src << a
..()

Let me know if you find anything unusual.
In response to Multiverse7
"Click!
The soil
The soil
Map Pane.map1
icon-x=22;icon-y=13;left=1;screen-loc=10:20,17:10"

The soil is coming up twice... So it's registering that for the object and location. I didn't think that was possible since it supposedly should be underlayed.
In response to Multiverse7
Multiverse7 wrote:
Rushnut wrote:
Stuff about engine limitations, and how mouse tracking is the solution for big icons.

All that stuff that is completely wrong

You cannot accomplish what he wants with just Click() because of the way big atoms are handled, and F_A's library is
1: buggy as hell, since he never touched it up it doesn't accurately track on any resolution other than the one he used
2: not native at all, that's the point of a library, things aren't native. Native means you don't need a library for it. HDK's is also far superior in almost ever way. I love F_A as much as the next guy but that's his worst library by a long shot.

Oh and not to mention, the overhead is pretty minimal. It's large in comparison to everything else in the engine, sure, but it's still negligible to the extent you can disregard it.
Page: 1 2 3