MantisBT - Issues

0004596: New menu option: ally/enemy icon size - big/small

Mon, 17 Aug 2026 01:58:06 +0000

When I first made the new ally/enemy icons, they were designed around standard 3v3 CTF gameplay, where you want to see your allies clearly from far away when across the map. Although the new icons are smaller than the old Skulltag ones, they can still appear a bit intrusive if there are more than 2 allies running around, or when enemies are located above other players' heads. See the attached screenshot.

I decided to slim the icons down a bit, and thought that instead of replacing the old ones completely, that it would be better if users could choose their preferred size, depending on their visual preferences. An additional multiplayer menu option where you could choose whether to use big or small ally/enemy icons would then be nice.

As mentioned earlier, the smaller icons allow you to see enemies located behind other players' heads a lot clearer, and especially works well for players who might want to use the ally icon in coop modes.

0004622: Optimized PNGs with palette have weird alpha

Tue, 11 Aug 2026 18:17:51 +0000

Optimized 8-bit indexed PNGs with a lot of transparent pixels (like clouds, smoke, vapor and etc) have stepped and weird alpha in zandronum

0004625: New default wadhost request for Pizzadoom

Tue, 11 Aug 2026 15:38:25 +0000

Ticket opened as a proxy for @heavymeteor_, Pizzadoom's administrator

As a newer server cluster, it may be nice to have them as one of the approved wadhosts as a lot of other server clusters are already listed.

The URLs are
https://wads.pizza-doom.it/
https://wads-uk.pizza-doom.it/

0003334: Tickrate discrepancies between clients/servers

Tue, 11 Aug 2026 02:56:20 +0000

This issue was first described by unknownna here: 0002859:0015907.
In this summary, all issues are addressed by 0003314, 0003317 and 0003316.
All but one issue:
[quote=unknownna]* Desyncs a little consistently every 24-25 seconds.[/quote]
Turns out this is a little off though, the exact period is 28 seconds.

When clients start on both Linux/Windows, a timing method is selected: either a timing event fired by the OS can be created and Zandronum will use it or time polling is used instead.
Unfortunately, as described in [url=https://forum.zdoom.org/viewtopic.php?f=3&t=30348#p576033]this thread[/url] from the ZDoom forums, Windows timing events are only precise down to the milliseconds and as such only a delay of 28ms can be achieved due to rounding.
Zandronum servers on the other hand always use time polling and, as a way of dealing with this issue, use a tickrate fixed at 35.75hz.
[code]lNewTics = static_cast ( lNowTime / (( 1.0 / (double)35.75 ) * 1000.0 ) );[/code]
Can you spot the problem here?
As described in the linked thread, a time step of exactly 28ms would theoritically result in a frequency of (1000 / 28) = 35.714285714...hz.
Using a tickrate of 35.75 instead results in a time step of (1000 / 35.75) = 27.972027972ms.
Calculating the difference and dividing the client time step by it (i.e. magnifying that difference until it equals one time step) and we get, you guessed it, 28 seconds.
(28 / (28 - (1000 / 35.75))) = 1001 tics or 28 seconds.
This means that after 28 seconds, the server will essentially be ahead of us by 1 tic.
The prediction will account for this and as such clients won't notice a thing but outside spectators sure will.
Attached is a demo of the desync occuring by using cl_predict_players false (28ms.cld).

By making the server loop use a proper time step of 28ms, the issue is fixed:
[code]lNewTics = static_cast ( lNowTime / 28.0 );[/code]
However a problem still remains: the windows timing method is the ONLY one that has a time step of 28ms.
If for some reason the creation of a timer failed at start, Windows will use time polling which will obviously be a proper 35hz.
Linux timer events are precise down to the microseconds as reported in the thread and will have proper 35hz both for polling and timing events.
As such, even with a fixed time step of 28ms on the server, clients using a proper 35hz tickrate will experience a desync too and a much worse one at that.
Calculating the difference again, etc...:
((1000 / 35) / ((1000 / 35) - 28)) = 50 tics.
Only 50 tics and these clients will appear to jitter to outside observers.
I will attach a demo of this with cl_predict_players false as well (35hz.cld).

The solution is obviously to enforce a consistent tickrate in every case but which one?
Should we force the time step to be 28ms globally or should we simply disable Windows timer events and use 35hz on the servers and be done with it?
In my opinion, we should simply disable Windows timer events and here are my arguments on why:
* The clients never slept to begin with if cl_capfps is off.
* As per 0001633, the timer events are [i]already[/i] disabled on linux for clients due to being faulty.
* Proper 35hz.
I'm not sure but doesn't the fact that the tickrate is not a proper 35hz mean that mods that would rely on it being correct experience time drift?
For example, a mod uses a timer in ACS that's supposed to count time at 35hz, does it keep track of the time correctly?
I haven't really checked this so I'm not sure but that could be a thing.
* If we want to look at some sort of standard, Quake 3 uses time polling for both its clients and servers and, just like Zandronum, only the servers sleep.

0004624: petition for sv_maxteams, buckshot and more latched CVars to be normally reachable

Mon, 03 Aug 2026 21:07:20 +0000

Currently, zandronum allows you to change stuff like the size of the teams, however, i wonder why this can't be done in scripts (ACS), for example, triyng to use "SetGameplaySetting" on "sv_maxteams" will do nothing, same goes for buckshot and, as far as i've seen, those commands can be modified BUT the changes will only take effect after a hard reset.

I think it would be better if people could modify those CVars on their mods, i am aware that you can do reach them via "ConsoleCommand", but this a function that has security issues and is flagged for removal so it shouldn't be an option.

In my case, my mapset is mixed with 2-way maps and 4-way maps, unfortunately a server reset is needed to be able to change the team size when needed, and for buckshot, i planned to activate it on a single exclusive map.

In summary, those CVars shouldn't really be latched or locked, atleast those like "sv_maxteams" or "sv_maxlives", this so they can give more variety to future mods, unless there is a good reason for keeping them latched, i don't think they should be inaccessible.

0004621: Projectiles lose the ability to go through allies when spectating

Sun, 26 Jul 2026 22:01:59 +0000

This has been a persistent issue since sv_shootthroughallies was added. Very annoying due to trolls using it. (Random thought, is there some random coop map set that abuses this?)

0004623: Add ACS function to get player camera's bob offset

Wed, 22 Jul 2026 13:15:20 +0000

GetActorViewHeight() function does not include bob offset in the return value, so it would be a good idea to add a new function that returns activator's(or certain player's) bob offset.

