search

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

Slots list discussion #86

Open LeonaMorro opened 8 years ago

LeonaMorro commented 8 years ago

Howard: If it is possible to dynamically build the slots list only when needed (handle a new sitter extends the slots list). I haven't given this enough thought to know if it is possible but there are some high hurtles to overcome. This could eliminate the differences between ANIM and SCHMO(E). It could also cut down on memory usage as we are not processing a bloated slots list. Maybe the slave is the only script to benefit from this. I guess just keep this idea in mind as things progress?

LeonaMorro commented 8 years ago

I guess you are talking about it because the slots list may become / is a big chunk of data that is send via a linkmessage on every change? Yes it is. And like you I also see that an improvement would be fine. But I would not try to make it some kind of dynamical, but to split it into several list for the different scopes. (But maybe that is the kind of dynamic that you talk about.)

First let us check what informations a slot in the list currently contains: 1) animation name 2) avatar position 3) avatar rotation 4) facials 5) avatar key 6) SATMSG 7) NOTSATMSG 8) seatName (2 parts: internal name and userdefined name)

All this informations are neccesary (except the internal seat name "seatX", which is redundant), but none of the scripts need them all. So lets see, which script needs which informations (beside the slotnumbers):

Core:

Slave:

Menu:

SAT/NOTSAT Handler:

RLV+:

If I should create a database with the given information pieces I would handle almost any piece of them in different tables, because they represent "different topics" and I guess it would be good to do so in our scripts also. I would make the following lists:

Which script should hold which list? (R: readonly; RW: readWrite)

Core:

Slave:

Menu:

SAT/NOTSAT Handler:

RLV+:

Which list should be propagated via linkmessage on change? (that are the lists which are marked as R in some script)

To minimize the number of linkmessages it could be possible to merge the Slots and the SlotsAvatars list.

This all are only my first thoughs and (maybe) there are problems that can't be solved.

HowardBaxton commented 8 years ago

I suggested this line in the hopes that maybe we could do the dynamic slots list in an effort to remove the need for that DEFAULT pose set when only SCHMO(E) are used in the build. I think currently a builder is probably making more seats available than they would usually get in world (I would). This is the bloat which came to my mind. Maybe it isn't possible. I was also thinking the slave did not need to know about empty slots but that is incorrect.

To follow your line of thought I think the core needs the entire slots list to make the decisions as to who sits where (which stride to put a sitter into) and send out the complete seatupdate. One more point is that we really shouldn't limit the seatupdate data because we have no way of knowing what information a custom plugin might need.

Gosh wouldn't it be nice to have database access.

The Menu and SAT/NOTSAT HANDLER only retain a subset of the slots list currently. (i.e. Each script processes the seatupdate and only retains what it actually needs.) The slave script is currently holding the entire slots list and probably shouldn't. It could get rid of (NOT)SATMSG information.

The internal seatName is currently used in many scripts to decide which seat a sitter is in. I agree this could be done in a smarter way than it currently is done. Perhaps simply find the slots list stride for a specific sitter. Early in the development of AssignSlots function I was following a different line of thought and never really removed that unneeded bit of info.

LeonaMorro commented 8 years ago

To follow your line of thought I think the core needs the entire slots list to make the decisions as to who sits where (which stride to put a sitter into) and send out the complete seatupdate.

The core don't need all informations that are currently in our slots list to make that decision. The core only need to know what slots exists and who is sitting in which slot.

One more point is that we really shouldn't limit the seatupdate data because we have no way of knowing what information a custom plugin might need.

Thats true, but there is no need to send all the data in that big chunk of data which is currently send via the seatupdate.

So there are ways to do it without sending that big chunck of data

Gosh wouldn't it be nice to have database access.

Yeah! .. Please also vote for no memory limit and multidimensional arrays and ... To be continued ;) IMHO: The memory limit is the worst: it forces us to separate scripts and write protocols for the scripts to communicate which each other and doing funny stuff to keep that all in sync. I guess we could write nPose with half the of the memory consumption if there wasn't a memory limit. Oh .. and of course it would use less CPU time because there is no need for all that overhead. I realy don't know why LL doesn't see that the memory limit is a very very bad idea. Please vote here: https://jira.secondlife.com/browse/BUG-9382

The Menu and SAT/NOTSAT HANDLER only retain a subset of the slots list currently. (i.e. Each script processes the seatupdate and only retains what it actually needs.) The slave script is currently holding the entire slots list and probably shouldn't. It could get rid of (NOT)SATMSG information.

That isn't exactly that what I have in mind. But I guess you know that.