Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

num_edicts command line parameter is not clamped #1777

Open
SamVanheer opened this issue Feb 14, 2017 · 10 comments
Open

num_edicts command line parameter is not clamped #1777

SamVanheer opened this issue Feb 14, 2017 · 10 comments

Comments

@SamVanheer
Copy link

SamVanheer commented Feb 14, 2017

The num_edicts command line parameter (value can also be set with liblist.gam "edicts" value) is not clamped to the maximum supported value, which is 2048.
If more entities than that are created the game will crash due to the networking code assuming no entity index is greater than 2047, since it uses an 11 bit bit mask (2^11 is 2048).
SV_WriteDeltaHeader and CL_ParseDeltaHeader are where the index is written and read, respectively. SV_BuildSoundMsg and SV_CreateBaseline also reference the number. CL_ParseEvent also appears to do so, not sure.

The function COM_EntsForPlayerSlots (engine repository root/engine/common.c, starts around line 2948) is responsible for calculating the number of edicts to allocate and use.

Note for modders: delta.lst must be updated to match this limit for any fields that store entity indices. (Would be nice if delta.lst were obsolete though)

@tschumann
Copy link

I remember reading on hlcoders a while ago that the maximum was 4096 but I don't remember what they based that on.
In delta.lst is the third argument to DEFINE_DELTA the number of bits? I guess it's just a matter of updating all the calls whose first argument is an edict_t* in the code.

@SamVanheer
Copy link
Author

I found the same statement here: #75

If you go above 2048 entities it will corrupt the heap. I fixed that issue for Sven Co-op.

The third parameter is the number of bits, the fourth is a multiplier.

delta.lst should be updated if you change engine limits at all, since there are a number of fields that rely on those limits.

@tschumann
Copy link

@SamVanheer
Copy link
Author

It premultiplies the value so you can network fractional values in floating point variables: https://github.com/dreamstalker/rehlds/blob/5c34ee85eab6c679a91bb0fa0b2f83fc1c6a404c/rehlds/engine/delta.cpp#L637

You can use it for other types as well but it's most common with floats. Sending floats as integers saves bandwidth because you're only sending the relevant bits; you can skip sending the exponent.

@pcenthusiast92
Copy link

@SamVanheer as developer or tester, can you do an analyze about Counter strike 1.6 the game has become unplayable, sluggish, stuttering etc etc even at 100fps stable... :(

@SamVanheer
Copy link
Author

@Cloudhaze unfortunately i haven't experienced those issues myself. Can you link me to the issues that describe that? Maybe i can find the cause in some other way.

@pcenthusiast92
Copy link

Thank so much for reading this commentary, hope you can read the whole commentary, and i apologies for my poor English

@SamVanheer , thanks for answer, but yeah is something weird, because i remember in 2009 game was perfectly smooth, when doing bunny jumps, or shooting to enemy, everything was so playable, till 2011-2013 that game started to feel weird, like hard to jump, not smooth at all, visual lag, even at 100fps, then valve at early 2013 update the game, adding some new features, commands, that make the rcoil of weapons, kinda weird...

but to be honest there are a couple of threads open in Github about half-life rcoill patterns, movement issues, choppyness. and so on. And i was wondering, if you can give me some tips or tell me what computers are optimized in order to play in half life engine 1? because i feel like now those old games from 2000 like counter strike 1.6 half life, are like those old games like (pitfall) that won't run perfectly in windows 7 or 8+++, so maybe Counter strike 1.6 is not development anymore for OS like windows 7+ ? or pc intels from 2009? and tis game perform better in old Amd anthlon ? or old intel?

I really don't know what to do, the game feels so slugglish :/
I've tried to underclock/overclocking without much experience, also by changing bios settings
etc etc, was wondering if you can help or guidance me to properly cfg? a little bit, or just go to Github forums and do a research about half life 1 and cs 1.6 not smooth, there a bunch of topics heheh
Please developer help us :D

PC SPECS:
motherboard: h55m-e33
psu: Thermaltake thoughpower 775w
ram: Corsair dominator dual channel 2gb x2 cmd4gx3m2a1600c8
monitor: Syncmaster t200g 2ms 16080x1050 60hz
case: V9 thermaltake (sometimes i get hissing sound in front panel audio-green jack

So maybe is my motherboard that has something with the (CPU PHASE CONTROL) ? in bios option are settings to put (auto or off) also my motherboard has some Overclocking switch, ive tried to swap or changes, but game perform same... , also i've notice sometimes at 2-3 am, my pc performs betters i dont know if because electricity get better? but is so weird

Thanks for read my commentary, hope you can do some research, also I've notice something weird about
num_edicts <-- if set or change num_edicts in half life or counter strike 1.6 steam parameters, rcoil performs different :O

@SamVanheer
Copy link
Author

Changing the number of edicts could cause changes in how the game handles logic in places due to having to iterate over a larger number of entities. Even if the actual number of entities in existence doesn't change it will add some additional overhead. It also affects memory allocation a bit, but i doubt that makes any difference.

If the game really is acting differently then it's probably related to either networking settings or changes made to the game (like the 2013 changes) that caused the problems.

I have noticed some animation issues on the client side when using weapon prediction, if you have enough latency then it just skips over events and doesn't play the animations. I wasn't able to pinpoint the cause of that, it seems to be in the engine.
It's probably caused by prediction only handling up to 64 frames, so higher latency means some frames are lost. It rather defeats the purpose of having prediction when it can't actually predict weapons properly though.

@pcenthusiast92
Copy link

pcenthusiast92 commented Feb 19, 2017

@SamVanheer So mr Sam according to you, what cvars did yo use, to reproduce this problem? cl_lw, cl_lc ? and whats the solution to this problem, whats the latency considered? or rates considered in order to play without skipping frames even at 100fps ?

And what is the number of editcs that shall we use? 500, 900, 4096?

and what about this (It's probably caused by prediction only handling up to 64 frames,)
how can i reproduce the error?
Thanks alot, i really want to keep reproducing these errror, and find a way to fix all of them, with your help, or others people help, thanks again for your attention.

@SamVanheer
Copy link
Author

@mikela-valve This could cause clients to experience memory corruption if the code that parses entity updates uses the wrong entity index. It should be easy to fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants