Internal communication inefficiencies

[DoomRater]

Currently Menu hears its own sendSettings values which means it also processes them after it has sent them. While this issue doesn't necessarily affect script functionality it does produce a lot of redundant work inside the menu script. It also points to another internal functionality issue: Preferences sends a lot of information back to Menu via strings but this information is already being communicated around through sendSettings. A chain of events occurs every time Preferences changes something:

1. Preferences updates its own internal variables and sends a linked message to Menu indicating what was changed. It needs to update its internal variables because it immediately displays the menu it was on, which occurs before saved changes reach back to Preferences.
2. Menu processes this change and saves settings.
3. Menu, Preferences, AND the memory core all hear this message and process it separately.

The initial proposed change is to have Preferences simply sendSettings like Menu already does, which removes Menu's need to separately process a second linkmessage and resend settings. The proposed change would look something like this:

1. Preferences updates its own internal variables and calls sendSettings.
2. Menu, Preferences, and the memory core all hear the message and process it separately.

Dealing with the scripts hearing themselves when they send a message is a bit trickier, but again it does not produce any internal issues since it does not recursively send messages when any of them receive an update message. It can be dealt with afterwards.

[DoomRater]

Now when Menu updates a saved variable it sends all the settings to Preferences with a number of -6, and Preferences sends its settings to Menu with a value of -3 to avoid cross communication. Both send to all other prims with a value of 6 to reach the memory core, but not trigger parsing the settings they just sent.