[Marscaleb]

I suppose this is really just an empty rant. I would love to direct my complaints somewhere that someone who could do this might actually hear my complaints and maybe agree with me and take action; but I have no idea where that would be. So all I can do is just yell at the empty sky...

I want a Duke3D port that works the same way that ZDaemon does.
A dedicated app for Duke that connects people to a server and launches a modified version of the game. From the user's perspective, it's all just one program.
But it doesn't just run the basic default Duke multiplayer. It has to have added features to do things like end matches after a score count and/or time limit, and cycle to the next map. An ability to customize your controls and character from within the game would be nice too. The stuff that just wasn't done in the DOS days but is so critical to multiplayer today.
And it needs to support LAN as well. I'm getting downright tired of all these efforts to revitalize Duke's multiplayer but that require using the internet. I'm not opposed to having internet matches, but I just want the ability to set up my own private server and play with friends under the same roof, no internet connection required. No depending on someone else's server.
I'm also a really big fan of the way ZDaemon starts you off in a spectator mode, and you just gotta hit E or fire to actually play, (and inactive players are dropped to the same mode.) I don't see other games doing this but its just super convenient, especially for a game with a strong modding community making new maps. Honestly what I really like about it is that you can get up and step away from the keyboard after a match, and you don't hold up everyone else waiting for you to get back, and neither have some brainless body just sitting in the map taking hits. I suppose this isn't exactly the most important feature, especially for a game that doesn't have bots to fill out a roster, but I've just really grown to appreciate that feature and would like to see it become more commonplace.

That's what I want.
I'd build it myself if I could code at that level. I can't, and I don't want to ignorantly claim it would be easy, but I do wonder if one could actually just copy a lot of code straight out of ZDaemon and paste it into a fork of eDuke, just to get a lot of groundwork done. Obviously not everything, but maybe the launcher program. But I guess that's just me reaching for something; I don't know.

I'm just dreaming, but that's the program I want.

[dnskill]

Just curious.. Have you heard of and/or tried NetDuke32?

It includes the following:

• 16 player support, vs Duke3D's original 8.
• Improved networking code that is more reliable and less prone to desynchronization than vanilla Duke3D.
• Rewritten prediction code that gives immediate and smoother response to weapon and inventory use.
• New, easier to understand scoreboards for both DukeMatch and CO-OP, including ping display.
• Lifted limits for number of spawn points allowed in a map, and maps with fewer spawns than players no longer cause broken behaviour, allowing SP maps to be played online.
• Smarter DukeBot AI that's better at pathfinding, can swim, use jetpacks, use steroids, retreat and/or prioritize items based on combat situation, and understand how elevators work. They can also be used online with other players, too!

While it may not have all the features you're wanting, it should at least allow you to have a fun experience. You can join the Duke4 discord sever, enter the #dukematch channel, and see if anyone's up for Dukematch, coop, or other game modes like Duketag.

[Marscaleb]

dnskill, on 24 June 2026 - 01:53 PM, said:

Just curious.. Have you heard of and/or tried NetDuke32?

Yes, and hands down the biggest problem with it is that it cannot operate on a LAN without internet connection. I'm looking for a way to play Duke without having to be connected to the internet.
Secondly, it won't run in Windows XP, so supporting 16 players doesn't mean anything to me because I couldn't run it on more than six of the computers I have.
I'm also very displeased about the inability to join a match ad hoc; we have to have everyone connected at the beginning of a match and no one can join once a connection has started. Shutting down the whole server to add a player is even more annoying considering that you have to type in the IP address to join. But honestly, I could deal with that, and I'm probably more upset about the lack of having a time limit on matches.

[NY00123]

I suggest to check this thread about NetDuke32: https://forums.duke4...duke3d-netplay/

To make this short, after working on NetDuke32 during 2015-2023, Striker basically took a break for most. He's been back to working on TerminalFury during the last two years.

In the meanwhile, I prepared two separate maintenance releases of NetDuke32. The last of them introduced - still possibly in an experimental form - a time limit option. Striker was also briefly back to NetDuke32, adding the new "unlagged" toggle in 2025. That's also found in the last maintenance release. See most recent posts in the thread above for details, but for the maintenance releases themselves, you may currently check this page: https://voidpoint.io...ctor/-/releases

Better assume in general that what I prepared for NetDuke32 is what you may give a try.

