Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Build 2889: weapon slot keybinding messed up

@skyjake

I checked the recent build 2889. The gains in game speed due to the latest committed fixes are freakin' awesome. Now I get three times the FPS compared to older builds. Wow! Here's hope that more complex maps will finally be playable in Doomsday, but I haven't tried that yet due to the following bug:

The keybinding system for the weapon slots is broken. Instead of selecting a particular weapon bound to a certain key, all available weapons are cycled through when repeatedly pressing the same weapon slot key. Doom, Heretic and Hexen are affected likewise.

Comments

  • The same problem with keybinding is also present in build 2887
  • deus-ex wrote: »
    @skyjake

    I checked the recent build 2889. The gains in game speed due to the latest committed fixes are freakin' awesome. Now I get three times the FPS compared to older builds. Wow! Here's hope that more complex maps will finally be playable in Doomsday,

    Just out of curiosity. What framerate do you have in the beginning of map e4m2 on UV difficulty (without addons)? In my case it is below 45, most of the time about 30fps.
  • edited Nov 30, 22:06
    E4M2 UV: Starting with ~47 fps, going up to ~72 fps depending on the player location and viewing direction.

    Now I've also tested several complex addon maps which previously either were unplayable or wouldn't load at all, for example the most excellent Breach.

    Overall the FPS situation has improved quite a lot with Doomsday, although in complex addon maps the frame rate often is at the lower twenty-ish level and below, which makes gameplay rather sluggish. Also Boom script support is still laking, which currently counteracts the idea of playing those addon maps in Doomsday anyway. Nevertheless there have been made quite good steps forward in the right direction with the recent Doomsday builds.
  • I guess that fps will improve again significantly in the new renderer since most of the work will be on GPU instead of CPU.
  • edited Dec 1, 14:50
    I will check out the key binding issue.

    When it comes to the recent renderer speedups, I've been addressing some of the bottlenecks, but not all. The renderer still has a problem with particularly large and/or complex maps, for example, and this hasn't changed.

    Some of these issues are pretty fundamentally tied to how the renderer is designed, so I doubt they will ever get fixed. Instead, I'm going to focus on the new fully GPU-based renderer, which will avoid these issues (but of course require a bit more beefy GPU).
  • edited Dec 2, 05:41
    Weapon switching fixed in today's build.
  • Confirmed, thanks. You might want to use it as a feature for the Nightmare difficulty setting. :D

    Btw, after updating my Doomsday installation from build 2890 to 2891 I was greeted with this mess:7oc9q1zh9i9r.png
    I created the addon load list from scratch just two days ago using build 2889, no changes were made to the addons since.
  • If you right-click on "jDoom_Skies_(deus-ex_edition).pk3" on the right, what version number does it say you have? (Since it wanted 0.2018.1111.100.)
  • edited Dec 2, 10:25
    That version number is different, but I don't know why. Like I wrote, no changes were made since I recreated the entire addon load list two days ago.

    9zixaa90rdet.png

    EDIT: I guess I should add the "info" file to every addon, like you recommend in another discussion. Apparently that prevented the jDRP and Plasma_Shot addons and the DHMP models from becoming ~dirty~ in the addon list.
  • Interesting, the version number implies that Doomsday thinks the file was modified recently (December 2nd). Does Windows agree, if you check the PK3's last modified time in Explorer?
  • edited Dec 2, 10:33
    Oh dang! Yes, that's what happened, I accidentally updated the file modification date of all addons, when I meant to update just the folder name itself. First time I made this mistake, but it wasn't in vain because now I'm confident the addon parsing works as intended. I'm going to add the "info" file to all my addons now as it clearly helps to avoid confusion.
  • edited Dec 2, 10:38
    Yep, Info files will help here.

    You could alternatively try adding a version number to the PK3 file names, if that's easier. For instance this should be recognized as version 1.2:

    jDoom_Skies_(deus-ex_edition)_1.2.pk3
  • edited Dec 2, 10:46
    Yay! Just out of curiosity I restored the original file dates of my addons to see what happens. It fixed Doomsday's addon list. That's what backup copies are good for. :)
  • skyjake wrote: »
    You could alternatively try adding a version number to the PK3 file names, if that's easier.
    Yes, I'm already doing that, as you can see in my first screenshot above. I've now updated all addons to reflect a version number in the filename and added a info file to each of them. So the addon load list should be rather rock solid from now on (fingers crossed).

  • edited Dec 2, 14:44
    I'm pleased that Dday boots up much quicker these days (the last stable release took a very long time to start).

    Though Dday has long often crashed while starting up for me, with errors about failing to load console font 18 and not finding paths matching fx.blur.horizontal.

    I also usually fails to find the game deds (i.e doom2.ded) after the first time I launch a profile.
  • That sounds quite odd. Are you sure your installation of Doomsday is “clean”, that is, there are no files from different versions in the same directory structure or perhaps on any search path or environment variable?
  • deus-ex wrote: »
    [...] I accidentally updated the file modification date of all addons [...]


    It seems to me that it is not a good idea to identify files based on the modification date. That may change when an user just moves files from one location to another. I think that it will be much better to identify files based on filename+filesize, or filesize+crc32(file).

  • filename+filesize fails to detect changes that don't affect the size of the file, and filesize+crc32 is relatively slow to generate (as one needs to read the complete file to calculate the checksum). Imagine reading hundreds of megabytes of data when indexing a large collection of add-ons...

    This is why the modification time is used as the fallback in case no other version is specified: it's quick and should always detect any change to the file (even when it's just a Unix "touch"). An operating system should not change the last modified time when just moving files around.

    Considering a better way to handle things, there should probably be an option to say that "any version" of the package is accepted, but that should only be allowed in the game profile. Compatibility must still be preserved for save games and multiplayer.
  • edited Dec 2, 18:07
    skyjake wrote: »
    That sounds quite odd. Are you sure your installation of Doomsday is “clean”, that is, there are no files from different versions in the same directory structure or perhaps on any search path or environment variable?

    I have yet to work out a possible pattern to the start up errors.

    But I have noticed that it fails to find the game deds only once I quit and restart Dday (i.e I can launch the same game profile multiple times without issue as long as I don't quit and relaunch Dday).
Sign In or Register to comment.