![]() Jun 22 2013, 7:47 am
|
|
Also fixed, but to no avail. For the record, when I remove the .dmf from compilation and run it, everything works smoothly except of course the right-clicks, which do nothing.
|
Yes. I can click-to-target and then attack without it effecting my movement. Now, I haven't redefined Move() at all, so I'm convinced that it has something to do with either the interface file or the bit of code that checks for right-clicks.
|
Okay and then also I just reduced the code to the following:
//Attack and Defend Controls Compiled and ran it and it still gives the same issue. I can attack or target, but it'll freeze movement whether I left or right click. Thing is, I have no sort of experience with .dmf so I'm quite clueless as to what I'm doing. I've been looking for a tutorial. Essentially, my interface file just has a map though. |
Er. The ..() under the else clause is kind of pointless. ..() is called inside the if-statement.
Can you open up your DMF file in notepad, and paste the contents here in DM tags? |
DMF Code:
macro "macro" |
Well, there's your issue. You created a second window, where the macro set for the window is not set. Meaning, whenever you set focus to that window, the macros for movement don't work, because the window doesn't have any set.
Go to the window the map, edit the actual window, Go into the Options tab. Type "macro" into the box labeled "Macro ID". Do you really want two windows, though? |
Awesome, thank you!
No, I didn't know what the hell I was doing lol. Is there a good guide for interfaces out there? |
Lummox JR's skin tutorial does an okay job of introducing interfaces I guess.
For manipulation of interfaces during runtime, there's a few entries in the reference, they all begin with "win". (winget, winset, winclone, etc), and then there's the Skin Reference. The skin ref is also available in Dream Maker, in the Help menu. |
Oh, and one last question. After redefining click-to-target from this...
mob ...to this... mob ...it appears that everytime I click to target a mob, it places the reticle over it, but when the mob moves the reticle stays in place. Now I'm pretty sure that, for whatever reason, it's treating mob/C as the location of the click as opposed to the object. Why would it do that? Granted, I could fix this by reverting it back, but I just want to get a better understanding of what's going on. |
Well, you're using mob/Click() wrong in that example.
If you look at the reference entry for atom/Click(): Click(location,control,params) location: the turf, stat panel, grid cell, etc. in which the object was clicked So, in that last snippet you posted, 'C' would be the turf the mob is standing on. You're better off keeping it as "src" there. src is the being clicked. usr is the thing doing the clicking. The first argument of Click() is the location of src, either a turf, cell, or interface element (depending on where it's clicked). |
So essentially, atom/Click() doesn't have an argument for the object as opposed to the other click procs. That makes sense now.
And also using src, despite the nature of it, does the same thing. So I guess in this case it'd be best to just define the variable outside of the arguments as I had previously. |
Well, there's only two click procs.
client/Click() and atom/Click(). mob/Click() etc is descended from atom/Click() client/Click(atom/object) calls object.Click() by default. The atom/Click() is called on the object from client/Click(), so "src" is the object that Click() is called on. |
I've come to the realization that defining them all within client/Click() is much simpler.
client Thanks for all your help, guys. :D |
You should probably just call ..() once (ever) outside of everything. Returning ..() does nothing.
|
Yeah, sorry. That was originally in there because there was an if(..()) statement at one point to check if the mob/Click() would override it. If a player was targeting someone, I didn't want it also attacking in the same click.'
//Attack, Target, and Defend Controls Better? |
You should probably combine the ismob check with the usr==object check. Also - you're still using src in your if-statements, you probably want that that to be object. Src is the client itself, in this proc.
if(ismob(object) && usr != object) probably. |