Skip to content
This repository has been archived by the owner on Aug 19, 2018. It is now read-only.

InWorldz Halcyon Server 0.9.24 R5977
Compare
Choose a tag to compare
@appurist appurist released this 17 May 06:07
v0.9.24.5977
39d8878

This update includes the following changes:

Owner-Configurable Region Avatar Limit
There are two limits on avatars in a region. The first is a hard limit set by InWorldz (currently 100 avatars). That limit will deny even the Estate Owner and Estate Managers.

This update adds support for the second, soft limit, which can be set or changed on the Region/Estate form. The InWorldz implementation differs from the implementation on other grids such as SL, in that it will still allow the Estate Owner, Estate Managers, and anyone on the region access whitelist to enter the region. This works for cases where a club or performance group may always want its club staff or performers to get in after a crash, but otherwise apply an agent limit to the region as a whole.

Other Fixes

  • Fixed a problem with bots sometimes not actually deleting attachments when removed (DeleteAttachment not called).
  • Fixed the initial/default appearance to use Current Outfit folder (COF) version of -1 like the viewer expects. The viewer defines the initial/default/unknown appearance serial number (version) as -1 (not zero).
  • Appearance changes to avatar layers was incorrectly resetting the COF version number to 0. (This has been fixed, to leave it alone.)
  • Several references were not being cleared in session Close methods, holding
    references and prolonging object memory usage (leakage).
  • Fixed a case where scene presence (avatar) event handers were added twice.
  • Several existing log messages improved, and others added to help us diagnose appearance Mantis 3162.
  • Implemented iwDeliverInventory and iwDeliverInventoryList, as well as the IW_DELIVER_* series of error return code constants (more info below).

Details on iwDeliverInventory and iwDeliverInventoryList
These two new functions are really small enhancements to iwGiveLinkInventory and iwGiveLinkInventoryList (folder version), which themselves are enhancements over the normal SL llGiveLinkInventory and llGiveLinkInventoryList functions. The two new iwDeliver functions provide deep tracking of the delivery of the items to user, returning an error code to the caller if the delivery is not successful. (Note: It is considered successful when the item(s) are delivered to the recipient user's Inventory, regardless of whether the user later declines the inventory or not, which could happen days, or months later.)

The new functions are:
integer iwDeliverInventory(integer link, key target, string inventory)
and
integer iwDeliverInventoryList(integer link, key target, string folder, list inventory)

The parameters and operational semantics match those of iwGiveLinkInventory and it's multi-item (folder) variant, iwGiveLinkInventoryList.

Several return values are defined:
IW_DELIVER_OK = 0
The inventory was successfully delivered to the user's Inventory.

IW_DELIVER_BADKEY = 1
The 'target' parameter is not a valid key.

IW_DELIVER_MUTED = 2
The recipient user has muted the sending object, or its owner.

IW_DELIVER_ITEM = 3
At least one of the specified item(s) was not found in the Contents.

IW_DELIVER_PRIM = 4
This is mostly an internal error meaning the prim with the script could not be found. This could probably happen if you did a Take or Delete of the sending object just as it called this function.

IW_DELIVER_USER = 5
The specific delivery recipient does not exist.

IW_DELIVER_PERM = 6
The permissions of one or more items does not allow delivery. This can occur if the Contents item is no-trans, or if the item is no-copy and the object itself is no-mod.

IW_DELIVER_NONE = 7
There were no matching items were found in the Contents for delivery.

The R5977 Update
The following R5969 change has been reverted (removed), and the previous behavior restored:

  • Fixed the missing permissions pre-check on Contents item moves. Either the task item must be copyable (for a copy operation), or the enclosing object must be modifiable (for a move operation). If neither of those is true, the operation now fails with "Cannot remove a no-copy item from a no-modify object." Fixes Mantis 3192, which was a problem that allowed users to accidentally damage no-mod objects if there were no-copy objects inside.
Assets 2