Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007903opensim[REGION] OpenSim Corepublic2016-05-08 00:262016-06-26 00:50
Assigned Tomelanie 
PlatformOperating SystemOperating System Version
Product Versionmaster (dev code) 
Target VersionFixed in Versionmaster (dev code) 
Summary0007903: Avatars float over seats, LegacySitOffsets has no effect
DescriptionIn 0.9, avatars are seated 0.1m higher than in previous versions as pictured in issue 0007820 (narrowing incorrectly the issue to NPCs).

The LegacySitOffsets in OpenSimDefaults.ini has no effect.

It was found that LegacySitOffsets, the C# variable, is set from LegacyOpenSimSitOffsets, the ini parameter (Scene.cs, line 972).

Adding a LegacyOpenSimSitOffsets parameter to OpenSimDefaults.ini had no more effect.

This breaks a botload of content (OARs, freebies) that can't be expected to be fixed soon.
TagsNo tags attached.
Git Revision or version number1e44aba
Run ModeStandalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineODE
Script Engine
EnvironmentMono / Linux64
Mono Version3.2
Attached Filespatch file icon 0001-Fixed-flipped-sign-in-sit-position-computation.patch [^] (1,021 bytes) 2016-05-08 18:06 [Show Content]
patch file icon 0002-Fixed-discrepancy-between-code-and-ini-symbols.patch [^] (1,176 bytes) 2016-05-08 18:06 [Show Content]
png file icon true.png [^] (205,755 bytes) 2016-05-17 16:55

jpg file icon sit-position-08.jpg [^] (70,330 bytes) 2016-05-18 05:48

jpg file icon sit-position-09.jpg [^] (74,521 bytes) 2016-05-18 05:48

jpg file icon sit-position-sl.jpg [^] (99,576 bytes) 2016-05-18 05:48

jpg file icon commit_bcee4e3_vs_08.jpg [^] (69,913 bytes) 2016-05-24 01:41

- Relationships
related to 0007096closedjustincc llSitTarget (and llLinkSitTarget) result in different position in opensim than in SecondLife 
related to 0007820closedDiva osNpcSit does not work well in actual 0.9.x 
related to 0001716closedcfk Gap when sitting on single prims with a sit target (discrepancy with SL) 

-  Notes
Mata Hari (reporter)
2016-05-08 08:41

Considering the drastic effect the sit target offset change has on all existing content, I question the need to have altered it at all in 0.9. Is there some real justification for reverting to the pre-Opensim sit target behaviour?
JeffKelley (reporter)
2016-05-08 18:07

Two patches submitted.

The first changes a flipped sign in the sit position computation. This was spotted by Mandarinka Tasty in the discussion of issue 0007820. Thanks Mandarinka.

The second changes "LegacyOpensimSitOffsets" in the code to match "LegacySitOffsets" in OpenSimDefault.ini.
aiaustin (developer)
2016-05-13 03:34
edited on: 2016-05-16 01:29

I hope these fixes can be incorporated soon...

I have noticed that sit target positions and the height an avatar is placed above a seat are now very confused as I move between grids and regions, some on 0.9 and others on 0.8... even when on regions on different grids using the same open source "OpenVCE" OAR.

JeffKelley (reporter)
2016-05-14 04:41

There is no reason they could be rejected.

First patch fixes a mistake in commit a11edce :

- // sitOffset is in Avatar Center coordinates: from origin to 'sitTargetPos + SIT_TARGET_ADJUSTMENT
- // So, we need to _substract_ it to get to the origin of the Avatar Center.
- Vector3 newPos = sitTargetPos + SIT_TARGET_ADJUSTMENT - sitOffset;
+ Vector3 newPos = sitTargetPos + sitOffset + SIT_TARGET_ADJUSTMENT;

-sitOffset was flipped to +sitOffset. Ironically, the comment saying it should be subtracted had been deleted. Second patch fixes a mispelled ini parameter. Until core commits, you can safely apply to your git.
aiaustin (developer)
2016-05-16 01:29

