Code:
Problem description:
very simple problem (or not)
I have a obj with opacity 1, however I wanted so one player could ever see through this is to make obj?
sorry for the google translator
ID:948460
 Aug 26 2012, 11:01 am
|
|
|
Aug 26 2012, 11:22 am
|
|
Luizwalber917
 |
Oh I almost forgot also, how do I go when the player on top of an object motion it run slower? or better yet how do I when he comes on top of an object I set a variable type and speed of movement when it resumes back to normal?
|
then .. the sight from what I saw I give permission for the User to see through objects of ALL limit and I wanted to see through the User object has only 1 as??
and is an example of using the enter and exit?? I could not use ... explaining what I want to do, I'm making a game naruto jutsu and has the mist Momochi, with this jutsu when the enemy get into the negoa (5x5 area) will take a slow (only set a variable when it enters) and leaving the variable unset, and this mist will get opacity 1, ie no one will see through it and have utility for the jutsu Momochi had to see through the mist however if I give a - usr.sight | = (SEE_MOBS | SEE_OBJS | SEE_TURFS) - the Momochi will see through all the fog not only | |
so i'll use
obj/'obj_Name'/Enter(mob/m)? isn't working | |
It is best to know the difference between Enter() and Entered(). In your example, you've frozen all movement entirely.
| |
I know the difference. If you look into Enter() you are bound to look into Entered(), I just assumed Enter() would provide his needs better, slowing movement as you enter into the 'mist' and speeding it back up as you exit. He said slow down, not hault. m.variable does nothing in the example posted. Entered() and Exited() would provide almost the same effect, just only after the mob is inside the mist rather than while the mob is coming into the mist.
[EDIT] Assuming the movement takes place between Enter() and Entered(). I am not completely sure on this. If Entered() is called before the movement then it's more logical to use Entered() and Exited(). [END EDIT] | |
I could do with turf .. so now I have a doubt .. how do I go back after 1 min prior to the turf ... ie how do I get the informations of the previous turf ..?
| |
What I said was, you've completely frozen all movement on all turfs because you aren't returning anything. Enter/Exit are what allow things to happen, not where you put code for when things happen.
| |
Ah, my bad. I missunderstood. I was only showing an example of how he could change a variable. But I understand completely to that extent. BUT Enter/Exit is a part of the movement process. Exit>Enter>Exited>Entered, correct? I don't see anything wrong with assigning a variable uppon entering a specific turf, though it's not something I've done myself. I've personaly only used Enter() to ensure the person can enter a 'safe zone' or what-have you(by not being hostile/in a fight, not carrying anything hostile, and not currently in the process of doing anything). I did not see anything wrong with assigning a variable inside Enter() as objected to Entered(), and assumed Enter() was called before movement and Entered() after. Which would make it logical to 'slow' the person entering the area rather than slowing them after they've entered the area. Would it instead be better to include them into Move() instead of Enter()?(Just to ensure we both are on the same page; I understand fully well that return ..() is needed inside of procs like these.)
| |
Well, return a true value to allow and a false value to disallow. For example, by default Exit returns 1 because you're usually allowed to exit things.
Move's default action is to set off the chain that goes something like this: Can I exit the current turf? (Check currentturf.Exit) No (returned false): Move fails (returns 0) Yes: Call currentturf.Exited Can I enter the new turf? (Check newturf.Enter) No: Move fails (returns 0, Bump into the turf) Yes: Am I dense? Are there other obstacles in my way? (Pixel movement adds Step stuff here) Call newturf.Entered, Crossed, etc. And of course, all of this happens in ..() of Move(). You can call ..() wherever you want in Move(). You don't even need to return a value in Move(), but that would break any checks you make like if(Move()). | |
Lol, feels like you're trying to teach a kid the basics. That's not what I have issues with. But that doesn't seem logical. Shouldn't Enter() be called before Exited() to ensure you actualy exit the turf? Other than that, you didn't clearify anything I didn't already know.
And I don't use return ..() inside move, but instead inside Enter(). I have yet to need to dabble into Exit(), though it's almost the exact same as Enter(). I asked if it would be better to include the 'slow' inside of Move() rather than in Enter() as I orriginaly suggested. it seems more logical to include it in Enter(). But you're trying to say that Entered() is also called before Move()'s default functionality? | |
If you want the official DM translation of the movement procedures (shouldn't be too much different with Cross stuff stuck in), check this: http://www.byond.com/forum/?post=19508
What I've said is that it's all inside Move's default action (accessed with ..() when overriding). In response to your question (could it go in Move?), I will say this: in Move(), before calling ..(), nothing has happened yet. After ..(), you've either bumped something or moved successfully (as described by the value of ..()). Therefore, if you want to do something before checking anything, put it in Move before ..(). If you want to do something after you've successfully entered a turf, you can check Move's return value (inside Move if you want) or put it in Entered (which has no significant return value). I myself like using Move just because I have clear pointers to the mover (src), the original turf (loc, before ..()), and the next turf (first argument), and I can easily control when to actually perform the move and check if the move is successful. | |