| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| | |
textures (which are already stored permanently)
|
| | |
| |
| |
| | |
Needed to hook up the Close() function in the NPCAvatar IClientAPI implementation, which [unfortunately] is still needed
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
can just use the currently set Rotation
looks like I spoke to soon about eliminating jerkiness on "go here"/autopilot. It's still there.
|
| | |
| |
| |
| | |
eliminate the second setting in AddNewMovement()
|
| | |
| |
| |
| |
| |
| | |
after finishing their movement. This also fixes judder after an avatar has finished "go here"/autopilot movement in a viewer.
This meant reseting the SP.AgentControlFlags since the Animator uses these to determine the correct default animation.
|
| | |
| |
| |
| |
| |
| |
| | |
Default for this function is now not to automatically land.
This allows better control by scripts when an avatar is going to be landing on a prim rather than the ground.
Stopping the avatar involves faking a collision, to avoid the pid controller making it overshoot.
A better approach would be to gradually slow the avatar as we near the target
|
| | |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
agent
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
storage.
This works by serializing and deserializing NPC AvatarAppearance to a notecard in the prim inventory and making the required baked textures permanent.
By using notecards, we avoid lots of awkward, technical and user-unfriendly issues concerning retaining asset references and creating a new asset type.
Notecards also allow different appearances to be swapped and manipulated easily.
This also allows stored NPC appearances to work transparently with OARs/IARs since the UUID scan will pick up and store the necessary references from the notecard text.
This works in my basic test but is not at all ready for user use or bug reporting yet.
|
| | |
| |
| |
| | |
This seems to make more sense as we can get SP.ControllingClient
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
when they get there.
This doesn't help where the target is a prim surface. In these situations, it might be better to provide manual overrides so the script can control whethre an avatar flys there/lands, etc.
|
| | |
|
| | |
|
| |
|
|
| |
where needed instead of passing in a flag
|
| |
|
|
| |
classes can use it.
|
| |
|
|
|
|
|
| |
target, move it directly to the target.
This makes the movement exact. Regression test changed to check avatar reaches exact target.
Also has the nice side effect of making NPC animations continue to work after the first movement (which wasn't working). However, avatar still pauses in mid-stride
|
| | |
|
| |
|
|
| |
consistency. Improve method doc.
|
| |
|
|
| |
extends npc move to regression test to check stop after sufficient sim updates
|
| |
|
|
| |
INPCModule
|
| |
|
|
| |
setting a move target
|
| |
|
|
| |
the npc to move.
|
| | |
|
| | |
|
| |
|
|
| |
consistent with terminology used by scene object part and elsewhere
|
| | |
|
| | |
|
| |
|
|
| |
Default is disabled. You will need to explicitly enable to toy with this.
|
| |
|
|
|
|
| |
Avatar moves and stops. However, will stop in mid stride.
And if the move to position is in the air, avatar will continue to make vain and quite hilarious attempts to take off (but never doing so).
Clearly more work is needed.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This is not used for anything - appearances are always properties of objects with ids (ScenePresence, AgentCircuitData) and just has the potential to get out of sync when the appearance is cloned.
|
| |
|
|
|
|
| |
Had to stop using AvatarService for now since it doesn't store baked texture IDs (which is why this was failing).
Also failing because cloning appearance was also cloning the AvatarApperance.Owner field, which we weren't then changing.
Extended TestCreate() to check this.
|
| | |
|
| |
|
|
| |
SychronousRestObjectPoster.BeginPostObject() to the identical SynchronousRestObjectRequester.MakeRequest()
|
| |
|
|
|
|
| |
connected to.
Currently disabled.
|
| |
|
|
| |
(setting SculptData is done through the property)
|
| |
|
|
| |
the scene presence exists
|
| |
|
|
|
|
| |
indirectly via a timer
no obvious reason for doing this asynchonously, especially as the caller was sleeping in order to pick up the response anyway!
|
| |
|
|
|
|
| |
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!
|
| |
|
|
| |
'MessagingModule' in [Groups] section in accordance with OpenSim.ini.example descriptions
|
| |\ |
|
| | |
| |
| |
| | |
Add notification to neighbors when logins are enabled.
|
| |/
|
|
|
|
|
|
|
|
|
| |
rather than just saying "destination not found"
Instead of performing the 4096 check when the region is linked (and subsequently removing the link), leave the link in place and perform the check in the entity transfer module
This allows us to explicitly tell the hypergridder why the teleport failed (region out of range).
It also allows people on regions that are within range (on a large source grid) to teleport.
The Check4096 config parameter in the [GridService] section is replaced by a max_distance paramter in a new [EntityTransfer] section in OpenSimDefaults.ini
Since the parameter is in OpenSimDefaults.ini no action needs to be taken unless you want to increase this limit. It could also be decreased.
The check is being made in the base entity transfer module, since I believe the viewer problem occurs both on extremely large grids and while hypergridding.
|