Good, I hope this can be committed soon and hence will propagate to OSGrid and others grids on the latest dev 0.9.0

Jeff, in your patch for the sign flip, is it worth adding back in the comment lines too, so that this is not accidentally changed in future too?
JeffKelley (reporter)
2016-05-17 16:54

There are actually two distinct issues here.

One is an improved sit target computation. It is said to be more compatibile with SL. Since it could break old content, a switch 'LegacySitOffsets' has been added to OpenSimDefault.ini. Unfortunately, the code reads 'LegacyOpenSimSitOffsets'. That explains that setting LegacySitOffsets = true in OpenSimDefault.ini has no effect. This was reported first by Bruce in related issue 0007820, Feb 26. At the time i'm writing this, nobody could test legacy sit yet.

Another issue is the sign appearing to be flipped bewteen 8.3 and 9.0. This was reported first by Mandarinka Tasty in same issue, May 8. What is important to note is that this affect BOTH options (new sit, legacy sit) since it is done AFTER the switch:

  // Legacy code
  // New code

Vector3 newPos = sitTargetPos + sitOffset + SIT_TARGET_ADJUSTMENT;

They may be mathematical discussion about if it should be a plus or a minus. One sure thing is : when you flip it again, you get exactly pre-0.9 sit as shown in the attached picture. The avatar is slightly too high in both cases, but that's because the sit was targeted for my big butt, not for a slim lady.

The consequence of this patch not being applied is : retargeting all your seats, inworld, in inventory, in OAR, IAR, in rezers. This is a thing I will never dare to ask my users.
Mata Hari (reporter)
2016-05-17 19:13

While I agree that there is a strong need to avoid breaking an enormous amount of existing content, having 2 different systems that result in two markedly different positions is a nightmare. As a content creator, will I now be expected to provide two versions or anything I make -- one for legacy and one for "new" -- and hence double the mount of set-up work I have to do to create those products?
Mandarinka Tasty (reporter)
2016-05-18 00:28
edited on: 2016-05-18 00:42

Hello :)

I perfectly understand and realise Mata's concerns, she could not have known

about mistake in math sign in vector that refers to how avatar sits.

She has correctly assumed, that it is new change and she has changed her products,that mostly are based on llSitTarget = poseballs, dance systems etc.

She did much work to apply new changings of opensim in her products.

And now, mistake in the code has been found, and patch has been offered.

And Mata can see, that another work awaits her.

But now: we need to understand in what place, precisely, new system has been applied in OpenSim code.

New system of SitOffsets is not based on Vector3 newPos

Vector3 newPos is just final result of how old system = SL and new system = Avination computes sitOffset

Do You all understand ?

So in both cases we need to write:

Vector3 newPos = sitTargetPos - sitOffset + SIT_TARGET_ADJUSTMENT;

because actual form of this vector:

Vector3 newPos = sitTargetPos + sitOffset + SIT_TARGET_ADJUSTMENT; is wrong.

Becasue in both cases: SL and avination, it leads to inappropriate position of sitting avatar.

I strongly believe that mistake has been made unconciously = maybe as result of hard work at night :) Never mind now.

Please once again open this:

ScenePresence.cs file in


