I'm getting random crashes in StudioRenderer.dll. It happens in both release and debug. I can go days without an issue and it can happen several times in a row. Let me know if anyone else is having this problem.

mapbase-source/source-sdk-2013#69

When playing on dm_steamlab against resistance NPCs I pretty consistently get the game to hang after a couple of seconds just standing around.
When attaching a debugger, it seems an infinite loop is responsible for that. I traced the problem down to a potentially uninitialized variable. It does get conditionally initialized in MoveCalcDirect(), but it seems not for the path I'm encountering.
It works (as in doesn't loop infinitely) if one just initializes the variable to 0 in line 328, though I'm not sure about the implications - which is why I also didn't open a PR to "fix" this and chose to open this issue instead.

As the title says, it would be good that the system of custom player models was more dynamic, I explain, currently the system only looks for models that are in "models/player/playermodels" The problem obviously lies if you want to distribute your model in a folder because the current system does not review the folder in question and do not precache it by using it very possible crash game when using it (as with the VGUI of model selection so you should use the console if or if) and like the system of voices to The player would be good to be applied this formula (something similar to Obsidian Conflict but that this can use custom voices)

This was closed after I renamed the mapbase branch.

It seems that this looping through the players is occurring for every spawnlist entry, but I'm not sure what this is trying to do? It seems to be trying to the maximum level and deciding whether to spawn a particular entry at the same time? Is the spawn level for an entry supposed to be based on the maximum level?

The additional damage-types overflow the 32-bit integer, since DMG_LASTGENERICFLAG == DMG_BUCKSHOT == 1<<29 and we're going 4 more shifts beyond that (DMG_KNOCKBACK == DMG_LASTGENERICFLAG<<3 == 1<<32 and DMG_KICK == DMG_LASTGENERICFLAG<<4 == 1<<33), whereas only up to 2 (up to 1<<31) are possible with a 32-bit int.

I suppose it'd be possible to change the damage-type in to an int64_t, though that change may be a bit iffy to properly carry out throughout the code-base. Perhaps it's possible to reduce the number damage-types back down to 32 in some manner.
Note that damage-types up to DMG_REMOVEONRAGDOLL are normally available for mappers through trigger_hurt.

I have not checked how this issue actually presents itself in-game. Strictly speaking, this is undefined behavior. I would have assumed that practically this would just define these constants to 0, though that'd make these flags useless/"inactive" and I assume such missing behavior would have been noticeable.

mapbase-source/source-sdk-2013#5
mapbase-source/source-sdk-2013#21

ValveSoftware/source-sdk-2013#436
https://github.com/FIREFIGHT-RELOADED/source-sdk-2013-ce
https://github.com/FIREFIGHT-RELOADED/source-shader-editor

https://github.com/ValveSoftware/source-sdk-2013/pulls

The thumb, the box thing you can scroll up and down with, is not visible in the shop. I had change one line in ClientScheme.res. At least I think that's what I changed. I can't seem to attach mine, but I believe the line looks like:
ScrollBarSlider.FgColor "Blank"
I switched that to SMODNormal.

mapbase-source/source-sdk-2013#63
mapbase-source/source-sdk-2013#36
mapbase-source/source-sdk-2013#54
mapbase-source/source-sdk-2013#56

After debugging, this is returned

Thread 1 "fr_linux" received signal SIGSEGV, Segmentation fault. HashInt (n=-1) at /projects/FIREFIGHT-RELOADED-src-sdk-2013/sp/src/tier1/generichash.cpp:151 151 even = g_nRandomValues[odd ^ ((n >> 8) & 0xff)]; (gdb) quit

from CActivityToSequenceMapping. Cannot find the cause.

Current issues:

• Death Notice Enemy Names are missing (in console and on the Death Notice itself)
• Wrong/large death notice icon (should be the skull icon like the Windows version, not the main focus but still a good mention.)
• Missing shop item title text
• Missing shop button text
• Reward item name showing up as (null)

I feel the reason why this isn't happening is that the byte size for all of these char values is too low or high for Linux. Will need to experiment with ways to fix this.

Throwing knives are infinite and powerful. Two possible solutions:

Knife is singular

• Will thrown knives be cleaned up with other items lying about?
• Need to make sure knives are not cleaned up when embedded in any entities that are cleaned up.
• Can be collected again.
• More realistic, but more complicated to implement.

Knife has ammo

• Might be recollectable, but not as big of a deal.
• Can buy/collect more knives.
• Don't worry about cleaning up knives when embedded in entities that are cleaned up.
• Less realistic, but easier to implement.

Not high on my list, but I would like to tackle this at some point. Any input would be appreciated.

I reworked the layouts with the following changes:
o Raised up the SuitPower panel which was overlapping some panels below it.
o Shrunk the HudHistory panel to not overlap the ammo at the bottom or death messages at the top.
This file isn't in the repo so I will attach it.
HudLayout.zip