2018-09-22 18:26 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001704FSSCPmodular tablespublic2012-11-27 01:57
ReporterFUBAR-BDHR 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionnot fixable 
Product Version3.6.9 
Target VersionFixed in Version 
Summary0001704: Large coordiante values result in ships not being where they apper to be.
DescriptionUsing an existing background for a dogfight I placed an asteroid field and ships at roughly 90000 on the z axis. No problems flying by myself but when tested with 2 people I saw the client flying off into the distance firing at nothing. Testing it myself with 2 computer and I found out why. While to me it appeared he was firing at nothing he was shooting at the position I was being reported at over 6k away from the actual position. It also worked somewhat in both directions. I was showing the client as as being outside the asteroid field while the client screen was showing him inside the field. I could shoot the client but the client could not shoot me.
Additional InformationTBP 3.6.9 build. Attaching the same mission one working the other not. Only difference between the 2 is the working one has 80000 subtracted from all z axis values.
TagsNo tags attached.
Attached Files

-Relationships
related to 0002325resolvedValathil View shakes in 'show ship' flag when far from the mission origin 
+Relationships

-Notes

~0009365

Wanderer (developer)

Culprit appears to be multiutils.cpp's position handler function (around line 3960). It seems to be scaled for old mission area limitation (roughly 70 km).

03960 a = fl2i(pos->xyz.x*105.0f+0.5f);
03961 b = fl2i(pos->xyz.y*105.0f+0.5f);
03962 c = fl2i(pos->xyz.z*105.0f+0.5f);
03963 CAP(a,-8388608,8388607);
03964 CAP(b,-8388608,8388607);
03965 CAP(c,-8388608,8388607);

Changing it to use larger values (from current 24 bit to 32 bit) might make builds incompatible in mp though...

~0009367

taylor (administrator)

This doesn't have anything to do with the old mission area limit. The mantissa is only 24-bits with single-precision floats. So the 24-bit cap is to prevent overflow errors during conversion back to a float. Without changing everything to doubles, or completely changing how position values are determined, nothing can really be done about this.

~0009368

Wanderer (developer)

If the 105.0f (divisor/multiplier) would be changed to 10.5f - or to some other multiplier around 10 or so... Would it cause too much inaccuracy in the mission? It should expand the allowed area by tenfold - assuming i got that part right.

~0009369

taylor (administrator)

I'm not really sure why they went with 105.0f there, so it's tough for me to say one way or the other without taking a really close look into that code. It would definitely break compatibility though, so if that would work then it should only be changed for a major release or something.

~0009714

Goober5000 (administrator)

Not fixable without a serious redesign, so closing.
+Notes

-Issue History
Date Modified Username Field Change
2008-05-29 15:54 FUBAR-BDHR New Issue
2008-05-29 15:54 FUBAR-BDHR File Added: FUBAR_MD11_working.fs2
2008-05-29 15:54 FUBAR-BDHR File Added: FUBAR_MD11.fs2
2008-06-01 05:36 Wanderer Note Added: 0009365
2008-06-01 07:43 taylor Note Added: 0009367
2008-06-01 08:03 Wanderer Note Added: 0009368
2008-06-01 08:18 taylor Note Added: 0009369
2008-09-27 02:11 Goober5000 Note Added: 0009714
2008-09-27 02:11 Goober5000 Status new => closed
2008-09-27 02:11 Goober5000 Resolution open => not fixable
2012-11-27 01:57 Goober5000 Relationship added related to 0002325
+Issue History