and go to 3315 line where interesting things in our context start to happen:

                        double m1,m2;

                        m1 = r.X * r.X + r.Y * r.Y;
                        m2 = r.Z * r.Z + r.W * r.W;

                        // Rotate the vector <0, 0, 1>
                        x = 2 * (r.X * r.Z + r.Y * r.W);
                        y = 2 * (-r.X * r.W + r.Y * r.Z);
                        z = m2 - m1;

                        // Set m to be the square of the norm of r.
                        m = m1 + m2;

                        // This constant is emperically determined to be what is used in SL.
                        double offset = 0.05;

                        // Normally m will be ~ 1, but if someone passed a handcrafted quaternion
                        // to llSitTarget with values so small that squaring them is rounded off
                        // to zero, then m could be zero. The result of this floating point
                        // round off error (causing us to skip this impossible normalization)
                        // is only 5 cm.
                        if (m > 0.000001)
                            offset /= m;

                        Vector3 up = new Vector3((float)x, (float)y, (float)z);
                        sitOffset = up * (float)offset;
                        m = r.X * r.X + r.Y * r.Y + r.Z * r.Z + r.W * r.W;
                        if (Math.Abs(1.0 - m) > 0.000001)
                            if(m != 0)
                                m = 1.0 / Math.Sqrt(m);
                                r.X *= (float)m;
                                r.Y *= (float)m;
                                r.Z *= (float)m;
                                r.W *= (float)m;
                                r.X = 0.0f;
                                r.Y = 0.0f;
                                r.Z = 0.0f;
                                r.W = 1.0f;
                                m = 1.0f;

                        x = 2 * (r.X * r.Z + r.Y * r.W);
                        y = 2 * (-r.X * r.W + r.Y * r.Z);
                        z = -r.X * r.X - r.Y * r.Y + r.Z * r.Z + r.W * r.W;
                        Vector3 up = new Vector3((float)x, (float)y, (float)z);
                        sitOffset = up * Appearance.AvatarHeight * 0.02638f;

Vector3 newPos = sitTargetPos + sitOffset + SIT_TARGET_ADJUSTMENT;

In first condition concerning SL we have:

Vector3 up = new Vector3((float)x, (float)y, (float)z);
                        sitOffset = up * (float)offset;

In second condition concerning new implemented system we have:
Vector3 up = new Vector3((float)x, (float)y, (float)z);
                        sitOffset = up * Appearance.AvatarHeight * 0.02638f;

so difference between LegacySitOffsets enabled and disabled

we can see in vector sitOffset, because:

Old version: sitOffset = up * (float)offset;

New version: sitOffset = up * Appearance.AvatarHeight * 0.02638f;

And final result = important vector we have under those two condtions,

Vector3 newPos = sitTargetPos + sitOffset + SIT_TARGET_ADJUSTMENT;

We can see, that this last line refers to both conditions, no matter if

we use old version or new version.

and that is wrong = mistake, because this line should be written in form:

Vector3 newPos = sitTargetPos - sitOffset + SIT_TARGET_ADJUSTMENT;

for both cases: Legacy enabled or disabled.

Because idea of new version does not exist in this last line, but exist in

second condition: sitOffset = up * Appearance.AvatarHeight * 0.02638f;

Another problem is, that people wanted to use old version,

but they could not, because of mistake in line 972:

LegacySitOffsets = startupConfig.GetBoolean("LegacyOpenSimSitOffsets", LegacySitOffsets);

We can notice, here, that opensim searches variable:

LegacyOpenSimSitOffsets in OpenSimDefaults.ini but unfortunately

we have there: LegacySitOffsets

So no matter, how we set in this OpenSimDefaults.ini

variable LegacySitOffsets = true; LegacySitOffsets = false;

opensim does not use our setting, because:

in OpenSimDefaults.ini, there should be written:

LegacyOpenSimSitOffsets = true or LegacyOpenSimSitOffsets = false.

So to fix it, we need to change form of this variable in OpenSimDefaults.ini

from old one:LegacySitOffsets to new one:LegacyOpenSimSitOffsets

Or we need to change this 972 line:

from old one:

LegacySitOffsets = startupConfig.GetBoolean("LegacyOpenSimSitOffsets", LegacySitOffsets);

to new one:

LegacySitOffsets = startupConfig.GetBoolean("LegacySitOffsets", LegacySitOffsets);

And one of these solutions, has been introduced in patch made by JeffKelley

But please be aware of: that we need final vector in form:

Vector3 newPos = sitTargetPos - sitOffset + SIT_TARGET_ADJUSTMENT;

Otherwise, with sign " + " we have problem with everything what has been made in

OpenSim in the past.

aiaustin (developer)
2016-05-18 01:19
edited on: 2016-05-18 01:20

Lets get the patch to fix the flipped sign in 0.9.0 quickly so we can get this settled down.

Vector3 newPos = sitTargetPos - sitOffset + SIT_TARGET_ADJUSTMENT;

