Housing Editor bug when furniture rotated to 90 degrees pitch

WetWired

When furniture is rotated to 90 degrees pitch, the game incorrectly reports the rotation of the furniture. The yaw reported has the inverse sign of the actual yaw. This affects both the API and the server-processed movement using the cursor.

To reproduce:
1. Go into a house and place a piece of furniture. Preferably in the air with lots of space about it so that it is easy to observe.
2. In furniture selection mode, move your cursor so the furniture is highlighted
3. To get the ID of the furniture, run /script HousingEditorSelectTargettedFurniture();bug20180210wetwired=HousingEditorGetSelectedFurnitureId();HousingEditorRequestSelectedPlacement();
4. To set the furniture in the example orientation, run /script local p,w,r=math.pi/2,math.pi/2,0;d(p,w,r);HousingEditorRequestChangeOrientation(bug20180210wetwired,p,w,r);
5. Note the angle that was requested is also output in the chat window.
6. To inquire what orientation the furniture was actually placed in, run /script d(HousingEditorGetFurnitureOrientation(bug20180210wetwired));
7. Note that the reported angle does not match the requested angle. In reality, the furniture was placed correctly; the report is wrong.
8. Click the furniture to pick it up.
9. Click the furniture to place it.
10. Note that the furniture changed orientation from the preview when you performed step 9
11. Click the furniture to pick it up.
12. Click the furniture to place it.
13. Note that the furniture changed orientation again

Shadowshire

WetWired wrote: »

When furniture is rotated to 90 degrees pitch, the game incorrectly reports the rotation of the furniture. The yaw reported has the inverse sign of the actual yaw. This affects both the API and the server-processed movement using the cursor.

To reproduce:
1. Go into a house and place a piece of furniture. Preferably in the air with lots of space about it so that it is easy to observe.
2. In furniture selection mode, move your cursor so the furniture is highlighted
3. To get the ID of the furniture, run /script HousingEditorSelectTargettedFurniture();bug20180210wetwired=HousingEditorGetSelectedFurnitureId();HousingEditorRequestSelectedPlacement();
4. To set the furniture in the example orientation, run /script local p,w,r=math.pi/2,math.pi/2,0;d(p,w,r);HousingEditorRequestChangeOrientation(bug20180210wetwired,p,w,r);
5. Note the angle that was requested is also output in the chat window.
6. To inquire what orientation the furniture was actually placed in, run /script d(HousingEditorGetFurnitureOrientation(bug20180210wetwired));
7. Note that the reported angle does not match the requested angle. In reality, the furniture was placed correctly; the report is wrong.
8. Click the furniture to pick it up.
9. Click the furniture to place it.
10. Note that the furniture changed orientation from the preview when you performed step 9
11. Click the furniture to pick it up.
12. Click the furniture to place it.
13. Note that the furniture changed orientation again.

Thank-you for the scripts.

The behavior described by Number 8 - 13 on your list simply should never occur. The act of accessing an object per se should never change any attribute of the object, such as its location. That said, I don't know whether the behavior you describe reflects a defect in the ESO OOP algorithims, or a technical flaw(s) in the source code, or, perhaps, defects in the tools which the designers and programmers use to produce the software executables.

Personally, I also use the add-on Homestead Item Mover, and today I installed another one that seems promising, Homestead Engineer.

Usually, I initially choose a piece of furniture and place it with the ESO Homestead Editor. Then, while in the H.E. UI, and with the furnishing highlighted (with the mouse cursor), I use a keybind to select it for Homestead Item Mover. Then I use the H.I.M. features to fine-tune the furnishing's placement. Still, it can be a trial-and-error chore to place an item where I want it, and in the way that it should be placed.

One frequent problem is that, after placement, my character cannot obtain the Interactive Prompt to use the furnishing, for example, to sit on a chair, bench, sofa, etc. -- although an Interactive Prompt should be displayed to enable the character to do that.

Most often, moving the furnishing further away from a wall or from another piece(s) of furniture in its vicinity might enable the Interactive Prompt to sit on it, but not always. Sometimes /reloadui resolves the problem, or logging-out of the character and choosing to log-in to the character again will resolve it.

If not, then there's nothing that a player can do -- other than return the item to storage, exit the Housing Editor, leave the Homestead, quit TESO entirely, then return to try again (and expect to fail). Or instead maybe we should play another game in which the Homestead furnishing features work with few, if any, errors.

