reads one thing but not the other on the same line in Developer Help

ID:149563
 
Apr 4 2002, 2:00 pm (Edited on Apr 4 2002, 2:12 pm)
This is the weirdest problem i had to face yet, ok here what happens, i have a rand battle generator that sends the usr to a locate, after that on the same line plays a midi, it doesnt read the locate but plays the midi, here is the code.
mob/proc
randbattle()
var/dice
dice=rand(1,5)
if(dice==1)
if(usr.rarea=="over")
usr.loc=locate(19,3,1)
usr<<sound('dq5-battle.midi',1)
var/opponent=image('enemies.dmi',locate(x,y+1,z),"slime")
usr<<opponent
#1 Apr 4 2002, 5:45 pm
Draconite wrote:
This is the weirdest problem i had to face yet, ok here what happens, i have a rand battle generator that sends the usr to a locate, after that on the same line plays a midi, it doesnt read the locate but plays the midi, here is the code.
mob/proc
randbattle()
var/dice
dice=rand(1,5)
if(dice==1)
if(usr.rarea=="over")
usr.loc=locate(19,3,1)
usr<<sound('dq5-battle.midi',1)
var/opponent=image('enemies.dmi',locate(x,y+1,z),"slime")
usr<<opponent

Change all usr to src
#2 Apr 5 2002, 3:20 am
In response to Skysaw (#1)
this might be something but i think it isnt locate it is move try using F1
#3 Apr 5 2002, 5:08 am
In response to Mrhat99au (#2)
Mrhat99au wrote:
this might be something but i think it isnt locate it is move try using F1

No, it doesn't pertain to this issue. There is nothing wrong with setting loc directly, unless you're simply setting the loc of the wrong atom.
#4 Apr 5 2002, 5:14 am
In response to Skysaw (#3)
when me and Draconite were trying to fix that problem last night he tried moving the code that calls the randbattle proc from the Move proc to an Enter proc for an area. now i dont see how this could affect what is in the randbattle proc but it then relocated the player corectly, but then it didnt create the monster. my Q is why would that have any affect?
#5 Apr 5 2002, 5:44 am
In response to Loduwijk (#4)
Loduwijk wrote:
when me and Draconite were trying to fix that problem last night he tried moving the code that calls the randbattle proc from the Move proc to an Enter proc for an area. now i dont see how this could affect what is in the randbattle proc but it then relocated the player corectly, but then it didnt create the monster. my Q is why would that have any affect?

Post some code would help.
#6 Apr 5 2002, 6:08 am
In response to Skysaw (#5)
he had the randbattle in walk, like so:

mob/Walk()
if(rarea<>"town")
src.randbattle()
..()
else
..()

but then copy/pasted it to area/Enter like this:

area/over/Enter()
if(rarea<>"town")
src.randbattle()
..()
else
..()

and the randbattle proc u saw in his post
#7 Apr 5 2002, 6:20 am
In response to Loduwijk (#6)
Loduwijk wrote:
he had the randbattle in walk, like so:

mob/Walk()
if(rarea<>"town")
src.randbattle()
..()
else
..()

but then copy/pasted it to area/Enter like this:

area/over/Enter()
if(rarea<>"town")
src.randbattle()
..()
else
..()

and the randbattle proc u saw in his post

I don't see in either of those where a monster is created, so I'll assume it's within the randbattle() proc.

The main difference between these two snippets is that src has a completely different meaning in each. In the first, it refers to a mob, in the second to an area. If you want the second to refer to the mob that enters the area, you'll have to rewrite it to something like:

area/over/Enter(mob/who)
if(rarea<>"town")
who.randbattle()
..()

However, since I can't tell what rarea refers to, this is probably not correct. It would be easiest to Just define an area as your random combat area, and do this:

area/battle_area
Entered(mob/who)
who.randbattle()

Also note that Entered() is safer than Enter() here, since it is called after an object actually enters. Enter() is called if something attempts to enter, whether it is successful or not.
#8 Apr 5 2002, 9:20 am
In response to Skysaw (#7)
i made a mistake, i meant to type usr, not src. he has usr there. and rarea is his var to keep track of the general location of the player. and yes the monster is created in the randbattle. randbattle is in draconites original post at the head of this thread.
#9 Apr 5 2002, 9:29 am
In response to Loduwijk (#8)
Loduwijk wrote:
i made a mistake, i meant to type usr, not src. he has usr there. and rarea is his var to keep track of the general location of the player. and yes the monster is created in the randbattle. randbattle is in draconites original post at the head of this thread.

Using usr outside of a verb is a recipe for a disaster. Use src if it's a mob proc, and when in doubt, pass the mob along to the proc. Within Entered(), you should check the first argument: If it's a mob, you can call the random battle code:
turf
  Entered(atom/movable/A)
    if(ismob(A))
      var/mob/M=A
      M.randombattle()

Then, since randombattle is a mob proc, you can use src instead of usr.

Lummox JR
#10 Apr 5 2002, 9:31 am
In response to Loduwijk (#8)
Loduwijk wrote:
i made a mistake, i meant to type usr, not src. he has usr there. and rarea is his var to keep track of the general location of the player. and yes the monster is created in the randbattle. randbattle is in draconites original post at the head of this thread.

Don't use usr in Enter() or Entered(). Bad idea.
#11 Apr 5 2002, 12:55 pm
In response to Lummox JR (#9)
changing all usr to src made many many bugs, which i fixed tried no effect. Still same problem, is BYOND Ver 321 having coding problems or something , if so i need to get a update or go back.
#12 Apr 5 2002, 12:57 pm
In response to Draconite (#11)
Draconite wrote:
changing all usr to src made many many bugs, which i fixed tried no effect. Still same problem, is BYOND Ver 321 having coding problems or something , if so i need to get a update or go back.

Nope, these are programming issues.
I think the reason you saw errors from changing away from usr is that you made a huge mistake using usr in the first place. Disentangling yourself from that mess could be tricky, but it's worth the effort.

Lummox JR
#13 Apr 5 2002, 1:00 pm
In response to Lummox JR (#12)
heh, i just said i made it compile, i fixed it, and it had the same effect. read last post for more info at 10 o clock news ;p
#14 Apr 5 2002, 1:54 pm
In response to Draconite (#13)
I forgot to mention one tiny lil detail hehe, sometimes the random meter would read the locate and sometimes it didnt, it would always play the music but never enter at the same time, i even put usr<<"Before Locate" ( locate ) usr<<"After Locate" . It would play both lines and just skip locate 3/4ths the time , but every so often goto the locate. Wierd stuff man wierd stuff.