Increase engine limits in accordance to the new update

[fantoro]

Increase packet entity limit for compatibility with the 25th anniversary update's maps (Primarily rocket_frenzy, at least that's the only one that caught my attention so far) in accordance to the limit present in the 25th anniversary update's engine.

[fantoro]

Also I only now realized that the line about MAX_EDICTS in the 25th anniversary's changelog was actually about NUM_EDICTS since that one's set to 900 by default. Not sure if I should push a commit changing that one as well since it's technically configurable, though it seems like the update changed the default limit on the engine.
Pushing a commit to change it since I feel like it's probably better to stay in line with the new defaults than make server operators manually configure the limit.

[SergeyShorokhov]

Each mod overrides the num_edicts value in the <gamedir>/liblist.gam file

https://github.com/dreamstalker/rehlds/blob/ecfe8bb5fb7a8f82c13113ac10ef88461878d8fc/rehlds/engine/sys_dll.cpp#L837-L842

Perhaps this is what the developers of the update changed? (I haven't looked in the IDA)

[fantoro]

Each mod overrides the num_edicts value in the <gamedir>/liblist.gam file

https://github.com/dreamstalker/rehlds/blob/ecfe8bb5fb7a8f82c13113ac10ef88461878d8fc/rehlds/engine/sys_dll.cpp#L837-L842

Perhaps this is what the developers of the update changed? (I haven't looked in the IDA)

That's what I thought at first which is why I hadn't changed it before. Then I randomly decided to look into it again and I noticed that valve/liblist.gam doesn't use it* which is why I came to the conclusion that they probably changed the default value in the engine. The changelog kinda confirms that assumption imo since the changes are advertised as done for modders and the header does say "Engine Improvements".

* Contents of valve/liblist.gam found in my local installation of the 25th anniversary update:

// Valve Game Info file
//  These are key/value pairs.  Certain mods will use different settings.
//
game "Half-Life"
startmap "c0a0"
trainmap "t0a0"
mpentity "info_player_deathmatch"
gamedll "dlls\hl.dll"
gamedll_linux "dlls/hl.so"
gamedll_osx "dlls/hl.dylib"
secure "1"
type "singleplayer_only"
animated_title "1"
hd_background "1"

[SergeyShorokhov]

At the moment, when game clients have not updated and have an old version, this change can be critical and older versions of game clients will get critical errors.

safe point is here
https://github.com/dreamstalker/rehlds/blob/3f19bc1d3e254d9665893e93383487ba03d29f2a/rehlds/engine/sv_main.cpp#L4671-L4675

You can test it with CI binaries:
https://github.com/dreamstalker/rehlds/actions/runs/6957538650

[SergeyShorokhov]

Archiving until better times... (when will Valve fix their bugs in the update)

[StevenKal]

Need the engine be able to detect the client version (HL25...) & apply changes & limits in consequence.
But VALVe is boring at releasing butched updates not deeply tested, or/and, lack of infos & deeper changelog for programmers.

[dystopm]

Need the engine be able to detect the client version (HL25...) & apply changes & limits in consequence.

In this case everybody should upgrade their clients (Steam, maybe GSClient dev team also) and ReHLDS too, we cannot stick with the older versions if we want better features and tools for modding

[StevenKal]

When some recent clients are causing troubles because VALVe did not tested all well, or need deep changes in our client & server configs, etc., not everyone will like to update, neither have time or motivation for such, also knowing nowadays people on HL1 might no longer have same motivation than before (also the frequentation is now lowered than the past).
For example on server configs, when offsets, signatures, functions format & cie are fucked up on new updates (also if this is frequently updated & refucked up later), a lot of people will just prefer to stick to their old servers binaries & configs rather than waste their time updating, for benefits they might not judge necessary. Maybe on HL updating could worth, but most HL1 engine-based users & players are on CS, & from a moment we have the chance to have Re* projects as example, VALVe is probably not gonna release an update "2x better" than those, they have the possibility to upgrade "legally" both servers & clients binaries to make them tied automatically & publicly via updates (which is not the case with Re*, being server-side binaries with limited possibilites without a client updated to have more features), but not all worth.

I always thinked that trying to provide support for old versions, by detecting client's build is the best to avoid issues.
I did not tried neither checked their HL25 update, but did they added new CVar "game_version" or something like? I recall suggested such here.

[dystopm]

When some recent clients are causing troubles because VALVe did not tested all well, or need deep changes in our client & server configs, etc., not everyone will like to update, neither have time or motivation for such, also knowing nowadays people on HL1 might no longer have same motivation than before. For example on server configs, when offsets, signatures, functions format & cie are fucked up on new updates (also if this is frequently updated & refucked up later), a lot of people will just prefer to stick to their old servers binaries & configs rather than waste their time updating, for benefits they might not judge necessary. Maybe on HL updating could worth, but most HL1 users & players are on CS, & from a moment we have the chance to have Re* projects as example, VALVe is probably not gonna release an update 2x better than those, they have the possibility to upgrade "legally" both servers & clients binaries to make them tied automatically via updates, but not all worth.

I always thinked that tried to provide support for old versions, by detecting client's build is the best to avoid issues. I did not tried neither checked their HL25 update, but did they added new CVar "game_version" or something like? I recall suggested such here.

I agree with you. Thing is, if we want a way to make client show his version to the server engine, an update is required, so everybody should be forced to update their binaries. It's cyclical

[fantoro]

I don't really know GoldSrc code-wise that well, but before I looked into this my initial idea was to see if if the server can find any hint as to which version of the engine the client runs on and adjust accordingly. I ended up submitting the PR kind of as a last resort since the lower limit does end up making the experience worse on the new maps.

Since my PR got closed I've been trying to think of a way to detect if the client is running on the 25th anniversary update and think of detectable differences.

[StevenKal]

I agree with you. Thing is, if we want a way to make client show his version to the server engine, an update is required, so everybody should be forced to update their binaries. It's cyclical

Current CVar "sv_version" on the client can be queried by the engine (& parsed...), or the presence of new CVar(s) added after each version could be used as second tricky workaround, but unfortunately a minor "ping delay" until he replies (so not accessible at first "server contact"), also the fact the client can alter it (but usually the client will not think to trick it), while devs should make it unmodifiable/locked.
Setinfo can worth too (like for "cl_lw"...), but currently its length of 256 is limited...

Since my PR got closed I've been trying to think of a way to detect if the client is running on the 25th anniversary update and think of detectable differences.

Type "cvarlist log" on old build (on your client), then again on new build, use a text comparator like PSPad or else to check if there are new or removed CVars, etc., or query "sv_version" (& parse it), must be higher than 8684 for sure!

[fantoro]

Type "cvarlist log" on old build (on your client), then again on new build, use a text comparator like PSPad or else to check if there are new or removed CVars, etc., or query "sv_version" (& parse it), must be higher than 8684 for sure!

Is there a way for the server to query CVars on the client though? I figured there wasn't since it seems like the CVars that the server needs are put in userinfo.

EDIT: sorry for the stupid question, just found it lol

[StevenKal]

The engine can obviously does it, but the value must be stored, so either add a new member on an existing or a new structure, either a new global variable.
Could be implemented on "client_t" but this will break it (at least its size if put in the end), or easier, on "CGameClient".

[dystopm]

Type "cvarlist log" on old build (on your client), then again on new build, use a text comparator like PSPad or else to check if there are new or removed CVars, etc., or query "sv_version" (& parse it), must be higher than 8684 for sure!

Is there a way for the server to query CVars on the client though? I figured there wasn't since it seems like the CVars that the server needs are put in userinfo.

EDIT: sorry for the stupid question, just found it lol

pfnCvarValue, but

but unfortunately a minor "ping delay" until he replies (so not accessible at first "server contact")

[fantoro]

pfnCvarValue, but

but unfortunately a minor "ping delay" until he replies (so not accessible at first "server contact")

I think a slight delay is better than nothing atp tbh.

Also thank you!

[dystopm]

pfnCvarValue, but

but unfortunately a minor "ping delay" until he replies (so not accessible at first "server contact")

I think a slight delay is better than nothing atp tbh.

Also thank you!

We might wait to see an update from Valve first, this is breaking everything

[fantoro]

We might wait to see an update from Valve first, this is breaking everything

I mean I guess I might try seeing if I can get this idea to work anyways in case Valve takes their time maybe.

I'm not gonna push anything like that unless Valve takes too long.

[StevenKal]

I think a slight delay is better than nothing atp tbh.

Also thank you!

Yeah if we query it from client connection, we will have the value before it enters the game (pfnPutInServer), except for a player being on mars!, so this should work fine for our needs & cover most of the areas where only in-game codes are used.

But yeah, better wait for a more stable/definitive update by VALVe, but we do not know what are their plans, if this is just a minor one for 25th and if their current ongoing work is just about to fix the issues they brought on it, or if they magically plan to do more, then update all HL1 games in a mass with a bunch of changes & new features.

[fantoro]

Based on the last update (improving mod support and updating HLDS) it seems like their plan is to move everything over to the new engine version and consider the older versions unsupported. I have a feeling like it might just be smarter to make an optional CVar that raises the limit if enabled for now and if the community ends up adopting we should make it the default. I feel like having it as an optional CVar for now won't mess with people's existing configs and will allow owners to host newer maps without issues.

Also speaking of the last update, what should be done about the steam_api changes? Seems like they made HLDS use the safe versions of the calls and trying to run ReHLDS on an installation with updated libraries fails because of it.

Also I'd like to apologize if this is not the best place to discuss the changes in general and I'm sorry for my lack of experience (I'm realizing that I'm not the best person to work on this and I don't wanna be too much of an annoyance for the contributors and maintainers).

[mlibre2]

apparently this time they are doing "private" tests before releasing future updates

[FEDERICOMB96]

CS and CS:CZ updated 2h ago to support the HL25th engine updates. Finally.
https://store.steampowered.com/news/app/10/view/3889483908318472024

I understand that implementing these changes will make clients with older versions incompatible. However, I also understand that it is necessary if we want better features and tools for modding. I would have liked them to expand the limits of the sounds/models/sprites/etc precache as well. Perhaps they forgot (?