Adjust issue when save

[HowardBaxton]

Emilie Muggins: each time you change something that implies rebuilding the menu like renaming a set nc or adding new ones the av revert back to the default nc which is not a problem but it also kills the hud so you have to detach reattach it

[HowardBaxton]

When current running pose name is changed, the core initiates a reset. This clears hudId var and the hud is no longer responsive.

The only reason for the reset is to get the menu up to date which is being done in state_entry of the core. As noted in the core script, this is also being handled in the menu script. Removed this code from the state_entry of the core and also removed the reset commands in the changed event of the core. This fixes the issue and also cleans up the code.

I will create a branch from the Grouping branch with this and other changes.

[HowardBaxton]

I find that the core needs to run this on reset or the changed event does not work after the slave is reset. No new sitter is allowed.
When inventory changes, the menu does a NC_READER_REQUEST but the core seems not to get the end result.
The core must have a card to fill the slots list. Currently there is no path for getting the default pose to the core other than when it finds the default for itself. There are several ways to get this info to the core, I am just not sure what way is most effective.

[HowardBaxton]

Also the slave does not have a slots list after reset and does not get it until a seatupdate is done. There is no harm in this action because as soon as we have a new sitter, the slave gets the update.

[LeonaMorro]

You removed a few resets inside the core. That means that the DEFAULT NC is not running after changing a script. I don't now if that is bad for every day usage, but if you develop a script you have to reset the core after you saved your script to get for example the global options or a new Slots list.

[HowardBaxton]

I removed these resets because the adminhud stops working any time the
reset is invoked. This was happening when a notecard was saved. The hudid
was being cleared. Also assignslots was being run causing any sitter to be
assigned new seats.

The worst problem I observed was when the slave is reset, it would not have
a slots list until someone sits. Seatupdate then runs and all is well with
no bad effects.
On Jul 12, 2016 5:00 AM, "LeonaMorro" notifications@github.com wrote:

You removed a few resets inside the core. That means that the DEFAULT NC
is not running after changing a script. I don't now if that is bad for
every day usage, but if you develop a script you have to reset the core
after you saved your script to get for example the global options or a new
Slots list.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#72 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADcmopiHIS_K4vt-u3h_p5tQMyrTgTn0ks5qU4HBgaJpZM4G0Z0q
.

[LeonaMorro]

Well, I don't think that removing the resets is a good idea. As an example, let us assume a setup like this:

NC: DEFAULT:default
ANIM|...
LINKMSG|207|BTN:1

NC: BTN:1
Do some nice an neccesary stuff

The old code resets the core if changing the BTN:1 card, with the new code I guess nothing will happen ...

Let us first split the problem into to separate problems. As Emilie Muggins said:
1)

each time you change something that implies rebuilding the menu like renaming a set nc or adding new ones the av revert back to the default nc which is not a problem

I also don't see it as a problem
2)

but it also kills the hud so you have to detach reattach it

Well that is a problem. But maybe we should not try to fix it by removing the resets but by improving the HUD protocol to allow a reconnect after a reset.

[HowardBaxton]

On the other side of the coin, if we do everything a reset would do in the changed event without destroying the current state of the system, we accomplish protecting the HUD protocol and maintain the slots list to keep all sitters in their current seats... etc.

This side of the coin says do what needs to be done when a card is modified or added rather than discard everything and rebuild.

[LeonaMorro]

Well .. that may also work.
I don't know if we will able to determine all things that have to be done to accomplish this kind of "soft reset" ... maybe it is much easier than I assume at the first moment.

Perhaps we should make a little list of things that could be changed inside the prims inventory and what should happen then.

We can add, delete and modify each possible inventory item. If the added, deleted and modified inventory item is a NC maybe we have to determine its relevance to nPose. so we have:

add a DEFAULT NC
edit a DEFAULT NC
delete a DEFAULT NC
add a SET NC
edit a SET NC
delete a SET NC
add a BTN NC
edit a BTN NC
delete a BTN NC
add a undefined NC
edit a undefined NC
delete a undefined NC
add a animation
edit a animation
delete a animation
add a script
edit a script
delete a script
add anything other
edit anything other
delete anything other

and of coure the script itself don't know what is added/edited/modified

[HowardBaxton]

Of course you're right about the script not knowing but I believe all of these things fall under changed inventory. It would be nice to act smart and only handle the situations which pertain to the moment in the script but we are really limited as to how much code we can write in SL. All we can do when inventory changes is to handle the situation as if it were important at the moment without destroying the moment (if possible).

[LeonaMorro]

