1.9.8 Candidate Testing
It is time to start the Candidate phase for 1.9.8. This is the second time we're doing a candidate phase, so I'm hoping we can get through it quicker than on the first try. We have only a couple of months' worth of commits to finalize -- however, there is a large number of fundamental changes to the very core of the engine.
The first candidate build is available: http://dengine.net/build472
We are updating a to-do list of our tasks here: http://skyjake.fi/dl/public_todo_for_stable_1.9.8.txt
If you wish to participate in testing the candidates and helping us improve the upcoming stable release, please check the todo list and see if you can find something that is obviously broken when compared to our previous releases (particularly the previous stable version). You should post your findings here in this thread. Please do not resubmit bugs that already are in the SourceForge bug tracker; we'll get to those in time.
When reporting bugs/crashes, please include information about which OS you're using, resource packs loaded, and game & map that you were playing. It's also very helpful if you include your Doomsday.out log and run with the -v option for verbose log messages.
The first candidate build is available: http://dengine.net/build472
We are updating a to-do list of our tasks here: http://skyjake.fi/dl/public_todo_for_stable_1.9.8.txt
If you wish to participate in testing the candidates and helping us improve the upcoming stable release, please check the todo list and see if you can find something that is obviously broken when compared to our previous releases (particularly the previous stable version). You should post your findings here in this thread. Please do not resubmit bugs that already are in the SourceForge bug tracker; we'll get to those in time.
When reporting bugs/crashes, please include information about which OS you're using, resource packs loaded, and game & map that you were playing. It's also very helpful if you include your Doomsday.out log and run with the -v option for verbose log messages.
Comments
The massive quantity of flying bad guys (i.e Gargoyles) and their behaviour, in Heretic, makes the presence of such a bug bigger.
Also, the switch sound origin bug; you don't always have the time to look at a switch to see if you've hit it (i.e. to look for the change in graphic; i.e. the light on the switch changing). There are occasions where you rely on the sound to know you've hit it (such as when you are dodging bad guys).
One such point is when the player goes down the stairs behind the window in the Windowing Hall, a second point is at the start of the Seven Portals.
The Windowing Hall crash appears related to attempting to look at the wall that opens to reveal a switch as you reach the bottom of the stairs.
The Seven Portals crash appears to be related to Dday trying to render something just below and behind the Korax wall at the start of the map (i.e. something initially out of view that moving just a few steps forward brings into view).
Is there a bug report for that? I am having no luck finding one.
This is a known issue (first item on the list, in fact). It is due to recent changes in the BSP builder which haven't yet been fully accounted for in the renderer.
Indeed, maybe I forgot to post a report;
In Vanilla, the switch code specifies that a switch sound should play in the middle of the sector the switch is attached to.
However, a bug in the code changed this behaviour. This bug made it so that switch sounds were played at the location player is, when the switch is pressed (i.e to make it clear that the switch sounds didn't follow the player around if he moves during the sound playing).
Dday 1.9.7 fixed this 'bug' when the code was rewritten and restored the 'correct', but 'incorrect' behaviour, if you get what I mean.
Also, another bug;
Once upon a time, I thought this related to the bug where Dday gaining mouse focus during engine start up stopped the keyboard from working. However when that bug was fixed, this issue remained, so I guess it was actually a different bug: the console key (other keyboard controls all seem fine) seems to randomly stop functioning when I alt tab or move between maps; I haven't yet been able to narrow it down or find any reproducible way of making it happen, but it happens pretty often. Indeed, once, I actually got the console key to start functioning again, after it had stopped functioning through alt tabbing.
Pressing the Alt key several times in quick succession, at any time in game (at least in a map), appears to both render the console key infunctional and also makes it work again, if the console key has become infunctional.
I guess I was barking up the wrong tree with busy mode being a potential cause and may have also been in-avertedly triggering the issue with alt tabbing.
In Vanilla Heretic, the foot clipping only stops once the middle of the player moves off the higher sector, at which point they also begin falling into the lower sector, so it is barely noticeable if at all.
But in Dday 1.9.x, the foot clipping in such a case stops good distance before the edge of the higher sector.
As an aside, in Dday 1.9.x, the floor fire attack of Maulotaurs is sometimes spawning, when it shouldn’t, if the Maulotaur is on the higher edge of two foot clipping sectors. I wonder if it's related to the above.
Lots of text to explain something that is quite easy to notice in game.
The start of E3M3 is a good place to see the footclipping anomaly effect the player and E2M8 is a good place to see the Maulotaur floor fire.
bundleapp.sh is a Mac-only script that is run after compilation. It copies the executables into the appropriate places. In other words, it's only relevant for developers.
Please see the attached image:
If the player noclips into the void to view the estranged linedefs marked in red, Dday will crash, presumably because Dday’s new BSP can’t deal with them (i.e like Dday’s new BSP had issues with Map01 a couple of builds ago).
The player will never see these particular lines in normal play, but somewhere out there in the world of pwads, there may be a similar construct the player can see in normal play.
I did see some pauses myself when I was testing the latest code in OS X 10.4 today.
With the option on in Doom, if a flying bad guy has not yet been shot, it will instantly jump to the tops of objects it runs into, rather than rising up them. If a flying bad guy has been shot, it will correctly rise up the object.
In Heretic, the option appears to work perfectly.
If you turn the option off in either game while a flying bad guy is in direct contact with the top of a object it's raised over, the bad guy will become stuck and immobile.
All the above is based off stationary scenery objects; I haven't tested it with regards to whether flying bad guys correctly rise/lower over/under moving objects (i.e. other bad guys).
Attached is the wad I used to test the option in Doom with. It's Map01. Fire a shot anywhere, except at the Cacodemon, to alert it and watch it interact with the pillars.
EDIT; Why can't we attach wads to posts (though wads in zips are fine)? Given the games we are talking about, it seems a bit strange.
Now you can (file size limit is 256kB, same as every other file type). Please note however, that there is only a relatively small amount of disk space (50MB) set aside for attachments on this forum. If your file is something that is only going to be relevant for very short time period, please choose a more suitable way of publishing it (there are countless ways to share files of all types these days; dropbox, pastebin, imgz, etc...).
Just two things. Was the key to the console changed? I tried pressing ~ to get it open a couple times, but I couldn't get it open. Was there something that I'm missing?
Also wanted to bring up the Tag 667 issue I brought up a while back. Should that be more of a bug or a feature request?
in HeXen, this causes a problem, as unlike Doom and Heretic, your stats aren't reset by the level warp cheats; you end up a 'zombie player' sans the ability to pick up items (a common term for a Doom engine bug involving Voodoo dolls).
Given that there is no skippable 'after' map Infine defs in the original games except for HeXen, which has no intermissions, this will only potentially come up with mods specifically made for DDay.
While I'm here; long standing Infine issue; screenwipes for 'before' map infine display nothing, instead of melting from whatever was displayed on the screen prior to the screenwipe.
This one can be seen with the mid game text screens in Doom2/Final Doom and HacX as they are 'before' map Infine.
'Before' and 'after' are Infine script fields that refer to what point between two maps that an Infine def (i.e. text screens), will play.
The terms originally referred to 'before' and 'after' a map. However, as of 1.9.x they both play after the intermission, with 'after' marked defs coming before, 'before' marked defs.
This was a change made to allow Dday to better imitate Vanilla. However in some ways, it made the terms a little misleading. IMO, it would have been better to add a third field type; 'after intermission', or something, rather than alter the long standing 'after' type; I know of a couple of Dday 1.8.x mods that expect the old behaviour.
The level warp cheats in both Vanilla and Dday* skip all text screens/Infine that would happen between the previous map and the one you are warping to.
*there was a bug at some point in earlier Dday 1.9.x versions, that caused the level warp cheat in Dday not to skip 'before' Infine.
After toggling antialiasing you can simply press escape to leave the control panel and the display returns to normal.