|
|
|
It's true that it's not physics related, however it's false that it's not specific to Havok4, since the issue here is that the H4 beta does not correctly duplicate the existing behavior on the main grid, which breaks existing content and needs to be fixed before H4 can go live, regardless of whether the general bug is fixed or not.
In any case, I was asked at the last H4 office hours to make sure the issue was in JIRA by either Andrew or Sidewinder. Either this or SVC-38 should have Havok 4 listed in the affects version, or it kinda defeats the purpose. I would think this would be the more logical choice, since all that needs to be done before H4 can go live is fix the issue reported here (not working in cases where the main grid works), not necessarily actually fix SVC-38, although doing that would solve the problem too. Editting this bug to clarify a few things.
This is NOT a duplicate of SVC-38. Clearly, it is a related bug. However, it's entirely possible to fix THIS bug WITHOUT fixing SVC-38 (which logically precludes it from being a duplicate of it). One merely has to make the same workarounds for SVC-38 that work on the main grid also work on the H4 beta. The code snippet above is a good example. Changing the order of setting the sides from 0-1-2 to 1-0-2 effectively worked around SVC-38 on the main grid – the snippet works fine there. However, it fails on the Havok4 beta. Somehow, something related to SVC-38 has changed in such a way under the H4 beta that it breaks the known workarounds that work fine on the main grid. It would be nice if SVC-38 could get fixed, and that would make this problem go away. But, failing that, one need only make the H4 beta compatible with the main grid with regards to how it handles these calls to fix this bug, and then worry about SVC-38 later... Just tested, the bug is still on H4 beta. Reopening...
I am seeing this too. It is new to havok4-enabled regions. Somehow, enabling havok 4 on a region can bring up bugs that aren't related to physics at all.
This breaks a lot of scoreboards that try to set textures on multiple faces at once. This seems similar to SVC-38, and perhaps fixing one will fix the other, but they are distinct bugs, and this refers specifically to the newly broken functionality seen only in havok4 servers
It is sometimes tough to tell what is related to the physics engine and what isn't. Some of the linking rules had to change with Havok4, and that is related to how llSetPrimParams works ... in a round about way. I'll try to look into it this week.
Changing the list order to
PRIM_COLOR, 1, ZERO_VECTOR, 0.0, in a new prim works correctly. If you then change it to the workaround order (from the the first post) and recompile, both face 0 @Clarknova: Yup. Different orders will work. For example, the following works fine on both H1 and H4:
llSetPrimitiveParams([ Alas, I've been selling products for over a year now that use the order from the original post. If H4 doesn't restore the original H1 behavior, I have a heck of a mess on my hands. At least one of the products was from before I developed an auto-upgrade system, and is one of my bestsellers, too. Big hairy mess... Fixing SVC-38 would allow any order to work, but failing that, we at least need the orders that have worked fine for the last year under H1 to continue working fine, or I suspect quite a few of us are going to have issues (my airships and Rifkin's scoreboards are probably the tip of the iceberg here). Because you can chain settings in a single script call we do some magic around when we actually apply the settings to the object. For example when we do PRIM_COLOR we apply any pending color changes (so they won't be lost). However we weren't paying attention to the various sides and there is only one side variable. If you set a side for a PRIM_TEXTURE, then called PRIM_COLOR we would apply the color values then change the side - which would screw the previous PRIM_TEXTURE values. Pre-Havok4 we just blindly applied all pending changes but only on specific values (this is why the old work arounds worked), however this behavior didn't work with changes made to setting prim movement, scale and rotation which is why it was changed to only apply pending changes of the same type.
Now if side being modified is changed we apply all pending changes that change side values (ie everything except pos, rot, scale, shape etc). I think there is a better fix or project to properly queue up changes per side (as opposed to per prim) but I think that is a non-havok4 bug and issue. I also think it effects too much for me to go changing it as a side note to the havok4 project. My current fix should be in the next havok4 push. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
On Havok4 beta grid, llSetPrimitiveParams behaving differently from main grid
And this is not physics related, or specific to havok 4. Removing havok 4 from affects version, as it's an organisational tool.