UZDoom 5.0.0

[Delfino Furioso]

I started migrating to 5.0, here some (admittedly minor) issues I've found:
- the +LogFile command line parameter does not seem to work anymore => as a workaround I'm redirecting stdout/stderr to a file (I'm on windows)
- the hud_aspectscale cvar does not seems to have any effect, when hud_oldscale is true

[Boondorl]

For the log file, it now always creates a file in the same directory UZDoom was executed from (beginning with log-). This will be fixed at a later time but requires some internal reworking since it presented a security concern.

[phinet]

5.0.1 is now available with a number of minor bugfixes and additions:

---

• Added deh/bex support to file dropping in launcher

• Added missing support for NoPerPixelLighting to weapon models

• Added more banner options

• Allowed -pride to choose specific banner

• Fixed OOB string access in MODELDEF path parsing

• Fixed local pickups not working with dehacked items

• Fixed particle flag SPF_NO_XY_BILLBOARD being ignored

• Fixed visual issue with banner in light mode

• Improved some translations

It's available in the usual places:
https://github.com/UZDoom/UZDoom/releases/tag/5.0.1
https://zdoom.org/downloads

If you have the auto-upater enabled, the update should be coming your way soon.
It will be available in flathub as soon as possible.

[dargant06]

"The initial loading screen now takes longer to appear. This is purely visual and does not impact how long the engine takes to actually start."
Has this been fixed yet? Haven't using the new UzDoom yet, still using the one that came out last November.

[phinet]

Has this been fixed yet?

Not yet. We have a band-aid fix in mind. It should be resolved in the next patch.

[Doom64hunter]

The updater exe quite specifically takes a package and replaces another executable with the contents of said package. Now this for uzdoom is perfectly safe but under another context is the same thing a trojan does, and anti-virus signatures aren't smart enough to know the difference.

If this behaviour is merged into the main uzdoom executable instead and it replaces itself (you can't delete a running executable but you can rename it, even itself), this should resolve the detection as self-replacement should be less likely to trigger such detection.

To be clear it isn't a trojan and cannot be reliably used as a trojan, so you're safe.

Yeah eduke32 used to generate Windows Defender reports as well due to its version check. Defender loves to interpret this as a trojan (or similar) trying to phone home.

I think Microsoft offers a service to upload binaries for analysis to remove bad detections: https://www.microsoft.com/en-us/wdsi/filesubmission

Might be worth a try.