nposeteam / npose-v3 Goto Github PK

If there are 2 or more SCHMO lines in a notecard where each have SATMSG or NOTSATMSG lines, only the menu user's slot should have new SAT and NOTSAT updates. The current result is that all slot strides read and process the msg lines.

The problem arises because the SCHMO line is run separately from the SATMSG and NOTSATMSG lines. The SCHMO lines are working perfectly and only updating the menu user's slot stride. However the SATMSG lines have an incorrect visibility to only update the menu user's stride and will update every stride's SAT and NOTSAT msg data.

I have built a flag which seems to successfully limit these SCHMO SAT and NOTSAT lines to only the menu user's stride. This is a mod to the core script only. I will submit the changed core in a new branch of of the currently released version as a proposed fix for review. If it is found to be an acceptable fix, I'm hoping it can just be merged into the other branches.

The list elements are cast to integer inside the menu script. Thats wrong.

Howard wrote:
I found a couple places where the default card is run and the Slots list needed to be cleared as well as SlotMax needed to be set to zero.
see see 5a97170

Would be nice to be able to grab display names for sitters by seat. In the case where the seat is empty it would use the seat name instead (similar to how change seat menu works).

Useage example:

MENUPROMPT| The poses in this menu interact with %DISPLAYNAMESEAT2%.

Amr has suggested this enhancement stating that some users are getting confused and seem to have a lot of trouble adjusting their offsets when he (as the owner) could adjust offsets for them with far less issue. He suggests this enhancement would be an owner only function but still allow individuals to adjust their own.

This would require something like the following:
Add a function to return all sitters to a menu for selection
After Owner selects the sitter to apply offsets, pull the Offsets menu
Upon any changes in the Offsets, apply these changes to the sitter and save using sitter uuid into offsets

I can see that this is possible to do but have no idea what impact this could have on used memory. It makes sense that if this feature were available, others would use it as well.

Howard wrote:
I noticed that the Slots list had extra stride spaces at the end and every time seatupdate would fire, the extra spaces would grow. I thought at first these were a full stride each but they were not. I tracked this issue down to being the integer variable 'LastStrideCount' being initialized to 12. Since the instruction flow has changed from V2 to V3, this is now an issue and needs to be initialized to 0. I remember initializing this number high to get around some issue I thought I was having.
see 5a97170

Make it possible to play multiple Animations at once. Example:

ANIM|animation1,animation2,animation3...
SCHMO|1|animation1,animation2,animation3...
SCHMOE|1|animation1,animation2,animation3...

While chatting new positions to local and also support moving the slave script to another linked prim the slave always assumes there is a linked set when it tries to grab the root prim name and saves the name of linked prim 1. This creates an issue for single prim builds as the root prim here is 0 and prim 1 doesn't exist.

This is the same for the Dump function.

It is not longer neccessary to send the chatChannel as rezParam because the chatChannel is build from the rezzers prim uuid (which is known in the prop/Adjuster: OBJECT_REZZER_KEY).
This would give us at least 3 bytes of new data we could send to adjusters and/or props during the rezzing.
I don't think we will need the 3 bytes for the Adjusters, but for props it could become very handy to track them via a unique id (given when rezzed)

I have been able to play animations sequentialy with a Set: notecard contents such as this:

TIMER|myTimer| 0 |ANIM|LPS01|<0.525318, 0.0000, 0.100>|<0.000000, -90.000000, -180.000000> TIMER|myTimer| 8.917 |ANIM|LPS02|<0.525318, 0.0000, 0.100>|<0.000000, -90.000000, -180.000000> TIMER|myTimer| 20.167 |ANIM|LPS03|<0.525318, 0.0000, 0.100>|<0.000000, -90.000000, -180.000000> TIMER|myTimer| 65.833 |TIMER_REMOVE

Because I created these animations in Blender I know exactly how long they last, and so I can schedule them to play sequentially using the timer as demonstrated above.

But there are problems. It does not happen every time, but very often when an animations transitions from a just ended one to the next the avatar is very briefly dislocated from the position it was intended to be in. It looks to me like lag regarding reading the next position and orientation vectors. What I think is a manifestation of the same problem is on first sitting when the default animation plays. The first instant my avatar is horizontal above ground with its feet on the sit object's origin point. This seems to last for only one or maybe just a few animation frames, and them the avatar is positioned where it is expected to be.

Is there a solution to this? Is there a better way to play the animations sequentially?

Since in the above example the position and orientation vectors are the same for every animation it seems wasteful of script execution time to set the same again for subsequent animations in the sequence. An option not to have this might be a way to solve this for between animations in future nPoser versions.