0001330: When you die in TLMS, any projectile that was yours becomes server's

Mon, 20 Jul 2026 19:08:34 +0000

After an ally dies and you get hit by a projectile spawned by them you get hurt. Watermelon AFAIK told this to me way back in Skulltag times that once you die everything you had became the server's, so if you died you would be dead to server or something.

0004620: Certain joysticks have issues with default controller settings

Sun, 05 Jul 2026 12:46:34 +0000

I've tested this with PS4 and PS5 controllers. Due to the axis being set up the way they are on PS4/PS5 controllers, the game will cause the player to spin in circles while staring at the ceiling. Attached is an image of the default PS4 controller readings. I'd like for the controllers to work properly when plugged in, but not sure the best way to go about doing so. Would also be nice to have some of the controller's buttons bound by default.

0004619: PRINTNAME_NEXTLEVEL does nothing

Mon, 22 Jun 2026 14:51:54 +0000

This produces a null string in Zandronum both online and offline, it works in GZDoom however. It'd be nice to backport this, as the current map rotation functions require a map rotation, and most servers don't bother with this or just use a map hub like lexicon, which don't need this anyway. Their mapinfo for the individual map packs separated as episodes handle it.

Doesn't work in 3.3 either. It'd be way more useful than the rotation set of functions as users don't have to make one to play the wads from start to finish.

0004601: SetCurrentGamemode keeps certain properties when switching from team to non-team modes

Sun, 14 Jun 2026 12:17:02 +0000

If you use SetCurrentGamemode to switch from Team to Non-Team modes (ie TeamDM to DM), it will keep some properties like the win/lose image/theme.

0004606: Add unlagged projectiles and possibly Q-Zandronum client-predictable ACS scripts

Tue, 02 Jun 2026 16:41:03 +0000

With the lack of support and activity on Q-Zandronum I'm finding it hard to provide support for my mod. I'd like to port it back over to Zandronum potentially but the lack of unlagged projectiles is the main thing holding it back I fear. How hard would it be to implement this in, even if done differently than how Q-Zandronum does it?

0001673: Changing a player's class/team w/o respawning?

Tue, 02 Jun 2026 16:25:20 +0000

I recently returned to work on my Infected Horde mod. If you remember one of issues with its development that has stopped it was bad handling of changing a player's class to another alongside w/ changing his team. While the issue w/ team changing was hopefully fixed there is still no way to change a player's class or team w/o respawning him. It severely hinders my mod since it requires newly infected humans to stay there they were prior to infection. It think a flag paramater to Player_SetTeam() (STF_KeepPosition/Health/Armor/CurrentWeapon/Weapons/Inventory) should be enough. But now I need a new function to prematurely set another class w/ the same traits. Player_SetClass(classname,flags) w/ the same possibilities could do the trick. I understand what it maybe impossible to do it w/o actually respawning, so I asked more flags in case one wants to keep players health, etc.

Another mod what could benefit from this is AOW 2. It provides a way to change your team to the weaker keeping (most?) of your stuff but by restoring it from variables.

0004618: If a client was already logged in before "map" map change, log in automatically again

Tue, 02 Jun 2026 16:16:28 +0000

I was thinking from the perspective of regular users, that they would probably expect to remain logged in for the entirety of the game session after map changes, provided that they already logged in once already.

