nPoseTeam / nPose-V2

nPose is an LSL script for use in Second Life® that allows one or more avatars to sit on (and otherwise control) objects and rez props, without poseballs. A versatile animation system/engine.
10 stars 3 forks source link

More issues to discuss with SCHMO(E) #39

Closed HowardBaxton closed 9 years ago

HowardBaxton commented 9 years ago
  1. The Syntax and real world functionality seem to be in conflict.

SCHMO|seat#[|animation[|<0,0,0>[|<0,0,0>[|facial[|seat name]]]]]

This syntax suggests that the only required items are SCHMO and seat#, yet a line below makes no sense to use:

SCHMO|1

Next I thought well maybe a line such as SCHMO|1||<2, 0, 1> would make sense. However this line gives an error "Could not find animation: ". Thus I believe the syntax requires the animation and should not be one of the optional items. To make animation optional, the code line should look something more like this: if(index==2 && llList2String(params, 2) {. Now the above NC line works. This could be done for all these items.

Next I tried something like this: SCHMO|1|otherAnimation. I was thinking this made sense because I didn't want to change any of the other items from the slots list. This does work until I needed to make another SCHMO line that did require a position change. I added a second NC but after switching to this new pose set and then back to the one above, the position was wrong. This leads me to also believe that position and rotation also cannot be optional.

Next I tried making all SCHMO(E) pose sets within BTN cards. This appears to work well until some contents of the build change. The changed event checks if our last card name exists and runs DOPOSE on our BTN NC. The slots list then becomes empty for some reason and no one can sit without running a pose set with ANIM lines. I thought to try tracking this down in the scripts but will be difficult when we start out running DOPOSE on a NC that should be DOACTION. The better fix for this is to be sure to do SCHMO(E) in SET type NC's.

My recommendations are as follows:

  1. Remove the ability to use SCHMO(E) in BTN cards. (This is easier than sorting out how to handle the changed event.)
  2. Change code and syntax to read as follows:
    SCHMO|seat#|animation|<0,0,0>|<0,0,0>[|facial[|seat name]] SCHMOE|seat#|animation|<0,0,0>|<0,0,0>[|facial[|seat name]]
LeonaMorro commented 9 years ago

SCHMO(E) Syntax:

I try to make a short table out of the currently possible combinations:

CMD valuation
SCHMO(E)|seat# useless
SCHMO(E)|seat#|animation can be usefull in some cases
SCHMO(E)|seat#|animation|position can be usefull in some more cases
SCHMO(E)|seat#|animation|position|rotation usefull but not always*
SCHMO(E)|seat#|animation|position|rotation|facial very usefull but not always**
SCHMO(E)|seat#|animation|position|rotation|facial|seatName always good

(* you can expand your above example and say: If I set a facial in one SCHMO(E) command it stays if it isn't removed in other SCHMO(E) commands .. ) (\ you can expand your above example and say: If I set a seat name in one SCHMO(E) command it stays if it isn't removed in other SCHMO(E) commands .. )

My goal was to give the user the maximum of freedom in creating the command (even if he/she has to think about what he is doing). I think your goal is to take the user by the hand and eliminate the need of thinking about what he/she is doing (Which may result in less support questions). I think both are good goals. Restricting the command to only work with a certain number of parameters would also require an additional line of code to the script (Thats why I didn't disable the SCHMO(E)|seat# so it is valid, legal and useless but also does no harm). The syntax description SCHMO|seat#[|animation[|<0,0,0>[|<0,0,0>[|facial[|seat name]]]]] currently reflects the code, not the usefulness. After all that said I could think of a third way which may obtain your approval: We could change only the documentation to:

Syntax: SCHMO|seat#[|animation[|position[|rotation[|facial[|seat name]]]]] Recommended use: SCHMO|seat#|animation|position|rotation[|facial[|seat name]] or if we also like to respect * and **: Recommended use: SCHMO|seat#|animation|position|rotation|facial|seat name

LeonaMorro commented 9 years ago

Remove the ability to use SCHMO(E) in BTN cards: Currently we remember the cardName on an incomming DOPOSE_READER and I guess thats the problem. Instead of this we could/should remember the card if the assignSlots() function is called. (Done in: 8e744bdc50da3230a9a77a6863cf15743d6702e0)

LeonaMorro commented 9 years ago

Yes, I also remembered our disussion about the (NOT)SATMSG and I also saw that this is (almost) the same problem. (Almost because I see a little difference but it isn't worth to discuss it here) We also see that all (but one) of the 6 variants may be usefull in a build (a build may contain only animations that don't make it neccesary to use the position oder rotation). I also guess that Pro and Contras are exchanged (I agree to all of them and I accept each decission). There seems to be three ways to handle it: the current: SCHMO|seat#[|animation[|position[|rotation[|facial[|seat name]]]]] your recommendation: SCHMO|seat#|animation|position|rotation[|facial[|seat name]] and the one that always work: SCHMO|seat#|animation|position|rotation|facial|seat name

HowardBaxton commented 9 years ago

Taken care of all the issues here. Time to close.