The folowing is a copy/paste from each one of the AV Sitter scripts. In them it says (the begining comments):
/*

• [AV]sitB - Main Memory script - needs [AV]sitA to work
• (OpenSim version)
• This Source Code Form is subject to the terms of the Mozilla Public
• License, v. 2.0. If a copy of the MPL was not distributed with this
• file, You can obtain one at http://mozilla.org/MPL/2.0/.
• Copyright © the AVsitter Contributors (http://avsitter.github.io)
• AVsitter™ is a trademark. For trademark use policy see:
• https://avsitter.github.io/TRADEMARK.mediawiki
• Please consider supporting continued development of AVsitter and
• receive automatic updates and other benefits! All details and user
• instructions can be found at http://avsitter.github.io
  */

I would like to suggest that you update the version number to reflect the current release of "AV Sitter2.2-03.01". I believe this would lessen any cunfusion about what's out there available from sources other than github.

Thanks for the consideration.

Regards,
Gary Hodges (a.k.a. Gary Kohime in SL & OpenSim)

The bug that surfaced in AVsitter/AVsitter#33 prompted me to add some guidelines about how the commits should be created and how they should appear in the history.

It probably won't be easy to word this in a way suitable for the contributor guidelines, but here we go...

• Commits should change one thing at a time. By that I don't mean one line at a time, or one character at a time. More like one "atomic" feature at a time, so that the repository is in a working state after every commit, but trying to avoid commits that make several unrelated changes. There are several purposes: to ease review by others to ensure there are no new problems, to ease checking the history and to ease rolling back a commit, should that be necessary.
  • For the latter reason, it's best if PRs are not squashed. I usually use "Rebase and merge", though "Merge" would work as well. (*) For small amendments to the PR, e.g. something that was overlooked in one of the commits, it's best if the submitter amends the commits as necessary and force-pushes.
• The commit message should describe the change as best as possible. The first line is the title and should summarize the commit in about 70 chars if possible; if more explanations or some clarifications are necessary, leave a blank line under the title and explain further below that.
• Indentation and formatting changes cause very messy diffs, because they tend to sync with the wrong lines. It's best to separate those from the functionality-changing ones, while announcing that there are no code changes otherwise, in order for the reviewer to focus on what's important without having to decipher the messy diffs.
• Sometimes, while making a change we spot a part of the code that needs an unrelated change, and we go ahead and fix it before we forget. For those cases, git provides the -p flag for the commit and add commands, which allows selecting which changed lines go into the commit and which ones don't, or even editing the diff of what goes into the commit. To avoid mixing unrelated changes, you can make use of that.

(*) Both have pros and cons. "Rebase and merge" adds the new history at the top of master, which is good; however, the commit ID changes, leaving a lingering branch that git complains about when trying to delete it, saying it's not merged into master (which isn't true). This one leaves the repository history in the cleanest state. "Merge pull request", on the other hand, merges master and the PR commits without adding them at the top, and creates an extra merge commit. I find that a bit messier most of the time. I'm not a big friend of merge commits when they're not strictly necessary.

I believe the documentation for the MLP converter has the calculation of the offset backwards. It should be the new position minus the old one, typically about <0, 0, .5>, not <0, 0, -.5>.

Add documentation for WARN 3 (disable all permissions warnings), added in AVsitter/AVsitter#90

I've noticed that http://avsitter.github.io seems to have stopped auto-updating to reflect changes made to the pages in the AVsitter documentation repository. I assume it's because of the "Dependabot alerts" seen when I log in: https://github.com/AVsitter/avsitter.github.io/security/dependabot which seem to indicate we need to update some dependencies.

I'm making this issue as I am not sure how to solve the issues and get the documentation pages auto-updating again. Hoping that Sei will take this up if familiar with resolving the conflicts, otherwise I will look at it in more detail when I get a chance.

Please see AVsitter/AVsitter#38 for a brief discussion.

In https://avsitter.github.io/avsitter2_avpos.html#set there is a link to https://avsitter.github.io/avsitter2_sittargets.html#assigningsittargets

That link doesn't go to the appropriate anchor. Maybe the intended destination can be adjusted to add an anchor with the name "assigningsittargets".