A case in point: after I placed a sofa in one Homestead room, I could never obtain the I.P. for the character to sit on it -- regardless of where it was placed, and regardless of all the remedies which I tried. All my time and effort to furnish that room with it was wasted. So I returned the sofa to the character's bags. Subsequently, I moved that character to another Homestead which had no furnishings. There, I encountered no problem obtaining the Interactive Prompt for the character to sit on the same sofa, after I had placed it with the ESO Housing Editor. Go figure.

In my humble opinion, ZOS will never correct any, let alone all, of the design flaws and/or bugs in the Housing Editor. Succinctly, there is just no consistency in the behavior of TESO game software. I cannot ever be sure as to what it will do when I press a key or a mouse button. Make of that what you will.

mystfit

I mentioned this in game, but will post it here. As far as I know (which is very little), this is called a gimbal lock and happens when the pitch of the item is very close to 90. This causes it to spaz out. I do not think this is an ESO related issue as eq2 has it as well. Getting it as close to 90 without being 90 (pitch) is your only option.
Depending on what add on you're using, that would either be 89 or 91 or 89.9 or 90.1 if you can decimals. Engineering and OCD do decimals. Homestead Item Mover only does whole numbers. Mover will also alert you when you're getting close to the gimbal lock. Which you will of course know anyway when it's dancing around


https://en.wikipedia.org/wiki/Gimbal_lock

WetWired

Gimbal lock refers to the inability to rotate in a desired direction due to loss of degrees of freedom. The problem here is that the code that ESO uses to report the orientation to the API and to its internal movement system (which is not exposed to the API beyond functions for each keypress) gives incorrect results when the pitch reaches 90 degrees. Specifically, it very repeatably reports an inverted sign on the yaw.

If I did not have to cause the game to move the object in order to get its ID, I could account for this bug in my add-on code; it is not a fundamental limitation.

Shadowshire

@WetWired

In my experience, each and every time that I have selected a piece of furniture with the ESO Housing Editor, it has always changed the position of the selected piece. It usually changes the "yaw" but it can also change the "pitch", and/or sometimes its elevation ("align"ment).

This does not happen while I use the add-on Homestead Item Mover. However, if I rotate the selected furnishing's pitch to 90 degrees, it reports a "Gymbal Lock". It is unclear to me whether that is an error condition, or simply meant to inform the player that the pitch cannot be changed more than +90 or -90 degrees.

With regard to obtaining the ID of the object, have you examined the source code for Homestead Item Mover?

WetWired

Every existing furnishing addon gets the ID of the furniture under the cursor in the same way: the item is picked up, just as when you click it, the held furnishing ID is retrieved, then the item is put back down. The game does not apply movements when this is done all at once, but due to the bug, the action of placing the item back where the game thought it was causes motion because the game thought it was in a different position than it actually was.

I am unsure of the exact reason for reporting gimbal lock. Certainly, there are limitations on what you can do when you only operate directly upon the "gimbals" that the API system suggests, but it can be shown that any arbitrary orientation of an object can be expressed in terms of pitch, yaw, and roll.

Shadowshire

WetWired wrote: »

Every existing furnishing addon gets the ID of the furniture under the cursor in the same way: the item is picked up, just as when you click it, the held furnishing ID is retrieved, then the item is put back down. ....

I am unsure of the exact reason for reporting gimbal lock. Certainly, there are limitations on what you can do when you only operate directly upon the "gimbals" that the API system suggests, but it can be shown that any arbitrary orientation of an object can be expressed in terms of pitch, yaw, and roll.

Pitch, yaw, and roll describe an object's "orientation" to the viewer. Elevation above "the horizontal plane" must be included to describe an object's location. Three-dimensional space has three axes (X, Y, Z) and the center of the volume of an object is at a coordinate with respect to where they intersect (0,0,0). But don't ask me about the various methods for displaying a three-dimentional world on a two-dimensional plane.

By the way, before I activate the Housing Editor, I always switch to first-person view from third-person view. The Housing Editor behaves much better that way. But if I want to place something above the character's head, then the character usually must stand on a stool, bench, chair, or crate. (Just like you and I, unless we have a step ladder. ) However, I haven't tried entering /kneel in the Chat text entry field when an object, such as a book, needs to be placed into something (such as a bookshelf) below the character's knees.