| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
This better reflects the long-term purpose of that project and matches Monitoring modules.
|
| |
|
|
|
|
|
|
|
|
|
| |
<category/module>" to display commands in a category.
This is to deal with the hundred lines of command splurge when one previously typed "help"
Modelled somewhat on the mysql console
One can still type help <command> to get per command help at any point.
Categories capitalized to avoid conflict with the all-lowercase commands (except for commander system, as of yet).
Does not affect command parsing or any other aspects of the console apart from the help system.
Backwards compatible with existing modules.
|
| |
|
|
|
|
| |
a particular baked texture, if any.
This is for debugging to relate texture console entries back to particular users on the simulator end.
|
| |
|
|
| |
texture ids were available for the rebake request
|
| |
|
|
|
|
|
|
| |
from the server end.
This is not as useful as it sounds, since you can only request rebakes for texture IDs already received.
In other words, if the viewer has never sent the server this information (which happens quite often) then it will have no effect.
Nonetheless, this is useful for diagnostic/debugging purposes.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
UUID for each bake type and whether the simulator can find it.
|
| |
|
|
| |
than accidentally doing nothing
|
| | |
|
| |
|
|
| |
send" command for a chosen avatar as well as all
|
| |
|
|
| |
"appearance send" console command
|
| |
|
|
|
|
| |
from previous commit which sort out which iterator is used are left
intact. A discussion is needed as to what constitutes an avatar vs a
ScenePresence.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the 3 iteration functions so more of them are using the correct
iteration for the action they are performing. The 3 iterators that seem
to fit all actions within OpenSim at this time are:
ForEachAvatar: Perform an action on all avatars (root presences)
ForEachClient: Perform an action on all clients (root or child clients)
ForEachRootClient: Perform an action on all clients that have an avatar
There are still a dozen places or so calling the old
ForEachScenePresence that will take a little more refactoring to
eliminate.
|
| | |
|
| |
|
|
| |
scene presence by client ID.
|
| |
|
|
|
|
| |
This now creates an avatar but appearance is always cloudy.
Move doesn't work.
Really, creating an NPC should only involve a ScenePresence rather than doing anything with IClientAPI, since an NPC has no viewer to communicate with!
|
| |
|
|
| |
at the moment, this just performs a baked avatar check for everybody in the region. If the check returns 'corrupt' then a baked texture is missing and other avatars will continue to see the gas ball.
|
|
|
At the moment, this command just asks the AvatarFactory to perform the existing baked texture check for each avatar in the simulator and returns "OK" or "corrupt".
This is for debugging purposes
|