The list above was to think about what could happen inside the inventory. As you said: we can not write code for each different event (because of the memory and because we don't know what exacly happens).
The question is: Can we react on all the different possibilities that are listed with a single piece of code that "do whatever is needed" and that will not destroy our "current state"? After thinking a few minutes about it I would say it is impossible.

All we can do when inventory changes is to handle the situation as if it were important at the moment without destroying the moment

Can you explain it a little more? Maybe I'm thinking in a wrog direction?

[HowardBaxton]

I think we must rebuild the menu any time a DEFAULT, SET, or BTN card is
changed, modified, or deleted.

I think it probably doesn't matter if we rebuild the menu in the case where
anything else happens in inventory. The system should currently respond in
time to handle any other situations.

If this script changes, it will be reset.

Well anyway this is my train of thought.

On Jul 15, 2016 7:41 AM, "LeonaMorro" notifications@github.com wrote:

The list above was to think about what could be happen inside the
inventory. As you said: we can not write code for each different event
(because of the memory and because we don't know what exacly happens).
The question is: Can we react on all the different possibilities that are
listed with a single piece of code that "do whatever is needed" and that
will not destroy our "current state"? After thinking a few minutes about it
I would say it is impossible.

All we can do when inventory changes is to handle the situation as if it
were important at the moment without destroying the moment

Can you explain it a little more? Maybe I'm thinking in a wrog direction?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#72 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADcmotM1mAM_Rd0VDejMaJQ5sX5yN8R_ks5qV5wigaJpZM4G0Z0q
.

[LeonaMorro]

I think we must rebuild the menu any time a DEFAULT, SET, or BTN card is changed, modified, or deleted.
I think it probably doesn't matter if we rebuild the menu in the case where anything else happens in inventory

yes. and because we don't know if a DEFAULT, SET, or BTN card is changed, modified, or deleted. we have to rebuild it on every inventory change. But we are not talking about the menu, we are talking about the core.

What if we changed for example a global option (or anything like it) inside the DEFAULT card? Then the DEFAULT card must be executed to let the core itself and/or any the other scripts know that it is changed. ->the "current state" is destroyed
Or if we delete the DEFAULT card with a global option (or anything like it)? Then we have to reset all global option in any script to its default value. ->the "current state" is destroyed.
I could made the same example for userDefinedPermissions ...->the "current state" is destroyed.

The longer I think about it the bigger my concerns. If we miss only one part ...
Imagine:
Someone (A) builds an object, changes a dozens NCs while building it and never resets the scripts. Then (A) gives the oject to another person (B). (B) reset the scripts and the object acts different .... only because we want to keep "the current state" while building ...

[HowardBaxton]

As for the core we check if the current card still exists and if it has
changed. If we meet these two tests we do the pose. This is an attempt to
maintain the current state and include any current changes.

In any other case, is it wrong to do nothing until a menu selection tells
the core to do something different? It could be wrong to reset.. and in
the given case is wrong.

Which is worse; reset when we know it is wrong in some cases, or do nothing
and wait for the next instruction knowing in some cases we could handle it
better (given tons of memory and scripting)?

This is the dilemma. The reset is causing a problem and removing the reset
although not the perfect solution is hopefully acceptable given the
restraints we work under.

If options change in the current card, the changes would/ should be picked
up. Otherwise in any other card would not be picked up until the card is
run. I think this is the safer action.

On Jul 15, 2016 9:36 AM, "LeonaMorro" notifications@github.com wrote:

I think we must rebuild the menu any time a DEFAULT, SET, or BTN card is
changed, modified, or deleted.
I think it probably doesn't matter if we rebuild the menu in the case
where anything else happens in inventory

yes. and because we don't know if a DEFAULT, SET, or BTN card is changed,
modified, or deleted. we have to rebuild it on every inventory change. But
we are not talking about the menu, we are talking about the core.

What if we changed for example a global option (or anything like it)
inside the DEFAULT card? Then the DEFAULT card must be executed to let the
core itself and/or any the other scripts know that it is changed. ->the
"current state" is destroyed
Or if we delete the DEFAULT card with a global option (or anything like
it)? Then we have to reset all global option in any script to its default
value. ->the "current state" is destroyed.
I could made the same example for userDefinedPermissions ...->the
"current state" is destroyed.

The longer I think about it the bigger my concerns. If we miss only one
part ...
Imagine:
Someone (A) builds an object, changes a dozens NCs while building it and
never resets the scripts. Then (A) gives the oject to another person (B).
(B) reset the scripts and the object acts different .... only because we
want to keep "the current state" while building ...

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

[HowardBaxton]

Sorry about that last post. My smart phone did something not so smart and that post ended up scrambled it seems. It gave me a bit of time to look at the core and reflect on this situation (My head sometimes casts too large of a shadow).

When I look at the state_entry() function to see what happens on reset besides clearing the history of variables associated with a clean script, I see 3 things happening:

1. Create the chat channel based upon the root uuid.
2. Turn on the listener.
3. Find the default pose set and send out a DOPOSE message for this default pose set.

Items 1 and 2 really have no effect on the system or situation.

Item 3 however has a some possibilities to do some things either wanted or unwanted.

1. Where the current pose set is not the default pose set:
   With Reset; The current pose set will be the default pose set after reset no matter what the inventory change was which fired the script reset. Since the slots list is cleared, the core will rebuild the slots list with the default pose set and move all sitters in logical order. (What if the inventory change were to add a prop or simply adding another BTN card or deleting an unwanted plugin.. etc.? There are dozens of reasons this is not a suitable thing to do.)
   Without reset; Nothing is changed as far as the core is concerned even if the current card is changed or deleted. The slots list still retains the current status with all SCHMO(E) and Adjuster movements that have been made.

Global options might be the only good reason to re-read the default card but only if the options exist in that card. We do have the ability to put the global options into any card or even have different options for different situations in other cards. Removing a card which has set some global options is going to require all scripts reset to remove them completely from nPose, re-reading the default card or finding a new default card and running it will not reset the global options other than the ONE global option stored in the core (to get a menu when new sitter sits).

Also, yes the core, the menu, and the slave do reset when there is a change of ownership.

All this and I do not find one good solid valid reason to reset the core when inventory changes.

[LeonaMorro]

After sleeping and reread the whole stuff ... let me try to make a summary:

• a reset does (sometimes / almost every time) more than needed ... and will not be suitable to reach the goal
• not reseting may (sometimes / almost every time) do less than needed ... and will also not be suitable to reach the goal
• we will not be able to make some code that will do everything we want (memory/script limitations)

I guess we exchanged almost all Pros and Cons and I see that not reseting will solve the problem with the HUD without great effort. Nevertheless I'm still a little concerned, but not enough to definitely say that not resetting is a no-go. Additionally my concerns seems to be more like a gut feeling, because I can't add any futher sound arguments. Maybe I should wipe them away.

[LeonaMorro]

Improved in nPose V3.00 and in nPose V3.10