<blockquote>Beat DooMII and while its going through the charachters of the game press escape and use the arrow keys to change options in the menu. You should notice that pressing a key will kill the monster (even though the menu(not doomsdays control panel) is up)</blockquote>
Fixed in SVN 3193.
When the menu is active none of; InFine, chat widget, cheat responders should get a chance to process the input event.
<blockquote>For example when calling P_Callbackp with a dummy sector and eg DMU_SECTOR, R_UpdateSector is called on the dummy. Now because it is a dummy it doesn't have a valid subsector or line list so that is where the segmentation violation occurs.</blockquote> Ah, I see. However, the change notifications should be implemented differently. For example, when the light level of a sector changes, the notification should come directly from the DMU_LIGHT_LEVEL case of SetProperty. The function could be named something like R_NotifySectorLightLevelChanged(sector_t* sec, int new, int old). The new value is known because it is in args, and the old value is known because it is the current value of the lightlevel before the new one is applied.
However, before we redo the whole thing, wouldn't a "P_IsDummy" test in R_UpdateSector suffice?
<blockquote>any attempt to get the sector of a plane will cause seg vio</blockquote> Are dummy sectors used anywhere at the moment?
I don't think the silent bfg trick works anymore in doomsday..
e.g. Press the space bar on a blank wall just after pressing the fire button while using the bfg. it is supposed to silence the bfg
<blockquote>Ok when i try and load this xg file (made by dani)</blockquote> Try pasting the definition here, inside <pre> tags. Wordpress has the same "helpful" feature that MS Word has, namely "smart quotes" where the ASCII character 34 is replaced with its Unicode left quote and right quote variants.
Doomsday defines the DED file format as ISO 8859-1 (Latin 1), and the syntax is that all quotes must be the ASCII character 34 (like in most programming languages).
However, the bug here is that Doomsday should detect and report this, not crash outright.
<blockquote>However, the change notifications should be implemented differently. For example, when the light level of a sector changes, the notification should come directly from the DMU_LIGHT_LEVEL case of SetProperty.</blockquote>
Yes I agree. I just moved all the update checking out of the routines that checked each tic for changes, into one function as a temporary measure.
<blockquote>However, before we redo the whole thing, wouldn't a "P_IsDummy" test in R_UpdateSector suffice?</blockquote>
In that particular instance, yes.
<blockquote>Are dummy sectors used anywhere at the moment?</blockquote>
Yes in XG for various stuff.
Also, properties of the dummys arn't being initialized anywhere currently (other than the DMT type header).
<blockquote>I don't think the silent bfg trick works anymore in doomsday..
e.g. Press the space bar on a blank wall just after pressing the fire button while using the bfg. it is supposed to silence the bfg</blockquote>
That particular trick hasn't worked in jDoom for quite a while. I know why and I know what needs to be done to emulate this behaviour. I'll add a compatibility option for it once implemented.
<blockquote>Also, properties of the dummys aren't being initialized anywhere currently (other than the DMT type header).</blockquote> I would imagine that just clearing all of them to zero would suffice (?), in P_AllocDummy. The game's dummy alloc routine should do a similar operation. In a dummy sector's case, could the planes be initialized so that they point to the right sector, i.e. the dummy sector?
<blockquote>I would imagine that just clearing all of them to zero would suffice (?), in P_AllocDummy. The game's dummy alloc routine should do a similar operation.</blockquote>
Sounds OK to me.
<blockquote>In a dummy sector's case, could the planes be initialized so that they point to the right sector, i.e. the dummy sector?</blockquote>
Well, technically they shouldn't given that planes are now a seperate object (as far as users of DMU are concerned).
If we are going to allow an arbitary number of planes per sector then the game should make the decision if and how many planes a dummy sector is intialized with.
Perhaps the best scenario is if there is a helper function game-side that instigates the call to alloc the dummy sector while at the same time, alloc and link the dummy planes?
<blockquote>Are dummy sectors used anywhere at the moment?</blockquote>
Actually I've just checked and dummy sectors arn't used at all in XG. Sorry about the misinformation.
We should still safeguard them though.
I'm getting a "P_Callbackp: Type (invalid) unknown." error with xgtest.wad when I activate the up switch in the elevator.
Also some of the switches don't seem to work correctly. I can't get through the split door without noclip for instance.
I've fixed most of the bugs in XG but the remaining ones are proving quite tricky to track down with my limited selection of debugging tools.
xgtest.wad (and XG) also seems to have plentiful endianness problems.
Problems I noticed:
<ul>
<li>Floor textures don't scroll (I recall that they should?).
<li>Stair builder doesn't do anything.
<li>After life bank withdraw, player has something like -10000 health...
<li>The door to the elevator does not open.
</ul>
<blockquote>Floor textures don't scroll (I recall that they should?).</blockquote>Yes.
<ul>
<li>The floor in the entry room should scroll toward the door to the elevator.</li>
<li>The back wall behind the floor that drops when the zombie is killed should scroll toward the lower left corner.</li>
<li>The little room beyond the stair builder room; each quadrant of the floor's texture should scroll toward the center of the room</li>
</ul>
Note, they work on my system so it does sound like endianness problems.
I've now managed to fix all of the problems I listed above.
I am wondering about hall-of-mirrors on missing bottom (and top) wall segments, though. Originally, the renderer replaced those automatically with the floor (or ceiling) texture. I made this the default behaviour because in Hexen map01 there is a missing top texture in the key room (after the sideways-moving brass doors), behind the glass on the far side of the room. Apparently this behaviour has been broken at some stage? In any case, we should not be getting HOM anywhere, so I recommend we fix the renderer to work like before.
<i>This comment was posted by dengDevs user <b>Melfice</b>.</i>
I have still been experiencing save game errors while testing a specific map, although in another map I haven't had any problems. Refer to the link below for a .txt log of errors I've had while testing and developing my maps I stared today.
If you'd like to see for yourself if you can reproduce errors, below is a link to MAP12.rar which includes the wad file for the map and the BIAS lighting .ded for it. If you need the resouces and pk3, DaniJ has them.
<blockquote>I am wondering about hall-of-mirrors on missing bottom (and top) wall segments, though. Originally, the renderer replaced those automatically with the floor (or ceiling) texture. I made this the default behaviour because in Hexen map01 there is a missing top texture in the key room (after the sideways-moving brass doors), behind the glass on the far side of the room. Apparently this behaviour has been broken at some stage? In any case, we should not be getting HOM anywhere, so I recommend we fix the renderer to work like before.</blockquote>
It wasn't broken as such but I removed this behaviour as it was causing problems with common DOOM.EXE renderer tricks employed in PWADs. This behaviour was also causing seg violations with some PWADs, such as bludwrks.wad
I removed it with the plan that I would implement a better system to detect and fix these before 1.9.0 final.
<blockquote>I've now managed to fix all of the problems I listed above.
Any more problems left with XG/DMU?</blockquote>
I'll run through some of the PWADs I've got that make use of XG, and look for any issues.
<blockquote>I have still been experiencing save game errors while testing a specific map,</blockquote>
Thanks for the report Melfice. I'll see if I can reproduce the problem(s).
<blockquote>I am wondering about hall-of-mirrors on missing bottom (and top) wall segments, though. </blockquote> Revision 3202 has a fix for these. Now the undefined wall segments are rendered as before, using the ceiling/floor texture.
<blockquote>It wasn't broken as such but I removed this behaviour as it was causing problems with common DOOM.EXE renderer tricks employed in PWADs. This behaviour was also causing seg violations with some PWADs, such as bludwrks.wad</blockquote> I see. However, I think that we should by default keep the behaviour I reintroduced, and do something else in the cases where a hack requires it. For example, using some special flag to prevent the wall segment from being rendered? We cannot have HOMs in the official Doom, Heretic and Hexen maps, though.
<blockquote>I see. However, I think that we should by default keep the behaviour I reintroduced, and do something else in the cases where a hack requires it. For example, using some special flag to prevent the wall segment from being rendered?</blockquote>
Thats what I was thinking yes.
Most of the logic to detect the hacks is already implemented (see R_RationalizeSectors in r_world.c) but to make use of the new information requires a reshuffle with how we handle linked sectors. With beta4's release looming; I decided not to start messing with this yet.
<blockquote>We cannot have HOMs in the official Doom, Heretic and Hexen maps, though.</blockquote>
Of course. Anything I implement won't prevent those HOMs from being fixed.
<i>This comment was posted by dengDevs user <b>PiCKleBro</b>.</i>
Feature Request: I've commented about this (albeit a really long time ago) on the bugreport and I think I put it as a feature-request on another page somewhere once...but here are my thoughts on the feature:
-Sound Generator
Would function in much the same way sounds function now except this would allow sounds to be placed anywhere and be bound to more than just objects.
-Should allow sounds to be linked to objects, textures, and x/y/z coords.
-Should Attenuate sound based on distance (something like radius=xx, but with a true attenuation instead of being at full volume when you enter the radius)
-should have a volume setting
-should allow channel (left/right) settings
***Discussion***
Currently the only way to create a sound generator now without attaching the sounds to an object is to create a particle generator and set the opacity of the particles to 0. This is a very crude way of doing it and still doesn't allow for
Comments
Fixed in SVN 3193.
When the menu is active none of; InFine, chat widget, cheat responders should get a chance to process the input event.
However, before we redo the whole thing, wouldn't a "P_IsDummy" test in R_UpdateSector suffice?
<blockquote>any attempt to get the sector of a plane will cause seg vio</blockquote> Are dummy sectors used anywhere at the moment?
e.g. Press the space bar on a blank wall just after pressing the fire button while using the bfg. it is supposed to silence the bfg
Doomsday defines the DED file format as ISO 8859-1 (Latin 1), and the syntax is that all quotes must be the ASCII character 34 (like in most programming languages).
However, the bug here is that Doomsday should detect and report this, not crash outright.
Yes I agree. I just moved all the update checking out of the routines that checked each tic for changes, into one function as a temporary measure.
<blockquote>However, before we redo the whole thing, wouldn't a "P_IsDummy" test in R_UpdateSector suffice?</blockquote>
In that particular instance, yes.
<blockquote>Are dummy sectors used anywhere at the moment?</blockquote>
Yes in XG for various stuff.
Also, properties of the dummys arn't being initialized anywhere currently (other than the DMT type header).
<blockquote>I don't think the silent bfg trick works anymore in doomsday..
e.g. Press the space bar on a blank wall just after pressing the fire button while using the bfg. it is supposed to silence the bfg</blockquote>
That particular trick hasn't worked in jDoom for quite a while. I know why and I know what needs to be done to emulate this behaviour. I'll add a compatibility option for it once implemented.
Sounds OK to me.
<blockquote>In a dummy sector's case, could the planes be initialized so that they point to the right sector, i.e. the dummy sector?</blockquote>
Well, technically they shouldn't given that planes are now a seperate object (as far as users of DMU are concerned).
If we are going to allow an arbitary number of planes per sector then the game should make the decision if and how many planes a dummy sector is intialized with.
Perhaps the best scenario is if there is a helper function game-side that instigates the call to alloc the dummy sector while at the same time, alloc and link the dummy planes?
Actually I've just checked and dummy sectors arn't used at all in XG. Sorry about the misinformation.
We should still safeguard them though.
I'm getting a "P_Callbackp: Type (invalid) unknown." error with xgtest.wad when I activate the up switch in the elevator.
Also some of the switches don't seem to work correctly. I can't get through the split door without noclip for instance.
I've fixed most of the bugs in XG but the remaining ones are proving quite tricky to track down with my limited selection of debugging tools.
Problems I noticed:
<ul>
<li>Floor textures don't scroll (I recall that they should?).
<li>Stair builder doesn't do anything.
<li>After life bank withdraw, player has something like -10000 health...
<li>The door to the elevator does not open.
</ul>
I'll start digging...
<ul>
<li>The floor in the entry room should scroll toward the door to the elevator.</li>
<li>The back wall behind the floor that drops when the zombie is killed should scroll toward the lower left corner.</li>
<li>The little room beyond the stair builder room; each quadrant of the floor's texture should scroll toward the center of the room</li>
</ul>
Note, they work on my system so it does sound like endianness problems.
I am wondering about hall-of-mirrors on missing bottom (and top) wall segments, though. Originally, the renderer replaced those automatically with the floor (or ceiling) texture. I made this the default behaviour because in Hexen map01 there is a missing top texture in the key room (after the sideways-moving brass doors), behind the glass on the far side of the room. Apparently this behaviour has been broken at some stage? In any case, we should not be getting HOM anywhere, so I recommend we fix the renderer to work like before.
Any more problems left with XG/DMU?
I have still been experiencing save game errors while testing a specific map, although in another map I haven't had any problems. Refer to the link below for a .txt log of errors I've had while testing and developing my maps I stared today.
http://www.retetched.com/optix/theexiled/dengerrorlog.txt
If you'd like to see for yourself if you can reproduce errors, below is a link to MAP12.rar which includes the wad file for the map and the BIAS lighting .ded for it. If you need the resouces and pk3, DaniJ has them.
http://www.retetched.com/optix/theexiled/MAP12.rar
It wasn't broken as such but I removed this behaviour as it was causing problems with common DOOM.EXE renderer tricks employed in PWADs. This behaviour was also causing seg violations with some PWADs, such as bludwrks.wad
I removed it with the plan that I would implement a better system to detect and fix these before 1.9.0 final.
<blockquote>I've now managed to fix all of the problems I listed above.
Any more problems left with XG/DMU?</blockquote>
I'll run through some of the PWADs I've got that make use of XG, and look for any issues.
<blockquote>I have still been experiencing save game errors while testing a specific map,</blockquote>
Thanks for the report Melfice. I'll see if I can reproduce the problem(s).
Thats what I was thinking yes.
Most of the logic to detect the hacks is already implemented (see R_RationalizeSectors in r_world.c) but to make use of the new information requires a reshuffle with how we handle linked sectors. With beta4's release looming; I decided not to start messing with this yet.
<blockquote>We cannot have HOMs in the official Doom, Heretic and Hexen maps, though.</blockquote>
Of course. Anything I implement won't prevent those HOMs from being fixed.
Feature Request: I've commented about this (albeit a really long time ago) on the bugreport and I think I put it as a feature-request on another page somewhere once...but here are my thoughts on the feature:
-Sound Generator
Would function in much the same way sounds function now except this would allow sounds to be placed anywhere and be bound to more than just objects.
-Should allow sounds to be linked to objects, textures, and x/y/z coords.
-Should Attenuate sound based on distance (something like radius=xx, but with a true attenuation instead of being at full volume when you enter the radius)
-should have a volume setting
-should allow channel (left/right) settings
***Discussion***
Currently the only way to create a sound generator now without attaching the sounds to an object is to create a particle generator and set the opacity of the particles to 0. This is a very crude way of doing it and still doesn't allow for