Closed Ronin4862 closed 2 years ago
Probably not - you can increase their lifetime in client.dll (I don't think there is a cvar) but I assume the engine has a fixed sized list of temporary entities for the client and so there is probably a limit.
Probably not - you can increase their lifetime in client.dll (I don't think there is a cvar) but I assume the engine has a fixed sized list of temporary entities for the client and so there is probably a limit.
Ok! That's good enough. Any pointers on how to increase their lifetime in client.dll? I'm new at this and try to learn as I go on. Thanks! :)
In ev_hldm.cpp in the client.dll project there is an EV_EjectBrass function which calls gEngfuncs.pEfxAPI->R_TempModel - the fourth parameter is lifetime so you can increase it from 2.5 to whatever you want.
In ev_hldm.cpp in the client.dll project there is an EV_EjectBrass function which calls gEngfuncs.pEfxAPI->R_TempModel - the fourth parameter is lifetime so you can increase it from 2.5 to whatever you want.
Thank you Tschumann! I'll check it out later when I have some free time. Some noob questions:
Thank you again for the detailed replies!
In ev_hldm.cpp in the client.dll project there is an EV_EjectBrass function which calls gEngfuncs.pEfxAPI->R_TempModel - the fourth parameter is lifetime so you can increase it from 2.5 to whatever you want.
Mission accomplished! P.S. The *.cpp you want to edit is ev_common.cpp not ev_hldm.cpp. Thank you Tschumann!
Hey, looks like you figured out the SDK and Visual Studio. I think if Steam releases an update to Half-Life's client.dll it will overwrite your change, otherwise it should stay.
Hey, looks like you figured out the SDK and Visual Studio. I think if Steam releases an update to Half-Life's client.dll it will overwrite your change, otherwise it should stay.
I tried VS Express 2010 and 2013. I noticed that the built client.dll and hl.dll differ in size between these versions (they are larger in 2013). Any idea why? Afterall is the same code (I use halflife-master.zip). Are there performance issues with 2013? Should I stick with 2010? Thanks!
The different versions ship with different compilers - the 2013 compiler will no doubt support newer C++ features and have improvements and bug fixes etc. I doubt there will be any significant performance differences between the code they generate but you can configure the solution to prefer faster and larger code or slower and smaller code. Again, there is unlikely to be any noticeable difference as Half-Life would not max out modern hardware.
The different versions ship with different compilers - the 2013 compiler will no doubt support newer C++ features and have improvements and bug fixes etc. I doubt there will be any significant performance differences between the code they generate but you can configure the solution to prefer faster and larger code or slower and smaller code. Again, there is unlikely to be any noticeable difference as Half-Life would not max out modern hardware.
Are you talking about Debug vs Release? I see with Debug, the dlls are noticeably larger. Are you saying that Debug is faster than Release?
No debug is slower than release - I mean the compiler is like any program - they update it from year to year so while the logic generated by 2010 and 2013 will be identical, the code generated by 2013 will probably have small speed improvements etc (though nothing noticeable).
No debug is slower than release - I mean the compiler is like any program - they update it from year to year so while the logic generated by 2010 and 2013 will be identical, the code generated by 2013 will probably have small speed improvements etc (though nothing noticeable).
Hmmm...I played today with Solokiller's halflife-updated SDK and VS Comunity 2019. When installing, I made sure to select Desktop development with C++ in the workloads section. After installation I've set Windows 10 SDK (latest version) and MSVC v142. I could build the solution without a hitch BUT the following issue appeared. If RELEASE mode was selected (the dlls were smaller), the game started and ran well but when I tried to quit either through the menu or console->quit, the game would either take a few seconds to exit or lock (i.e. circular cursor, not responding, alt+f4 to force exit). In the DEBUG mode I never had any issues. The game exits instantly.
Hm, strange - when it hangs you could try attaching the debugger and see what is happening? I think debug does a few things differently so that would explain why you don't have issues there, but I'm not sure what would be causing it to hang.
In ev_hldm.cpp in the client.dll project there is an EV_EjectBrass function which calls gEngfuncs.pEfxAPI->R_TempModel - the fourth parameter is lifetime so you can increase it from 2.5 to whatever you want.
I've noticed an issue. I modified 2.5 to 99. Everything is ok except when a shell lands on an incline or, for the lack of a better word, wants to keep falling. In this case it loops its "soundtype" until 99 seconds expire. If the shell falls on a level ground it "sounds" until the shell stops moving, which is a few seconds.
Any ideas?
Hm not sure - probably a limitation in the physics engine.
Can the ejected shells be made to remain indefinitely after they fall on the ground? They normally vanish right away. I'm talking here about the pistol, MP5, shotgun and crossbow (I consider the darts shells as well). Thanks!