View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001704 | FSSCP | modular tables | public | 2008-05-29 19:54 | 2012-11-27 06:57 |
| Reporter | FUBAR-BDHR | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | not fixable | ||
| Product Version | 3.6.9 | ||||
| Summary | 0001704: Large coordiante values result in ships not being where they apper to be. | ||||
| Description | Using 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 Information | TBP 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. | ||||
| Tags | No tags attached. | ||||
|
2008-05-29 19:54
|
|
|
2008-05-29 19:54
|
|
|
|
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... |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Not fixable without a serious redesign, so closing. |
| 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 |
