I checked the latest build. I saw two Cacodemons fly up inside each other and get stuck just like before in E4M2. Either I just got very unlucky seeing this happen right away, or the problem still exists. I'll have to continue testing. I've also noticed a severe slowdown in E4M2 with resources enabled, which I didn't get in previous builds. Even with dynamic lights disabled, the slowdown still occurred. Hmmm.
Dani, did you look into the reason why Daniel Norton's Detail textures don't work? It is still broken with the latest build.
I checked the latest build. I saw two Cacodemons fly up inside each other and get stuck just like before in E4M2. Either I just got very unlucky seeing this happen right away, or the problem still exists.
Have you enabled game-mobj-fracepsilon? As skyjake described earlier, this must be manually enabled presently in order to test it.
Dani, did you look into the reason why Daniel Norton's Detail textures don't work? It is still broken with the latest build.
Not as yet no, I have been busy with other things.
Oh yeah, I also wanted to follow up on the first automap issue I reported a couple of posts ago (where you see a triangle on the map but on the gameplay nothing is there).
I was playing E2M5 and was in that room where the 2 Barons of Hell come down from those pillars (in the middle of the map). I was killing the last Baron of Hell and he threw a fireball at me. I switched to the automap for whatever reason. I noticed the triangle on the automap that represented the fireball traveling across the room. It missed me, and the fireball traveled to the corner of the room. The triangle on the automap representing the fireball never cleared off the automap, and you saw a triangle facing the corner of the room. To be more specific, it was in the northwest corner of the room, and the coordinates are about -2224, 1152.
But I see these issues a lot on E2M8, for testing purposes.
And you don't believe that the stuck monsters issue is fixed now?
automap issue I reported a couple of posts ago... ...I was playing E2M5 and was in that room where the 2 Barons of Hell come down from those pillars... ...he threw a fireball at me... ...I noticed the triangle on the automap that represented the fireball traveling across the room... ...never cleared off the automap
I'll take a look. That would suggest that the mobj is either not being destroyed or is not being unlinked from the blockmap for whatever reason.
And you don't believe that the stuck monsters issue is fixed now?
No I don't believe its fixed at all. Skyjake's change does indeed prevent it entering a float if a mobj is in the way, however once the float has begun, it can still move inside the mobj.
DOOM's logic for this is very odd indeed - the first half of which is handled alongside the X|Y movement while the other half is handled in the Z axis movement.
Edit: Ok, I can solve the stuck issue with the Cacodemon in synthetic test situations between two mobjs without affecting the original game logic. However, the same fix is ineffective when multiple mobjs overlap on the X|Y plane.
Fundamentally, this is not solvable as is using vanilla's 2d logic. We either need to restore the original movement logic which prevents mobj's from passing over/under each other, or we need to implement an entirely separate logic branch which allows it, using the correct mechanisms for the purpose.
It is my opinion that the 3d movement cannot be supported by the logic which also must retain compatibility with the original game.
The latest build did nothing to resolve any of the issues in Armadosia map 25 with certain walls not opening and a pillar not raising, as well as a switch near the beginning not opening a wall in the lava area right before the room with 4 radiation suits. Can someone or some people please test this map and play through it to see what I mean? I'm forced to use -noclip in certain sections of the map as a result. Is this a Doomsday problem or a map problem?
No I don't believe its fixed at all. Skyjake's change does indeed prevent it entering a float if a mobj is in the way, however once the float has begun, it can still move inside the mobj.
As DaniJ says, Doom's movement logic is complex (not to mention buggy), and there are many scenarios remaining where mobjs (including Cacodemons) may end up stuck. It seems very unlikely we can fix all of these for 1.9.7.
It is my opinion that the 3d movement cannot be supported by the logic which also must retain compatibility with the original game.
I agree. Since the original game relies on 2D logic, enabling 3D movement by definition means that compatibility is broken. At some point we need to set up a completely separate logic for the "modern" playsim.
Presently we have the "game-zclip" cvar, though. It should have an influence on this so that if set to false, the logic strives to conform to the original 2D logic. Does anyone play with "game-zclip" set to zero? I wonder if the monsters get less frequently stuck that way.
I've just been discussing this with Vermil and we reached the conclusion that the reason this is now happening is because the Cacodemon is being allowed to pass over/under other mobjs - this wasn't allowed in 1.8.6
The player however, is allowed to pass over/under a Cacodemon. The Cacodemon checks the player it is targeting with its "float-to-target" logic in P_MobjMoveZ(), so in single player it is not normally possible for it to get stuck. Multiplayer however, is a different matter because other players are not included in this logic.
Is the insanely fast wallrunning in Doomsday deliberate? I usually kind of avoid being near the walls when playing in Doomsday. Was this something that happened in Vanilla? I recently decided to turn on "Use Doom's original clipping code" in gameplay options.
I have already said I would take a look at Armadosia and I intend to. There is nothing more I can say until I've taken a look - you haven't really given us much to go on other than "stuff doesn't work".
I didn't know if you were referring to just checking Armadosia to see if the monsters can see you through walls and nothing else. Well, I described what I could in several paragraphs and gave examples and even described a location on a particular map.
Anyways, thanks for saying you would check it out. I'm on map 26 now.
Yeah I noticed you made an effort to describe where the problem could be observed in a few instances. However, this kind of description is not generally helpful to a developer, particularly when they are completely unfamiliar with whatever it is you would like them to look into.
With map issues, ideally we want the coordinates in the map where the problem occurred. For example, if you pull a switch and it doesn't work as you think it should - open the console and enter "where". This will give you the coordinates of your current location which you can then include in your report. If its a visual issue a screenshot may be helpful also.
Basically the more the user can do to minimize the developer's "startup time" the better your chance that one of us will take it up. If we have to actually play through a mod following an abridged walkthrough chances are it will be put off until we don't have anything more urgent to address.
Anyways, for map 25, the coordinates for the area in front of the switch that is misbehaving are X: -203.469 Y: -158.191 Z: -496
As for the area in front of the pillar that should open: X: -1638.11 Y: -3057.83 Z: -504 and I'm guessing the floor trigger is somewhere around X: -1839.7 Y: -4041 Z: -504
As for the area in front of the wall that should open: X: -2404.64 Y: -3003.52 Z: -640 and the floor trigger that is supposed to open seems to be very near to X: -1832.14 Y: -3047.76 Z: -640
If one tries to alt tabs out of Dday on Windows in the new builds while the games are being searched for, Dday will often hang.
If one tries to alt tab at any later point during engine and game startup, Dday will crash with an 'Fi responder not initialized yet!' error.
The out file doesn't produce a specific error, but here are the last lines:
Starting music 'dm2ttl'...
Deactivating binding context 'finale'...
Unloaded game.
MasterWorker_Shutdown: Waiting for thread to stop...
Shutting down the console...
A little testing reveals this issue seems to go back to build 404. 402 has no issues with one alt-tabbing during startup and 397 crashes, but produces an entirely different error message about the console being busy, with the out file stating: 'Con_Error: Stack overflow imminent, aborting...'
If one tries to alt tabs out of Dday on Windows in the new builds while the games are being searched for, Dday will often hang.
This stems from the fact Con_BusyLoop() now processes events. It is dd_input.c's dispatchEvents() which causes the error, its trying to execute gx.Responder but the entrypoints haven't been imported yet.
Game resources are located using busy mode. To locate game resources it is presently necessary to change the global theGame reference so that the resource system can temporarily pretend it's another game and have access to all the search paths (etc...) for that game. During this time DD_GameLoaded() will misleadingly return true even though the game hasn't actually been loaded yet. Busy mode calls this method to determine whether it should execute the game's event responders.
Edit: This issue should now be fixed for Monday's build 416.
I was able to find another instance of stuck monsters clustered together, like DaniJ was pointing to in E1M5. This is in E1M7, near the infamous column. If you look at the nearby window, you'll see a group of three Imps stuck together (on UV at least).
The issue where you kill an enemy like a Shotgun Guy and they seem to drop boatloads of Shotguns?
I got the issue while I was testing E1M7. This was at the beginning of the map on the UV skill level.
Notice how there are multiple Shotgun Guys lumped together, so instead of a Shotgun Guy dropping multiple Shotguns, somehow killing the Shotgun Guy produced several Shotgun Guys, and a Shotgun to go with each of them. Again, there are only 2 or 3 Shotgun Guys at the beginning of E1M7, so that's out of the question.
So maybe
this is just me not having had this happen but could this happen when the engine thinks there is more then one mobj in the same spot?
It's not just episode one, in that first instance I showed you in that topic, I encountered the bug in E2M5.
And I just got it again while playing E2M1. It was with the first Shotgun Guy you see after going through the starting teleporter (on UV). Killed it with a Pistol and there was an Imp right next to it too, if that means anything.
I really wish there was a way to consistently reproduce this because even DaniJ says that there isn't a whole lot he could do without constant reproduction of the bug.
automap issue I reported a couple of posts ago... ...I was playing E2M5 and was in that room where the 2 Barons of Hell come down from those pillars... ...he threw a fireball at me... ...I noticed the triangle on the automap that represented the fireball traveling across the room... ...never cleared off the automap
I'll take a look. That would suggest that the mobj is either not being destroyed or is not being unlinked from the blockmap for whatever reason.
I tested this and there appears to be nothing strange going on with Baron of Hell fireballs. They spawn, move and then die, disappearing from the automap as expected, for me at least. Are you using any addons which change their behaviour?
Notice how there are multiple Shotgun Guys lumped together, so instead of a Shotgun Guy dropping multiple Shotguns, somehow killing the Shotgun Guy produced several Shotgun Guys,
I've tried but failed to come up with a possible explanation for such behaviour. A dead shotgun guy is still the same shotgun guy, i.e., there is only one mobj for both the live and dead version of the enemy; upon death it merely changes to another state. In order for multiple guys to appear on death (at different coordinates) there would need be additional enemies spawned into the world.
Next time this happens, open the console and turn on "rend-dev-thinker-ids 1", the engine will then render some identifiers over the top of all mobjs in the world. Position yourself so that all the offending objects are in view and then take a screenshot. The values of the identifiers might help to shed some light on this issue.
Edit: Re embedded enemies that cannot separate
This seems to be caused by "game-mobj-fracepsilon", so effectively you can fix the E1M7 column but break the rest of the game... This suggests to me that it isn't the collision detection which is at fault here.
I want to follow up with another detail on that Shotgun Guy issue. I haven't encountered anything yet, but I wanted to note that every time I previously encountered this issue, it was with the first Shotgun Guy that I killed in the map. If that can give you any possible lead, that'd be great.
I've been trying several times to get this reproduced, but of course the issue won't happen when I need it most...
EDIT: Need to contradict my findings here, but I encountered this issue on E1M3, but it was the second Shotgun Guy I killed. I did, as Danj requested, screenshotted with the thinder IDs, and the ID came as 1725.
The Shotgun Guy right in front of me.
I'ma gonna go back to testing.
EDIT #2: Any way to reset the thinker ids back to 0 without quitting the game? Like every time you change maps, the thinker ID numbers increase. I'm trying to tag another Shotgun Guy as thinker id 1725. Thanks.
Your screenshot only seems to show one Shotgun Guy at that spot, where are his doppelgangers?
The thinker ids are managed automatically by the engine and are automatically reset when the map changes. There is no guarantee that a mobj will be assigned the same id each time you play; this is determined by spawn order (including things dynamically spawned like missiles).
Dday's default remapping of the menu and intermission graphics to text, appears to confuse Dday's resource replacement system.
One has to use the '-pwadtex' command line option to make external replacement graphics for graphics Dday remaps to text by default, to be used in game.
I found that difficult to write. Hope it's understandable.
This effects the JDUI add-on for instance, as incinuated in the add-ons thread here on the forum.
It seems that the problem is that certain walls and doors are stuck. In map 26 of Armadosia, when I got the blue key and tried to opened the first blue key door (the one near that key), I could hear it open but it didn't move at all.
It seems that the problem is that certain walls and doors are stuck. In map 26 of Armadosia, when I got the blue key and tried to opened the first blue key door (the one near that key), I could hear it open but it didn't move at all.
That isn't a bug in Dday. The door relies on behaviour ZDoom altered compared to Vanilla Doom, to work.
One has to use the '-pwadtex' command line option to make external replacement graphics for graphics Dday remaps to text by default, to be used in game.
Comments
Dani, did you look into the reason why Daniel Norton's Detail textures don't work? It is still broken with the latest build.
Not as yet no, I have been busy with other things.
I thought that was for the E1m7 column bug? That's what I gathered by reading his post. I didn't realize that command was for the Cacodemon bug.
I was playing E2M5 and was in that room where the 2 Barons of Hell come down from those pillars (in the middle of the map). I was killing the last Baron of Hell and he threw a fireball at me. I switched to the automap for whatever reason. I noticed the triangle on the automap that represented the fireball traveling across the room. It missed me, and the fireball traveled to the corner of the room. The triangle on the automap representing the fireball never cleared off the automap, and you saw a triangle facing the corner of the room. To be more specific, it was in the northwest corner of the room, and the coordinates are about -2224, 1152.
But I see these issues a lot on E2M8, for testing purposes.
And you don't believe that the stuck monsters issue is fixed now?
DOOM's logic for this is very odd indeed - the first half of which is handled alongside the X|Y movement while the other half is handled in the Z axis movement.
Edit: Ok, I can solve the stuck issue with the Cacodemon in synthetic test situations between two mobjs without affecting the original game logic. However, the same fix is ineffective when multiple mobjs overlap on the X|Y plane.
Fundamentally, this is not solvable as is using vanilla's 2d logic. We either need to restore the original movement logic which prevents mobj's from passing over/under each other, or we need to implement an entirely separate logic branch which allows it, using the correct mechanisms for the purpose.
It is my opinion that the 3d movement cannot be supported by the logic which also must retain compatibility with the original game.
I agree. Since the original game relies on 2D logic, enabling 3D movement by definition means that compatibility is broken. At some point we need to set up a completely separate logic for the "modern" playsim.
Presently we have the "game-zclip" cvar, though. It should have an influence on this so that if set to false, the logic strives to conform to the original 2D logic. Does anyone play with "game-zclip" set to zero? I wonder if the monsters get less frequently stuck that way.
The player however, is allowed to pass over/under a Cacodemon. The Cacodemon checks the player it is targeting with its "float-to-target" logic in P_MobjMoveZ(), so in single player it is not normally possible for it to get stuck. Multiplayer however, is a different matter because other players are not included in this logic.
Given that the head is a small mob, it can sometimes lead to the camera clipping into the void if the head happens to land right next to a wall.
Anyways, thanks for saying you would check it out. I'm on map 26 now.
With map issues, ideally we want the coordinates in the map where the problem occurred. For example, if you pull a switch and it doesn't work as you think it should - open the console and enter "where". This will give you the coordinates of your current location which you can then include in your report. If its a visual issue a screenshot may be helpful also.
Basically the more the user can do to minimize the developer's "startup time" the better your chance that one of us will take it up. If we have to actually play through a mod following an abridged walkthrough chances are it will be put off until we don't have anything more urgent to address.
Anyways, for map 25, the coordinates for the area in front of the switch that is misbehaving are X: -203.469 Y: -158.191 Z: -496
As for the area in front of the pillar that should open: X: -1638.11 Y: -3057.83 Z: -504 and I'm guessing the floor trigger is somewhere around X: -1839.7 Y: -4041 Z: -504
As for the area in front of the wall that should open: X: -2404.64 Y: -3003.52 Z: -640 and the floor trigger that is supposed to open seems to be very near to X: -1832.14 Y: -3047.76 Z: -640
If one tries to alt tab at any later point during engine and game startup, Dday will crash with an 'Fi responder not initialized yet!' error.
The out file doesn't produce a specific error, but here are the last lines:
A little testing reveals this issue seems to go back to build 404. 402 has no issues with one alt-tabbing during startup and 397 crashes, but produces an entirely different error message about the console being busy, with the out file stating: 'Con_Error: Stack overflow imminent, aborting...'
Game resources are located using busy mode. To locate game resources it is presently necessary to change the global theGame reference so that the resource system can temporarily pretend it's another game and have access to all the search paths (etc...) for that game. During this time DD_GameLoaded() will misleadingly return true even though the game hasn't actually been loaded yet. Busy mode calls this method to determine whether it should execute the game's event responders.
Edit: This issue should now be fixed for Monday's build 416.
Also, remember this issue?
viewtopic.php?f=7&t=901
The issue where you kill an enemy like a Shotgun Guy and they seem to drop boatloads of Shotguns?
I got the issue while I was testing E1M7. This was at the beginning of the map on the UV skill level.
Notice how there are multiple Shotgun Guys lumped together, so instead of a Shotgun Guy dropping multiple Shotguns, somehow killing the Shotgun Guy produced several Shotgun Guys, and a Shotgun to go with each of them. Again, there are only 2 or 3 Shotgun Guys at the beginning of E1M7, so that's out of the question.
So maybe
That has something to do with it?
And I just got it again while playing E2M1. It was with the first Shotgun Guy you see after going through the starting teleporter (on UV). Killed it with a Pistol and there was an Imp right next to it too, if that means anything.
I really wish there was a way to consistently reproduce this because even DaniJ says that there isn't a whole lot he could do without constant reproduction of the bug.
Next time this happens, open the console and turn on "rend-dev-thinker-ids 1", the engine will then render some identifiers over the top of all mobjs in the world. Position yourself so that all the offending objects are in view and then take a screenshot. The values of the identifiers might help to shed some light on this issue.
Edit: Re embedded enemies that cannot separate
This seems to be caused by "game-mobj-fracepsilon", so effectively you can fix the E1M7 column but break the rest of the game... This suggests to me that it isn't the collision detection which is at fault here.
I've been trying several times to get this reproduced, but of course the issue won't happen when I need it most...
EDIT: Need to contradict my findings here, but I encountered this issue on E1M3, but it was the second Shotgun Guy I killed. I did, as Danj requested, screenshotted with the thinder IDs, and the ID came as 1725.
The Shotgun Guy right in front of me.
I'ma gonna go back to testing.
EDIT #2: Any way to reset the thinker ids back to 0 without quitting the game? Like every time you change maps, the thinker ID numbers increase. I'm trying to tag another Shotgun Guy as thinker id 1725. Thanks.
The thinker ids are managed automatically by the engine and are automatically reset when the map changes. There is no guarantee that a mobj will be assigned the same id each time you play; this is determined by spawn order (including things dynamically spawned like missiles).
One has to use the '-pwadtex' command line option to make external replacement graphics for graphics Dday remaps to text by default, to be used in game.
I found that difficult to write. Hope it's understandable.
This effects the JDUI add-on for instance, as incinuated in the add-ons thread here on the forum.
That isn't a bug in Dday. The door relies on behaviour ZDoom altered compared to Vanilla Doom, to work.
And that wad demonstrating it, if the image is unclear: http://koti.mbnet.fi/jeejeeje/doom/marbface.wad