Property: maxtargetrange [range]

[ant1991331]

The monster's target must be within [range] in order to start attacking. (Good for monsters with short-range weapons...)

[Osiris Kalev]

You could always use [wiki]A_JumpIfCloser[/wiki].

[Graf Zahl]

Could be done. Then the Arch-Vile hack could be removed.

[ant1991331]

You could always use [wiki]A_JumpIfCloser[/wiki].

... That didn't work... (that's why I suggested this...)

[Matt]

Why wouldn't it work? Did it look something like

Code: Select all

Missile:
 MNST E 0 A_JumpIfCloser (512, 1)
 goto See
 MSNT E 8 A_FaceTarget
 ...

?

[ant1991331]

Why wouldn't it work? Did it look something like

Code: Select all

Missile:
 MNST E 0 A_JumpIfCloser (512, 1)
 goto See
 MSNT E 8 A_FaceTarget
 ...

?

More like...

Code: Select all

Missile:
    NOD6 EF 10 A_FaceTarget
    NOD6 G 0 A_JumpIfCloser(156,2)
    NOD6 G 0 A_PlaySound("grenade/fire")
    NOD6 G 4 Bright A_CustomMissile("NODGrenade", 38, 10, 0, 0, 64)
    NOD6 F 4 A_FaceTarget
    goto See

We don't want a Grenadier to fire a grenade up close, so it skips the 2 firing frames and goes straight to "NOD6 F 4 A_FaceTarget"

[Matt]

You miscounted the frames. Jumping two frames means jumping from the first NOD6G to the third NOD6G, in other words the frame that calls the grenade attack. What you want is A_JumpIfCloser (156, 3).

[ant1991331]

You miscounted the frames. Jumping two frames means jumping from the first NOD6G to the third NOD6G, in other words the frame that calls the grenade attack. What you want is A_JumpIfCloser (156, 3).

Hmm.... that can't be right, because that's not how the other A_JumpIf's work..

[Matt]

...can you give an example of one of the other ones? Because last I checked that's how A_Jump, A_JumpIfCloser, and A_JumpIfInventory work...

EDIT: A_JumpIf, too.

[ant1991331]

Code: Select all

  Fire:
    TIBR B 1
    TIBR C 0 A_PlaySound("mantis/fire")
    TIBR C 1 BRIGHT A_FireCustomMissile("ToxinShell",1,1,1)
    TIBR D 1 A_GiveInventory("MantisClip",1)
    TIBR E 2
    TIBR A 2 A_JumpIfInventory("MantisClip",50,2)   <--- this will jump the next frame and the goto bit.
    TIBR A 1 A_Refire
    goto Ready
    TIBR A 4 A_PlayWeaponSound("mantis/reload")
    TIBR FGFFFAAHIJIH 5
    TIBR A 5 A_TakeInventory("MantisClip",50)
    Goto Ready

[Matt]

Well, what you've got there is the same as what I've got... remember, though, that A_Jump doesn't count the goto lines.

[ant1991331]

... remember, though, that A_Jump doesn't count the goto lines.

I'm sorry to say but it does count the goto lines, otherwise I wouldn't hear the reload sound being played. >_>

EDIT: Wait... now I'm confused...

[Matt]

Let's say you've got the following:

Code: Select all

MNST A 1 A_JumpIfHealthLower (20, 3)
MNST B 1
MNST C 1 A_AlertMonsters
MNST D 1

Here, the jump would go three frames: the jump call would skip A, B, and C, landing on D.
Without the jump, the actor would execute frames ABC first before it can do anything with D.

Now let's say we had this:

Code: Select all

MNST A 1 A_JumpIfHealthLower (20, 3)
MNST B 1
MNST C 1 A_AlertMonsters
goto See
MNST D 1

Here, the jump would go three frames: the jump call would skip A, B, and C, landing on D. It then executes D which is already past the goto and therefore doesn't execute the goto.
Without the jump, the actor would go through frames ABC, then encounter the goto, then go to its see state without hitting D.

The way I think about it is that the jump number should be the number of frames before the frame you want to jump to, including the frame that calls the jump and excluding the frame you want to jump to.

[Zippy]

The [wiki]A_Jump[/wiki] page on the wiki has nice examples of just about all possible jump scenarios, and does a good job explaining how the offsets are calculated.

[Graf Zahl]

And if Randy released a new version you wouldn't have to bother with the offsets anymore!