2018-03-21 04:02 EDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001704FSSCPmodular tablespublic2012-11-27 01:57
Assigned To 
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

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



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...


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.


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.


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.


Goober5000 (administrator)

Not fixable without a serious redesign, so closing.

-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