Avoid intro camera switching when only 1 trigger_camera available

[dystopm]

This PR omits the logic that changes the player's introduction camera to it (the same), which forces a rather annoying change of angles because there is no behavior that verifies if there is more than just one trigger_camera.

• m_bMapHasCameras member from CSGameRules changed type to int, which is the same as BOOL internally, and it counts the number of trigger_camera entities in the map.
  • It is cached once on ClientPutInServer.
  • Default value in the construction of the CSGameRules class is now -1 (ToDo: I don't think I need to enclose that with the fixes macro).
• m_fIntroCamTime is assigned to 0.0 if there's just only one trigger_camera, so it wont force an unnecesary camera updating every 6 seconds. A simple condition was added in the related thinking function JoiningThink.
• Extra: code cleaning inside CheckLevelInitialized on the counting of info_player_* entities using the added function UTIL_CountEntities.

[fl0werD]

m_bMapHasCameras is unused. You can check if the next camera is available and that’s it.

[justgo97]

A better spot than ClientPutInServer to cache the number of trigger_camera would be CheckMapConditions.

[dystopm]

m_bMapHasCameras is unused. You can check if the next camera is available and that’s it.

Well I think I gave it one 😄

A better spot than ClientPutInServer to cache the number of trigger_camera would be CheckMapConditions.

I mean, the caching isn't an issue, only in the fact a modder is dynamically changing trigger_cameras in world, which tbh is strange. Any suggestions?

[justgo97]

I mean, the caching isn't an issue, only in the fact a modder is dynamically changing trigger_cameras in world, which tbh is strange. Any suggestions?

I think it's up to the modder to also modify m_bMapHasCameras when they alter trigger_cameras in world, recaching the value when a trigger_camera is created/destroyed is also an option, but without that it's fine too.