Currently Adjusters will only rezz inside the 10m radius.

I have rewritten parts of the Adjuster and Slave script to do a proof-of-concept of Animesh adjusters. The problems I saw are all solved but there is one problem I didn't saw, which will make the project (almost?) impossible:
In the Slave script there is the function "MoveLinkedAv" where the Avatar is moved to his final postion. But this positon isn't the position where the adjuster is, but it is offsetted by a few fancy lines:
avpos.z += 0.4;
llSetLinkPrimitiveParamsFast(linknum, [PRIM_POSITION, ((avpos - (llRot2Up(avrot) * size.z * 0.02638)) * localrot) + localpos, PRIM_ROTATION, avrot * localrot / llGetRootRotation()]);

Questions:
a) Why? Are these lines to do some offset for different Avatar heights?
b) What are these values: 0.4 and 0.02638?

Whith this offset the Animesh Adjusters had to be offsetted the same way like the Avatars inside the slave, while still reporting the unoffsetted pos/rot values to the slave (because these unoffsetted values are going to the NC) and even if this would work then the piviot point of the adjusters are at the wrong place making rotations around the x and y axis nearly impossible.

There is a feature request https://jira.secondlife.com/browse/BUG-139336 that would solve this problem but until something like that is implemented, Animesh Adjusters will not working in a good way.

Howard wrote:
I tracked this problem down to the Slots list not being cleared when ANIM line is found.
see 5a97170

A request has been made to add options to unsit new sitters.

1. A complete lock to not allow menu or sitters except for owner.
2. A lock to not allow more sitters. Example: If owner and a guest are on a vehicle set up to allow more sitters, lock to not allow any other sitters to prevent unwanted boarders from sitting. Not allow more sitters. This option can be turned on/off on the fly cause obviously sometimes more sitters are wanted and other times the current sitters are enough.

These suggestions were made by Coca Yven who sells boats where a hud is used to rez the sold boat. His customers would have to rez the hud on the ground, pull the boat out of the hud and rez it, and rez the boat to make the adjustments. The new owner would then have to pull this new copy of boat back to contents and then replace the version that is in the hud. This is much hassle for those customers to do.

All works well if the numbered seats are used, the problem arises if the numbered seats are not used and new sitters click the root prim to sit. Here's what happens:

The first sitter will sit as usual and uses the root prims sit target (link number 1).

The second sitter is assigned to the sit target in link number 2. All is well if link number 2 prim is not numbered or is numbered for seat 2. However if this linked prim is using numbered seats and this particular prim with link number 2 is using seat 3, then the sitter will be assigned to seat 3.

The third sitter is assigned to the sit target in link number 3. Same story as with the second sitter. It can work or it will be messed up depending on the seat numbering.

((The same issue occurs in SL and on OS where it was discovered.))

Howard wrote:
I also noticed the chatchannel is broadcasted via link message every time nPose sees a new sitter. I'm not sure this is required for proper functioning of the program but I guess it isn't hurting anything. We can remove that instruction from the Changed event or leave it, I'm open to suggestions.

Feature request: I would like to have a command that sends a text message into local chat that all within chat range can see. I want to give the user the option to send emotes that are coincident with each animation in animation sequences set up to play by the timer. The developer should have the option to give the user the ability to turn the emotes off so that animations could also play silently.

More of a query than an issue.....do the Npose scripts that Christine Nyn did for InWorldz still exist in any form and is there any way we could get them, IW's sinking ship took them down with it....

To detach the message "/die" is send from core via chatChannel. In DigiWorldz the leading slash is removed.

open the nPose menu
let the nPose object cross a sim border
click a menu button
-> no action and no remenu

I currently don't know if it is a LSL restriction or a nPose bug
tested with nPose V3.10
doesn't work with nPose V2 too, as reported by COCA

