tweak(client): Show additional information for selected objects while observing

[Stubbjax]

This change expands object selection information for observers. While a player is selected, the following information is now displayed for selected objects:

• Group numbers / formations
• Ammo
• Passengers / occupants
• Car bombs
• Rally points

[xezon]

I expect there will be a lot more changes necessary to get the full observer experience. Are there plans to expand this more?

[Stubbjax]

I expect there will be a lot more changes necessary to get the full observer experience. Are there plans to expand this more?

That is true, though they are likely better off as separate changes as they are more involved and require different solutions. The selection logic especially needs looking at (e.g. player relationship comparisons still use the local player when observing a player).

[xezon]

Prefer to not use returns in the middle of functions, because it makes logic eventually more difficult to follow along

Can simplify to:

if (Player* player = TheControlBar->getCurrentlyViewedPlayer())
{
	if (TheGlobalData->m_timeOfDay == TIME_OF_DAY_NIGHT)
		marker->setIndicatorColor( player->getPlayerNightColor() );
	else
		marker->setIndicatorColor( player->getPlayerColor() );
}

[Stubbjax]

I typically try to draw the line at three levels of nesting. The end of the loc == NULL block should really be a return instead of an else. I'm also wary of putting assignments within conditions, which can be useful in specific situations (i.e. reducing loop verbosity), but is otherwise generally discouraged. I'll give the method a readability refactor.

[xezon]

No need to be discouraged to put assignments into conditions. In modern C++ this is even made explicit with if (expr; cond) syntax. The benefit of doing that is the smaller scope for the pointer, which avoids misuse at compile time.

The confusion with returns, other than those on early outs or final return, can make the flow of the function more difficult to follow, depeneding on the overall complexity of the function. Early returns also put a strict requirement on use of RAII, because otherwise resources may be left leaking. Furthermore, any trailing critical logic may be left uncalled. Early returns are a very common source of error.