TeamTNT's Return From Oblivion: Released

[Chris Couleur]

What's with the bat? Have not tested the final version but this does not sound good. Are you talking about the little annoying bat that puts a bit of damage on you if it gets close and bites? Turns into a floating imp warlord? Never saw that when testing but does not sound good.

chris

[Enjay]

That is basically the effect, but its the red mini wyvern, not the bat. I don't think the bat does it. I just grabbed this video which shows the problem in action. Or you could just summon an imp warlord and wait for it to spawn a wyvern. I think you have to get close enough for it to enter a melee/close attack state.

http://rapidshare.com/files/83357726/wrong.zip.html

[edit]Actually, I'm not sure (because of the loss of resolution) but my video *might* show a bat turning into a Warlord too. [/edit]

[Xaser]

I'm pretty sure the Dragon familiars are fine. I remember them torching me on occasion. Well... trying to, at least ;P

It's definitely the bats. In Schloss Alder's "sewer-y" section, several bat enemies reside there naturally. They still transform.

Also, in the big round room in Alder, I think one of the textures on the outside wall is misaligned vertically (it's underneath an arch, I believe). Nothing major... it wasn't a secret area, either.



EDIT: I checked the bat's decorate and I diagnosed the problem. Apparently, in order to prevent infighting I presume, both familiars' definitions inherit from ImpWarlord and uses SKIP_SUPER (for the layperson: SKIP_SUPER causes the actor to inherit *only* states, no flags or properties). However, this poses a problem as the bat familiar has no Missile states. Why, you ask?

A_Chase naturally calls the actor's Missile state at random intervals, and normally if a monster does not have them, this action is skipped (thus why demons don't randomly bite thin air ;P). Normally this would work fine in the bat's case, but the problem is that thanks to inheritance, the weapon *does* have a Missile state, left-over from the Imp Warlord. So, when the bat decides to use an attack, it sees the ImpWarlord's missile states, thinks they are its own, and runs them. All of a sudden, you have a tiny, floating Warlord throwing death skulls at you.
(Also note that this is why the dragon works fine. Unlike the bat, it defines its Missile states so it doesn't wind up using the Warlord's).

So, how to fix this? The easiest way would be to remove the inheritance but I'm sure that without it, the bats are prone to attack their masters (I've seen it happen in Zen Dynamics, 'tis why). I would propose adding a simple "empty" Missile state consisting of a 0-length frame and a jump back to the See state, but that would result in jerky animation... if Frame B decides to call the Missile state, it will wind up jumping straight back to Frame A... skipping over C and B again.

Sadly, I can't seem to find what I'm looking for on the wiki. Does anyone know if it's possible to completely clear a certain set of states? I know it used to be possible, but this was deprecated IIRC and doesn't work now. I'm slightly stumped on this one... unless it's possible to clear the states, we'll either have to settle for a jerky animation or run the risk of spawned bats turning against their creators. Either way, not an optimal solution.

Decorate gurus, let us unite and slay this menace of a problem!

[Enjay]

Nope, neither are fine. The problem is similar for each, but different.

I summoned a drgonfamiliar and, at a distance, it tried to spit fire at me (which seemed wrong because it looks like short range fire but that could be as intended) but when I moved into melee range, it turned into a warlord.

I summoned a batfamiliar and at melee range it just nibbled at my ankles (nasty low-flying bats). However, when I walked away from it and waited for it to try a ranged attack (not sure if it is supposed to have one or not) it changed into a warlord.

The above things happen with GZdoom and ZDoom SVN (r703) but I checked Zdoom 2.1.7 and it does not happen - which probably explains why it wasn't picked up. No idea if it is a bug with Zdoom or due to the changes in the way DECORATE support has gone, but it is a problem one way or the other.

[edit]Checking the DECORATE, both actors inherit from the ImpWarlord actor. The bat does not redefine a Missile State and the Dragon does not redefine a Melee state so, logically, both just use the state from the original actor. That's certainly what I would expect if I'd defined an actor like that. Looks like a DECORATE bug to me, but for what ever reason, Zdoom 2.1.7 didn't show it up.[/edit]