I assume the LegacyOpenSimSitOffsets/LegacySitOffsets parameter mismatch in code and OpenSimDefaults.ini is a simple mistake that must be fixed too?

Then I assume that 0.8.x and 0.9.0 will behave identically, so we can start to find seating targets in our regions, OARs and IARs that may have been set wrongly in the time that these varied.

I for one started to fix the OpenVCE OAR (which has about 200 seating objects! Several of which had been partially adjusted at various times and thus were wrong) and made a new OAR based on the relatively clean MOSES 0.8.x version of OpenVCE which I then tested on an Sim-on-a-Stick and on a manually patched 0.9.0 dev grid with the above changes and that all seats then work fine in both cases.

Mandarinka Tasty (reporter)
2016-05-18 04:32
edited on: 2016-05-18 04:44

Yes, Ai. Exactly. Jeff has created the appropriate, correct patch with corrected form of this vector and corrected form of variable that gives possibility to use first or second version.

And now, we only wait for some core developer to accept it, test it and apply it to the master code.

And info for Mata: after applying this patch = returning to

Vector3 newPos = sitTargetPos - sitOffset + SIT_TARGET_ADJUSTMENT;

Both versions are not going to vary in such way like we experience with the mistake now.

New calculation of vector sitOffset = up * Appearance.AvatarHeight * 0.02638f in version referring to LegacySitOffsets = false gives better adjustment in aspect of sitting avatars. Because it shows dependency on AvatarHeight.

Please look, actually with sign " + " the vector difference between:
Opensim and Opensim 0.9.0. is equal to:

( sitTargetPos + sitOffset + SIT_TARGET_ADJUSTMENT ) - ( sitTargetPos - sitOffset + SIT_TARGET_ADJUSTMENT ) = 2*sitOffset = 0.01 = 10cm.

And when we use patch with:

Vector3 newPos = sitTargetPos - sitOffset + SIT_TARGET_ADJUSTMENT;

our difference is going to be equal to:

( sitTargetPos - sitOffset + SIT_TARGET_ADJUSTMENT ) - ( sitTargetPos - sitOffset + SIT_TARGET_ADJUSTMENT ) = 0 for LegacySitOffsets = true


( sitTargetPos - up * Appearance.AvatarHeight * 0.02638f + SIT_TARGET_ADJUSTMENT ) - ( sitTargetPos - up * (float)offset + SIT_TARGET_ADJUSTMENT ) =

- up * Appearance.AvatarHeight * 0.02638f + up * (float)offset =

up * ( (float)offset - Appearance.AvatarHeight * 0.02638f) for LegacySitOffsets = false

JeffKelley (reporter)
2016-05-18 05:55

Trying to sort-out the question of sl-os compatibility, i have attached 3 screenshots of the default avatar sitting on a cube in 0.8, 0.9 and SL in good resolution (1280 x 1024). This is a scripted sit:

vector offset = <0.3, 0.0, 0.55>;
vector rotate = <0,0,0>;

