| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
| | | |
| | | |
| | | | |
understood by AVN v0.3
|
|/ / /
| | |
| | |
| | | |
on get_agent_home in UAS.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
<Files>
<Match pattern="*.cs" recurse="true"/>
<Match pattern="../bin/MyConfig.xml" buildAction="Copy" recurse="false" destination="$(OutputPath)" />
</Files>
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
into a region that does not exist. This is particularly problematic for
physical objects where the velocity continues to move them out of the
region causing an infinite number of failed region crossings. The patch
forces an object that fails a crossing to be non-physical and moves it
back into the starting region.
|
| | | |
| | | |
| | | |
| | | | |
temponrez flag
|
| | | |
| | | |
| | | |
| | | | |
otakup0pe
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
external as a property
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
boolean setting in the OpenSim.ini config [Startup] section.
Naturally, default is true.
When set to false, "phantom" flags on prims can be set as usual but all prims remain phantom.
This setting is for test purposes.
This switch does not affect the collision of avatars with the terrain.
|
|/ / / |
|
| | |
| | |
| | |
| | | |
passing the entire agent with attachs in one big message we don't necessarily need to wait for confirmation. The callback sometimes is problematic and it adds delay to the process. (2) Z velocity sent to the viewer = 0. This is an heuristic; the Z velocity usually is negative, and it makes the viewer move the avie down. This only matters while the agent is in transit and therefore not being physically simulated by neither region. As soon as the receiving region receives CompleteMovement from the viewer, the position and velocity get corrected.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
CheckForBorderCrossing the right way.
|
|\ \ \
| | |/
| |/| |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
baked texture caching when crossing region boundaries.
Needs further investigation.
Revert "Stop sending the viewer its own AvatarAppearance packet."
This reverts commit 92039f295d7fe66bf1a09b29483f9057e395839e.
|
| | | |
|
|/ / |
|
|\ \ |
|
| | |
| | |
| | |
| | | |
as this is updating SOG/SOP.GroupID, which is arguably generic.
|
| | |
| | |
| | |
| | |
| | | |
The viewer warns in the log if it receives this.
Stopping this doesn't appear to have adverse effects on viewer 1 or viewer 3 - the viewer gets its own appearance from body parts/clothes and self-baked textures.
|
| | |
| | |
| | |
| | |
| | |
| | | |
As far as I know, viewers don't use this mechanism to recieve new TextureEntry data for avatars. This is done via the AvatarAppearance packet instead.
Tested this back to viewer 1.23.
Replacing with Utils.EmptyBytes since converting the texture entry to bytes on each AvatarUpdate (or which there are many) is not cost-free.
|
| | |
| | |
| | |
| | |
| | |
| | | |
after another thread had started it on QueueAppearanceSave() or *Send()
However, the window for this race is very small, and the next queued appearance save or send would restart the timer anyway.
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
RAdmin - admin_save_oar fails if noassets parameter missing
thanks Michelle Argus
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
AvatarFactoryModule from AppearanceInfoModule so that it can be used in debug (inactive).
Further filters "debug packet <level>" to exclused [Request]ObjectPropertiesFamily if level is below 25.
Adjust some method doc
Minor changes to some logging messages.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is handled by treating UUID.Zero as a special case.
Currently, asking for the "none" group returns nothing because XMLRPC groups, at least, is not properly handling this case.
It may be better in the future to have GroupsModule return an appropriate GroupsData structure instead or require the underlying services to behave appropriately.
This is a further component of http://opensimulator.org/mantis/view.php?id=5588
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
created in that client session, or if no other action has been performed on the object.
There were two problems here:
1) On object group update, we looked for the group is the IClientAPI group cache rather than in the groups service. This fails to groups created newly in that session
2) On object group update, we weren't setting the HasGroupChanged flag. This meant that the change was not persisted unless some other action set this flag.
This commit fixes these issues and hopefully addresses http://opensimulator.org/mantis/view.php?id=5588
This commit also moves HandleObjectGroupUpdate() to the GroupsModule from the Scene.PacketHandlers.cs file
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
selection code rather than before.
This allows the script to change the selected region without having it immediately undone.
Thanks to Garmin Kawaguichi for this patch.
|
| | | |
|
| | |
| | |
| | |
| | | |
GetGroupByPrim() rather than retrieving GetEntities() and inspecting the entire list
|
| | |
| | |
| | |
| | | |
These were entirely unused.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
is less than 0
This is to stop bad values and subsequent viewer crashes.
Thanks to Michelle Argus for this patch.
|
| | | |
|
| | |
| | |
| | |
| | | |
XmlRpcGroupsServicesConnectorModule so that we can record cache misses
|
| | |
| | |
| | |
| | | |
directions. This was a 1-off bug: the terrain was being placed in 127, 127 resulting in a bounding box if -2, 256. I placed it in 128, 128 resulting in a bounding box of -1, 257.
|
| | |
| | |
| | |
| | | |
a little bit.
|
|/ / |
|
| |
| |
| |
| | |
in other regions, as opposed to <128, 128, 70>
|
| |
| |
| |
| |
| |
| | |
BEGIN] to [SCENE] because that's where the message happens.
Also changed the instantiation of a vector object to be done only once instead of every time we receive a position update.
|
| | |
|