It's never possible for SOG to have no RootPart, except in the first few picosends of the big bang when it's pulled from region persistence or deserialized
The only times when ParentGroup might be null is during regression tests (which might not be a valid thing) and when scene objects are being constructed from the database.
At all other times it's not possible for a SOP not to have a SOG parent.
The root part state is the canonical value, so always send that instead.
Sending conflicting attachments states for non-root parts of a rezzed object is enough to crash the client.
Fixes http://opensimulator.org/mantis/view.php?id=5664.
Many thanks to mewtwo0641 for some fantastic qa work on this one.
This is done by introducing a PresenceType enum into ScenePresence which currently has two values, User and Npc.
This seems better than a SaveAttachments flag in terms of code comprehension, though I'm still slightly uneasy about introducing these semantics to core objects
this is to allow walking on prims. it will be up to the script writer to be sure that there is a continuous path.
currently implemented in osNpcMoveToTarget(), but none of this is final.
This now works again except that it requires a click or avatar mvmt to get going
This is because the ScenePresence.HandleAgentUpdate() method doesn't trigger until the client does something significant, at which point autopilot takes over.
Even clicking is enough to trigger.
This will be improved presently.
However, what happens now is that undo just doesn't do anything when the root prim is selected on its own. This requires more code than just fiddling with undo states.
This involves implementing a boolean in UndoState to signal whether the undo needs to be done for an entire group/linkset or just a single prim
Resizing individual components of linksets is still dodgy.
Resizing still has to be down twice, since for some reason the client is sending two multiobjectupdate packets on every resize except the very first. This applies to single prims and linksets. Need to look into this.
Undo rotation and position appear to be working.
Resizing a single prim appears to be working, though the undo has to be done twice.
Resizing a group of prims still does not work properly - possibly because in the UndoState we don't store a knowledge of when we're resizing a whole group rather than individual prims.
This needs to be addressed.
Unable to get to the bottom of why resizing a mesh fails to properly reset the physics proxy, when toggling phantom does
After a mesh is generated, the existing sculptdata is set to zero in PrimitiveBaseShape to save memory
When phantom is toggled, the sculptdata is regenerated before remeshing.
But on resize, the sculptdata is not regenerated.
So clearly, resetting sculptdata is possible, but haven't quite been able to pin down how this is being done when phantom is toggled.
Many thanks to the aurora project for pioneering this.
This code is almost certainly not bug free, but it does at least appear to handle simple meshes (except when the viewer crashes - but it is beta!).
Changed the experimental capability introduced a couple of commits ago: now sending that extra information as part of the response in the SimulatorFeatures cap.
It appears that if the viewer requests a folder containing links, we must also send the folders that contain the link targets first.
This was tested with Kokua 0.1.0 WIP though I predict it will also work with other viewer 2s
limits because the only ones used now are the defaults (which are overwritten
by the client throttles anyway). Updated the default rates to correspond to
about 350kbps.
Also added a configuration to disable adaptive throttle. The default
is the previous behavior (no adaptation).
command to look at the entity update priority queue. Added a "name" parameter
to show queues, show pqueues and show throttles to look at data for a specific
user.
per Melanie's very good suggestion. The immediate queue is
serviced completely before all others, making it a very good
place to put avatar updates & attachments.
Moved the priority queue out of the LLUDP directory and
into the framework. It is now a fairly general utility.
clients. If the sent packets are ack'ed successfully the throttle
will open quickly up to the maximum specified by the client and/or
the sims client throttle.
This still needs a lot of adjustment to get the rates correct.
Often, by the time the UDPServer realizes that an entity update packet
has not been acknowledged, there is a newer update for the same entity
already queued up or there is a higher priority update that should be
sent first. This patch eliminates 1:1 packet resends for unacked entity
update packets. Insteawd, unacked update packets are decomposed into the
original entity updates and those updates are placed back into the
priority queues based on their new priority but the original update
timestamp. This will generally place them at the head of the line to be
put back on the wire as a new outgoing packet but prevents the resend
queue from filling up with multiple stale updates for the same entity.
This new approach takes advantage of the UDP nature of the Linden protocol
in that the intent of a reliable update packet is that if it goes
unacknowledge, SOMETHING has to happen to get the update to the client.
We are simply making sure that we are resending current object state
rather than stale object state.
Additionally, this patch includes a generalized callback mechanism so
that any caller can specify their own method to call when a packet
expires without being acknowledged. We use this mechanism to requeue
update packets and otherwise use the UDPServer default method of just
putting expired packets in the resend queue.
this appears to cause problems with the system timer resolution.
This caused a problem with tokens going into the root throttle as
bursts leading to some starvation.
Also changed EnqueueOutgoing to always queue a packet if there
are already packets in the queue. Ensures consistent ordering
of packet sends.
types of property updates to be specified. Not sure if one form
of property update should supercede another. But for now the old
OpenSim behavior is preserved by sending both.
to the entity update queue. The number of property packets can
become significant when selecting/deselecting large numbers of
objects.
This is experimental code.
when client and simulator throttles are set. This algorithm also uses
pre-defined burst rate of 150% of the sustained rate for each of the
throttles.
Removed the "state" queue. The state queue is not a Linden queue and
appeared to be used just to get kill packets sent.
types of property updates to be specified. Not sure if one form
of property update should supercede another. But for now the old
OpenSim behavior is preserved by sending both.
to the entity update queue. The number of property packets can
become significant when selecting/deselecting large numbers of
objects.
This is experimental code.
when client and simulator throttles are set. This algorithm also uses
pre-defined burst rate of 150% of the sustained rate for each of the
throttles.
Removed the "state" queue. The state queue is not a Linden queue and
appeared to be used just to get kill packets sent.
time to wait to retransmit packets) always maxed out (no retransmissions
for 24 or 48 seconds.
Note that this is going to cause faster (and more) retransmissions. Fix
for dynamic throttling needs to go with this.
Handling these synchronously kills the inbound packet loop if many requests are made for remote land and those requests are handled slowly or timeout (timeout is 10s)
This can happen if a user searches for "land for sale" and then clicks many of the parcels in the list (or just presses down arrow to move through every entry).
This applies to adding/removing estate users, groups, managers and bans.
This is the application of the AllEstates_0.5.patch from http://opensimulator.org/mantis/view.php?id=5420
Thanks very much, Snoopy!
time to wait to retransmit packets) always maxed out (no retransmissions
for 24 or 48 seconds.
Note that this is going to cause faster (and more) retransmissions. Fix
for dynamic throttling needs to go with this.
In order to pass ILandObject into IClientAPI.SendLandProperties(), had to push ILandObject and IPrimCounts into OpenSim.Framework from OpenSim.Region.Framework.Interfaces, in order to avoid ci
Counts are showing odd behaviour at the moment, this will be addressed shortly.
This is in a very crude state, currently.
The LindenUDPModule was renamed LindenUDPInfoModule and moved to OptionalModules
OptionalModules was given a direct reference to OpenSim.Region.ClientStack.LindenUDP so that it can inspect specific LindenUDP settings without having to generalize those to all client views (some of which may have no concept of the settings involved).
This might be ess messy if OpenSim.Region.ClientStack.LindenUDP were a region module instead, like MXP, IRC and NPC
* Added Calculating Time Dilation in the OdePlubin
* When multiple object updates are stuffed into one packet, average the time dilation between them as a compromise.
* Time Dilation on the update is calculated when the EntityUpdate object is created. The pre-calc-ed TD is stored in the Entity update and used when it goes out on the wire. Previously, it was 1.0 all the time. The time dilation is tied to when the update is created, not when the update is sent.
* Adds an item that checks to see if the top request has been there for longer then 30 seconds without an update and sends an AbortXfer if it encounters one. This allows the client to cancel the Xfer on it's side so you can re-select the prim and get the inventory when it fails the first time.
* Some interesting locking... Using NewFiles to lock the rest of them. We'll see how that goes.
* The goal of this is to ensure that Xfers are restartable when they fail. The client will not do that on it's own.
These locks are necessary to avoid a delete/update race condition for scene objects.
However, since we're now locking on m_killRecord this shouldn't cause delays to m_entityUpdates reprioritization
Remove the too coarse CanEditParcel method in favor of a CanEditParcelProperties
method that takes a GroupPowers argument to specify what action is to be
taken. Also, make the method to set parcel data much more granular. Permissions
in a deeded setting should now work.
Revert "This may have been the biggest, baddest bug in OpenSim ever... confusion between bytes per second and bytes per millisecond."
This reverts commit 870bbcfc6c.
If an LL 1.23.5 client (and possibly earlier and later) receives an object update after a kill object packet, it leaves the deleted prim in the scene until client relog
This is possible in LLUDPServer if an object update packet is queued but a kill packet sent immediately.
Beyond invasive tracking of kill sending, most expedient solution is to always queue kills, so that they always arrive after updates.
In tests, this doesn't appear to affect performance.
There is probably still an issue present where an update packet might not be acked and then resent after the kill packet.
For each agent, this command shows how many packets have been sent/received and how many bytes remain in each of the send queues (resend, land, texture, etc.)
Sometimes useful for diagnostics
This will cause visual params to be persisted along with worn items. With
this, alpha and tattoo laters will be saved. Multiple layers MAY work, but
not tested because I don't use Viewer 2.
Setting this to true avoids a 500ms or so client freeze when the LLUDP server thread is taken up with processing a UseCircuitCode packet synchronously.
Extensive testing on Wright Plaza appeared to show no bad effects and this seems to reduce login lag considerably.
Of course, a lot of login lag is still coming from other sources.
It contains a major interface version bump and will NOT work with earlier grid
services. This is preliminary work that will lead to layers support.
Rest appearance services are commented out completely, they will have to be
adapted by someone who actually uses them. Remote admin is working, but has
no layers support. There is no layers support in the database. Login likely
won't work. You have been warned.
AvatarService -- add two new methods, GetAppearance and SetAppearance
to get around the lossy encoding in AvatarData. Preseve the old
functions to avoid changing the behavior for ROBUST services.
AvatarAppearance -- major refactor, moved the various encoding
methods used by AgentCircuitData, ClientAgentUpdate and
ScenePresence into one location. Changed initialization.
AvatarAttachments -- added a class specifically to handle
attachments in preparation for additional functionality
that will be needed for viewer 2.
AvatarFactory -- removed a number of unused or methods duplicated
in other locations. Moved in all appearance event handling from
ScenePresence. Required a change to IClientAPI that propogated
throughout all the IClientAPI implementations.
Object updates are sent on the task queue. It's possible for an object update to be placed on the client queue before a kill packet comes along.
The kill packet would then be placed on the state queue and possibly get sent before the update
If the update gets sent afterwards then client get undeletable no owner objects until relog
Placing the kills in the task queue should mean that they are received after updates. The kill record prevents subsequent updates getting on the queue
Comments state that updates are sent via the state queue but this isn't true. If this was the case this problem might not exist.
This is necessary because it was still possible for an entity update packet to be constructed, the thread to pause, a kill to be sent on another thread, and then the original thread to resume and send the update
This would result in an update being received after a kill, which results in undeletable ghost objects until the viewer is relogged
Extending the lock looks okay since its only taken by kill, update and reprioritize, and both kill and update do not take further locks
However, evidence suggests that there is still a kill/update race somewhere
* Removed StorageManager
* CONFIG CHANGE: There are no more database settings in OpenSim.ini. Check the config-include configuration files for region store and estate store database settings