Effect of Client:Eye to multiple mobs in the area

ID:159811
 
Jan 9 2009, 5:19 pm
I have no code to share or examples, it is simply something I want to do. I have had no luck so far with the codes that I have been using, so they are obviously not working. To the point.

I am attempting to create a code that first targets all mobs in the surrounding view area, then moves their 'client:eye'from one spot to another.

Another problem which I will encounter sooner or late, is to save time and coding for repetitive lines. I am attempting to make a randomization for the for how much the increments of the y and x move up and down around the character, with variables of -5 - +5 on each side of the character. To give a shaking screen effect for everyone near.

Thank you for your help if possible
-Keiron.
Jan 9 2009, 6:28 pm
Ever heard of the for() loop proc?
Jan 9 2009, 7:21 pm
Use a mixture of typecasting and the . operator instead of the : operator. It's bad because it suppresses compiler errors, giving them as potentially game destroying runtime errors instead. If you don't have a clue what I just said, read the chapters of the DM guide on typecasting.
Jan 10 2009, 1:16 am
That's pretty simple, and there are even libraries/demos on the subject of such an earthquake effect. What I suggest doing is if the effect could be placed on multiple mobs at once, make your earthquake function take a list of them to alter all of their eyes at once, and in the same way; that would be more optimized than running a separate, single-version function on each mob individually.
Note a newer addition to effect the player's viewport exists, which allows you to displace the view by pixels rather than whole tiles (multiples of 32 pixels) only (look up the pixel_x and pixel_y vars of the client). This allows for a smoother effect, and what you should use. Incidentally it's even easier to use than the eye for this purpose; all you need to do is alter the numerical pixel_* vars by whatever amount needed (as returned by rand()).
Jan 10 2009, 7:46 am
 
mob
    verb
        Earthquake()
            src << "Intilized"
            var/mob/M
            src << "Intilized"
            for(M in oview())
                M << "This effects you"
                usr << "Intilized"
                src.random = rand(-32,32)
                src.random2 = rand(-32,32)
                src.pixel_y = src.random
                src.pixel_x = src.random2
                sleep(1)


This is the pathetic peice of code that I've managed to written, all terribly wrong. In the sense, it doesn't work. I know there are better ways of structuring it than I have, but to start with I'd need to get it working. Where have I gone wrong? Thanks again for the tips and any further help.
-Keiron.

--Edit--

For quick refernece, errors were checked using the constant text being flowed to the various people in area and the usr who was using it, neither of the messages after the for() Proc actually run on my screen.
Jan 10 2009, 9:51 am
In response to Keiron
Because oview() excludes the usr or src of the verb/proc. If you want it to affect you as well, use view() or range()
Jan 10 2009, 9:56 am (Edited on Jan 10 2009, 10:01 am)
In response to Keiron
Keiron wrote:
I know there are better ways of structuring it than I have, but to start with I'd need to get it working.

Why not write it as best as you can first, then get it working? =P I don't see why you'd need vars like random to be defined under /mob, that's just silly. If anything those should be local vars declared in the verb.

