ZDoom

Yep, it was a single line of code.

Probably by a tiny error in thousands of lines of code affecting a game mode that the devs don't play very often?

Once I'm back from holiday I'll check the most modern build and see if it fixed the issues I was experiencing.

On the other hand, how did this bug occurred in 3.5.1 in the first place? It's not only about bots. I can't even changemap in multiplayer mode, or even change gameplay settings.

In fact, if the issue is not reported, make sure to report it. If it's already reported, please add as many details as you can.

What you see at a given moment in Dev Builds is always going to be a candidate for whatever release may be following them.

If you think that stable versions are built from some different codebase that magically solves all issues then you are wrong.
The next major release would be exactly the same as the last devbuild with exception of its version number.

I have to roll back to 3.5.0 and wait for more stable version. I'm having issues with dev builds.

_mental_ wrote:This was fixed in 5b7d3c9.

Thank you for the feedback and a big thanks to the Devs for keeping this port alive!
I will discard the demonstration video as it is unnecessary presently.

This was fixed in 5b7d3c9.

Is there any other way to add bots to the game?

AFAIK it's fixed in recent devbuilds.

PixelWAD wrote:I have the same issue. Is there a workaround or I need to reverse to previous version?

I am unaware of a workaround, but if you need that functionality - merely roll back to GZDoom 3.5.0 until the issue is resolved.

I have the same issue. Is there a workaround or I need to reverse to previous version?

The difference is, now player_t explicitly initializes its settings_controller member variable, the old implementation did not. Apparently there are some dirty side effects at work here which depend on the value not getting cleared on a player reset. A player reset has always been supposed to be complete, so I had changed the inline initialization to set all fields, including the ones that were left in the old version. In this case it apparently just hid a bug in the implementation that, from the looks of it, does not properly set up this thing when a player gets reset.

Haven't checked but i think the problem was introduced in "- got rid of FNameNoInit and made the default constructor of FName non-initializing."

This bug is easy to confirm, just did in 3.5.1. I unfortunately don't have the time to look into it but I suspect a variable init got broken or omitted somewhere.