default {

    state_entry() {
        llSitTarget (offset, llEuler2Rot(DEG_TO_RAD * rotate));
        llSetClickAction (CLICK_ACTION_SIT);
        llOwnerSay ("Sit target set");

Mata Hari (reporter)
2016-05-23 13:19

Re commit: 775a65

I see that legacy offset is now restored and working, however the sit position math under 0.9 for "new" version continues to use a positive offset and therefore results in the same behaviour that Jeff illustrated where the avatar floats above the surface of the object -- approximated 0.1m higher than the identical test performed in SL.

The commit comment says "New offsets of course still use the correct math" but I'm not sure that's accurate. The offset value being calculated is the relative delta between the actual avatar and the default capsule, and therefore needs to be subtracted rather than added in order to position it correctly.
JeffKelley (reporter)
2016-05-24 02:15

I have tested commit bcee4e3 and the sit position matches perfectly 0.8. See last picture 'commit_bcee4e3_vs_08.jpg'. This was the very object of this issue and, given that LegacySitOffsets is true by default, I think the issue is solved. No content will be broken.

SL compatibility is another issue.
Mata Hari (reporter)
2016-05-24 02:55

The developers have repeatedly stressed that having Opensim match SL behaviour as closely as possible has been one of their key goals and that SL is the "gold standard" against which things are to be compared.

But it goes beyond that. If 0.9 were to use the same math that legacy uses (by subtracting the adjustment value) the general behaviour/comparison between SL _and_ Opensim 0.8 _and_ 0.9 will match. The 0.9 version will simply be slightly more accurate since it's being calculated based on a more accurate avatar height evaluation instead of a blanket adjustment value. Content made for SL, 0.7x, 0.8x and 0.9 will all more or less match one another for many/most avatars. If 0.9 remains as it currently is, it will result in breaking ALL existing content and will double the future workload for content creators who wish to supply things to people running older versions or for possible use in SL.
Mandarinka Tasty (reporter)
2016-05-24 07:16

Hello :)

I agree with Mata and she confirms my texts that I have written above - analysis of actual situation.

Commit comment should rather look:

"New offsets of course still use the corrected math". Instead of "correct", better to use "corrected" or even "appropriate to new assumptions"

I absolutely still consider and i am convinced that vector sitOffset should be

subtracted, not added in final form of vector newPos.

And new method, as I have mentioned above, and also Mata confirms, new method

refers to slightly more accurate estimation of avatar's sitting = such better adjustment, that exists, here: Appearance.AvatarHeight * 0.02638f

new method is not based on "plus sign or minus sign".

But There was discussion in opensim-dev channel, and I have been told

and that is my conclusion, that the main reason of setting now, two versions of vector newPos is that 0.9 code has been offeerd and is being merged from

Avination grid. And them = in avination, they use form of this vector with

"+" sign. And now when we want to have "minus" in both cases: old method and new method, there appears problem with them = Avination.

Because they would need to change their all content, so core developer

has decided to lighlty modify this patch, to satisfy us ( sign "minus")

and satisfy them (sign "plus").

I deliberately use such language now, to be understood clearly by everyone.

So , to make resume, last patch, after developer's modification, gives us, following situation:

When person wants to use old content, then person should set variable:

LegacySitOffsets = true, that is even easier, because true is default setting.

But please be aware now, that setting LegacySitOffsets = true, means, we can use old content but we can't use new estimation:

sitOffset = up * Appearance.AvatarHeight * 0.02638f;

With LegacySitOffsets = true, we can use this:

sitOffset = up * (float)offset

And when person wants to use LegacySitOffsets = false,

then it is not going to nicely work with old content, because:

avatar is going to sit 2*0.05 = 0.1m, higher, than in classic way.

So developer has offered such compromising, between opensim and avination

to satisfy everyone. That looks for me in such way.

I have been also told that there is going to be released certain improvement

to make prim detect version of LegacySitOffsets automatically.

That is good offer, because such ppl liek Mata or other creators that use:

llSiTarget will not be worrying to create two versions or not.

But we need to wait for it.

Because maths is my daily bread and i have read all parts of this code: old method and new method.

It is also possible, to create situation:

That sitOffset = up * Appearance.AvatarHeight * 0.02638f can be also set

in old method = old version, but final vector newPos can use it with "minus" liek we want

and secodn method would use also sitOffset = up * Appearance.AvatarHeight * 0.02638f but with newPos using "plus" with it.

It is possible. And everyone would be happy .

Avination beacuse they do not need to change anythign and us too, because

we can still use old content with sign "minus" and also new method of better

adjustment of the sitting of avatar.

Mata Hari (reporter)
2016-05-24 07:29

If that is indeed the case, it means that anyone wishing to use 0.9 sit calculations will be required to break all of their existing content because ONE GRID is holding the rest hostage (because they didn't implement the correct math 5 years ago when the core Opensim code did).

Further, it will make it impossible for content creators in EVERY GRID EXCEPT AVINATION to make items that are properly positioned unless they create 2 variations of it.

If Avination wants to preserve its old (and incorrect) math they can of course implement their own custom version of the code. Core should aim to meet the needs of the wider metaverse.
aiaustin (developer)
2016-05-24 07:34
edited on: 2016-05-25 01:03

Surely this is not a big issue, its just that the large quantity of Avination merged code introduced a number of things we are gradually finding. The various merged changes just introduced this mistake and its easily fixed by making the sign of the sitOffset be -ve as it has been for some time.

There were other merge issues, some of which took some thrashing out with Ubit to get back to how they were before the merge. But we seem to be gradually resolving these in 0.9.0 dev master.

One thing that ought to be discussed at some stage is why we are sticking as the default with LegacySitOffsets=true though. Does that make sense going forward as 0.9.0 is meant as a tidy up release?

I just want to know what the defaults will be for the future so the many changes that may be needed to sit positions, etc can be made once and for all. When I produce an OAR I would like it to be correct for OpenSim going forward.

Mandarinka Tasty (reporter)
2016-05-24 08:32

Hi AI.

Well I have written resume of actual situation in my last text.

But eng is not my native so I repeat:

Actual 0.9.0 and new 0.9.0 is going to use this variable in two ways:

LegacySitOffsets = true <- to satisfy old content and it is also default setting.

LegacySitOffsets = false < - to satisfy each grid where "plus" is used.

So we have choice. If You want to use old content = from the past,

please choose: LegacySitOffsets = true.

If you do not care about old content in your grids and you also want to use

new way of sitting computation, then use

LegacySitOffsets = false

It is going to be in the future too.

Until moment, I have been told about it, but i can't guarantee, that

developer is going to create such "encoding of the prim",

to make prim knows what you use in your grid.

So then assume, Mata Hari gives you her version of dance system, then

it is going to detect your version of sifOffsetting automatically.

In this way, Mata will not worry to create two versions, but will create only one.

But when this improvement is going to happen, i do not know.

Developers say, that it is not only this one task to do.
Mandarinka Tasty (reporter)
2016-05-24 10:13

I understand now, you simply wish your objects, products, creations work in the future.

Well, You agree, that no one can give us such warranty, it is always possible that something can be changed in the future.

What I feel intuitevely now, that we have enough shown, what we want and

new situation based on compromising gives certain hopes, that it is going to work

in the future too, this old content, or old methods.

Even if new improvement appears, it will cover old and new ways.

So now, You may only make some assumptions, based on probability =

what version of SitOffsets people will be willing to use in the future.

For now, it seems, that rather more choose old way, so in your place, I would save OAR using old sitoffsetting.

But as a person who creates , you may always state: to use my creations, please

set this variable in such and such way.

You have always rights to say that. Maybe in future, residents notice significant differences and advantages of using new sitoffsetting.

Hard to predict now.
Seth Nygard (reporter)
2016-05-24 18:41

If we consider this discussion for a moment as educated findings/comments based on actual comparative testing then it seems clear that the code resulting from the merge found in 0.9 is indeed incorrect. Further actual in-world testing proves behaviour differs from behaviour with SL as well.

If we also consider that approx 3 years ago sit targets were changed/fixed and that resulted in numerous discussions and complaints that it was going to break existing content. The choice was made at that time to put in place an agreed upon fix that compared very favourably with the SL behaviour.

Now I see a much bigger issue where the entire user base of OpenSim is considered to be second class citizens compared to a single grid, Avination. While I do not discount the contribution in the merge it makes no practical sense to define “correct” behaviour based on a single grid when it differs from all others and SL. Is is not possible for a moment that the behaviour in that one gird is perhaps incorrect and therefore needing to be corrected?

Default and programmed behaviour for OpenSim should strive to meet the needs of the greater community, and probably never serve the unique needs of select grids. If we are going to integrate different behaviours for specific grids then who decides what is valid and what is not? Do we favour larger grids at the expense of smaller ones? Do we at some point start to degrade OpenSim intentionally to ensure select grids work “better”? Where does such practice stop?

As a user, tester, and grid owner I for one would expect to see the core code designed, targeted, and maintained to suit the greater community. Making LegacySitPositions work as expected but leaving the broken behaviour when it is not used is not a fix or a solution.
melanie (administrator)
2016-05-25 02:21
edited on: 2016-05-27 12:25

There is a switch, LegacySitOffsets, to give people a stopgap measure to keep content working. Eventually, we will have the prim itself encoded with the offsets to use so everything will work everywhere.
Apart from that, I haven't had the time to test 0.9 code against SL and Avination. The current merge base may well be wrong but I see no point in making willy-nilly back and forth changes to appease people's emotions. This needs to be fixed according to test results and I don't have these test results yet.
Avination is very similar to SL and is, in tests, closer to SL than Opensim. However, that doesn't mean there wasn't an error in the merge and the merge is now really wrong. I need to test various devices I have both in Opensim and in SL to see what the facts are. Once that is done, necessary changes will be made.
However, I can say one thing with certainty: Anything made with legacy offsets will continue to work everywhere when I'm done, no matter how options are set. So content creators should not make things with the new offset logic yet because it may be broken. We all will know more in a few days when I have had the time to test.

aiaustin (developer)
2016-05-25 02:59

Thx Melanie. Any thoughts on whether (or when) the default in the master/release code for LegacySitOffsets default would change to false? Is that a sensible move for 0.9.0 as its a "tidy up" release?
Bruce (reporter)
2016-05-28 20:11

Thank you for everybody who contributed to make the LegacySitOffsets work.

However, my scripts used to move the avatar away from the sit object on standing up, now with 0.9 the avatar stands on the object. This results in tall avatars (>1.90m) getting their upper body stuck in the ceiling of the buildings.

Perhaps this should be reported in a separate mantis ?
UbitUmarov (administrator)
2016-06-25 08:07

Ooops I forgot i renamed the "LegacySitOffsets" option and lost a '-', thx Jelly.

about the standup offset, there is no solution to fit all cases, 0.9 just seems to work better on more cases.
Diva (administrator)
2016-06-25 20:24

I'm confused.
a) What's the name of the config var?
b) Is this working or is it broken?

