| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This has not been maintained for more than 2 years, is unimplemented for newer features (e.g. built-in groups) and has no core developers using it.
If somebody fixes these issues then it could be reinstated.
|
| |
|
|
| |
console as it is unused/ignored, at least in core.
|
| |
|
|
| |
within themselves and OpenSim.ini.example by changing tabs to spaces, indenting, spacing.
|
| |
|
|
| |
creator data
|
| |
|
|
| |
reflect its location (UMM not Scene) and add the user name and ID.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
thread and run work in the jobengine from Watchdog to a WorkManager class.
This is to achieve a clean separation of concerns - the watchdog is an inappropriate place for work management.
Also adds a WorkManager.RunInThreadPool() class which feeds through to Util.FireAndForget.
Also switches around the name and obj arguments to the new RunInThread() and RunJob() methods so that the callback obj comes after the callback as seen in the SDK and elsewhere
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
on any teleport within a foreign grid after the first.
Bug was introduced in ghosts branch commit 69abade
|
| | |
| |
| |
| | |
loglevel, in common with similar commands.
|
| | |
| |
| |
| | |
when [Startup] section is not present (though this is extremely unlikely).
|
| | |
| |
| |
| | |
disabled for testing purposes if necessary.
|
| | |
| |
| |
| | |
inside Watchdog.RunJob() (renamed from RunWhenPossible) and generalize them.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
avatars collide. This is true by default.
This is implemented with a new collision type (PhantomToOthersAvatar) to potentially allow colliding and non-colliding avatars to be present in the same scene.
So there is no provision yet for giving avatars different collision types.
This commit replaces the temporary change in commit f3eaa6d8 where avatars would never collide when using BulletSim
This is equivalent to the av_av_collisions_off option in ODE.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
valid set pin in a destination prim rather than the unset no pin state
Adds regression test for this case.
|
| | |
| |
| |
| |
| |
| |
| | |
or final asset import takes too long remove remaining requests from same user to prevent hold up of other user's incoming attachments.
This improves upon the earlier naive simply queueing immplementation.
Threshold is 30 seconds. If this happens to a user they can relog and fetch will be reattempted.
|
| | |
| |
| |
| |
| |
| |
| | |
(iteration) can be controlled by the caller.
This is to enable an imminent change where incoming HG scene object fetching can assess the time taken by each request rather than being forced to perform all requests in one call.
Soon, this will replace the existing UuidGatherer since it is both simpler and more flexible.
|
| | |
| |
| |
| |
| |
| |
| | |
requests.
This is to reduce the potential for overload of the threadpool if there are many simultaneous requets in high concurrency situations.
Currently only applied to AvatarProperties and GenericMessage requests.
|
| | | |
|
| | |
| |
| |
| |
| | |
This shows named threadpool calls (excluding timer and network calls) that are currently queued or running.
Also shows total of labelled and any anonymous calls.
|
| | |
| |
| |
| |
| |
| |
| | |
Instead of processing all incoming attachment scene object concurrently, process them consecutively to eliminate potential overload from this source.
This is a naive implementation because it does not currently account for slow foreign asset services.
Although it may take longer, this approach may also improve attachment visibility for HG avatars
since the scene object is now always added to the scene after receiving assets from the foreign service and not before.
|
| | |
| |
| |
| |
| |
| | |
problem diagnosis.
"show threadpool calls" now also returns named (labelled), anonymous (unlabelled) and total call stats.
|
| | |
| |
| |
| | |
smartthreadpool calls
|
| | |
| |
| |
| |
| |
| |
| |
| | |
server-side preferences due to no e-mail address being sent.
This is to avoid user confusion in the oscc rehearsal as they are often not aware that this fails because no e-mail is set.
Also may be failing in the hypergrid case, though this may also be a config issue.
This is meant as a temporary solution.
|
| | |
| |
| |
| |
| |
| | |
This resolves an issue with pCampbot where some bots would occasionally connect with the same UDP source port.
This sometimes led to console messages where bots would report receiving packets multiple times that weren't marked as resends.
DLLs built under windows
|
| | |
| |
| |
| |
| |
| | |
At least on Mono 3.2.8 (but not under Windows), one can bind multiple UDP sockets to the same port by default.
Different simulators cannot demultiplex each other's messages, so a set of confusing non-obvious errors arise if this occurs.
This change prevents such multiple binding.
|
| | |
| |
| |
| |
| |
| | |
bots in motion.
Previously, adding this behaviour after physics (p) would leave the bot to drift off for ever in its last movement direction.
|
| | |
| |
| |
| | |
This checks that all the wearable assets and any assets for a given logged in avatar exist in the asset service
|
| | |
| |
| |
| |
| | |
This shows summary wearables information (shape, hair, etc.) for all avatars in the scene or specific information about a given avatar's wearables.
Similar to the existing "attachments show" command.
|
| | |
| |
| |
| | |
Extends regression tests to test response of adaptive throttles to ack'ed and expired packets.
|
| | |
| |
| |
| |
| |
| |
| | |
client throttles properly.
In "show throttles", also renames 'total' column to 'actual' to reflect that it is not necessarily the throttles requested for/by the client.
Also fills out 'target' in non-adapative mode to the actual throttle requested for/by the client.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
settings.
As part of this also refactors code to put all throttle asserts in a single regression test method
|
| | |
| |
| |
| | |
client has made no AgentUpdate requests (as is the case with agents that have only even been child) rather than throwing an exception
|
| | |
| |
| |
| | |
Scene.cs (almost five years ago!)
|
| | |
| |
| |
| |
| |
| |
| | |
client being added to the manager without IClientAPI.SceneAgent being set.
This is done by adjusting the order of code so that SceneAgent will always be set before adding the client.
Various parts of the code (rightly) assume that a a client registered to the manager will always have a SceneAgent set no matter what.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
LLUDP client stack rather than queueing internally within LLClientView.
When an HG avatar enters a scene, it delays processing of entity updates. Could be crowding out by other updates or something else.
This delay in ones own av mvmt updates results in mvmt lag experienced on the client. Avoiding the internal LLClientView for these packets appears to resolve this issue.
Appears most noticeably for avatars with attachments, though has also been seen on those without sometimes. Hasn't been observed for non-HG avatars in general.
Will be investigating exactly what the problem is, at which point there will be a more permanent solution.
|
| | |
| |
| |
| | |
This allows one to set the requested throttle (which normally comes from the client) as opposed to the max.
|
| | |
| |
| |
| |
| | |
On server, scene-throttle-max becomes max-scene-throttle and likewise max-new-client-throttle
On clients, throttle-max becomes max
|
| | |
| |
| |
| |
| |
| | |
client throttle to be set separately from existing clients.
"debug lludp throttles get/set throttle-max" now only gets and sets current max client throttles
|
| | |
| |
| |
| |
| |
| | |
to mirror "debug lludp set"
Information is also available in "show server throttles" but that's more for non-debug info rather than attempting to get and set parameters on the fly for debug purposes.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
streaming xml basis rather than loading it all into memory via XmlDocument.
This is because objects with lots of parts can have a lot of xml to load into memory, and this has been seen to have a noticeable performance impact.
Whereas streaming has been seen to reduce the impact in normal serialization.
Implmentation is messy but I couldn't see a better way of doing it when you can't assume that you know the exact structure of the input XML.
|
| | |
| |
| |
| | |
HGAssetMapper.Post() object asset rewriting,
|
| | |
| |
| |
| | |
instead of letting it terminate the simulator...
|
| | |
| |
| |
| |
| | |
To do this required GetMesh to be converted to a BaseStreamHandler
Unlike GetTexture connector, no redirect URL functionality yet (this wasn't present in the first place).
|
| | | |
|
