View Issue Details

IDProjectCategoryView StatusLast Update
0001704FSSCPmodular tablespublic2012-11-27 06:57
ReporterFUBAR-BDHR Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionnot fixable 
Product Version3.6.9 
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.

Relationships

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

Activities

2008-05-29 19:54

 

FUBAR_MD11_working.fs2 (13,092 bytes)

2008-05-29 19:54

 

FUBAR_MD11.fs2 (13,104 bytes)

Wanderer

2008-06-01 09:36

developer   ~0009365

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

2008-06-01 11:43

administrator   ~0009367

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

2008-06-01 12:03

developer   ~0009368

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

2008-06-01 12:18

administrator   ~0009369

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

2008-09-27 06:11

administrator   ~0009714

Not fixable without a serious redesign, so closing.

Issue History

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