Yeah, good chances are the Windows executable requires an OS newer than Windows XP.

LAN games should be supported, I'm wondering what problem did you have. The bundled NetLauncher might require internet access, but NetDuke32 itself supports LAN games via command-line arguments. Alternatively, if using Windows 7 or another compatible OS, the IRC-based NukemNet launcher may be used for creating a chat room and then starting a new game - it should also allow some configuration for LAN games.

Unfortunately, in-game joining is still not a possibility in any Duke3D source port, as far as I know. Striker wanted to get there, and not just him, but technical barriers have been there along the way.

[Marscaleb]

NY00123, on 28 June 2026 - 09:57 AM, said:

LAN games should be supported, I'm wondering what problem did you have. The bundled NetLauncher might require internet access, but NetDuke32 itself supports LAN games via command-line arguments. Alternatively, if using Windows 7 or another compatible OS, the IRC-based NukemNet launcher may be used for creating a chat room and then starting a new game - it should also allow some configuration for LAN games.

When I tried launching it on a LAN with no internet connection, it went through its process and was trying to connect to addresses it could never find. It never even got to the part where I can tell it to stop looking for more players and launch it with bots. If there is support via command-line arguments, this was not mentioned in the read-me file. And there was no NukemNet launcher in the zip file, unless you are referring to the NetLauncher exe which is what I was using. (And if that's the case, then it was still asking for an IP address I had to type in. Not exactly the desired interface, but I used DOS, I can manage.)

I'll take a look at the newer build you linked the next time I have a free day. Thanks for the update. Maybe it will do the trick.

And I for one would be interested in a Win XP compatible version. I know that sometimes (but not always) that compatibility is basically a setting in how Visual Studio compiles the exe. So long as there is no functionality within the code that has any problems with XP, it really comes down to some settings with the compile that are generally not left on by default anymore. I know this from talking with some people working with source ports of other games when they lost XP compatibility after an update.

[NY00123]

Marscaleb, on 28 June 2026 - 09:55 PM, said:

When I tried launching it on a LAN with no internet connection, it went through its process and was trying to connect to addresses it could never find. It never even got to the part where I can tell it to stop looking for more players and launch it with bots. If there is support via command-line arguments, this was not mentioned in the read-me file.

I suppose it's about the last zip released by Striker, i.e., netduke32_v1.2.1.zip? The included readme documents usage of NetLauncher. Emphasis was indeed on online internet games and less on local ones, and I recall NetLauncher potentially not supporting LAN games at all.

Regarding command-line usage: NetDuke32 v1.1 RC1 removed peer-2-peer mode, leaving just master-slave. Command-line syntax should remain more-or-less the same for this mode as it was beforehand, actually being the same in JFBuild and VoidSW. Note that JFBuild did change the syntax for peer-2-peer mode at some point, but that's less relevant to NetDuke32 as said.

Details are currently found here:

https://wiki.eduke32...iki/Multiplayer (under "Old-Style Lockstep Multiplayer" as of now, since the page is mainly about EDuke32)
https://www.jonof.id...tml#multiplayer

Quote

And there was no NukemNet launcher in the zip file, unless you are referring to the NetLauncher exe which is what I was using.

NukemNet is a separate program created by aaBlueDragon. Albeit saying "Nukem" in the name, it supports various other games. It lets people configure supported games and source ports of them, create and join chat rooms for communication and start games after creating such rooms. There are also some workarounds/solutions for possible (internet) connectivity issues, like STUN and relays.

I've just added a post to the NukemNet thread within these forums with a status update, given that the last releases were from October 2025: https://forums.duke4...post__p__387387

Quote

I'll take a look at the newer build you linked the next time I have a free day. Thanks for the update. Maybe it will do the trick.

You're welcome! As hinted earlier, I currently expect that to be the latest build (at least from me) - unless that changes one day.

Quote

And I for one would be interested in a Win XP compatible version. I know that sometimes (but not always) that compatibility is basically a setting in how Visual Studio compiles the exe. So long as there is no functionality within the code that has any problems with XP, it really comes down to some settings with the compile that are generally not left on by default anymore. I know this from talking with some people working with source ports of other games when they lost XP compatibility after an update.

In NetDuke32's case (and also for EDuke32 and other derived ports), the included makefiles are used in general, also for Windows builds. MinGW-w64 is used for them. What makes NetDuke32 different from the related ports is that it hadn't migrated to 64-bit Windows binaries for releases - Striker didn't do so at the time, and so I didn't for the last 2 maintenance release. I could still make 64-bit builds, and I had often done so for Linux; That said, different builds (even debug and release ones for the same platform) might desync, as found out beforehand.

Support for Win XP or other older operating systems might really be a matter of luck - if the codebase and executable allow that, then it'll be allowed. Otherwise, a newer OS is required.

[Marscaleb]

NY00123, on 29 June 2026 - 09:14 AM, said:

You're welcome! As hinted earlier, I currently expect that to be the latest build (at least from me) - unless that changes one day.

Okay, I've finally gotten around to testing this out. First of all, thanks for all the information you gave, it was a big help.
I pulled out four computers to test it with. First off, Net Nukem failed to launch on a machine that was running Windows 7. It gave an error of "Caught exception 0xC0000005 at 0x00000000: Access violation." I have the whole crash log but I don't know if anyone cares.

The next issue I found is that, even if this new version of Net Duke I got from you will support time limits, Nukem Net doesn't let me configure that option. Can I add any "Extra manual arguments" to the game settings to make use of the time limit?

But apart from that, it worked! I'm not sure how many machines I will be able to get this to work on, but I can at least offer it on some of them, which is better than nothing.
Again, thank you for the help.

[NY00123]

Marscaleb, on 19 July 2026 - 07:30 PM, said:

Okay, I've finally gotten around to testing this out. First of all, thanks for all the information you gave, it was a big help.

Great to see it's been useful!

Quote

First off, Net Nukem failed to launch on a machine that was running Windows 7.

Have you tried using the 32-bit binary? That's the one listed as Win7+ compatible on the website.

That said, it had to be made with an older version of Electron, following removal of support for Win7 in later Electron versions as done for the Chrome browser.

Quote

The next issue I found is that, even if this new version of Net Duke I got from you will support time limits, Nukem Net doesn't let me configure that option. Can I add any "Extra manual arguments" to the game settings to make use of the time limit?

I'm afraid configuration is possible only after starting NetDuke32, either from the menu or via a console var. The most recent NetDuke32 build was prepared after the last NN version, but even if that weren't the case, that NetDuke32 build offers no way to change the timeout via a command-line argument or a .cfg setting.

Quote

But apart from that, it worked! I'm not sure how many machines I will be able to get this to work on, but I can at least offer it on some of them, which is better than nothing.
Again, thank you for the help.

You're welcome!

[Striker]

Marscaleb, on 27 June 2026 - 09:46 PM, said:

Yes, and hands down the biggest problem with it is that it cannot operate on a LAN without internet connection.

That is not true.

[Marscaleb]

NY00123, on 20 July 2026 - 11:03 AM, said:

Have you tried using the 32-bit binary? That's the one listed as Win7+ compatible on the website.

I am using the exe I found on this page, in the section labeled as "test build originally prepared on Feb 5 2026"
Under "release notes" there was a 7z file that included only one exe file. The other links were labeled as source code. I saw no separate executable labeled as a 32 bit version. If that is not your new version with time limit options, then I'm looking in the wrong place. Where do I get the 32 bit version?

NY00123, on 20 July 2026 - 11:03 AM, said:

I'm afraid configuration is possible only after starting NetDuke32, either from the menu or via a console var. The most recent NetDuke32 build was prepared after the last NN version, but even if that weren't the case, that NetDuke32 build offers no way to change the timeout via a command-line argument or a .cfg setting.

Okay, I found it in the in-game menu. Which means I have to start the match in Nukem Net, and then RE-start the game from the in-game menu in order to enable a time limit. And unfortunately the setting doesn't save between sessions.
Well, beggars can't be choosers. It's better than not having the option at all. Hopefully a future version can improve the experience.


Hmm, after fooling around with this for a while, I have discovered that I am in want of a solid map cycle, so I can keep the game focused on the better multiplayer maps. But as I think about this, would I be able to achieve this just by altering the con file? Just create a custom USER.con that replaces all the maps with the ones I want to cycle.
However, when I was first trying it, when the match ended it gave the losing player a screen to vote for the next map instead of just cycling to the next map. Any idea what caused that?
EDIT: It seems that was because it was the last map in the episode. It turns out when it finishes an episode it just stops and goes to an empty screen. That's going to be annoying; I was really trying to set up a system where the maps just keep going.
Also, for some reason when a match ends it skips a level instead of going to the next level. This seems to be a bug.

Striker, on 21 July 2026 - 11:21 AM, said:

That is not true.

It isn't possible using the "NetLauncher" bundled with NetDuke. I have since learned that Nukem Net supports LANs just fine, and I have switched to that.

[Marscaleb]

So, I'm working with Claude to try to get a build that works with Windows XP, since there is really no reason for anyone else to help me with that task. I honestly doubt that anyone else needs this.

Anyway, while I was working with Claude, I asked him to track down this bug that selects the wrong level at the end of a match. This is what he found:

Quote

I traced this down and found the exact mechanism — it's a genuine race between per-player logic, not anything in the level-loading code itself.

Root cause

The two level-end paths use completely different call patterns:

Normal exit switch (sector.cpp) — a single player triggers the switch, which calls Net_EndOfLevel(false) exactly once. ud.level_number goes up by 1. Clean.

Score/time-limit win (player.cpp) works very differently:

P_HandlePlayerWin() / P_HandleTeamWin() detect the limit was hit and set an 8-second exit countdown, identically, for every connected player:
cpp
for (int32_t ALL_PLAYERS(i))
g_player[i].ps->timebeforeexit = GAMETICSPERSEC * 8;
Each tick, P_ProcessInput(i) runs in a loop over every player, and for each one calls P_HandleSpecialTimers(i), which ticks down that player's own timebeforeexit.
Because every player's counter was seeded with the same value at the same tick, they all hit 1 on the same tick.
When a player's counter hits 1, P_HandleSpecialTimers calls Net_EndOfLevel(false) — which increments ud.level_number. Since this fires independently for each player whose countdown expired that tick, a 2-player match calls it twice, bumping the level number by 2 instead of 1 (and it would be worse with more players).

This explains exactly what you're seeing: only the limit-triggered ending goes through this per-player-looped timer; the switch-triggered ending is a single direct call and never had this problem.

The fix

The cleanest fix is a guard in Net_EndOfLevel() itself (netduke32/src/oldnet.cpp) so a second call arriving before the level actually transitions is a no-op, rather than trying to rework the per-player timer/win logic (which has other UI side effects per player worth leaving alone):

Viewed 2 files, edited a file
Viewed 2 files, edited a file

The patch is applied. Here's the summary of the diagnosis and fix:

Diagnosis

This bug lives specifically in netduke32 (not the plain duke3d codebase, which uses a different, single-call P_EndLevel() for everything). The multiplayer score/time-limit path is structurally different from the switch-triggered exit:

Switch exit: one player action → one direct call to Net_EndOfLevel() → level advances by 1.
Limit-hit win: the win handler arms an identical 8-second exit countdown on every connected player at once. Each player's countdown is ticked down independently inside a per-player loop that runs every game tick. Since all counters started at the same value on the same tick, they all expire on the same tick — so Net_EndOfLevel() fires once per player instead of once per match, and each call increments ud.level_number. With 2 players, that's +2; it would scale with player count in bigger matches.
Fix

Added a re-entry guard at the top of Net_EndOfLevel() in netduke32/src/oldnet.cpp: if ud.gm already has MODE_EOL set (meaning a level-end transition is already underway), any further calls in that same transition are now no-ops. MODE_EOL gets cleared again the moment the next level actually loads, so this only blocks the redundant same-transition calls — it won't interfere with legitimate future level-end events.

This is a minimal, surgical change — it doesn't touch the per-player countdown/UI logic (each player's screen still gets its own win-countdown behavior), it just makes sure the global level-advance side effect only happens once.

One thing worth testing before we call this closed: please verify a match that ends via the "last enemy fist-pump" bonus trigger (P_HandleFist) still behaves correctly too — that path calls Net_EndOfLevel() the same way and could theoretically have had a similar latent risk, though it's less likely to double-fire since normally only one player performs that specific action. The guard protects it either way, but it's worth a quick playtest since it wasn't the bug you originally reported.

Want me to also do a quick pass to see whether this same "identical per-player timer" pattern shows up anywhere else in the codebase, in case it causes other double-firing bugs beyond this one?

I really don't know who I need to give this information to; I expect this bug has been inside Duke for a long time.
I guess I'll have Claude poke around with some other changes I want, since I'm building my own personal version.

I feel dirty.

[NY00123]

Marscaleb, on 21 July 2026 - 07:17 PM, said:

I am using the exe I found on this page, in the section labeled as "test build originally prepared on Feb 5 2026"
Under "release notes" there was a 7z file that included only one exe file. The other links were labeled as source code. I saw no separate executable labeled as a 32 bit version. If that is not your new version with time limit options, then I'm looking in the wrong place. Where do I get the 32 bit version?

You've mentioned "Net Nukem", hence my assumption being you've wanted to refer to NukemNet (NN), rather than NetDuke32. The NN website currently hosts a separate archive for NN listed as "Windows 32 Bit (7+)".

