new question

ID:179556
 
Dec 6 2001, 6:30 am
When you use new to create a mob will it have all the same defaults of a mob you place on the map yourself before compiling?

My mobs that are created while the program is running act differently than the mobs I create in the map editor.
Dec 6 2001, 6:53 am
English wrote:
When you use new to create a mob will it have all the same defaults of a mob you place on the map yourself before compiling?

My mobs that are created while the program is running act differently than the mobs I create in the map editor.

They should be the same, unless you have edited the mobs in the map editor (changing default values).
Dec 6 2001, 10:28 am
In response to Skysaw
I haven't changed any of them. I just clicked on their icon and placed them on the map.

This is the code for my npc's:

base_EventCycle()
if (next_walk_time <= world.time)
next_walk_time = world.time + walking_delay - round(speed/10)
if(agressive && followTar == null) //will attack unprovoked?
lookArround() //check for prey
if(gotAttacked == 1) //if was attacked or is attacking
if(get_dist(src,followTar) <= canSee) //if can see target
step_to(src,followTar,1)
if(get_dist(src,followTar) <= maxRange) //if target is in attacking range
attack(followTar)
return
else
if(agressive) //if agressive and lost target, reset and look for another target
followTar = null
gotAttacked = 0
world << "[src] lost target"
if (prob(movement_percent)) //if no target wander
step_rand(src)


proc
lookArround()
var/tmp/mob/M5 = null
for(M5 as mob in oview(canSee)) //scan through visible mobs
if(M5.type != src.type) //no cannibalism
followTar = M5
gotAttacked = 1
world << "Got target: [followTar]"
break


I put those messages to world and such to help me identify the problem but I can't find it. The mob's work fine and do what they're supposed to. Then when I delete them when they die and create another one the new one doesn't attack on it's own. It just wanders arround.
Dec 7 2001, 3:02 am
In response to English
Well, I don't know what else is going on in your code, but I'm guessing base_EventCycle() is being called for each mob at startup in some sort of main loop. I don't see where base_EventCycle() would be called at all. Are you using Deadron's loop library? I'm not familiar with it, so you'd have to read his documentation if that is the case.
Dec 7 2001, 7:49 am
In response to Skysaw
Yep, I'm using that. I read through it and it didn't seem to have any conflicts with my code.

base_EventCycle is called every 1/10 of a second I believe.
Dec 7 2001, 7:58 am
In response to English
English wrote:
Yep, I'm using that. I read through it and it didn't seem to have any conflicts with my code.

base_EventCycle is called every 1/10 of a second I believe.

It's not a matter of conflicts, but rather whether base_EventCycle() is called on objects that do not exist when the game begins. It doesn't look like it's being called here at all, but I don't know how the loop works.
Dec 7 2001, 9:01 am
In response to English
English wrote:
Yep, I'm using that. I read through it and it didn't seem to have any conflicts with my code.

base_EventCycle is called every 1/10 of a second I believe.

I missed this discussion because the title is generic.

base_EventCycle() by default is called every tick (1/10th) of a second, for every object that is on its event_cycle_receivers list.

You can put objects on that list directly if you wish. By default, mobs place themselves on the list when they are created, unless you are overriding the New() proc and not returning ..().

(I think it's New()...I'll have to check in a bit to be sure.)
Dec 7 2001, 6:27 pm
In response to Skysaw
It's really a weird problem. I know it is being called because all of my mobs move at the right speed. Whether they were created on the map or while the game was running. They even respond to my attacks as they should.

The problem is that mobs that are toggled as aggressive don't seek aquire targets after they've been killed and a new mob of that same type has been created. The new mob still walks arround and does everything fine except it doesn't aquire targets on it's own for some reason. The ones I create on the map do though :(

I have a feeling the problem might be in the lookArround() proc. I've put in testing statements and I know that it is being called while they are walking arround. However, they don't seem to be able to see other mobs.

Is there a side effect to using:
//////////
for(var/tmp/mob/M as mob in oview(8))
if(requirement)
break
//////////
Then doing operations with M? Maybe it is ignoring mobs it has already seen or something like that?
Dec 7 2001, 9:16 pm
In response to English
English wrote:
It's really a weird problem. I know it is being called because all of my mobs move at the right speed. Whether they were created on the map or while the game was running. They even respond to my attacks as they should.

If you want to zip this up and mail it to me at [email protected] I'll take a look.
Dec 8 2001, 1:30 am
In response to English
English wrote:
Is there a side effect to using:
//////////
> for(var/tmp/mob/M as mob in oview(8))
>      if(requirement)
>           break

//////////

I dont think this does what you want. Im not sure if tmp matters here, but I'd think it would. I doubt break is what you want as well, because that quits out of the entire for loop. Look up continue :)

Alathon
Dec 8 2001, 4:43 pm
In response to Deadron
OMG, I feel like such an idiot. In the loop I'm trying to get the caller to target a mob in it's view. Then once it aquires a valid target it should break out of the loop and start attacking that mob. I was using:
for(M as mob in oview(canSee))

That targets something in the USERS view, not the callers view (I think...). I changed it to:
for(M as mob in oview(canSee,src))

And now it works fine!

I'm sorry for wasting your guys time like this, thanks for all the help you offered though :)

I was thinking about not posting in the newbie forum anymore and moving to the code problems area but I see I've still got some work to do.
Dec 8 2001, 5:04 pm
In response to English
English wrote:
I'm sorry for wasting your guys time like this, thanks for all the help you offered though :)

I was thinking about not posting in the newbie forum anymore and moving to the code problems area but I see I've still got some work to do.

The fact that the view() and range() procs use usr as a default is a very, very easy stumbling block, and extremely difficult to diagnose when it causes problems in the code. I've run into it myself a few times. So don't feel too bad. :)

Lummox JR
Dec 8 2001, 5:12 pm
In response to Lummox JR
Lummox JR wrote:
I was thinking about not posting in the newbie forum anymore and moving to the code problems area but I see I've still got some work to do.

The fact that the view() and range() procs use usr as a default is a very, very easy stumbling block, and extremely difficult to diagnose when it causes problems in the code. I've run into it myself a few times. So don't feel too bad. :)

Eyup. I imagine Dantom really wish they could go back in time and make those methods on objects...

In the meantime, you can put covers in place to do that.