===========
RLVa v1.0.1
===========

v1.0.1a (2009-07-28)
--------------------
- internal	: m_fCanCancelTp wasn't initialized (harmless since gRlvHandler is static, but still good form - thankies Zwagoth)
- fixed		: @attach:<folder>=force should perform partial name matching on folders (thankies Shuggi)
				-> ie: @attach:AB=force would only force-attach if there was a folder named "AB" (preferred) or "ABC" (starts-with match)
				-> but @attach:AB=force should also force-attach a folder named "BAB" since it contains "AB"
				-> (extends to every inventory command: @getinv, @getinvworn, etc)

v1.0.1b (2009-07-29)
--------------------
- internal  : nested paranthesis no longer confuse attachment point name extraction (didn't lead to a bug, just for future proofing)
				-> ie: "Some text (pelvis (2))" now properly yields "pelvis (2)" instead of "2)"
- internal	: added RlvHandler::getAttachPointLegacy(const LLInventoryCategory*) to handle (some) legacy naming of folders
				-> see http://rlva.catznip.com/blog/2009/07/attachment-point-naming-convention/
- internal	: moved folded folder detection logic from RlvWearableItemCollector::onCollectFolder() to RlvHandler::isFoldedFolder()
				-> now used by @getinv as well to hide legacy attachment point folders from scripts
				-> ie: #RLV / Something / pelvis -> @getinv:Something=1 returns an empty response (if RLVaEnableLegacyNaming == TRUE)
- changed	: (some) legacy naming of folders is now - optionally - supported (thankies Sei)
				-> RLVaEnableLegacyNaming controls the behaviour (current default is TRUE)

v1.0.1c (2009-07-30)
--------------------
- internal	: commands received by an unrezzed object are no longer held until the object actually rezzes in
				-> @detach=n - by nature - can't take effect until after the attachment rezzes though
- fixed		: @behaviour=n,getstatus=<channel> doesn't always return /behaviour
				-> was by design (@behaviour=n would be delayed until the object rezzed while the @getstatus executed right away)
				-> caused issues with scripts that verify restrictions after setting them

v1.0.1d (2009-08-04)
--------------------
- added		: @detach:<attachpt>=n
				-> part of RLV-1.20.0 (locking an attachment point empty is postponed until undesirable side-effects can be eliminated)
- added		: @notify:<option>=add
				-> part of RLV-1.20.0
- fixed		: unrezzed objects' - or avies' - chat isn't subject to @recvchat, @recvemote or @shownames filtering
				-> part of RLV-1.20.0

v1.0.1e (2009-08-05)
--------------------
- internal	: added rlvSendChatReply() to send chat directly rather than RlvHandler::sendCommandReply() -> ... -> send_chat_from_viewer()
				-> eliminates the need for the ugly looking "zero-length chat message hack" in Emerald
- internal	: commands are once again retained up until STATE_STARTED (was changed to STATE_MISC in one of the 0.2.x)
				-> the extra few seconds should help make most reply and force commands that rely on world state more reliable at log-on
				
v1.0.1f (2008-08-07)
--------------------
- fixed		: the #RLV/~ prefix isn't stripped from script offered inventory if the offer spans multiple BulkUpdateInventory messages
				-> thankies Eglan for first reporting this and thankies Tammy for providing a solid repro case to track down the cause
				=> the folder actually did end up renamed, but the second BulkUpdateInventory created a client-side cache discrepancy

v1.0.1g (2008-08-09)
--------------------
- internal	: worn inventory items are now fetched at log-on
- fixed		: items marked as "nostrip" can still be stripped or detached if the item can't be found in inventory
- fixed		: reattach-on-detach fails if the item can't be found in inventory 

v1.0.1h (2009-08-11)
--------------------
- changed	: showing the filtered name tag above an avie's head under @shownames=n is now optional (thankies Tammy)
				-> some people prefer not to have an "in your face" way to tell which anonym belongs to which nearby avie
				-> other people prefer not to have to hover their mouse over every nearby avie to know which anonym belongs to which avie
				=> controlled by RLVaShowNameTags (default is FALSE)
- changed	: @detach:<attachpt>=n should lock an attachment point empty without undesirable side-effects
				-> see Test case 1 through 3 below
- changed	: @detach:<attachpt>=n should not detach an attachment at log-on
				-> see Test case 4 - not presently fixable but hopefully the current solutions only inconveniences a few people





*******************************
@detach:<attachpt>=n test cases
*******************************
These aren't all the test cases I made for this command, but rather a highlight of the four most problematic ones.

Repro       : simple uncomplicated sketch of the situation
Expected    : the desired result
Caveats     : highlights what can happen if there's no code in place to properly handle "out-of-sequence" events
Caveat-repro: steps that can be used to recreate the sequence of events described in the caveat


Test case 1 – reattach-on-detach (attachment point locked non-empty by another object)
Repro:
	• Attach something on attachment point A
	• Attach something on attachment point B that issues @detach:A=n
	• Detach and/or replace the attachment on attachment point A (llDetachFromAvatar() or llAttachToAvatar() respectively)
Expected result:
	• Reattach-on-detach should reattach the detached object
Caveats:
	• Even though attachment point A is empty when the object becomes detached, @detach:A=n should not block (=force-detach) 
	  the reattach-on-detach


Test case 2 – @detach=n vs @detach:A=n
Repro:
	• Attach something on attachment point A that issues @detach:A=n 
Expected result:
	• The object should behave as if it had just issued @detach=n
Caveats:
	• If @detach:A=n is received *before* the object’s initial ObjectUpdate message then the object will inadvertently lock 
	  its own attachment point empty and when the object finally rezzes its own locking command will cause it to be force-detached 
	  rather than become undetachable
Caveat-repro:
	• Edit / Preferences – Network tab – Clear Cache and relog on a healthy sim (this is crucial)
	• After the relog, open the inventory window and type something random in the search box to fire off a full inventory fetch 
	  (which should cause enough delay for our purpose)
	• Now attach the object to a currently *empty* attachment point while the inventory is fetching 
		-> to help let you know that you did indeed hit the caveat the script should do the following:
			- in its attach() event it should issue @detach:<attachpt>=n,getattach:<attachpt>=<channel>
			- if you hit the correct sequence the viewer will respond with "0" since as far as it knows the attachment doesn't exist yet
	=> You can use llAttachToAvatar() to trigger this as well - see case 3 below


Test case 3 – conflicting @detach:A=n and @detach=n
Repro:
	• Attach something on attachment point B that issues @detach:A=n
	• Attach something on attachment point A that issues @detach=n
Expected result:
	• @detach:A=n came first and locked the attachment point empty so the new attach should fail (get force-detached)
Caveats:
	• If the new @detach=n is received *before* the object’s initial ObjectUpdate message then we end up with 2 conflicting 
	  commands that will cause a potentially endless reattach-detach loop (@detach:A=n locked the attachment point empty so it 
	  will detach anything new while @detach=n on the new attachment will cause it to get reattached on detach)
Caveat-repro:
	• Write a script that uses llAttachToAvatar() to attach to the avie on a currently *empty* attachment point
		-> the script's attach() event is almost guaranteed to fire "long" before the viewer knows the object is attaching itself
	• In its attach() event it should issue @detach=n,getattach:<attachpt>=<channel>
		-> if you hit the caveat the viewer will respond with "0" since it hasn't received the ObjectUpdate message for the attach yet


Test case 4 – log on
Repro:
	• Attach something on attachment point A
	• Attach something on attachment point B that issues @detach:A=n
	• Relog
Expected result:
	• The same situation that existed at log-off: A and B should have their respective attachments with A undetachable
Caveats:
	• If @detach:A=n is received and processed *before* the object’s initial ObjectUpdate message then the attachment point 
	  would be considered empty and the attachment on attachment point will end up being force detached
	• Note that test case 2 and 3 can occur at log-on as well but since there’s a more reliable repro we won’t specifically 
	  look at those here
Caveat-repro:
	• Edit / Preferences – Network tab – Clear Cache
	• Edit / Preferences – Network tab – Set bandwidth rather low (or to 50 as an extreme)
	• Attach (preferably prim-heavy) attachments on numerous attachment points
	• Relog to a sim you haven't logged on to (or tp'ed to) in the past 12-24 hours
		-> simulates being logged off long enough for the sim to refetch your attachment asses (cause additional rezzing delay)
	• (Starting a full inventory fetch will introduce additional delay as well)