Welcome to the ZDoom Forums!

Continued from 0003418: (3.1 alpha) Stuttering ingame There's currently some bugs fixed and readjustments being made to Zandronum's unlagged system, which required changing some time functions and make them similar to GZDoom. There was some stuttering caused by a bug which was fixed later, however ...

Continued from http://forum.zdoom.org/viewtopic.php?f=7&t=47454&p=804810 It needs to be adapted to 3D floor/midtexture combinations as well. thingz_spawnrespawn_09.wad 1. zdoom -iwad doom2.wad -file thingz_spawnrespawn_09.wad +sv_itemrespawn 1 +map map01 2. Go down to the chainguns on the leftmost ...

This also affects GZDoom's vid_brightness "Brightness" slider when setting it back to 0 in the middle of the slider.

When using the left arrow key to move a slider to its lowest value, it first sets the value to some different number like 7.45058e-10, then sets it properly to 0 when you use left arrow key again, so you have to use left arrow key one extra time when it's at 0 to really set it to 0. I noticed this ...

The number on the slider is not necessarily representative of the true value of the variable if it only shows one decimal when incrementing by 0.05, potentially leading to some confusion. I found these as I went through the menus: "Team Damage Scalar" in "Gameplay Options" "Prediction Leap Scale" in ...

For the AltFire issue, AmmoUse2 is 0 by default. I see, so you have to explicitly define "Weapon.AmmoUse1/2 1" as the engine assumes "Weapon.AmmoUse1/2 0" by default if omitted. As for the "Weapon.AmmoUse1/2 0" case, some mods such as Zombie Horde set these to 0 and use A_Jump* combined with A_Give ...

0002880: cl_noammoswitch switches to empty weapons if Weapon.AmmoUse is 0 or when AltFire state is present I was testing some mods and got confused wondering why the client was able to switch over to weapons without any ammo despite having cl_noammoswitch set to false. I investigated the issue ...

Confirmed to be working. Thanks a lot, Eruanna and Graf. Appreciate it, cheers!

Graf, would it be possible to at least have a text displayed somewhere in the error window that says "Generating crash report, please wait." or something like that? I think the average, casual user would find it very confusing to just see a bunch of text streaming down the window fast without any ...

Personally I never cared for "blood brightness" or blood_fade_scalar as the names always sounded very ambiguous to me. Something like pickupflash_intensity with a "pickup flash intensity" menu entry and damageflash/painflash_intensity with a "damage/pain flash intensity" menu entry would sound very ...

0000342: pickup_fade_scalar Since blood_fade_scalar exists, would it be possible to have a similar control for pick-up flashes? Zandronum has something called bood_fade_scalar that determines how intense the pain flash is displayed when receiving damage. I asked the Zandronum developers many yeas ...

Graf, several of the Zandronum developers are wondering whether you're going to improve the fix? Apparently it's not good enough for backporting in its current state. It took around 36 seconds for it to generate the report when crashing after having copy-pasted the command in the OP. They're not too ...

It took around 36 seconds for it to generate the report when crashing after having copy-pasted the command in the OP. That's the equivalence of having played for around 1.5-2 hours on a high-intensity Zandronum CTF server I think.

Ok, using zdoom-2.8pre-1669-gadd52d4.7z I was able to confirm that the issue has been resolved. However, it takes ages for it to generate an error report now if the console was full of stuff before the crash occurred. But I suppose it's fine for most cases though. It'll only take a while if it ...

Graf Zahl wrote:I'm waiting for confirmation now.

I'll need someone to supply me with a test build again. Or I could wait for the next build at DRD (which could take days).