The two UDP sample scripts show how to create and update a UDP (I guess if it doesn't exist the update link message to nPose creates it?) But what they do not show is how to access the UDP values for use in the script.

Maybe create an example where the UDP value is fetched, and then used to fire of a SET card depending on its value?

Current license text:

The nPose scripts are licensed under the GPLv2 (http://www.gnu.org/licenses/gpl-2.0.txt), with the following addendum:
The nPose scripts are free to be copied, modified, and redistributed, subject to the following conditions:

• If you distribute the nPose scripts, you must leave them full perms.
• If you modify the nPose scripts and distribute the modifications,
  you must also make your modifications full perms.

"Full perms" means having the modify, copy, and transfer permissions enabled in Second Life and/or other virtual world platforms derived from Second Life (such as OpenSim). If the platform should allow more fine-grained permissions, then "full perms" will mean the most permissive possible set of permissions allowed by the platform.

Issue:
If you compile a nPose Script with an experience (for example the experience enabled temp attach script or the upcomming prop script) you are forced by the license to give it away FullPerm which is exactly what you shouldn't do ...

Affecteted Versions: V3.00 and later

Line 467 of the Core script we find this line:
rezParam=rezParam | (quietMode << 1) | ((propGroup & 0x2F) << 2);

The calculation (propGroup & 0x2F) will only allow 0 to 15 group numbers, after that, they start over at 0 again, so prop group of 16 will become 0 and be sent to the prop plugin as normal prop, etc.

The wiki states the limit is 63 (https://github.com/nPoseTeam/nPose-V3/wiki/NC-Contents#prop).
Which do we want the limit to be?

If using a "~" inside the MACRO, UDPLIST and UDPBOOL names or values they will not work.
(wrong parsing inside the menu script)

I've been seeing this happen now and then but didn't pay a lot of attention to it. If adjusters are rezzed and the parent build is taken back to inventory or deleted, the Adjusters do not automatically die.
I've tracked that issue down and found that in the adjuster script, somehow we've not grabbed the parent key at all. In the timer the script checks if the parent is still around and if not, the adjuster dies automatically. Without the parent key, this does not happen.

• this problem doesn't exist in nPose Gecko
• I don't know if it exists in nPose V2 (has to be evaluated)

In nPose Core you can find the following lines:

        if(change & CHANGED_REGION) {
            llMessageLinked(LINK_SET, SEAT_UPDATE, llDumpList2String(Slots, "^"), NULL_KEY);
        }

and I guess that the purpose of this lines is to restart the animations on region change. The lines are untouched in V3 so I guess it may be a problem in the slave.

@HowardBaxton : Do you have an idea which change in the slave may cause this issue?

Does not understand RLV options.
Does not instruct you on what to do with your SATMSG/NOTSATMSG

Howard wrote:
At lines 268 and 307 within the ProcessLine function I've added a couple fairly simple routines which allow SCHMOE lines to be used within the default card. It simply adds a STRIDE to the slots list and gives SCHMOE a stride to modify. This has an additional benefit of enabling a menu user to add seats on the fly. The drawback to doing so is that changing from 4 available seats down to 2 is not possible, once added they stay added. This is my reason for tracking down Bug 2 and Bug 3. All I wanted to do is put an example together and open discussion about it but ended up chasing bugs in order to make the example. This one is open for discussion if you have other ideas, objections, or suggestions.
see 5a97170

Messages for the commands:
PLUGINCOMMAND, PLUGINMENU, DEFAULTCARD, OPTION, UDPBOOL, UDPLIST, MACRO and all user defined commands
are not send to props.

malfunction in assignSlots function introduced in V3.10

While making a line dance pad where multiple sitters could be added and using the same pose, we tried activating a sync just after a new sitter arrived to get all sitters to dance in sync.
What we found is this:

• When three or more sitters had successfully sat, a new sitter would sit
• Sitter would initially be positioned at the sit target position
• Sitter would animate
• Sync would kick in and sync all sitters
• The processes would finish and leave that new sitter positioned at the sit target. The slave would not move them to the final position

The fix was to add a timer to delay the sync command for a short period of time which allowed the slave to finish the "new" sitter process before sending the sync command.

We have seen something very similar while changing poses in the new alpha system for animesh adjusters.

With the advent of UDP's determining which menus are available to each user, the possibility exists for a user to have a menu already open, which might then be made invalid by the state change of a UDP by another user.

Redrawing everyone's menu when a UDP changes state is problematic. Instead, if there were a remenu by seat command it could be used by the creator to redraw the menus only for those seats which would be impacted by the state change of the UDP:

REMENU|UDPBOOLE to monitor for state change |seat list (filterable by UDPs)|flag

The seatblist filterable by UDPs is important to allow the creator to cause a menu redraw only for those seats who are affected by the state change. Among other cases, it would allow the creator to cause a menu redraw only if a UDP changed state in one direction (I.e. from true to false, but not from false to true) thusly, (assuming the command executes after the UDPBOOLE is updated):

REMENU|isOpen| 1 ~ 2 & !isOpen|1

The flag would be used to include/exclude the user who's action precipitated the state change. Reason being, some user likely clicked a button which caused the UDPBOOLE to change state, so their menu is getting redrawn already and we wouldn't want it redrawn twice in a row.

Can we have a long term stable version, or should I just ignore nPose 3 and fork myself my own nPose 2? Removing core functionality (DEFAULT for example) is not something I want to deal with running my store.

I went through this with Wendy's Open Collar where the API changed constantly, not interested in doing it again.