The released NetDuke32 binaries, as prepared by Striker, have been 32-bit so far (possibly due to past bugs related to mod compatibility). For now, that hasn't been changed as of the two maintenance releases prepared by me.

Quote

Hmm, after fooling around with this for a while, I have discovered that I am in want of a solid map cycle, so I can keep the game focused on the better multiplayer maps. But as I think about this, would I be able to achieve this just by altering the con file? Just create a custom USER.con that replaces all the maps with the ones I want to cycle.

Yeah, that's one option. Note that if you're using NN's file transfer feature, USER.CON should not be used as the main CON file - that's GAME.CON for the stock game, which uses directives to include DEFS.CON and USER.CON.

NetDuke32 hasn't had an alternative implementation of maps cycling as found in other games. Given the lack of in-game joining, it has probably been considered less useful, with sessions either going through a few maps, or whole predefined episodes for cooperative games.

Quote

Also, for some reason when a match ends it skips a level instead of going to the next level. This seems to be a bug.

Match ending was a new addition to NetDuke32/EDuke32-OldMP not present in the original game, occurring upon reaching frag limit (or time limit in the last maintenance release). People would often select a single map being loaded as a user map, then when the match completes, players would return to the menu for map selection or quit the game.

I'm unsure your scenario has really been brought up or taken into account. Some refactoring I had done as part of implementing time limit had possibly had an effect.