[edit2]I just noticed that both actors use SKIP_SUPER. The Wiki says:

use SKIP_SUPER to reset the actor to default values. It only uses inheritance to get access to the parent's states

My reading of that is that when you use SKIP_SUPER, everything is defaulted except the states, which are inherited from the parent. So, again by my reading of that, ZdoomSVN and GZdoom are doing it right because they have inherited the parent's melee/missile states in the absence of redefined ones. Is that correct?[/edit2]

[wildweasel]

Unrelated gameplay nitpick: when you do things like freeze the player during text briefings, please either allow the player to skip them or autosave immediately after them. Dying sucks half the time because I get sent back to the briefing and have to wait several seconds before I can move again.

[Xaser]

Agreed. Right after the weapon loss is a good spot.


@Enjay: Ah, I didn't realize the Dragon was borked too. Still, it's the same problem I illustrated above: The dragon has no melee states so it uses the Warlord's. Also note that if you no-clip into the wall and watch bats fly around while they don't have a direct line of sight, they never transform. 'Tis the inheritance.

[Enjay]

'Tis the inheritance.

Yup, I came to the same conclusion. The only question is, I guess, why 2.1.7 didn't inherit properly. Bug I guess.

I found this in another thread entirely:

Write 'Raise 0' outside the state block and it is gone.

I wasn't sure if it was raise state specific, so I tried Melee 0 in the dragon and Missile 0 in the bat decorate definitions and it seems to have cured both (after a quick test).

[hnsolo77]

for the dragon familiar just define a melee state and put in stop after that, same with a missile state for the bat, that should fix it no problem

[Xaser]

Ah, Enjay, that's the one.


Just in case (for the lazy), just copy+paste this code into the DECORATE (overwriting old definitions) and it'll be all good:

---

Code: Select all

actor DragonFamiliar: ImpWarlord 20125
{
    SKIP_SUPER
    SpawnID 218
    Health 25
    Radius 16
    Height 32
    Speed 10
    PainChance 200
    MONSTER
    +FLOORCLIP
    +NOGRAVITY
    +FLOAT
    +STRIFEDAMAGE
    SeeSound "DragonSee"
    PainSound "DragonPain"
    DeathSound "DragonDeath"
    ActiveSound "DragonIdle"
    Obituary "%o was cooked by a dragon familiar."
    States
    {
    Spawn:
        DFAM ABCD 10 A_Look
        Loop
    See:
        DFAM AABBCCDD 3 A_Chase
        Loop
    Missile:
        DFAM E 0 A_PlaySound("DragonAttack")
        DFAM E 0 A_Jump(208,7)
        DFAM E 2 Bright A_FaceTarget
        DFAM E 0 A_CustomMissile("MiniFirePuffNoDamage", 12, 0, 0)
        DFAM E 2 Bright A_FaceTarget
        DFAM E 0 A_CustomMissile("MiniFirePuff", 12, 0, 2)
        DFAM E 2 Bright A_FaceTarget
        DFAM E 0 A_CustomMissile("MiniFirePuff", 12, 0, -2)
        Goto See
        DFAM E 2 Bright A_FaceTarget
        DFAM E 0 A_CustomMissile("MiniFirePuffNoDamage", 12, 0, 0)
        DFAM E 2 Bright A_FaceTarget
        DFAM E 0 A_CustomMissile("MiniFirePuff", 12, 0, 2)
        DFAM E 2 Bright A_FaceTarget
        DFAM E 0 A_CustomMissile("MiniFirePuff", 12, 0, -2)
        Goto Missile+1
    Melee 0
    Pain:
        DFAM F 2
        DFAM F 2 A_Pain
        Goto See
    Death:
        DFAM G 0 A_Die
        DFAM G 8 A_NoBlocking
        DFAM H 8 A_Scream
        DFAM I 6 A_Fall
        DFAM JKL 6
        DFAM M -1
        Stop
    }
}
actor BatFamiliar: ImpWarlord 20126
{
    SKIP_SUPER
    SpawnID 217
    Health 10
    Radius 12
    Height 24
    Speed 14
    PainChance 200
    MONSTER
    +FLOORCLIP
    +NOGRAVITY
    +FLOAT
    SeeSound "BatIdle"
    PainSound "BatPain"
    DeathSound "BatDeath"
    ActiveSound "BatIdle"
    MeleeSound "BatIdle"
    HitObituary "%o was scratched by a bat familiar"
    MISSILEHEIGHT 0
    MeleeDamage 1
    States
    {
    Spawn:
        BFAM ABCB 3 A_Look
        Loop
    See:
        BFAM ABCB 3 A_Chase
        Loop
    Melee:
        BFAM A 3 A_FaceTarget
        BFAM B 3 A_MeleeAttack
        BFAM CB 3 A_FaceTarget
        Goto See
    Missile 0
    Pain:
        BFAM A 2
        BFAM A 2 A_Pain
        Goto See
    Death:
        BFAM D 0 A_Die
        BFAM D 0 A_NoBlocking
        BFAM D 5 A_Scream
        BFAM E 5 A_Fall
        BFAM FDEF 5
        Goto Death+5
    Crash:
        BFAM G 6 A_PlaySound("BatCrash")
        BFAM H 7
        BFAM I 8
        BFAM J -1
        Stop
    }
}