The problem with the current login behavior, is that whenever the server triggers a "map" map change, clients are forced to be logged out since it triggers a reconnect.
This means that clients with "cl_autologin 0" lose their login status upon entering the new map, and in turn cause them to lose experience and whatnot that any given mod might track.

Being forced to log out after map changes feels unnatural, IMHO. What do you think? If clients wish to deliberately log out, there should probably be a "logout" command implemented instead.

Since one can expect that users wish to remain logged in after map changes, maybe it would be better to have the server check whether a client was logged in prior to reconnecting after a "map" map change, and if so, automatically log it back in again, even when "cl_autologin" is 0.

I think this would make the login system feel more solid and robust for normal users.
I'd like to hear your opinion though, whether you think it's a decent idea, or think it's the wrong approach.

0004605: Logging in, then hard map reset will prevent Database features from working correctly

Wed, 27 May 2026 17:38:14 +0000

Self explanatory, this has happened in testing.

0004617: Player_SetTeam doesn't print join messages offline

Mon, 25 May 2026 12:28:48 +0000

A minor issue with this command is that it doesn't print any join messages during offline play, neither in true singleplayer or in multiplayer emulation.

0004615: Player_SetTeam is unable to switch players off of a team

Mon, 25 May 2026 12:25:18 +0000

There is a contradiction with the Zandronum Wiki's article on the function: https://wiki.zandronum.com/Player_SetTeam

"Using the current value of sv_maxteams removes the player from their current team without making them join another."

This is not possible. Trying to set the player to the value of sv_maxteams does not set the player to an unaffiliated team.

0004616: Dropped Flags/Team Items don't reset when the map resets, duping itself

Mon, 25 May 2026 12:21:38 +0000

The mod I've been working on with a team utilizes ResetMap for a pregame countdown. When resetting the map after a team item has been dropped, in our case a flag, the indicator to the flag's status is still left as a "?", which means that shortly after, the flag is automatically returned—despite the map resetting with a new flag, which leaves the map with two of the same flag.

0001952: Extreme lag from an old wad

Fri, 22 May 2026 23:38:07 +0000

So I've been going through a lot of old mods lately, when I came across this lag problem in supersonicdoom

On Map28 there is a room full of fans, whenever you walk in and the fans activate, the game starts lagging to about... 0 fps...

Tried to figure out why it happens before I posted this report, but couldn't reproduce the problem in my own test map.

This happens in both 1.3 and 2.0
Does not happen in ZDoom or GZDoom

0002852: The experimental A_Jump(256, ...) handling causes problem in weapon

Thu, 21 May 2026 12:33:41 +0000

The problem happens in the special build from ticket https://zandronum.com/tracker/view.php?id=2840 -- The weapon seems to work fine at first but as far as I can tell, after a countdown (like in Survival) the weapon messes up. This is quite possibly due to the random jumps in the weapon's ready state, which freezes it I think.

0003792: Incorrect hitscan behavior

Wed, 20 May 2026 09:52:45 +0000

It is possible to shoot at angles that should not be true in Vanilla settings where freelook is disabled. In the demo provided (see Additional Information), a player's Shotgun shot not only came out at a different angle from where the player's POV was when firing (typical desync behavior), missing the target completely when not supposed to, the pellets also somehow hit the floor instead of the wall in front of them. The player's target was on the same level as them, meaning vertical autoaim was not supposed to activate, and it was impossible for the target to be on the position the pellets hit as there is no lower floor in that spot.

0002272: Monster movement prediction on slopes

Tue, 19 May 2026 19:45:37 +0000

I've attached a demo showing the problem. The monster seems to warp down the slope and eventually warps back to the top of the slope.

0001162: A_Jump causes nasty desyncs to occur in Futur War online

Tue, 19 May 2026 13:04:22 +0000

Due to the way the clients handle A_Jump, actor flags/properties can desync between the client and server. Many of the monsters in Futur War use A_Jump to go to their death states. The death states call A_NoBlocking, but it isn't called on the client-end. If you then move through the corpses, it'll lag a lot. It feels terrible. And it's even worse if cl_ticsperupdate is set to 3.

Now, you can apparently work around this by adding a 1 tic frame before the one that calls A_NoBlocking, but I don't know if anyone is going to go through every affected monster in Futur War and do that anytime soon.

0002314: A_SkullPop actor seems to be client-sided or inherits flags it's not supposed to causing desyncs online

Tue, 19 May 2026 12:28:14 +0000

While investigating an issue with spectators and A_SkullPop actors I noticed that the actual actors seem to be client-sided only.

0002319: Corpses crushed by floors aren't removed after map resets

Tue, 19 May 2026 12:02:24 +0000

[quote=unknownna]I noticed another crush issue. I created a new example WAD. The floor has the same height as the ceiling. It is lowered by Floor_LowerByValue. A map reset crushes all the corpses on the floor, but the crushed actors aren't removed.[/quote]