- build-aux.py:
- Remove commented line
- Expose '-' for stdin/stdout in setvars (it was implemented but not exposed)
- Makefile:
- Default to gcpp as preprocessor instead of mcpp.
- BUILD_GUIDE.md:
- Now both Python 2 and 3 can be used, so remove the version requirement.
- mcpp is not available in precompiled form for newer Mac processors, so indicate cpp instead.
- Explain how to modify Makefile for mcpp.
- Other minor changes
I've got an issue reported several times by customers with furnitures moving with KFM. They get this error:
`Cannot use a script to move a linkset while it is playing an animation. Stop the animation first.`
Before this fix, the codes follow this workflow:
- it pause KFM
- it sleeps 0.15 seconds
- it updates the link position
- it sleeps 0.15 seconds
- it restarts KFM
I think you've put these 0.15 sleep before and after because both scripts `sitA` and `sitA 1` (and more if there 3 ore more sitters) can be slightly unsynched, so it is good to give a little delay to avoid that `sitA` restarts KFM while `sitA 1` hasn't changed the link position yet.
But it looks like the first llSleep is not only needless, but even increases the risk of error. Why sleeping 0.15 seconds between the KFM pause and the link position change? It makes the critical situation longer. The error occurs quite often. And it becomes alsmot systematic if both sitters select a pose roughly at the same time.
I did a test, sitting on a furniture with a friend. I asked her to click many times on all buttons. I was doing the same. In less than 20 seconds, i got the error 5 times!
Then i did the same test, remove the first llSleep, and keeping the second one, that i have increased a little bit to 0.2 seconds. Same test with this friend: 0 error.
This change has the potential of saving memory when there are multiple poses with the same position or rotation.
Based on a suggestion by @ohhmye (thanks).
The new versioning scheme uses a letter instead of the dash. The letter is a p for a work-in-progress/pre-release version, or an r for a release version. For example:
2.2p04 - work in progress for version 2.2r04
2.2r04 - release version (2.2-04 with the previous scheme)
The two digit number will be increasing even for minor changes. The last minor changes indicator is dropped.
This partially solves a race condition when avatars revoke animation permissions on stand, but the message needs to travel through several scripts and, in case of extreme lag conditions, can attempt to stop animations after the revocation arrives, resulting in an error.
It still suffers a TOCTTOU race, as demonstrated by the reporter. That race is probably unsolvable.
Fixes#119. Big thanks to @ohhmye for reporting and investigating this bug.
- Add a Quick Summary for the impatient / tl;dr.
- Try to refer to both SL and OpenSim without discriminating.
- Clarify when to save to a box (step 5). A user was confused by this step.
- Make emphasis in "Compile successful/Save complete" to ensure they don't get an error, especially now that it will err if not saving in Mono.
- Add misc. notes.
BUTTON is documented to pass the UUIDs of the controller *and* the sitter when they are different, separated by a "|".
ADJUST is not documented to do that (yet), but it behaves that way.
Both behaviours are undesirable for generic scripts that respond to a link message without being specifically designed for AVsitter, because they don't expect the extra UUID. This can be seen as an AVsitter shortcoming, therefore we implement backwards-compatible workarounds.
For ADJUST, the AMENU argument's range has been extended:
0, 1 and 2 behave the same as before.
4, 5 and 6 behave as 0, 1 and 2 respectively, but also inhibit sending the second UUID.
For BUTTON, two special values have been added for the ID field: <C> and <S>, which will be replaced with CONTROLLER and SITTER respectively. For example:
BUTTON text|num|str
behaves the same as before, sending both CONTROLLER and SITTER in the UUID field when they differ; however:
BUTTON text|num|str|<C>
always passes only the UUID of the person who controls the menu. Similarly for <S>.
Follow-up to a65d7cd, which failed for the main menu. That's because current_menu is -1 for the main menu.
Since current menu is either -1 or points to a MENU entry, it's safe to add 1 to it and bring it to a correct range.
While on it, remove redundant `if`.
Per bug report by RiderDavis.
Fixes#95.
When the same BUTTON appears in different submenus, with different parameters, pressing it always picked the one that appeared first in the notecard.
Fix that by making the search start at the current menu.
Per bug report by AceyXx.