[DBThanatos]

Why?? is fun to have a morphing familiar

Jump is allowed right?

[Graf Zahl]

My reading of that is that when you use SKIP_SUPER, everything is defaulted except the states, which are inherited from the parent. So, again by my reading of that, ZdoomSVN and GZdoom are doing it right because they have inherited the parent's melee/missile states in the absence of redefined ones. Is that correct?[/edit2]

Most definitely not! SKIP_SUPER is supposed to eliminate all state references to the parent.

[Graf Zahl]

DECORATE code

The code is syntactically incorrect. Either put the 'melee 0' and 'missile 0' outside the state block or use

Code: Select all

melee:
    stop

[Phobus]

I've not seen any floating Imp Warlords, and I've been assaulted by numerous bloody bats... so far all they've done is irritate me and die at the smoking barrels of my chaingun and SSG (in one case).

[Enjay]

I've not seen any floating Imp Warlords, and I've been assaulted by numerous bloody bats... so far all they've done is irritate me and die at the smoking barrels of my chaingun and SSG (in one case).

Are you playing using 2.1.7? The problem does not appear there.

Most definitely not! SKIP_SUPER is supposed to eliminate all state references to the parent.

In that case, Id say the Wiki is a bit confusing.

It only uses inheritance to get access to the parent's states

Is that meant to mean that you get access to them - ie those are the things that you get to edit? That maybe seems like the intention in the cold light of day, but at 3am last night that sounded like "this gives the inheriting monster access to the parent states". ie it sounded like it copied the parent states to the child. To be fair, I did think that was odd because I thought that was how inheritance for states worked anyway, without SKIP_SUPER. Perhaps an improvement to the wording of the Wiki?

Anyway, if SKIP_SUPER is supposed to eliminate all state references to the parent, then GZDoom and Zdoom seem to be doing it wrong because they have clearly inherited the parent's missile/melee states for an actor that does not define them but which has SKIP_SUPER in the definition to prevent that.

Also, a thought struck me as I woke up this morning - why, when the Warlord melee/missile state is finished does the dragon/bat continue using the warlord sprites and not go back to the dragon/bat ones? Surely "goto see" even though it comes from the warlords attack sequence should send it back to the see state for the inheriting actor and not the one it has inherited from?

The code is syntactically incorrect. Either put the 'melee 0' and 'missile 0' outside the state block...

I noticed that, when running with 2.1.7, that gives a warning at the console that it will be deprecated in 2.2.0. However, the SVN version and GZdoom do not give this warning. What it the state of affairs here. I assume that, since the two versions not giving the warning are newer, the feature will not be deprecated after all?



Anyway, I *think* perhaps we are at the point of identifying a bug, so I've put it in the bugs forum:
http://forum.zdoom.org/viewtopic.php?f=2&p=316429

[Phobus]

Indeed I am using 2.1.7 (software still looks 'right' to me)