| Commit message (Collapse) | Author | Files | Lines |
|---|
|
specific additions that should not have been there in the first place.
Sleeping and time measurement are now completely internal to XEngine
|
|
The approach is good but the way it is written breaks the architecture.
Rewrite follows.
This reverts commit a568f06b7faea807149205d0e47454e4883e4836.
|
|
Console command debug xengine now turns that on.
Also, per orenh, remove the triggers at 1000 and 10000 as they are not
useful now that top scripts works.
|
|
|
|
Signed-off-by: Diva Canto <diva@metaverseink.com>
|
|
loading and not using it
|
|
|
|
we don't want to ignore case. And this seems to be causing problems in mono 4.3.
|
|
one of the existing module interfaces to denote a module that holds
agent specific state that should be transferred to other regions
|
|
RequestObjectPropertiesFamily reply and not the actual ObjectProperties packet
Signed-off-by: Diva Canto <diva@metaverseink.com>
|
|
RequestObjectPropertiesFamily reply and not the actual ObjectProperties packet
Signed-off-by: Melanie Thielker <melanie@t-data.com>
|
|
Signed-off-by: Melanie Thielker <melanie@t-data.com>
|
|
|
|
|
|
Signed-off-by: Diva Canto <diva@metaverseink.com>
|
|
Previously the script state was never saved for a !Running script, so upon region restart the script would be Running again.
The use of the 'StayStopped' flag is needed because all scripts are automatically stopped when the region shuts down, but in that case we shouldn't save in their state that they're !Running.
|
|
Sleeping doesn't use the CPU.
|
|
The value shown is the number of milliseconds per frame that were spent executing scripts in this region.
|
|
handling it in XEngine
Previously the "Net Time" was reported: only the time actually spent in the script's code. This is not a correct indication of how much load the script places on the simulator, because scripts that change state often or have many events use up a lot of time just in the event handlers, and previously this time wasn't counted.
|
|
last 30 seconds. Use a sliding window to calculate this.
Notes:
- This metric provides a better indication of which scripts are taking up a lot of CPU (and therefore should be optimized).
- Previously the execution time was reset to 0 in every new measurement period, causing the reported time to fluctuate for no reason. This has been fixed by using a sliding window.
|
|
1. Use a Stopwatch (a high-resolution timer)
2. Whenever we start a new measurement period, zero out the total execution time (previously it just kept accumulating)
3. Changed the measurement period from 30 minutes to 30 seconds. This is much more useful in the "Top Scripts" dialog, as it shows currently active scripts
|
|
(milliseconds) and TimeSpan.TicksPerXXX (10000 x milliseconds)
|
|
of a problem
|
|
|
|
show the current log level; not crash
|
|
|
|
logging
If the XML was truncated for some reason then ExecuteReadProcessors() would get into an infinite loop, using high CPU. Now it detects EOF (and several other error cases) and aborts.
The rest of the changes just improve logging of XML in case of errors, so that we can see what the bad XML is.
|
|
|
|
of race conditions and, especially, race conditions when an object is
removed and quickly re-added to a scene.
This hopefully reduces the occurance of problems when avatars TP within
a region -- the main problem being the loss of collisions.
|
|
when Dispose() is called. This reduces chance of object leakage when
destroying objects.
Rearrange initialization and shut down of BSActorLockAxis so it is
consistant with other actors.
|
|
|
|
|
|
|
|
inventory folders. The newest version of libomv itself is committed here. Basically, everything that was using the AssetType enum has been combed through; many of those uses were changed to the new FolderType enum.
This means that from now on, [new] root folders have code 8 (FolderType.Root), as the viewers expect, as opposed to 9, which was what we had been doing. Normal folders are as they were, -1. Also now sending folder code 100 for Suitcase folders to viewers, with no filter.
All tests pass, but fingers crossed!
|
|
Another change: removed the second call to userManager.AddUser(). UserManagementModule won't modify an existing record.
|
|
Robust now tells viewers what the maximum number of groups is. Viewers show this limit to the users, and enforce it.
The default is 42, which is what viewers had assumed was the maximum number before this update.
Signed-off-by: Oren Hurvitz <orenh@kitely.com>
|
|
|
|
initialization race conditions reported in Mantis 6792.
When a region is initializing it seems that the prim initialization code
can be interrupted part way through then taints are processed for
prims that are not completely there.
|
|
Signed-off-by: Melanie Thielker <melanie@t-data.com>
|
|
Signed-off-by: Melanie Thielker <melanie@t-data.com>
|
|
E.g., instead of "first.last @grid.example.com", the name is now "first.last @grid.example.com:8002"
|
|
|
|
The migration file had a version 2 migration defined twice and
therefore the LastSeen field most likely never was defined in the
presence file. This migration adds the field and migrates the table to
version 4.
Signed-off-by: Oren Hurvitz <orenh@kitely.com>
|
|
|
|
Off by default but set with [Startup]ShouldUseFireAndForgetForCollsions=true
There is a problem with physics colliions sometimes stopping. One suspicion
is that the long callback path from the physics engine into the script engine
is causing problems. Enabling this feature passes the collision into the
script engine on a separate thread and not the main simulation thread.
Tester can enable this and see if the collsions stay around. If they still
fail, this commit should be reverted and another solution looked for.
|
|
|
|
Signed-off-by: Oren Hurvitz <orenh@kitely.com>
|
|
|
|
assets being passed around via HG and archives. No guarantees that all the leaks have been found, but at least it detects and fixes these bad assets upon:
(1) storing and getting assets over HG -- assuming the core HG asset service is being used (not the case with OSGrid!)
(2) importing assets via OAR and IAR
Instantiation of bad assets now should also work, instead of producing an exception, but the bad assets themselves aren't being fixed in the DB. That should be done with a cleaning tool -- see Perl script in Mantis #7657.
Virus!
|
|
what implementers need to provide publicly. This is used by 3rd-party addons such as Wifi.
|
