Jim Tarber wrote:
Jim Tarber wrote:
Some viewers may have lower limits but they are viewer limits/assumptions and not an InWorldz limit.
I just tested it in IW2 and was able to move a prim to 4100, then 9000, then 9999, then drag it up to 10000 but not beyond that.
However, IW3 seems to have the 4096 limit. (We'll have to fix that to use the InWorldz limit.).
Jim, [Apologies for being wordy here] you got it - yes
! It all works, as implemented, in the IW v2 viewer
. It's just IW's v3 that displays the "unwanted" behavior. [aside: my house is up there at 6000m, so when it happened it was rather sudden, startling and a bit jarring. I also have other planned builds that will occupy space between the (current) v3 viewer limit and the 6000m skybox that is already in place
]. As -perceived- "bugs" or "glitches" go, this one is pretty big. I just didn't want the report to get lost in the amalgam of requests in the other thread.
It's time-consuming and frustrating to have to drag
a build, in this case, almost 2000 meters by hand - had I been smart about it I would have just relogged on v2 and put it back. Hindsight is 20/20 and I was a little distracted when I wrote the OP .. besides, I have always hated having to be "familiar" with multiple viewers. I prefer to be as much "specialist" as I can in the workings of the one viewer I choose to use.
The v2 will just continue to remain my viewer "of choice" until the correct limit has been added to the v3 (along with a few other items that do not bear reiteration as they were noted and/or requested by other users in the v3 thread already). Speaking of which - The v3 thread, along with it's itinerant list of "needs" and "wants" is now so long as to be cumbersome. If I were asked for suggestions, I would recommend two threads - one for "expected" and/or "necessary" behaviors that should already be a part of using the v3 viewer .. and a second one for "requested" items that users would like
, or need
, to see changed or added to the viewer's capabilities.
The OP may not reflect it, but I was merely calling attention to InWorldz viewer 3 not supporting "our", "extended", elevation (I suspected this might just have been an "oversight" in the viewer-code - sometimes these things do get over looked among all the thousands of details that have to be taken into account when building a viewer).
For clarity [I may not have been in the OP]. -it's nothing to do with floating point "drift"- I can live with that. My virgo-brain finds floating point drift a tad annoying but that's my own demon to battle.
Anyone using the InWorldz v3 viewer
can (with 100% accuracy) reproduce the "failure" simply [note: this activity is not recommended outside the bounds of further testing to narrow down the exact corrections that need to be made in the viewer - or in cases of extreme boredom]:
1 - rez any object/link-set or single prim at altitudes higher than 4096 - even 4097 (I did not attempt to build
a new prim at that height to see if the enforcement goes that far, it may not. It may be that the problem is specific enough that "enforcement" only occurs when the height/altitude field is edited above the viewer's perceived limit).
2 - use the edit-number field (specifically the Z coordinate) in the "object" tab of the build/edit window, for manual placement above 4096 (I did not consciously
test whether adjusting x and y positions maintain the correct z location if attempts are made to adjust them above the enforced viewer height, though this too may not be an issue if the z coordinate is not updated without changes specific to that field)
3 - At the point of committing the "altitude" number (only "enter key" and "tab key" were tested) the build "defaults" to the v3 viewer's "strangled height" - i.e. 4096 *point* 0000 [warning: User may have to "retrieve" the object from 4096.0000 if they are substantially higher than that "current" viewer-imposed limit]