Configurable 'emit point' for radar

[Google_Frog]

Radar currently is emitted from a unit at a certain hard coded height above the ground. It would be nice if this could be configured.

The most noticeable example is flying radar sources. They still do the terrain blocking radar calculations from ground level instead of high in the air, this looks pretty silly. I would be happy if just this was fixed.

[Beherith]

I wish to help you in this, so I did some digging in the engine (cant compile, not at main PC)

in RadarHandler.cpp:

Code: Select all

void CRadarHandler::MoveUnit(CUnit* unit)
{
	int2 newPos;
	newPos.x = (int) (unit->pos.x * invRadarDiv);
	newPos.y = (int) (unit->pos.z * invRadarDiv);

	if (!unit->hasRadarPos ||
		(newPos.x != unit->oldRadarPos.x) ||
	    (newPos.y != unit->oldRadarPos.y)) {
		RemoveUnit(unit);
		SCOPED_TIMER("Radar");
		if (unit->jammerRadius) {
			jammerMaps[unit->allyteam].AddMapArea(newPos, unit->jammerRadius, 1);
			commonJammerMap.AddMapArea(newPos, unit->jammerRadius, 1);
		}
		if (unit->sonarJamRadius) {
#ifdef SONAR_JAMMER_MAPS
			sonarJammerMaps[unit->allyteam].AddMapArea(newPos, unit->sonarJamRadius, 1);
#endif
			commonSonarJammerMap.AddMapArea(newPos, unit->sonarJamRadius, 1);
		}
		if (unit->radarRadius) {
			airRadarMaps[unit->allyteam].AddMapArea(newPos, unit->radarRadius, 1);
			if (!circularRadar) {
				radarAlgo.LosAdd(newPos, unit->radarRadius, unit->model->height, unit->radarSquares);
				radarMaps[unit->allyteam].AddMapSquares(unit->radarSquares, 1);
			}
		}
		if (unit->sonarRadius) {
			sonarMaps[unit->allyteam].AddMapArea(newPos, unit->sonarRadius, 1);
		}
		if (unit->seismicRadius) {
			seismicMaps[unit->allyteam].AddMapArea(newPos, unit->seismicRadius, 1);
		}
		unit->oldRadarPos = newPos;
		unit->hasRadarPos = true;
	}
}

Seems like adding unit height to

Code: Select all

radarAlgo.LosAdd(newPos, unit->radarRadius, unit->model->height, unit->radarSquares);

the model height defined here could offer a solution. Please ignore this if i'm thinkin' it rong.

[Google_Frog]

Well it is important to keep the default height unchanged so noone has to go through their games and change everything. Linking it to model height is pretty silly so I'd prefer a unitdef tag that controls the vertical offset of radar relative to the centre of the unit (the white dot in debug view, idk the technical name). If this offset value is not set it should default to whatever offset will replicate the current behaviour for things on the ground.

Radar sources when off the ground still have their radar centred on the ground. This seems like a real bug so I don't think anyone would mind if it was fixed.

radarPlane.gif (1.88 MiB) Viewed 1915 times

[Forboding Angel]

Well google, considering that radar even in ba is all of what 4 or 5 units? I would say it would be worth it. I would much like to have this be configurable however, imo a tag to define the radar height would be infinitely better (However, imo if the tag isn't defined old behavior should take over (for radar planes etc, you never know what their height will be at any given moment).

[knorke]

What about the losHeight tag?
That could be used for radar too.
For 99% cases its probally ok if radar & LOS emit from the same point.

[AF]

But then what about the structure with the uber long antenna that peeps out over the hills and provides radar? But cant see very far los-wise because the hill blocks the view?

Or for setting a very very high radar height to bypass the terrain calculations for low hills and craters

[Pxtl]

Add a new tag for radarheight, but fall back to losheight, unit height, whatever.

[Google_Frog]

http://springrts.com/mantis/view.php?id=1668

What was done?

Seems, small hills, block radar rays too much.

How much is too much? I hope a hardcoded constant was not fiddled with instead of a propper fix.

[knorke]

fixed as of 267470f8816e5b21b779db6be9b0b1a24cdbd8ec

https://github.com/spring/spring/commit ... a24cdbd8ec

[FLOZi]

Now properly controllable via unitDef tags;

Code: Select all

	losHeight = udTable.GetFloat("losEmitHeight", 20.0f);
	radarHeight = udTable.GetFloat("radarEmitHeight", 20.0f);

[Tobi]

Performance wise it could be better if those high flying planes (optionally?) not use the raycasting algorithm at all, but simply use a circular radar. (Like what is used for airlos ATM.)

[hoijui]

sounds reasonable, except maybe on maps with very high steep cliffs, like BaNa's new map.
http://springrts.com/phpbb/viewtopic.php?f=13&t=26174

Though... maybe even there the planes would fly above the cliffs tops all the time, due to smooth-air-mesh.
And even if not, it would be an acceptable cut off on realism, if it gives us relatively big performance benefits with air-spam.

[Google_Frog]

https://github.com/spring/spring/commit ... a24cdbd8ec

Nice.