@Bruce, please open a new mantis for the standup
UbitUmarov (administrator)
2016-06-26 00:35

a) name is LegacySitOffsets
b) seems fixed

I just acknowledged this where two mistakes I made adding that option
aiaustin (developer)
2016-06-26 00:50

To avoid doubt this is marked as resolved with the changes made earlier to dev master. Please reopen if there are residual issues.

- Issue History
Date Modified Username Field Change
2016-05-08 00:26 JeffKelley New Issue
2016-05-08 00:26 JeffKelley Relationship added related to 0007096
2016-05-08 00:26 JeffKelley Relationship added related to 0007820
2016-05-08 08:41 Mata Hari Note Added: 0030282
2016-05-08 10:07 JeffKelley Relationship added related to 0001716
2016-05-08 18:06 JeffKelley File Added: 0001-Fixed-flipped-sign-in-sit-position-computation.patch
2016-05-08 18:06 JeffKelley File Added: 0002-Fixed-discrepancy-between-code-and-ini-symbols.patch
2016-05-08 18:07 JeffKelley Note Added: 0030288
2016-05-08 18:07 JeffKelley Status new => patch included
2016-05-13 03:34 aiaustin Note Added: 0030304
2016-05-14 04:41 JeffKelley Note Added: 0030313
2016-05-16 01:29 aiaustin Note Added: 0030319
2016-05-16 01:29 aiaustin Note Edited: 0030304 View Revisions
2016-05-17 16:54 JeffKelley Note Added: 0030337
2016-05-17 16:55 JeffKelley File Added: true.png
2016-05-17 19:13 Mata Hari Note Added: 0030338
2016-05-18 00:28 Mandarinka Tasty Note Added: 0030339
2016-05-18 00:30 Mandarinka Tasty Note Edited: 0030339 View Revisions
2016-05-18 00:42 Mandarinka Tasty Note Edited: 0030339 View Revisions
2016-05-18 01:19 aiaustin Note Added: 0030340
2016-05-18 01:20 aiaustin Note Edited: 0030340 View Revisions
2016-05-18 04:32 Mandarinka Tasty Note Added: 0030341
2016-05-18 04:35 Mandarinka Tasty Note Edited: 0030341 View Revisions
2016-05-18 04:35 Mandarinka Tasty Note Edited: 0030341 View Revisions
2016-05-18 04:36 Mandarinka Tasty Note Edited: 0030341 View Revisions
2016-05-18 04:36 Mandarinka Tasty Note Edited: 0030341 View Revisions
2016-05-18 04:44 aiaustin Note Edited: 0030341 View Revisions
2016-05-18 05:48 JeffKelley File Added: sit-position-08.jpg
2016-05-18 05:48 JeffKelley File Added: sit-position-09.jpg
2016-05-18 05:48 JeffKelley File Added: sit-position-sl.jpg
2016-05-18 05:55 JeffKelley Note Added: 0030342
2016-05-22 01:26 aiaustin Note Added: 0030354
2016-05-23 00:38 aiaustin Note Deleted: 0030354
2016-05-23 10:20 melanie Status patch included => resolved
2016-05-23 10:20 melanie Resolution open => fixed
2016-05-23 10:20 melanie Assigned To => melanie
2016-05-23 13:19 Mata Hari Note Added: 0030368
2016-05-23 13:19 Mata Hari Status resolved => patch feedback
2016-05-24 01:28 aiaustin Note Added: 0030369
2016-05-24 01:29 aiaustin Note Edited: 0030369 View Revisions
2016-05-24 01:32 aiaustin Note Edited: 0030369 View Revisions
2016-05-24 01:40 JeffKelley File Added: commit_bcee4e3_vs_08.png
2016-05-24 01:41 JeffKelley File Deleted: commit_bcee4e3_vs_08.png
2016-05-24 01:41 JeffKelley File Added: commit_bcee4e3_vs_08.jpg
2016-05-24 02:15 JeffKelley Note Added: 0030370
2016-05-24 02:55 Mata Hari Note Added: 0030371
2016-05-24 03:36 aiaustin Note Deleted: 0030369
2016-05-24 07:16 Mandarinka Tasty Note Added: 0030372
2016-05-24 07:29 Mata Hari Note Added: 0030373
2016-05-24 07:34 aiaustin Note Added: 0030374
2016-05-24 07:35 aiaustin Note Edited: 0030374 View Revisions
2016-05-24 07:36 aiaustin Note Edited: 0030374 View Revisions
2016-05-24 07:38 aiaustin Note Edited: 0030374 View Revisions
2016-05-24 07:39 aiaustin Note Edited: 0030374 View Revisions
2016-05-24 08:12 aiaustin Note Edited: 0030374 View Revisions
2016-05-24 08:32 Mandarinka Tasty Note Added: 0030375
2016-05-24 08:49 aiaustin Note Added: 0030376
2016-05-24 10:13 Mandarinka Tasty Note Added: 0030377
2016-05-24 18:41 Seth Nygard Note Added: 0030378
2016-05-25 01:02 aiaustin Note Deleted: 0030376
2016-05-25 01:03 aiaustin Note Edited: 0030374 View Revisions
2016-05-25 01:03 aiaustin Note Edited: 0030374 View Revisions
2016-05-25 02:21 melanie Note Added: 0030379
2016-05-25 02:59 aiaustin Note Added: 0030381
2016-05-27 12:25 aiaustin Note Edited: 0030379 View Revisions
2016-05-28 20:11 Bruce Note Added: 0030385
2016-06-25 08:07 UbitUmarov Note Added: 0030762
2016-06-25 20:24 Diva Note Added: 0030775
2016-06-26 00:35 UbitUmarov Note Added: 0030778
2016-06-26 00:50 aiaustin Note Added: 0030779
2016-06-26 00:50 aiaustin Status patch feedback => resolved
2016-06-26 00:50 aiaustin Fixed in Version => master (dev code)
2016-06-26 00:50 aiaustin Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker