Week 25/2013: Added DE menu, candidates begin

edited 2013 Jul 15 in Developers
Last week we started the Candidate phase for 1.11. I also continued with the new UI by adding a popup menu widget.

As we are now in Candidate phase, we won't be adding any more new major features for 1.11. Naturally work is ongoing to polish what has been added so far, plus we will again start looking at good old bug fixing.

During the week I made one last addition to the new task bar UI: clicking the DE logo will now open a popup menu instead of going straight to the Control Panel. This is the humble beginnings of our new vision for the Doomsday UI, where all the features are directly accessible as an overlay type of UI via the task bar instead of discrete, fullscreen views.

demenu.jpg

In the next release (1.12), I will be starting the work of recreating the Control Panel's settings in a more accessible/friendly way using new widgets, so that we can ultimately kill the old Panel entirely. The autoupdater UI will also be revised in 1.12 to use Doomsday's own widgets instead of native dialogs.

While Shift-Esc remains the hardcoded key for accessing the task bar, many of us would undoubtedly also use a key of our own choosing to access it and the console. Instead of the old console activation key mechanism that entirely bypassed the bindings system, there is now a way to get the same comfortable behavior using bindings: I've added a default binding for the Tilde key that toggles the task bar & console open/closed. You can get the binding with the "defaultbindings" command or by entering these into the console (a game has to be loaded as bindings are game-specific):
bindevent global:key-tilde-down+key-shift-up taskbar
bindevent console:key-tilde-down+key-shift-up taskbar
The plan is now to start focusing more on bug/regression fixing so that we can get the stable 1.11 into releasable state in July. (Which means now is the time to start pestering us with any bugs or other annoyances you absolutely want fixed soon. :) )
«1

Comments

  • May I ask about the prospect of a build number being added to the taskbar? Maybe, under the version number?

    I usually run Dday full screen and use to open the old console to check build or version number, rather than switching to windowed mode and reading the window title; force of habit from back when Dday didn't support toggling between windowed and full screen in engine.

    I think such would be good for technical support; placing the build number somewhere easily accessible for any user to see (i.e in plain sight on the taskbar).

    May I also suggest a slight change to the visuals of the DE button on the taskbar to make it more apparent it's a button; I know it lights up when you put the mouse over it, but the border indicating it's a button is somewhat obscured when the taskbar against certain backdrops (such as your Ultimate Doom title pic image above).

    One little thing I've noticed though, is that the new taskbar seems to be duplicating some messages? For instance, when Dday loops the currently playing music, it prints the same lump cache message three times in a row.

    Nitpicks aside, the taskbar is of course impressive; it’s stylish and functional.
  • Vermil wrote:
    May I ask about the prospect of a build number being added to the taskbar? Maybe, under the version number?
    Good suggestion, at least the unstable builds should show the build number prominently.
    May I also suggest a slight change to the visuals of the DE button on the taskbar to make it more apparent it's a button; ... obscured when the taskbar against certain backdrops
    We will continue making tweaks to the appearance over time. This sort of issues will be addressed as part of the overall visual theme development.
    One little thing I've noticed though, is that the new taskbar seems to be duplicating some messages? For instance, when Dday loops the currently playing music, it prints the same lump cache message three times in a row.
    This is partially because the new log widget shows all log output, including debug-level messages, if the user requests enough verbosity. Another reason for this particular message duplication is some inherent redundancies in the old file system ("FS1") implementation. Caching, for instance, is implemented in various places and each of them prints a separate message when the system is looking for a particular resource. The future holds many changes regarding this as we continue to migrate towards libdeng2 and its new unified caching mechanisms (the Banks I've mentioned in earlier posts).
  • Apologies for more nitpicking;

    I notice that clicking on the game mode name on the taskbar, is interpreted as an un-highlight command. It will un-highlight the console if you've got it open etc. But clicking on it while nothing in the taskbar is highlighted both closes the taskbar and also performs any game world event bound to the mouse button; given that clicking on any other part of the taskbar, history etc doesn't seem to close the taskbar, this seems like a little bug?

    I also notice that the esc key doesn't work when the test menu is open; I was kind of expecting it to close it, as you can close the console and such with esc.

    Also a big bug; closing the taskbar while the test menu is open doesn't close the taskbar properly and proceeds to breaks keyboard controls completely (i.e the keyboard becomes completely unresponsive) except for Windows shortcuts (i.e Alt+F4 to close).
  • A non-taskbar bug: the Phage bad guy in HacX is broken in Dday 1.11; if it enters it's melee attack states, it just starts looping them endlessly, instead of performing it's Lost Soul derived attack.

    EDIT: Further testing seems to indicate it's only broken if the player loads HacX from within Dday; if one starts Dday with HacX as the loaded game, the bug doesn't occur.

    EDIT2: Seveeral bugs with bad guys and weapons in HacX when loading it from within Dday.
  • My 1.11 wishlist:

    -The IDBEHOLD cheat is still a little broken in Doomsday. In Vanilla Doom, you could use the IDBEHOLD cheat to remove a powerup that you may have acquired in-game or by cheating. For example, if you picked up a Radiation Suit or used the IDBEHOLDR cheat to acquire a Radiation Suit, you could then type in IDBEHOLDR to remove that Radiation Suit. This is currently not functional in Doomsday.

    This is Bug #983 (where I submitted two bugs in one). DaniJ already fixed the first problem listed in this report, but I'd like to see the second part resolved too.

    http://sourceforge.net/p/deng/bugs/983/

    -Also, the problem of the player arrow on the automap not showing up on PCs with Intel HD video cards (bug #1060 IIRC, also a standing problem on my laptop).

    -This is probably unlikely for 1.11, given that we are close to a stable release, but is there any word on when FluidSynth will be implemented into Windows versions of Doomsday? This is so that I can use .sf2 soundfonts in Doomsday without needing to use external measures.

    -And since the issue popped into my mind, restoring the map title to the automap.

    Fun fact: I cleaned out my email inbox a bit and created a folder for all Doomsday-related issues, so any email that comes from SourceForge that relates to Bugs (ones I have submitted or have commented on) will get sent to that email folder. I'm still waiting to see if it will actually work, lol.
  • Vermil wrote:
    One little thing I've noticed though, is that the new taskbar seems to be duplicating some messages? For instance, when Dday loops the currently playing music, it prints the same lump cache message three times in a row.
    Actually it would seem this happens due to a threading issue in the log message management. I've seen this happen with messages produced by libdeng2 itself, so its clearly not the FS1 file system or old resource caching mechanisms at fault here.

    The reason this particular message is produced multiple times is because the lump that contains the music is removed from the cache once loaded. And so next time it is read it is therefore cached again. As the title animation repeats in a loop and the title music is so short this makes it more desirable to keep this data cached. This is however a special case as looping is otherwise implemented at music driver level. It is the title animation that repeatedly stops and then re-starts the current track for mod compatibility reasons. Once in-game there is typically no need to cache the music data as it doesn't change during the map (cache management is presently ignorant that music can be changed mid-map by mods).
  • Vermil wrote:
    I notice that clicking on the game mode name on the taskbar, is interpreted as an un-highlight command. It will un-highlight the console if you've got it open etc. But clicking on it while nothing in the taskbar is highlighted both closes the taskbar and also performs any game world event bound to the mouse button; given that clicking on any other part of the taskbar, history etc doesn't seem to close the taskbar, this seems like a little bug?
    The game mode name is currently not an interactive element in the task bar. The plan is to make it a button at some point. For now it will not handle events and thus whatever is underneath (game view) will handle them instead.
    I also notice that the esc key doesn't work when the test menu is open; I was kind of expecting it to close it, as you can close the console and such with esc.
    Ah yes, Esc should indeed close it. Fixed.
    Also a big bug; closing the taskbar while the test menu is open doesn't close the taskbar properly and proceeds to breaks keyboard controls completely (i.e the keyboard becomes completely unresponsive) except for Windows shortcuts (i.e Alt+F4 to close).
    Fixed.
  • skyjake wrote:
    Vermil wrote:
    I notice that clicking on the game mode name on the taskbar, is interpreted as an un-highlight command. It will un-highlight the console if you've got it open etc. But clicking on it while nothing in the taskbar is highlighted both closes the taskbar and also performs any game world event bound to the mouse button; given that clicking on any other part of the taskbar, history etc doesn't seem to close the taskbar, this seems like a little bug?
    The game mode name is currently not an interactive element in the task bar. The plan is to make it a button at some point. For now it will not handle events and thus whatever is underneath (game view) will handle them instead.
    I have to admit that I was expecting it to become a button at some point; though that 'empty' areas of the taskbar currently click through to the game world is a little strange in my opinion; it's not like if I click on a non-interactive (i.e 'empty') part of, say the Windows start menu (perhaps not the best example), that the click goes through to whatever desktop icon, window etc is or may be open behind it.

    Even within Dday, I can click anywhere on the history window, when, at least as far as I can tell, only clicking on the edges actually does something (being able to stretch the history window is impressive, though I note there's currently no option to stretch it diagonally by clicking the corner; I point that out because I'm not sure whether it's a bug or just something Deng team don't believe nesscerry) and the click isn't interpreted as clicking on the game world.
  • Also, the problem of the player arrow on the automap not showing up on PCs with Intel HD video cards (bug #1060 IIRC, also a standing problem on my laptop).
    Can you confirm that this issue is isolated to the automap player arrow? That is, all other line drawing works: crosshairs, automap lines, ... I would like to add a workaround for this but currently I have no idea what could be causing the issue, and I can't replicate it on any of my dev systems (including a MacBook Air with Intel HD graphics).
    This is probably unlikely for 1.11, given that we are close to a stable release, but is there any word on when FluidSynth will be implemented into Windows versions of Doomsday? This is so that I can use .sf2 soundfonts in Doomsday without needing to use external measures.
    Yeah this will not make it to 1.11. Personally I would like to see FluidSynth working on Windows, too, but I lack motivation for setting up glib for the Windows build...
  • skyjake wrote:
    Can you confirm that this issue is isolated to the automap player arrow? That is, all other line drawing works: crosshairs, automap lines, ... I would like to add a workaround for this but currently I have no idea what could be causing the issue, and I can't replicate it on any of my dev systems (including a MacBook Air with Intel HD graphics).
    Yeah, the issue is limited to the player arrow. The crosshair shows up fine, and the automap lines show up (that is, in earlier builds when the automap was not broken).

    Also, what is the driver version for the video card on the MacBook? Mine is 9.17.10.3062, dated 3/8/2013. However, when I tried out an older version of the driver a while back the automap player arrow showed up fine, but I started getting the problem again upon using newer drivers. So if you are using an older driver, try updating if you can and see if the problem appears for you.

    This does seem to be an occurrence on Intel HD video cards, as another person who had this problem (seen in the topic link below) was using an Intel HD 4000. I also got this problem on my mom's laptop, which was using an Intel HD 2000 (and my laptop is an Intel HD 3000).

    http://www.dengine.net/forums/viewtopic.php?f=7&t=1328
  • edited 2013 Jul 6
    The stbar hud opacity option notably misses the black bars that appear over the mana bars as you use mana and the forth weapon panel in HeXen. Comparing to Heretic, I imagine the ammo icons and life chain are not supposed to be transparent, hence I am assuming they are suppose to remain.

    Also, Dday has options for stretching the splash screens, hud weapons and menu's, but not the stbar hud?
  • "Bug 1: the Doom Guy mobjs passmobj flag over-rules the zclip cvar, meaning setting it to 0 has no effect on him. The passmobj flag was added to the doom guy mobj in dday, when the doom plugin got heretic's mobj flags added to it previously, Doom Guy did not have this flag.

    Bug 2: if Doom Guy falls on a scenery mobj (possible if Zclip is set to 1 or he has the passmobj flag), he falls through it, instead of landing on top of it. He then becomes stuck and unable to move. If Doom Guy lands on a monster, he doesn’t fall through them.

    Heretic seems not to have this bug.

    Bug 3: The Dday exclusive 3d movement option (under gameplay menu), which allows flying bad guys to both fly over other mobjs ala Vanilla Heretic and also raise over other mobjs (not something flyers could do in vanilla Heretic) doesn't work right in Doom. In heretic, it appears to work fine

    Unrelated note; the various Zclip options are a bit of a mess in Doom:

    In Doom, I'd expect setting Zclip to 1, to also affect monsters, but it only affects the player. I have to turn on 3d movement to get Zclip 1 like behaviour for monsters, which also means I have to accept flying monsters also raising over each other.

    It would be cool if Zclip 0/1 imitated Vanilla Doom and Vanilla Heretic respectively. The 3D movement feature would then simply allow flying bad guys to raise over each other (call it Zclip 2 if you will)."
  • Something in the latest build (I noticed a mention of the texture atlas being near full before one of the crashes) reguarly causes a seg fault in the latest build (916). Seemingly at random, but so often, as to unfortunetly render the build to all intents, unplayable.

    I've had it while running around, warping to maps etc.

    Also, the FPS counter doesn't seem to work.

    Apologies for all the bug reports.
  • Vermil wrote:
    Something in the latest build (I noticed a mention of the texture atlas being near full before one of the crashes) reguarly causes a seg fault in the latest build (916). Seemingly at random, but so often, as to unfortunetly render the build to all intents, unplayable.
    Please try 917, it should be fixed.
    Vermil wrote:
    Also, the FPS counter doesn't seem to work.
    The old counter was removed along with the rest of the old console. I will add an FPS counter to the taskbar soon.
    Apologies for all the bug reports.
    Please do keep 'em coming. :)

    You should submit the zclip bugs into the tracker, I doubt we are able to address them yet in this release.
  • Indeed, the seg faulting appears to be fixed in 917 :)
  • May I suggest adding the words "menu" to the doomsday button in the bottom right corner.
    As it is now, it's not obvious that it's a menu button.
    Or maybe you could place it in the bottom left hand corner?

    May I also suggest removing the "check for updates" text in the menu for ubuntu,
  • I'm inclined to say no to an explicit "menu" label. Later there will be a brief first-launch "tutorial" for introducing the major elements of the UI, though.

    I would argue that the "Check for updates" is only relevant for Ubuntu as it's the only Linux we're providing binaries for. It's true that it's redundant if the user has configured their apt accordingly...
  • Attempting to warp to HeXen DK Map05 (Badlands) crashes with an illegal op in the latest build (haven't tested to see if it crashed in earlier builds).

    EDIT: Ok, it seems to be somewhat more narrow than I thought; using the visit cheat to warp from Map01 to Map02 and then using the cheat again to warp to Map05 causes a crash every time.

    But using the portal to travel from Map01 to Map02 and then using the visit cheat to warp to Map05 doesn't lead to a crash.
  • My initial thought is that this may be the result of suspect ACS-scripted logic. Although the game allows one to warp between any map at any time the scripts for the original game(s) often don't take this into account. The global script state may be incorrect if the map is assuming it is only accessible when following the normal in-game path.
  • So I saw the change that the map title was reinstated into the automap.

    Since the next build won't come until Monday, is the automap title the CWILV graphic that you see on the intermission screen (and on the beginning of the level in Doomsday)? Or is it in the small Doom font as seen in Vanilla?

    Thanks.
  • The in-automap map title display has been implemented by reusing the map title display at the start of the map, so it will look exactly the same as that except that the author display is replaced with the map URI (e.g., "MAP01").
  • I understand the rationale behind the change of using the CWILV graphic in the automap and it is a good idea, but will Dehacked patches take preference over the CWILV graphic, if a mod uses one?

    Since the way it worked in Vanilla, is that the CWILV graphic replaced the map title and the Dehacked patch replaced the automap title. Countless Vanilla mods came with CWILV graphics for replacing the map title and a comparatively tiny fraction came with Dehacked patches for replacing the automap title.

    So, now if a mod comes with a CWILV graphic, but not a Dehacked patch, the CWILV will also be used on the automap. But what if there is both a CWILV graphic and a Dehacked patch present, or only a Dehacked patch?
  • If the CWILV patch has been replaced by a mod then this will have precedence. The next highest priority is the textual map title from either the MapInfo definition or a DeHackEd string replacement. The final choice in DOOM is between a PatchReplacement string (should one be defined) or the original CWILV patch.
  • In my opinion, the automap title should go; Map Info/Patch Replacement (ideally Map Info should feature an optional separate field for automap name to map title), Dehacked, CWILV. With the Map Info/Patch Replacement taking precedence; the CWILV lump should only be used if the Dehacked patch doesn't exist, in order to retain Vanilla compat.

    While either DDay ded option should take priority over Dehacked or CWILV, as deds written for Vanilla mods, will always have been written after the mod was made. While the map title should go; Map Info/Patch Replacement, CWILV.

    That Dday gives precedence to the CWILV graphic over Map Info/Patch Replacement got in the way of my past attempts to make DDay visual enhancement patches for Hell to Pay and Perdition's Gate; those mods replace the CWILV graphics with story text graphics, which look silly being used as map titles (and now automap titles), in Dday (not to mention the Map titles end up displaying the story text graphic meant for the following map).

    I planned to use patch replacement to stop the story screens appearing as map titles and re-create the story text as Infine.

    Of course, another possibility is that patch replacement in Dday might not actually be working and need fixing?
  • Tested out the new build with the fixed automap and restored map title, looks great.

    Found a little problem with the map title though. In a MOD like AV, the CWILV graphic is actually a little bigger, due to the name of the map author being displayed right under the level name.

    JNV7gKN.jpg?1

    Would it be possible to say, have it programmed so the map number appears right below the CWILV graphic, or would that cause other problems?
  • Another thing is the textures and interface of these custom wads needs upgrading. In 2013, low res has no place :P
  • The return of the automap and map title on the automap is cool.

    Though, I have to admit that I personally really would prefer the map title on the automap to appear down the bottom of the screen, as in Vanilla (bottom left in Doom, bottom middle in Heretic and HeXen).

    Also, Hell to Pay and Perditions Gate CWILV graphics; the makers of those mods applied a huge offset to the CWILV graphics to make them appear in the middle of the intermission screen; doesn't work so well with Dday's new features:

    hg4.png

    For what it's worth, I also recall a recently made wad (a tune up of 1994 levels I believe), that replaces the CWILV graphic with a near full screen image.
  • Tag 666/667/boss death bugs:
    1. Killing Spider on E2M8 or Cyber on E3M8 doesn't end the map as it does in Vanilla.

    2. E1M8 666 Tag compat option only checks for the first boss type to die (Barron, Cyber or Spider), rather than repeating for each boss type (i.e each boss type killed will re-trigger tag666 in pre Ultimate Doom Vanilla).

    3. 666 and 667 tags on Doom2 Map07 can only be activated in that order, rather than in either order. Might as well add, that like 2. above, these triggers can be re-triggered multiple times in Vanilla (for instance if an Arch Vile ressurects a boss monster or a Boss Shooter spawns one); though I haven't checked to see if Dday retains this behaviour.

    The later two are on Sourceforge (2. noticed by myself and 3. originally noticed by Jimi).
  • Re: Map title

    Well, given the extent at which modders have abused and repurposed the CWILV patches it looks to me like there is nothing we can do here. Either users will have to live with the map title looking wonky in some mods, or the majority of maps simply will not have correct titles. This all stems from the fact that id opted to not define the map names as strings. I don't see a way around this.

    Note that I'm referring to the actual title of the map and not the URI (e.g., E1M1).
  • It does look like the map number on the automap, assumes the CWILV graphic is always a set height? If so, something to consider is changing that to append it to the bottom of the graphic, where ever that may be?

    That would handle cases like Sonicmariodoom's example without affecting any mod that uses CWILV graphics properly (i.e like the Iwads?). Given cases like Hell to Pay are already very bad, it probably wouldn't make them any worse.
Sign In or Register to comment.