Where have I gone wrong?

  1. You're looping through oview(); something like an earthquake probably shouldn't depend on what the verb executor can see, rather on a pure range basis, so I'd use a range() family proc instead.
  2. You're setting src's pixel variables, but those are the mob vars (as src is a /mob), they don't alter the view but rather the actual placement of the mob on the map. What we were talking about are the client pixel vars.
  3. You shouldn't really call sleep() there; no reason to do it and it'll just create a delay between each player's processing, creating a difference in each player's experience (they'll happen at different times).
  4. For a proper quaking effect, you'll want to displace the player's view multiple times, then when finished return it to normal.


For quick refernece, errors were checked using the constant text being flowed to the various people in area and the usr who was using it, neither of the messages after the for() Proc actually run on my screen.

They wouldn't, because the for() is looping through oview(usr), and oview() excludes the Center object (usr in our case) and its contents, so it won't actually loop through whoever ran the verb.
Jan 10 2009, 11:05 am
In response to Kaioken
Thank you so far Kaioken, your help has been absolutely crucial to me as it is now. I have a fully functional working code. Well, it works for the pixel displacement and a way of not having masses of code.

 atom/movable/var
    random
    random2
    looped

var/
    looped = 0
mob
    verb
        Earthquake()
            src << "Intilized"
            var/mob/M
            src << "Intilized"
            Loop
            for(M in view())
                M << "This effects [M]"
                M.random = rand(-10,10)
                M.random2 = rand(-10,10)
                M.client.pixel_y = M.random
                M.client.pixel_x = M.random2
                if(M.looped <= 10)
                    usr.looped += 1
                    goto Loop
                else
                    looped = 0
                    M.client.pixel_x = 0
                    M.client.pixel_y = 0


But, you stated that having a sleep proc would be un-needed. But if there is no sleep proc then there is no screen shake and the last pixel is sent to reset. I was hoping for a way to solve this problem? Also any things you may be able to help with in the structure of that code would be helpeful also.

Thank you again for your time, you're a great help.

-Keiron.
Jan 10 2009, 11:32 am
In response to Keiron
Keiron wrote:
But, you stated that having a sleep proc would be un-needed.

The sleep() call you had before wasn't before the next Xth change to the pixel vars, it was before continuing on to the next player; you're right there should be a delay between changes, but not between proceeding to other players.

Also any things you may be able to help with in the structure of that code would be helpeful also.

There are still things I've mentioned in my previous post, so you should re-read it.
Also most notably, the extra vars on /atom/movable and the use of the goto instruction should all be scrapped. If you need vars, declare them locally on the proc itself (like you've done with M), it doesn't need to be on the mobs and certainly not all movables. And about goto, using it creates badly-structured code that is hard for a programmer to follow; it is highly frowned upon, and you're recommended to use a looping construct such as for() or while(). Ultimately behind-the-scenes goto, while() and for() all work the same, but using one of the latter two produces much cleaner source code.

I also recommend already taking a step and moving the actual Earthquake() code to an external proc that takes care of it, so you could call it from anywhere to repeat the behavior. Here's the beginning of it: 
mob/verb/Test_Earthquake()
   earthquake_effect( range(src,5) )

proc/earthquake_effect(list/targets)
   if(ismob(targets)) //if the argument is a mob and not a list
      //set it to a list containing that mob reference, \
      so it works with our code that expects a list.
      targets = list(targets)
   // -- do quaking for each mob in targets here --

In this proc, you're going to have multiple parts, and use 2 loops, one nested in the first. The first one would be a loop that repeats itself a certain number of times, the number of changes that should occur to the pixel vars, and in its end it sleeps so there's a delay between the changes. In that loop's body, you'll have a loop through the targets that changes each's pixel vars to the same value, etc. Then lastly you'll reset all the players pixel vars back to 0.
Note: Before changing a mob's client vars, check if he actually has a client first, since NPCs don't, and one could easily be caught in a function like range().
Jan 10 2009, 12:38 pm
In response to Kaioken
I'm really sorry... I'm having a hard time concentrating today, I'm having some giant problems outside of computer and can barely focus... But I said I would attempt to get this code done for the developer. So I'm trying my best.

mob/verb/Test_Earthquake()
   earthquake_effect( range(src,10) )

proc/earthquake_effect(list/mob/player/M)
    var/
        random
        random2
        looped
        targets
    if(ismob(/mob/player/)) //if the argument is a mob and not a list
                                //set it to a list containing that mob reference, \
                                    so it works with our code that expects a list.
        targets = list(/mob/player/)
        M.random = rand(-10,10)
        M.random2 = rand(-10,10)
        M.client.pixel_y = M.random
        M.client.pixel_x = M.random2
        usr.icon_state = "gathering"


As you can see from this mess storm of a code, I barely understand any of it as it is now... I was hoping that you could give me a further push or perhaps references to where the code is in the DM Reference? I had read the reference, but it was many years ago and coming back to the DM language is hard for me at this time.

Thank you for your patience is you still have any with such stupidness as you see infront of you. But if you still find it in your heart to help.
Thank you - Keiron