Server Deployments – Week 26
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (Main) Channel
On Tuesday 25th June, the SLS Main channel received the server maintenance package deployed to the three RC channel in week 25. This fixes a number of crash modes, addresses an issue with neighbouring region visibility, and adds the new pathfinding property CHARACTER_STAY_WITHIN_PARCEL to llCreateCharacter() and llUpdateCharacter() – see my week 19 report for details – and the object return functions I reported on in week 23.
While not intended to fix issues of diagonally adjacent regions not being visible to one another (SVC-8130), there are reports that at least some of the regions which have suffered from this issue for a considerable time can be seen from one another once more – although Maestro Linden isn’t entirely convinced the underlying cause of the problem has been corrected.
Release Candidate (RC) Channels
- A fix for ‘llApplyImpulse now works only in the root prim’ (SVC-8227)
- Crash mode fixes
- New LSL function: string llXorBase64(string str1, string str2)
- Returns a string that is a Base64 XOR of Base64-formatted input strings, str1 and str2.
- Fixes a ‘bad’ behaviour when the 2nd string contains nulls (“A” in base64) – SCR-35
- Aside from those cases, this function behaves identically to llXorBase64StringsCorrect()
- added to avoid changing the behaviour of existing scripts which may rely on llXorBase64StringsCorrect()’s current output
- Added max_materials_per_transaction flag to /simulator/features cap
- This number returns the maximum number of materials that can be sent to the “RenderMaterials” capability in a single request.
Speaking at the Server Beta meeting on Thursday 27th June, Maestro Linden described the max_materials_per_transaction flag thus:
It limits how many materials the viewer can request details for or set (POST, PUT methods) in a single message. By default, the limit is 50. The reason for the limit is that we don’t want the simulator to hang if a malicious viewer requests the details of 2 billion materials at once.
So, the capability for materials is called RenderMaterials [and] it has 3 HTTP access methods:
- GET: get the full list of details of all materials in the region
- POST: get the materials details for a list of material_ids (the server will only parse the first max_materials_per_transaction in the post data)
- PUT: set the materials properties of up to max_materials_per_transaction object faces
GET is used when you first connect to a region and want to get the materials of everything [in the region, not just within draw distance]; POST is used if, for example, a new object is rezzed with a new materials type, and the viewer needs to resolve what the normal map is, etc; and PUT is used for object editing.
[So] if the viewer needs to edit 80 faces at once, for example, it will know that the server limit is 50, and POST in 2 messages (one for the first 50, the other for the other 30). [The] ‘max_materials_per_transaction’ flag in the features cap will be a way for the viewer to know if the server limit changes from 50 per message. I’m not aware of any plans to change that limit in the near future, though.
Deployments for Week 27
There will be no server-side deployments in Week 27 (commencing Monday July 1st), as US Independence Day is on Thursday July 4th. The next scheduled deployments will be in week 28, commencing Monday July 8th.
Elijah Linden has discovered a bug within the pathfinding code, wherein certain regions have continuous navmesh rebaking, which causes some annoying UI effects, hurts simulator performance somewhat and causes memory spikes. Regions can be affected even if pathfinding is turned off.
The bug arose as a result of the recent CHARACTER_STAY_WITHIN_PARCEL property added to the pathfinding capabilities. Commenting on the bug at the Server Beta meeting on Thursday 27th June, Voidpointer Linden, who implemented the new CHARACTER_STAY_WITHIN_PARCEL property, said:
As part of the STAY_WITHIN_PARCEL changes, I needed to change the way the navmesh is constructed. This involved making sure that every region did a rebake once. Unfortunately, the criteria that I used to test whether a region needed rebaking had a flaw – it can’t see parcel edges underwater [possibly because the navmesh doesn’t include areas below sea level]. So if a region has more than 1 parcel and has no parcel edges above water, then it thinks it needs to rebake. So it does.
And does so repeatedly, as Elijah Linden reported in BUG-2975 (Regions continue to requests rebake after rebakes have been performed).
There is a fix for the issue, but it currently requires testing, and may not appear for a while. In the meantime, there is one assured workaround: if your region is suffering from the issue and has a parcel which is completely submerged, subdivide / raise one part of a boundary for that parcel (and which is not also a region boundary) above water so it can be found by the navmesh rebake process.
This bug is unlikely to be resolved before week 28 due to there being no deployments scheduled for week 27, as mentioned above.
The SL release viewer updated to version 184.108.40.2068007 on June 27th, containing the fixes from the 220.127.116.117611 beta release. This contains some updates related to the viewer being available via Amazon, and fixes for occlusion culling being less effective than it should be, legacy Shiny being too strong in ALM with materials,light function sampling is incorrect in advanced lighting model and a viewer compilation error.