ZDoom

[quote="Enjay"]Hey! Good to see you. It's been a while. I hope that all is well with you.[/quote]
:D Let's just say that I'm in a better place now than I was five years ago.

Hey! Good to see you. It's been a while. I hope that all is well with you.

Thanks for the explanation.

I [i]think[/i] the attached save might be just before the dragon gets stuck in the PK3* that I uploaded earlier in the thread. It's hard to tell though because the dragon is out of sight when it happens. However, when you load it up, you can hear the dragon finishing its wake-up scream and its first volley of shots exploding. Give it a second and them pop your head around the corner and the dragon should just be hovering there in much the same place as it was in the saves included with the PK3.

For what ever reason, it getting stuck seems to be quite rare today, so this took a lot of goes to actually get a save before (I hope) the dragon got stuck. I missed it once then had to restart the map countless times to get it again. So here's hoping that I did.

BTW, I realised after uploading the map that the map spot args were not set correctly but the map still works (which I think your explanation covers why) and I have still seen the problem with correctly set up map spots too.

[quote="Enjay"]I did notice this in the ZScript for the actor:
[code] // [RH] Don't lock up if the dragon doesn't have any
// targs defined[/code]
and I thought that it might have been an attempt to at least partially address this but the code for this actor is too much for me to fathom.[/quote]
I wrote that, so let me explain. When the Wyvern gets to its target, it checks that target's args for the TIDs of up to 5 other potential targets, then picks a non-0 one at random. If they are all 0, then the original code would get stuck in an infinite loop, since it mindlessly keeps repeating until it gets a non-0 TID. That might have been acceptable for an MS-DOS game released in the 90's, but it wasn't suitable for ZDoom. Going nowhere is better than locking up.

Now, if you had a savegame just before the Wyvern reliably lost its way, it [i]might[/i] be possible to fix...

Thanks for that. I don't think I'd have found it on my own.

But, as you say, the setup is fragile - too fragile I feel. Sometimes, with some setups, it breaks almost as often as it works. It's a shame because the flying does look quite good but I may just have to go with using a standard enemy version (perhaps using paths and so on) if I end up using it at all.

[edit]
[quote="Gez"]Something you could try to do with a custom actor derived from the death wyvern is to check for the validity of the tracer pointer before calling A_DragonFlight, [b]and if the tracer is null, go through a function to reacquire one (like A_DragonInitFlight does)[/b].[/quote]
And I have just realised that all my attempts to do this have failed because by the time I try to use A_DragonInitFlight to recapture a tracer, the A_DragonFlight pointer has removed the Wyvern's tid and so I guess that it is trying to point to a thing with tid 0 and not one that matches the original tid that the Wyvern had at map setup. So the Wyvern just sits there unable to move and screaming instead of flying to a suitable location.
[/edit]

[edit2]
However, cloning the dragon and removing RemoveFromHash from the A_DragonInitFlight and then modifying the See sequence so that it calls A_DragonInitFlight every time the sequence cycles so far seems to have prevented the Wyvern getting stuck. This does mean, of course, that it visits its initial spot every time it goes through the See loop.

I have therefore modified it further so that the See loop is longer. So, in a pretty simple setup (like the one in MAP12 of Hexen) the flight seems reasonably natural.

Ideally, now that the Wyvern no longer clears its own tid, I could use Gez's suggestion of "check for the validity of the tracer pointer" to allow the Wyvern to fly around normally unless it doesn't have a valid tracer and jump to my modified A_DragonInitFlight if the check for a valid pointer fails.

Any help as to how that check/jump should look in ZScript would be welcome.
[/edit2]

The TID clearing at least is [url=https://github.com/coelckers/gzdoom/blob/b4c74fabd3847e35a80c072ff0aad485950faab6/wadsrc/static/zscript/actors/hexen/dragon.zs#L187]DragonInitFlight()[/url] calling [url=https://zdoom.org/wiki/RemoveFromHash]RemoveFromHash()[/url] if it gets a valid target. As for the rest, yes it's a fragile setup. All you can do is set it up, give it as little to crash into as possible, and count on it dying before it has a chance to go wrong since it's pretty weak. Tellingly the version in Wrath of Cronos works like a standard enemy.

I'm still trying to fathom this - and failing.

However, I noticed another oddity (feature?) of this actor. After it has reached its first node, be it a map spot or an enemy or whatever, it loses its tid (gets set to 0).

I noticed this because as soon as it reached its first waypoint, I lost the ability to track it using ACS. Using the info console command confirmed that it had tid 2 before reaching the waypoint and tid 0 afterwards.

Is this intended? And can't figure it out from looking at the ZScript.


FWiW, also noticed an error in my example map (the first waypoint has its arguments set incorrectly - referencing waypoints that were present in an earlier iteration of the map, but not the one that was uploaded).

				// [RH] Don't lock up if the dragon doesn't have any
				// targs defined

Thanks to you both.

[quote="Graf Zahl"]Fly to a spot, look at the possible set of next spots, choose one at random, rinse and repeat. If that logic gets disturbed somehow and the wyvern misses the next spot, the game is over.[/quote]
I guessed that was basically what the logic was and what was happening. It does seem very easy for the wyvern to miss a spot (though I'm not sure how it manages to - it can even do it when flying around on its own with the player out of sight and no other enemies present - very easy for it to confuse its own AI) and, as you said earlier, there are no correction abilities. It sounds like the logic is pretty broken and presumably has been since 1995. In fact, I'm pretty sure I remember the very first time I met a Wyvern when I first played Hexen, it got stuck and what was obviously meant to be an impressive scene simply wasn't.

I did notice this in the ZScript for the actor:
[code] // [RH] Don't lock up if the dragon doesn't have any
// targs defined[/code]
and I thought that it might have been an attempt to at least partially address this but the code for this actor is too much for me to fathom.


[quote="Gez"]Something you could try to do with a custom actor derived from the death wyvern is to check for the validity of the tracer pointer before calling A_DragonFlight, and if the tracer is null, go through a function to reacquire one (like A_DragonInitFlight does).[/quote]
I'd kind of got to the point of thinking that what is needed is a "do I have a valid tracer, if not, get one" logic in there somewhere. Strange that Raven didn't.

I tried a few things to achieve the above but, as I said, the ZScript is over my head here so everything I tried just failed. I tried to make sense of the functions in the Wyvern that deal with this stuff but I simply don't know the ZSCript syntax well enough. I can see enough to guess "I think that's the bit that is doing what I'm interested in" but not enough to know "I understand exactly what this is doing, it all makes sense and I could replicate it if I wanted". There are just too many things in there that are unknown to me and I can't just intuit the syntax.

I also tried much more basic things like inserting a couple of A_Chase or A_Wander calls into the See sequence. They weren't too noticeable if the wyvern was working fine but, not surprisingly, as soon as it became stuck it was very obvious that the AI had changed and was behaving and a weird and not useful way.

Something you could try to do with a custom actor derived from the death wyvern is to check for the validity of the tracer pointer before calling A_DragonFlight, and if the tracer is null, go through a function to reacquire one (like A_DragonInitFlight does).

You must not forget that the AI looks like:

Fly to a spot, look at the possible set of next spots, choose one at random, rinse and repeat. If that logic gets disturbed somehow and the wyvern misses the next spot, the game is over.

That's a shame. It fails often enough for it to be too risky to use IMO.

Is this something that can be addressed or is it more of an "it's always been like this, so it's too late to change it" kind of thing?

Yes, it can get stuck. That's just a direct result of how its pathfinding AI works. It has no error correction capabilities at all, so if something goes wrong there's no way to get out anymore.

I'm quite prepared to believe that this is user error because the setup for the Death Wyvern is a little complicated. However, I *think* I have set things up correctly according to the Wiki and I have actually seen the same thing happen in Hexen in an unaltered vanilla map. So I think it might be possible that the Death Wyvern can sometimes get an invalid target to navigate to.

This little test map is mostly just an area taken from map12 of Hexen, but modified for Doom2. Sometimes it works just fine, sometimes it doesn't. In fact, initially, before I started messing with it, this map was an exact copy of the relevant area from the Hexen map with all of the same tids and everything and the problem could still occur.

I am also including two save games that should show the Wyvern in a stuck position. Shortly after the map started, the Wyvern flew to this position and got stuck. That's the first save. The second one is from a few moments later after I shot the Wyvern and it went into some sort of weird perpetual pain loop.

Points just to mention, the Wiki states that the first target that the Wyvern has is best if it is something that the Wyvern can attack (like an Ettin in the original Hexen map12). I have tried the linked map both with and without a killable first target. It made no difference to this particular problem - the Wyvern could get stuck with a shootable target as its first node and with a simple map spot (as per the linked example).

There are floating monster blocking lines in the map and the Wyvern does seem to be stuck against one of those. However, without these lines, the Wyvern just flies a bit further north and then gets stuck on a wall instead.

Test map and save files
https://aspectsweb.co.uk/enjay/doom/TestStuff/DragonTest1.zip
Load the PK3 into Doom2 (not Hexen) and use either of the save games to see a stuck Wyvern.

If you want to try to force this to happen from a new game, run forward, pick up the shotgun and shells (the Wyvern will see you and you should hear its wake up scream). Then go back to the player start spot and push yourself against the wall. Listen for the Wyvern's wingbeats and screams and pretty soon, if this is going to happen, they will start to sound like they are always coming from one place because the Wyvern is no longer moving. Like I said, sometimes it gets stuck, sometimes it doesn't but the above procedure seems to get it stuck more often than not whereas running straight out into the arena means that it very rarely gets stuck.

Probably not a bad idea to turn on god mode too. The Wyvern is nasty and the lava is set to do quite a lot of damage as well.