I'm curious...
When working with the cleint.Click() proc, is it possiable for me to assign it twice or more times? Example of what I mean below.
client/Click(mob/npc/O)
perform actions here.....
client/Click(mob/pc/O)
perform actions here.....
Or once you assign anything to the client.Click() thats it??
LJR
ID:148263
May 1 2003, 10:25 pm
|
|
In response to Crispy
|
|
Thanks.. these days I keep a DM Reference page up at all times for what else? "Reference!"
BACK: I checked out atom/Click() I know this well, but just checked in case I missed something which I do from time to time. In my case, it would not be to my best interest to use atom/Click(). I solved my problem with the ever handy backup "DblClick()" instead. I guess over all then you have 2 Click()s and 2 DblClick()s to work with to handle what you need. That is the answer I was looking for. Cheers! LJR |
In response to LordJR
|
|
LordJR wrote:
In my case, it would not be to my best interest to use atom/Click(). Why the hell not? Crispy thinks you are not doing something correctly. Please explain. =) P.S. You do know that you can do things like obj/whatever/Click() for any atom subtype, right? |
In response to Crispy
|
|
Crispy wrote:
P.S. You do know that you can do things like obj/whatever/Click() for any atom subtype, right? I think I already answered that question. Also you should realize the "MAD MAN" you're dealing with here. If I was to classify myself down the atom, they'd label me "Radical". Also what I'm doing works just fine, except after looking over my code I realize now I should just set client.Click(O) instead of making it only for one thing. Then just do a if(istype(O)) under that. Regardless it was more of a what-if question than a real CODE PROBLEM so thats why I posted where I did. LJR |
In response to LordJR
|
|
LordJR wrote:
Crispy wrote: Er... *searches forum* Nope, didn't think you did. Give me your reason, infidel. =P Also you should realize the "MAD MAN" you're dealing with here. If I was to classify myself down the atom, they'd label me "Radical". Har... har... har. =) Also what I'm doing works just fine, except after looking over my code I realize now I should just set client.Click(O) instead of making it only for one thing. Then just do a if(istype(O)) under that. That would work, but client/Click() is evil. Eeeevil I tell you! EVIL! =) |
In response to Crispy
|
|
Hold thy tongue naive! Its a big DARK secret that I'm working on under the hood of my next BYOND project, down in the far depths of Kalimaar Dungeon. None shall know of what client.Click() evils I speak of, till I'm ready to unleash my hordes of Click Happy Zombines upon the BYONDites of Player Central City! Muhahahahahahahahaha...... >:D
LJR |
LordJR wrote:
I'm curious... You've made an error here that hasn't quite been addressed yet and is worth bringing up: DM is not a strictly typed language. It is not possible to assign a type to an argument and guarantee that the argument, when it comes in, will actually be that type. You're coming at this from a C++ perspective of overloaded functions, but DM is not C or C++; it doesn't care what type the arguments are, and it doesn't choose which proc out of several to call based on which type is expected. The only reason you would want to assign a type to an argument is if it's pretty much not going to be used as any other type, and you can verify it in the proc (or control the procs that call it, to make sure the argument is always that type). Then you can use the . operator instead of : with the argument directly without having to type-cast it. It sounds to me anyway like you'd be better off overriding mob/pc/Click() and mob/npc/Click() instead. Regardless it was more of a what-if question than a real CODE PROBLEM so thats why I posted where I did. Questions about the idiosyncracies of the language usually belong here or in Newbie Central, so the moderator who moved it made the right call. Q&A, formerly known as General, is still misleadingly named; it is not the place to ask about this sort of thing. Rather that forum is intended for feature requests and engine-related issues. Lummox JR |
In response to Lummox JR
|
|
obj
{ DblClick() walk_to(usr,src,0,1) } mob { DblClick() walk_to(usr,src,1,1) } mob monster DblClick() usr << "[src]: Stop poking me [usr]!" three double clicks assigned to the clickee As far as I know, !client atoms have trouble clicking the mouse. -Salarn |
In response to Salarn
|
|
Not really. You just gotta position the mouse so that when you open the CD tray it will click the mouse. Then, the atoms that don't have clients can just open the CD tray and click. DUH!
|
In response to Lummox JR
|
|
Lummox JR wrote:
You've made an error here that hasn't quite been addressed yet and is worth bringing up: DM is not a strictly typed language. It is not possible to assign a type to an argument and guarantee that the argument, when it comes in, will actually be that type. You're coming at this from a C++ perspective of overloaded functions, but DM is not C or C++; it doesn't care what type the arguments are, and it doesn't choose which proc out of several to call based on which type is expected. Alrighty then... I've since decided to avoid changing client.Click() even though its worked fine up to this point and base it off the atoms themselves. Just to make sure this should that care of everything right? mob/mon/Click() var/mob/mon/O = src That way the rest of my could should accept O as though it were coming from client.Click(O)? Questions about the idiosyncracies of the language usually belong here or in Newbie Central, so the moderator who moved it made the right call. Q&A, formerly known as General, is still misleadingly named; it is not the place to ask about this sort of thing. Rather that forum is intended for feature requests and engine-related issues. Ok then, I'll try to keep that in find. Q&A really needs to be addressed as the name IS misleading, going off the name alone it could stand for ANYTHING dealing with BYOND and having a question, also Newbie Central is a bit misleading as well, as it seems to be the catch all for everything. Even though I have a problem syntax from time to time I often wonder if it should go in Code Problems or Newbie Central. LJR |
In response to LordJR
|
|
LordJR wrote:
Even though I have a problem syntax from time to time I often wonder if it should go in Code Problems or Newbie Central. Rule of thumb: If you already have code, AND it's not a newbie question, post it in Code Problems. Otherwise, Newbie Central. |
In response to LordJR
|
|
LordJR wrote:
Alrighty then... I've since decided to avoid changing client.Click() even though its worked fine up to this point and base it off the atoms themselves. Just to make sure this should that care of everything right? Why would you want to use O instead of src in Click()? If you have src to work with, it makes sense to just use that. Note also that you can use usr here, since client/Click() is technically a verb and will call this proc with usr intact. Ok then, I'll try to keep that in find. Q&A really needs to be addressed as the name IS misleading, going off the name alone it could stand for ANYTHING dealing with BYOND and having a question, also Newbie Central is a bit misleading as well, as it seems to be the catch all for everything. Even though I have a problem syntax from time to time I often wonder if it should go in Code Problems or Newbie Central. Typically the more basic the syntax problem, it should go to Newbie Central. If applying some of the traditionally obvious fixes doesn't help a particular problem though, it might be suited for Code Problems. In general though, pretty much any post with code in it is welcome in Code Problems. Lummox JR |
Oh, and Q&A is the wrong forum for this thread.