[SOLVED] How much RadiusGive's max allowed radius value is?

[Void Weaver]

Subj.
I've tried to set 0x7FFFFFFF into distance but it have cause game freeze. Anyway I need for maximal value that can cover a map of any size.
---
A_RadiusGive 16384 radius value is allow to cover entire map of any possible size, IF it called from the map center. Look for explanation here.

[Blue Shadow]

I need for maximal value that can cover a map of any size.

I'm not sure, but there is this from [wiki]A_RadiusGive[/wiki]:

Note that for very large distances, attempting to give to specific things map-wide may fail. A good range for the entirety of the map would be 16383. A dummy actor can warp to (0,0,0) coordinates to ensure the radius does not overflow from being too close to the map boundaries. Experimentation may be required.

[Void Weaver]

Earlier I've the same thoughts but it more looks like a some kind of pointless subjective advice rather than precise data.
Function accepts for sure value of 1048576 at least, but I can't verify is _RadiusGive really works for this value or maybe its effective range may be much less than allowed value. It is doubtful, but still I would like to know for sure.

EDIT:
Probably I should ask a bit differently. What is maximum possible map size and can it be successfully covered by _RadiusGive radius between farthest edges of map?

[_mental_]

Valid map vertex coordinates must be in -32768..32768 range.

[Void Weaver]

Oh, then there is no need to assign radius value more than 65536 at all?
And else one important thing for me. Does this diapason counts placement of container-sectors for monsters landing party?

[_mental_]

Distance between (-32768,-32768,-32768) and (32768,32768,32768) points is slightly greater than 65536

[Void Weaver]

Oh, of course! It's roughly equal of 113512.

[Empyre]

Is the Z height even considered for RadiusGive?

[Graf Zahl]

Never forget that the larger the radius is, the costlier the function becomes, especially on heavily populated maps.

[_mental_]

Is the Z height even considered for RadiusGive?

Yes, it’s a radius of a sphere.

[Void Weaver]

Never forget that the larger the radius is, the costlier the function becomes, especially on heavily populated maps.

Yeah, even 113k radius causes severe lags at map with 1k monsters, 2.5k items and total map length of 32k.

Yes, it’s a radius of a sphere.

Or a cube edge if the flag presented.

[ketmar]

>-32768..32768 range
32767.

[Void Weaver]

>-32768..32768 range
32767.

Why?
Source says that 32768 is't included in the bad range:

Code: Select all

if (sc.Float < -32768 || sc.Float > 32768)
	{
		sc.ScriptMessage("Value %f out of range for a coordinate '%s'. Valid range is ]-32768 .. 32768]", sc.Float, key);
		BadCoordinates = true;	// If this happens the map must not allowed to be started.
}

[phantombeta]

>-32768..32768 range
32767.

No. GZDoom uses floating point, therefore, the limits are entirely arbitrary*. If you look at the source code (which Void Weaver just posted a snippet of above), you'll see that the range is indeed [-32768, 32768].

* (Aside from the nodes format and the nodebuilder)

[ketmar]

>GZDoom uses floating point
yet most maps are using binary map format. also, i wonder how it managed to represent 32768 in 16.16 2-complement nodes data (which GZDoom is still using internally). i believe that this is a bug that should be fixed, or it will pop up eventually.

p.s.: GZDoom is doing fp<->16.16 conversions internally in more that one place, so the real positive limit is <32768 anyway. having it as 32768 is a bug. prolly not fatal (as code should do correct rounding and clamping, i believe), but still a bug.