[Striker]

Marscaleb, on 21 July 2026 - 07:17 PM, said:

It isn't possible using the "NetLauncher" bundled with NetDuke. I have since learned that Nukem Net supports LANs just fine, and I have switched to that.

It's entirely possible with NetLauncher. NetLauncher doesn't require an online connection. You can use direct IP connection and tell it to connect to the host's IP address. I know it can because I've developed NetLauncher and used it in a LAN before. You have to make sure your device priority/metric is set up correctly and that another device (like a virtual LAN adapter for a virtual machine) isn't stealing first priority.

[Hendricks266]

If you use MSYS2 MinGW 32-bit to build with SDL 1.2 (make SDL_TARGET=1) and also disable use of the aligned alloc functions (I don't think there is a one-line command for this any more), the resulting EXE should run as far back as Win98 SE. At least it used to.

[NY00123]

Striker, on 23 July 2026 - 04:50 PM, said:

It's entirely possible with NetLauncher. NetLauncher doesn't require an online connection. You can use direct IP connection and tell it to connect to the host's IP address. I know it can because I've developed NetLauncher and used it in a LAN before. You have to make sure your device priority/metric is set up correctly and that another device (like a virtual LAN adapter for a virtual machine) isn't stealing first priority.

Hmm, good to know. Seemed to misremember NetLauncher having limitations (at least possibly) restricting LAN use for some reason; It might rather be about mixing internet and LAN addresses, or such restrictions potentially existing in the older DiscordLauncher incarnation.

That means problems reported here about NetLauncher use were not related to total lack of LAN support.

Personally, whenever testing NetDuke32 locally, I'd use command-line arguments manually in most cases, hence haven't been entirely sure about LAN support for NetLauncher.

[Freudstein]

Hi guys, I'm experimenting with a few different multiplayer setups using NY00123's latest NetDuke32 test build and NetLauncher on Windows 10. I've been able to host a game and join it from another instance of NetDuke32 on the same machine (also using NetLauncher), and it works fine.

I'm now trying to join the Windows host from a VM with Ubuntu 22.04. The Ubuntu VM can ping the Windows public IP just fine. Since there are no ready-made NetDuke32 builds for Linux, I had to build my own on the VM from the netduke32_2026q1 branch. Once that was done, I started a 2-player game on the Windows host with NetLauncher, and ran the following on the VM:

$ ./netduke32 -net HOST_IP:23513

where HOST_IP is the public IP of the Windows host. When I do this, I see the NetDuke32 launcher window opens with a greyed-out Start button, and nothing happens. The terminal shows the following output:

runtime src|
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
Gtk-Message: 22:09:28.213: Failed to load module "canberra-gtk-module"
0,2855s INFO| Started at 2026-07-27 22:09:28.302
0,2856s INFO| NetDuke32 v1.3 r11701[netduke32_2026q1]-313e0ddde
0,2856s INFO| Built Jul 27 2026 22:07:12, GCC 11.4.0, 64-bit
0,2856s INFO| Application parameters: -net 84.52.233.227:23513
0,2857s INFO| Using directory /home/freudstein/Documents/eduke32-csrefactor/
0,2857s INFO| Using directory /home/freudstein/.config/netduke32/
0,2857s INFO| Player Color INIT:

0,2857s INFO| Added color Blue (9)
0,2857s INFO| Added color Red (10)
0,2857s INFO| Added color Green (11)
0,2857s INFO| Added color Gray (12)
0,2857s INFO| Added color Dark gray (13)
0,2857s INFO| Added color Dark green (14)
0,2857s INFO| Added color Brown (15)
0,2858s INFO| Added color Dark blue (16)
0,2858s INFO| Added color Bright red (21)
0,2858s INFO| Added color Yellow (23)
0,2858s INFO| Using directory /home/freudstein/.config/netduke32/
0,2858s INFO| Using config file 'netduke32.cfg'.
0,2890s INFO| CPU: 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
0,2893s INFO| Initializing SDL 2.0.20 (https://github.com/l...43353a5fee1b6b6)
ATTENTION: default value of option mesa_glthread overridden by environment.
0,3969s INFO| Using 'x11' video driver.
0,3970s GFX| Detecting video modes for display 0 (XWAYLAND0)...
0,3973s INFO| Searching for game data...
0,4563s INFO| Done
0,4566s INFO| Done
0,4568s INFO| Using DUKE3D.GRP as main data file.
0,4579s INFO| Using 'eduke32.dat' for internal data.
0,4601s CON| Compiling: GAME.CON (151190 bytes)
0,4603s CON| Including: DEFS.CON (35992 bytes)
0,4622s CON| Including: USER.CON (45482 bytes)
0,4625s WARN| USER.CON:844: overwriting existing definition for sound #261 (hydro43.voc)
0,4626s WARN| USER.CON:873: overwriting existing definition for sound #323 (aisle402.voc)
0,4633s INFO| GAME.CON: In actor `ORGANTIC':
0,4647s WARN| GAME.CON:3967: found 'else' with no 'if'
0,4651s INFO| GAME.CON: In state `pigshootenemystate':
0,4651s WARN| GAME.CON:5890: found 'else' with no 'if'
0,4659s WARN| Found 4 warning(s), 0 error(s).
0,4661s CON| Compiled 139240 bytes in 6ms
0,5682s INFO| Initialized 96,0M cache
0,5693s INFO| Loading eduke32.def
0,6131s INFO| Internal def file 'eduke32.def' loaded.
0,6133s INFO| Precaching sounds...
0,6563s INFO| Sound precache finished in 43ms
mmulti: This machine's IP is 127.0.1.1
mmulti: Player 0 at HOST_IP:23513
0,7463s INFO| Waiting for players...

Nothing else happens. I have no clue of whether I'm doing something wrong, or what exactly are the arguments that NetLauncher ends up passing to NetDuke32. I've done both manual port forwarding and UPnP on the host side, and always get the same result. Am I doing something wrong?

As a more general question, I'm curious as to why the NetDuke32 code hasn't been merged back into eDuke32 instead of having this mess of various forks and backported commits, etc. Have both codebases really diverged so much that they need to be maintained separately like this?

Thanks.

PS: One last stupid question, I see that a player can send audio taunts by pressing ALT+F*; however doing ALT+F4 will obviously open the game menu as if the player wanted to quit the game instead of sending the "Lucky Son of a Bitch" taunt. Is there another way to send this taunt?