[GoldSrc][Feature Request][Dedicated Server] Increase player slots > 32.

[MasteRs-git]

Increase player slots count more than 32 if it's technically possible. I think GoldSrc engine can support more than 32 players.

[di57inct]

How come I didn't think about this?
Really nice job posting it.

[911r0ck]

That will break almost every Amx Plugins .... They have a limit of 32 players :|
This is a good idea but then amx plugins have to get updated (almost all)

[txdv]

Use dynamic arrays!
And it would need a simple recompilation with a constant set to a different size.

[xPaw]

GoldSource will have to be partially rewritten to support more than 32 players, as there are a lot of places where it relies on maxplayers to be 32. That would be very breaking change, and that's out of scope of this update.

[txdv]

Out of scope of this update means that it is never going to happen?

[xPaw]

Pretty much.

[MasteRs-git]

Well you aren't forced to use more than 32 slots by the default, so it won't break anything for ordinary server operators. Valve can enable support if it is technically possible. This have to be optitonal paramater if it breaks something.

[di57inct]

Let's just wait and see what the devs have to say.

[MrSchism]

The thing is that it would require a rewrite which could potentially break the installs. Just because you aren't using the feature doesn't mean that it's very inclusion doesn't break something.

On an aside, 32 players is quite a few, plus it's a round number (100000).

[Gr1mRe4pEr]

Although I do like the idea of an uber deathmatch with 64 players BF1942 style, this would also require a re-build of many maps for different games to prevent telefragging. It is a big big job.

[m3tAf0x]

good idea but, almost all the maps
have only 32 player spawns

[LevShisterov]

Spawns is a least problem with this.

[MrSchism]

It'd create a unique issue for players playing on older setups.

Imagine logging onto a server and they've updated the engine by one or two bit-places. That's a max of 64 or 128 people. Lower ram/ weak processor builds would function like garbage and could potentially crash clients a bunch of clients and maybe even the server if... say... 50-100 people decided to all throw smoke at the same time.

It's never been tested with the engine and could very likely occur.

[MasteRs-git]

Well, if it is technically possible to enable support for more than 32 players you could test it for example in private beta. About smoke, Valve should fully rewrite smoke system, because even on high-end PCs there are big FPS drops. For example I am using GTX 670 and even I can get fps below 30. Smoke should be fixed. This isn't impossible. Support for more than 32 players also isn't impossible.

[ghost]

@MasteRs-git It is not about the smoke, MSAA causes fps drops. Post your system specs in #241, Valve ignores the problem...

[MasteRs-git]

@Maxkorz Yes, I know, but that isn't the biggest problem, smoke system what Valve use currently isn't well optimized, Valve should re-write it or at least optimize it. By the way entire GoldSrc should be optimized, there are alot of performance issues which cause high FPS drops, lags etc.

System specs:
CPU: i7 3770k
GPU: GTX 670 2GB
RAM: 16GB DDR3
GPU DRIVERS: 314.07
OS: Windows Server 2012 Standard x64

[ghost]

I'm fine with a lot less system specs :p

16GB o.O do you even break 20% usage?

[theAsmodai]

Increasing the number of slots is much more difficult than changing the maxplayers constant. It will also require some changes in client-server exchange protocol.

[MasteRs-git]

Any official response from Valve about this feature?

[MrSchism]

Any official response from Valve about this feature?

It was assigned to triage-valve.

[MasteRs-git]

@MrSchism I see. Are triage-valve or alfred-valve going to comment this issue? Well, a week is enough time to response.

[alfred-valve]

It is a feature request and has been assigned, we are focusing on bug fixes and stabilization right now. Right now I am leaning towards not doing this work, but if the time fairy finds me some free time perhaps...

[Gr1mRe4pEr]

Aww, I love it! @alfred-valve I too have a problem finding the magical time fairy with my work. If this request gets implemented, I know the time fairy exists and I will be a true believer!

[MasteRs-git]

@alfred-valve At the moment only you Alfred are working with HL1 coding? Only one developer?
Sorry for off-topic.

[SamVanheer]

Just noting for future reference that game code relies on the maximum number of players being 32. Tricks like storing player lists in 32 bit integers (sometimes in entvars_t) will not scale at all, so this is almost impossible without rewriting much of the game's code. Every game and mod would need an update to support the increased limit.

[uniarch]

@mikela-valve can it make its way to future release? I think this could be a great upgrade to possibilities along with #12
some guy even tried to support it by himself

[Maxi605]

@mikela-valve can it make its way to future release? I think this could be a great upgrade to possibilities along with #12
some guy even tried to support it by himself

unlikely, way too big of an update for something that isn't really needed.

[afwn90cj93201nixr2e1re]

Tricks like storing player lists in 32 bit integers (sometimes in entvars_t) will not scale at all, so this is almost impossible without rewriting much of the game's code

Also, in a simple language, we gonna possible (if we gonna use true 64 impl) loose 32 bit compatibility.

[SamVanheer]

Tricks like storing player lists in 32 bit integers (sometimes in entvars_t) will not scale at all, so this is almost impossible without rewriting much of the game's code

Also, in a simple language, we gonna loose 32 bit compatibility.

That has nothing to do with this.

[afwn90cj93201nixr2e1re]

? Int 32 replacing to 64 which can be stored in float like in js or in int64.

Check what i was replied exactly. Its related to bitwise only.

[SamVanheer]

? Int 32 replacing to 64 which can be stored in float like in js or in int64.

Check what i was replied exactly. Its related to bitwise only.

If it's necessary to store boolean variables for every player in a stack allocated buffer then a bitset is the best solution. The bitset can use a 64 bit int underneath if the implementation deems it necessary.

In any case it will not affect 32 bit compatibility. 64 bit types can be used in 32 bit programs.

[afwn90cj93201nixr2e1re]

But that's not truly 64 bits. So, no cpu optimization and other stuff, as i said above: like in js.

[SamVanheer]

But that's not truly 64 bits. So, no cpu optimization and other stuff, as i said above: like in js.

That has nothing to do with the problems that concern this issue.

[afwn90cj93201nixr2e1re]

Like as our last posts at all.