LMSOURCE 0 means it accepts link messages from the current prim only.

LMSOURCE 1 means it accepts link messages from any prim.

The change introduced in AVsitter/AVsitter#103 needs to be included in the documentation.

At the end of this page there are a few extra commands (HELPER, KFM, LROT, WARN 0, WARN 2) that are linked to an external Q&A page in the avsitter.com domain.

My suggestion is bringing that documentation into github, perhaps creating a Special Commands submenu under the Step by Step Guides submenu. Then, each page would link to the original Q&A page they come from at the end (and beginning?), for those that want to read the whole discussion in those pages.

What do you think of this?

[AV]root uses LM 9005 to fire the dialog.
[AV]select expects LM 9009.
Why?

Also, there is discussion in the blog or whatever of an update (Feb 2018) to include 9004 to force the top level dialog. Thats not in any of this source code.

....

Im working on updating a boat and Im not sure what version it has (Im in dialog with the builder). The boat [AV]select responds to 9005, and brings up the top level ("role select" ) dialog, and not [SWAP] button. This is the version I want. Boat scripts ae no mod of course.

But if I drop in the [AV]select & [AV]menu (changing 9005 to 9009) from here the dialog opens one level down, the "pose select" , and [SWAP] to cycle through.

What I want to do is to not have the dialog presented when the first person boards the boat (skipper) but to have it presented for the crew. An easy enough hack if only I had the right source code.

GitHub doesn't support to decide which branch or tag of the documentation to publish from, it always publishes from master.

This means that the documentation of changes that are not yet released, is visible to everyone, meaning features are visible when they shouldn't.

To prevent that, I suggest keeping a "devel" branch and merging from it when a release is made, and tagging both at the same time to help keeping track.

Using the utility to convert MLPV2 menus to AVsitter
Two passes are required. You should complete this before you work on setting up the menus in AVsitter.

-in your MPLV2 object, pull out all the MLPV2 scripts, and leave the notecards, props, and animations. Put in the AVsitter scripts, and then the MLP-converter script.
-It will run and output to chat line for an AVpos card, with MLPV2 positions converted. Copy and put that in the AVpos card, and (i always reset the scripts not sure if this is required)
-Restart and check the positions, need adjusting? Figure out how much (bring up the helper sticks, note the position numbers, move it to the correct location, note the new numbers, and calculate the difference), for me its about Z+0.5. Make a vector expression: <0,0,0.5>
-Put that expression into the Description field of your object, that is in the first tab under edit.
-Put MLP-converter back into the item, and let it run again. The new output should be corrected (its not perfect on menu conversions)
-You want to do this before you go fixing the AVsitter menu system, to match the old MLPV menu

A question that comes up often in the group is how to use the GitHub scripts. There are two main issues that people are having:

• Wrong naming of scripts (usually because they make the .lslo extension be part of the name)
• Dropping the [AV]helper script in the build, instead of preparing an object named [AV]helper containing it.

Including a note in the main docs regarding this would hopefully improve the situation.

I've just come in from MP in second Life. AVSitter 1 & 2 are both selling for 2,999 L
How else can I obtain the new CC versions?
Thank You
Gypsy
(DianeHolden007)

https://marketplace.secondlife.com/p/AVSITTER2-REVOLUTIONARY-Multi-Pose-System/2277498

This is for the Contribution guidelines.

The text says:

For small amendments to the PR, e.g. something that was overlooked in one of the commits, it’s best if the submitter amends the commits as necessary and force-pushes.

I'd like it to specify that, if the commit has already been reviewed, not to amend it unless instructed to do so.

I suggest the following wording:

"For small amendments to the PR, e.g. something that was overlooked in one of the commits, it’s best if the submitter amends the commits as necessary and force-pushes. But if the code has already been reviewed, submit it as new commit(s) instead, unless instructed otherwise. This will allow the reviewers to easily check what exactly has changed between the changes that were already reviewed and the new changes, without needing to go over the full set of changes. If the original changes were small and the new changes are assumed to be small, or cover the majority of the other ones, the reviewer may choose to indicate to amend the commit."