Update() now accepts a frames parameter which can control the number of frames updated.
-1 will update until shutdown.
The watchdog updating moves above the maintc recalculation for any required sleep since it should be accounted for within the frame.
This flavour is for changes in addition to the 0.7.3-post-fixes branch that are too large to be considered fixes but should be reasonably stable.
This flavour will almost certainly never see a formal release.
Viewer 2/3 contains a bug where the viewer will constantly retry ParcelVoiceInfoRequest requests on voice-disabled parcels where voice is otherwise available.
Attempts to fix this server-side have not been successful - sending a non-OK http code (e.g. a 404) just makes the viewer request again immediately.
Dropping the request entirely is a bit better but the viewer still retries after a minute.
Estate settings already enabled voice by default so doing the same for parcels. This only has an effect if you have any voice system active at all.
Ultimately, the re-request bug needs to be fixed viewer-side (LL suffers from the same issue!) but it might be worth implementing the drop request hack.
Unfortunately, the OnLoginsEnabled event is currently only guaranteed to fire if the RegionReady module is active.
However, we can instantiate the AuthorizationService in the module RegionLoaded method since by this time all other modules will have been loaded
The previous lines-per-second measurement used for top scripts report was inaccurate, since lines executed does not reflect time taken to execute.
Also, every fetch of the report would reset all the numbers limiting its usefulness and we weren't even guaranteed to see the top 100.
The actual measurement value should be script execution time per frame but XEngine does not work this way.
Therefore, we use actual script execution time scaled by the measurement period and an idealised frame time.
This is still not ideal but gives reasonable results and allows scripts to be compared.
This commit moves script execution time calculations from SceneGraph into IScriptModule implementations.
The first llDie() could lock Scene.m_deleting_scene_object.
The second llDie() would then wait at this lock.
The first llDie() would go on to remove the second script but always abort it since the second script's WorkItem would not go away.
Easiest solution here is to remove the m_deleting_scene_object since it's no longer justified - we no longer lock m_parts but take a copy instead.
This also requires an adjustment in XEngine.OnRemoveScript not to use instance.ObjectID instead when firing the OnObjectRemoved event.
This seems to be a particular problem with ReaderWriterLockSlim, though other locks can be affected as well.
It has been seen to happen when llDie() is called in a linkset running more than one script.
Alleviation here means supplying a ScriptInstance.Stop() timeout of 1000ms rather than 0ms, to give events a chance to complete.
Also, we check the IsRunning status at the top of the ScriptInstance.EventProcessor() so that another event doesn't start in the mean time.
Ultimately, a better solution may have to be found since a long-running event would still exceed the timeout and be aborted.