This will output the complete list of all dynamic entities in the map. *Todo: does it really?*
I did check this and it seems it only gives the active dynamic entities. Disabled ones dont show up on the list. However, they are still counted in that list.
To check the hidden ones you can use find_ent and find_ent_index. The normal finding will show all objects where the name or entity type matches. The index will show you the ent on the index.
Some player objects like the weapons you wear show up on it also. Some animated objects also only show up at limited parts so best is to check the index after the last one in the list with find_ent_index and repeat it until you realy hit the last.
I havent checked if in runtime other player do also give all their weapon entities to that list. If thats the case then testing the limit will become a pain at some moment.
func_detail
Any func_detail in hammer is not a dynamic entity ingame. You can have more than 2048 func_details in your map in hammer. Also, there is no difference if u make some big multibrush object a single func_detail or each brush of it. It's the same for engine. Why? During the BSP stage of compile, vbsp analyze the vmf and mark func_detail brushes that they don't block visibility. Then it generates portal file (*.prt). After that, all func_detail information and entities are discarded and not used in VIS or RAD. *Todo: does it really? DX levels * So there is no need trying to merge all your func_details in a single entity to "reduce number of them".
They are static as long as you dont mess with the dx levels (if you do i dont know if they will become dynamic though).
There is a simple trick to see if an entity is dynamic. If it has outputs or inputs other than the onuser/fireuser ones then they are dynamic. Same as when they are animated but other than that dont have any actions.
When on a static object you trigger the onuser objects then it will become dynamic if im right.
Another thing, entdata was something for HL2 to see if you are nearing the memory limit for the minimum requirements. As those are outdated that value isnt realy usefull.
Are env_sprites dynamic entities?
You can turn them on or off so yes.
Some others that are important for people to know that they are dynamic:
func_areaportal
func_areaportalwindow
func_brush
func_door
func_illusionary
func_lod
func_nobuild
func_occluder
func_physbox
func_regenerate
func_respawnroom
func_respawnroomvisualizer
func_tracktrain
ambient_generic
game_round_win
info_observer_point
info_player_teamspawn(so per spawn there is no use to exceed 16 when you are nearing it)
item_ammopack_small
item_ammopack_medium
item_ammopack_full
item_healthkit_small
item_healthkit_medium
item_healthkit_full
logic_branch
logic_case
logic_relay
math_counter
math_remap
path_corner
path_track
phys_constraint
team_control_point
team_control_point_round
team_control_point_master
team_train_watcher
team_round_timer
filter_*
trigger_*
+any prop except prop_static and prop_detail (which you shouldnt create anyway)
+any payload cart entity not listed above
Overlays and decals are static in the same way as lights. give them a name and they become dynamic.
Further, i havent checked the multiplayer variants of the prop_physics and func_physbox. I think they are dynamic but as they dont use any server sided actions they might not be. They are dynamic for the player that sees them thats what i know for sure though. Quite bad as people testing the map on lower settings can prevent crashes happening...
And most important. with brush entities that can be merged it should be done to reduce the dynamics.
EDIT: updated the list to have a bigged entity list. All filters, triggers and props are merged. And they are alphabetical now (and if i made a mistake mention it)