Menu
▾
▴
1 Attachments
#681 MBF dogs are broken
Attached is a U-shaped test WAD with two monsters:
- A demon (type 3002)
- A dog (type 888)
If the position with the dog comes into view, the engine says:
|
| Warn: R_ProjectSprite: invalid sprite frame 267 : 1 for DOGS
and the dog has no sprite (is invisible). The corresponding mobj is there and attacks the player.
If a helper dog is configured, the engine does not spawn it and says:
|
| Warn: P_SpawnMapthing: Unknown type 143 at (184, 74)
I have patched in some debug messages for the index of things:
|
| Spawn thing type: 3002
| Type: 3002 => Index 12
| Spawn thing type: 888
| Type: 888 => Index 143
It is likely no coincidence, that 143 is the index of thing type 888.
Tested with Doom Legacy 1.48.9 (rev 1598) on Linux/PowerPC.
The friendly dogs need start points for additional players.
The attached WAD file contains 4 player start points.
If you open console
You can then see your dog moving around. This works on any map, so I have been testing on doom2.
The dog on your map does work. The dog cannot be seen because the wad is not supplying a dog sprite. DoomLegacy does not supply a dog sprite for you.
I tested with dogs when this was developed, but now I cannot find the map with the dog sprites.
Using dehacked you can specify any monster type to be used as the DOG.
[HELPER]
TYPE = 23
There is an error in the extra dog spawn, which you noticed. It is using the MT_DOG code, instead of the doomed number using in mapthings.
I have a fix for that, but have a communication problem due to mapthing not having an extra dog doomed code. Inventing a new doomed code would expose it to use by wad maps, which would be a new hassle.
However I come at it, it ends up being hacked code.
Last edit: Wesley Johnson 2021-11-11
prboom+ has sprites and sounds for the dogs in its engine WAD (prboom-plus.wad). I have used SLADE to copy them from there.
If there are no license issues:
Would it be possible to add them to legacy.wad too?
Patched svn 1600.
I can confirm that the helper dogs now spawn as expected.
Tested with svn 1601.
Thanks, I have been trying to find some dogs for two days.
Would have to put dog sprites in a separate wad. Then can specify that wad when it is needed. Can keep the license issues separate too. Everything in legacy.wad is our own property.
Currently, if dogs were put into legacy.wad, they would override any dog sprites from the iwad, and pwads.
I am having this problem with other sprites.
There are some cases where the legacy wad needs to override the pwad, and I am finding more cases where it should not.
Easier for now to make it a separate wad, that could be specified before or after the pwad, depending on which overides which.
should call it:
dogs_prboom.wad
I think we also need a sprite, to be used by default, for other missing monsters.
See: The Antaresian Spacepond, antaxyz.zip
On Map01, there is a "something" that kills me, doomed type 7734.
It runs around, and shoots me, but does not have a sprite.
The Dehacked lump defines this type as "Lunch" and with PrBoom+ and Woof it has a sprite -- looks like a sandwich (and does not attack as expected).
Seems that Legacy does not correctly handle the Dehacked modification.
From Valiant.wad dehacked:
Thing 140 changes the rocket smoke into a monster. When the rocket-launcher is fired, a monster immediately appears and explodes the rocket.
The line has: Thing 140 (Avanc... (DOG SLOT)).
In Eternity Engine MT_DOG = 140, but in PrBoom MT_DOG = 138, but in
Legacy MT_DOG = 143.
In Legacy, 140 = MT_SMOK.
This cannot be fixed by moving the MT_DOG code.
see svn 1603
For Thing numbers in the range 138..150, have added an additional
test of the dehacked text.
Have created a table of a characteristic words that might appear for each
of the thing numbers in this range. If one of these words is found,
the thing number is changed to our MT code.
This fixes the rocket-launcher in Valiant.wad.
Now the "Lunch" in antaxyz.zip is still running around like a dog, and still does not have a sprite, but is no longer attacking me.
Any usage by a wad of the non-standard MT types, is likely to broken in
any port other than the one the wad was tested with.
This is becoming a losing battle.
SVN 1603 works better, e.g. in Eviternity the Nightmare demon uses the correct sprite.
SVN 1604 is a regression, e.g. the rocket launcher in Valiant is broken again (and the "Lunch" from Antaresian Spacepond attacks me).
If this cannot be fixed cleanly with autodetection. What about a manual configuration option?
In MBF mode at least the dogs (and replacements like in Eviternity) should be compatible with MBF (Woof) or PrBoom+ complevel 11 (looks like most MBF-WADs are designed for, or at least tested with this setup).
The previous dehacked fix was broken in multiple ways.
Please test svn 1606. Have commited to releasing 1.48.10 code and need to know if the are still problems, as even if I cannot fix them, I need to document them.
Have made dog sprites and dog sounds for DoomLegacy.
Have to spend a day remembering how to make a wad out of these (GIMP).
Code contains new command switch. See docs/whatsnew.
-dehthing prboom
A Legacy wad that uses dogs is Twilight.wad.
This uses dogs using the Legacy dehacked thing id, and supplies its own dog sprites.
I tested it Dec 19, and it seems to still work.
Tested SVN 1608 (with my modified legacy.wad for the dog sprites):
With my test map:
I have configured two helper dogs and my map contains one enemy dog.
Only the enemy dog attacks me. Looks good.
With Antaresian Spacepond:
The dog behind the first door does not attack.
It is marked as "friendly" in the map. Looks good too.
"Dog Jumping" configured to "On" does not work:
If I start Map 1 of Doom2 with helper dogs, they don't jump down from the starting ledge (and therefore can't follow me).
Compared with Woof: Here the dogs jump down as expected.
The Dehacked stuff as a whole still does not work as expected (even with -dehthing).
But this does not belong to this ticket (and is better than before ... maybe it should be addressed after the release).
If you have Monkeys turned OFF, it takes longer for them to come down, but they do eventually jump down. With Monkeys turned on, it is much faster.
I tested with 5 dogs, which speeds testing, as they jump down based on random numbers.
Tested with SVN 1620 (two helper dogs and dogs.wad):
Seems to work now in general.
It is still possible to complete Map 1 of Doom 2 while both dogs are located on the starting ledge.
In my test the dogs come off that ledge, and even higher.
It makes a difference how many dogs you have. I have been using 4, which works well. Using only 2 seems to take a while for them to jump down, but if the player waits close by they eventually will jump down. Must be the random numbers.
Also, somehow with 4 dogs, I will end up with 2 dogs back up on that ledge, even after I have had all 4 down and running around. I do not know how they are doing that. I have tested that they actually stay dead when killed, so it is not reincarnation.
Please check that you have monster dropoff set ON, as that is necessary (MBF logic, not mine). The dependence of dogs_jumping on mbf_dropoff is hidden and thus a continual problem.
It seems to me that the way MBF used dropoff is wrong.
I think I should change the monster dropoff from on/off to:
OFF,
MBF, // as in MBF, enable monster dropoff and dog jumping down.
DOGS, // allow dogs jumping, but not monsters dropoff
Also change dogs_jumping to:
OFF,
MBF, // allow dogs jumping, dependent upon mbf_dropoff
ON, // allow dogs jumping, independent of mbf_dropoff
This allows playing demos and gives the user two ways to avoid this gotcha.
There is a mbf21, that is going to add more complications, so my instinct is to fix both.
Last edit: Wesley Johnson 2022-02-08
| Please check that you have monster dropoff set ON, as that is necessary (MBF logic, not mine).
Yes, both are set to ON. If I wait directly beyond the ledge they jump down.
If I wait a bit more far away (but still between the starting ledge and the first enemies on Doom 2 / Map 1), they don't jump down. What was missing in my test was Monkeys set to ON.
In the "FAQ/Compatibility" section of the documentation there is now a good description.
I think it is sufficient and the extra setup options are not required (there are already too many options).
MBF21 support would be nice to have, but this is unrelated to this ticket.
Can be closed now.