Turning by following the mouse? in Developer Help

ID:158066
 
Nov 8 2009, 8:19 am
It's a simple question with an -I'm assuming- complex answer...

Is it possible to have it so that if I were to move my mouse left one it would rotate my character left 15 degrees or so, or right 15 degrees or so, that way if I were to move my mouse my character would always be looking at where the mouse is at? I can do the part for which he rotates but I'm not sure about how to make him follow the mouse... or if it's even possible.
#1 Nov 8 2009, 10:29 am
SadoSoldier wrote:
Is it possible to have it so that if I were to move my mouse left one it would rotate my character left 15 degrees or so, or right 15 degrees or so,

Yes.

that way if I were to move my mouse my character would always be looking at where the mouse is at?

This is a completely different issue, as you're describing a different thing here.

For either issue, you could use MouseEntered(). Making the character always face the location you have the mouse would actually be very simple, as you could just have MouseEntered() change the direction of the object to face src.

For the first issue you mentioned, you could keep track of what the mouse is currently hovering over, and if you move it to be over something one tile to the left or right (again, checked in MouseEntered()), then you could just take whatever action you want, such as turning 15 degrees.
#2 Nov 9 2009, 1:22 am (Edited on Nov 9 2009, 2:56 am)
In response to Loduwijk (#1)
EDIT:
My bad, easier ways are done than using Flick's system...
Here you go.
Now, I assume you have it so mouse opacity is 0 for all obj, mob, and turf.
Otherwise possible things such as Overlays, HUDs and whatnot will disturb it.
Also, this would be a very 'clunky' way of doing it but possibly the one way I know of to do it...
By clunky I mean let's say the player is fast enough to move their mouse over a new obj/mob/turf while moving...
They would instantly turn to that direction during walk.
Also this only works for the 8 PreSet Directions.
You can possibly produce a system where you include Turn() and whatnot.

obj
    MouseEntered(location)
        usr.dir = get_dir(usr,location)
        ..()
mob
    MouseEntered(location)
        usr.dir = get_dir(usr,location)
        ..()
turf
    MouseEntered(location)
        usr.dir = get_dir(usr,location)
        ..()
#3 Nov 9 2009, 3:25 pm
In response to Maximus_Alex2003 (#2)
You're somewhat misusing the location parameter. You should be doing this in client/MouseEntered() anyway. Like so:

client
  MouseEntered(object,location,control,params)
    //if it's not on the map, then don't try to face us towards it
    if(!istext(location))
      //replace with something more precise than get_dir():
      mob.dir = get_dir(mob, object)
#4 Nov 9 2009, 4:58 pm
In response to Garthor (#3)
Works perfectly fine for me.
Does what I intend on it doing.
Maybe the word, 'misused' should be looked at.
#5 Nov 9 2009, 5:08 pm
In response to Maximus_Alex2003 (#4)
It's messier when you're using mouseentered like that, because you have to override it for atom.MouseEntered() (You're not even doing that, you're overriding it for atom's subclasses.)

When you override client.MouseEntered(), it's easier to accommodate for things like client screen objects that you don't want to use MouseEntered() with (Like say if the screen objects had a null loc? or if the loc were actually the mob you want to turn?)
#6 Nov 10 2009, 7:52 pm
In response to D4RK3 54B3R (#5)
D4RK3 54B3R wrote:
It's messier when you're using mouseentered like that, because you have to override it for atom.MouseEntered() (You're not even doing that, you're overriding it for atom's subclasses.)

When you override client.MouseEntered(), it's easier to accommodate for things like client screen objects that you don't want to use MouseEntered() with (Like say if the screen objects had a null loc? or if the loc were actually the mob you want to turn?)

Well, sorry.
I used the whole mob, turf, obj because that's how you would simply single out whether you wish to make your character look at them or not.
But yes, to have it not single out certain Objects, use what Saber and Garthor have mentioned.
#7 Nov 11 2009, 10:11 am
In response to Maximus_Alex2003 (#4)
The word you should look at is "works". In no way does the situation that something is working imply anything other than it is working - i.e., it doesn't imply that that something is good (or even not horrible), or that it works well (or even sufficiently well).
Brushing your teeth using a finger instead of a toothbrush 'works perfectly fine'. It's not nearly as efficient or good, but it works. Despite working, it is still bad and inferior. The same analogy can be applied to a multitude of different situations, and it is the same in programming.
Saying that something isn't bad just because it 'works' in programming is a meaningless excuse that only newbies would use, and for a reason (as I've just mentioned above). Very often, they are satisfied with something just working even though it's not working well or works under specific circumstances only, and fails in others, or it works but the effort taken to pull it off is much greater than what's actually needed, or it works although it uses bad programming techniques or bad approaches that could be harmful to the project in the long run - etc, etc.

In your case, Garthor was even easy on you, since your working code is bad, not "somewhat bad", as it doesn't even work (which, again, isn't sufficient) in all the common situations. This is because the location argument can be a text string, which obviously shouldn't be used in get_dir(), which only accepts atoms.
In the case that you're giving it a non-atom value, get_dir() doesn't behave correctly (actually, this is a bug because it should fail instead, generating a runtime error).