| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This is in order to reduce the likelihood of naming clashes, make it easier to filter in/out attributes, ensure uniformity, etc.
All dynattrs in the opensim distro itself or likely future ones should be in the "OpenSim" namespace.
This does alter the underlying dynattrs data structure. All data in previous structures may not be available, though old structures should not cause errors.
This is done without notice since this feature has been explicitly labelled as experimental, subject to change and has not been in a release.
However, existing materials data is being preserved by moving it to the "Materials" store in the "OpenSim" namespace.
|
| |
|
|
| |
by DAExampleModule when instantiating a dynamc object.
|
| |
|
|
| |
necessary to get attributes to save (though this probably happens anyway due to the prim move)
|
| |
|
|
| |
conditions with a serialization thread.
|
| |
|
|
|
|
|
|
|
| |
This allows region modules to add dynamic objects to SOPs rather than having to continually push and pull OSD dynamic attributes.
This is to explore the original MOAP use case for dynamic attributes where it could be very awkward and possibly time-consuming to keep reconstructing MediaEntrys from stored DynamicAttributes.
This commit adds a DOExampleModule to demonstrate/evolve this code.
Dynamic objects involve no storage or persistence changes - the 'backing store' for any data that does need to be saved will remain the DAMap.
DOExampleModule in this commit only attaches a fresh dynamic object. Actually constructing this from stored dynamic attributes and handling persistence is left for later.
These changes should affect no existing functionality, though it may or may not reveal necessary changes in DAMap down the road.
|
| | |
|
| | |
|
| |
|
|
| |
names must have at least 4 characters.
|
| |
|
|
|
|
| |
from it
This is the easier way to give us control over locking, rather than asking that OSDMap IDictionary methods be virtual
|
|
|
This module demonstrates that we can add an arbitrary persisted value to SOP without any changes to core code.
Every time the object is moved, the move record is updated and the users in the scene alerted
The number of moves is persisted over server restarts in sqlite
|
