Just a quick update to fix a couple of bugs introduced in 1.11
- The user could click on certain objects that use the touch_end() event rather than the touch_start() event, despite the @fartouch restriction.
- The user could cheat around the @edit restriction by a clever use of the UI (which I won't disclose, of course).
Executable and sources : http://www.erestraint.com/realrestraint/
Have fun !
Marine
Tuesday, June 24, 2008
Sunday, June 22, 2008
RestrainedLife 1.11.4
Here is RL v1.11.4, still working over SL 1.19.1.4 (sorry a lot of people are asking for a version for RC 1.20 but release candidates are just changing too often, and it takes a while to adapt a patch to a new version, sometimes half a day).
Not really new features, let's say just ironing the already existing ones :
* added : inability to receive group chat when unable to recieve IMs (thanks Boy Lane for the trick).
* changed : cannot change the group tag if you are unable to send IMs anymore.
* changed : cannot Take and Return objects if you are unable to Rez things.
* changed : could not Delete objects when unable to Edit, now it is linked to Rez instead, since Rez is dedicated to build/remove objects while Edit is dedicated to modify existing content.
* fixed : bodyparts (shape, skin, eyes and hair) could not be shared. Keep in mind that bodyparts cannot be removed, only replaced by other bodyparts. [Note : it did not figure in the release notes, my bad. But it does work.]
As always, thanks to Orchid, you can find the viewer for windows, and its sources, on the eRestraint website :
http://www.erestraint.com/realrestraint/
Have fun !
Marine
Not really new features, let's say just ironing the already existing ones :
* added : inability to receive group chat when unable to recieve IMs (thanks Boy Lane for the trick).
* changed : cannot change the group tag if you are unable to send IMs anymore.
* changed : cannot Take and Return objects if you are unable to Rez things.
* changed : could not Delete objects when unable to Edit, now it is linked to Rez instead, since Rez is dedicated to build/remove objects while Edit is dedicated to modify existing content.
* fixed : bodyparts (shape, skin, eyes and hair) could not be shared. Keep in mind that bodyparts cannot be removed, only replaced by other bodyparts. [Note : it did not figure in the release notes, my bad. But it does work.]
As always, thanks to Orchid, you can find the viewer for windows, and its sources, on the eRestraint website :
http://www.erestraint.com/realrestraint/
Have fun !
Marine
Wednesday, June 4, 2008
Freezing at login : SOLVED
Or so I hope. Thank you all of you who helped me with logs, observations, objects, and most of all patience. I want to particularly thank Boy Lane and Hollie Wood for their precious help without which I would not have found the culprit.
Here is the new version :
Executable for windows : http://rapidshare.com/files/120107732/RestrainedLife.zip
Sources : http://rapidshare.com/files/120106959/RL_Sources.zip
(I have sent them to Orchid but if you're in a hurry and can't wait for her to upload the new viewer you have a link at least).
If you're interested in the technical details read on :
The bug was "simply" due to the fact that the viewer renames shared objects as soon as they are worn, only if their name does not contain any information about the target attachment point. So far so good, it works like a charm. But when logging on the viewer needs to download all the items contained into the shared folder ("#RLV" for the moment), otherwise you would have to open every sub-folder by hand, one by one, after each login (if you didn't do so the scripts would not even be able to force you to attach them, since for your viewer they don't exist until download from the server, and it's done by opening the parent folder manually).
However, some items are "not complete" when they are downloaded, I frankly don't know what that means (likely that they are not fully downloaded but the name and UUID are known by the viewer, something like that) but attaching and renaming an incomplete object leads the viewer into an infinite loop. The actual name of the method is LLAppViewer::forceErrorInifiniteLoop(), for those who can look at the original code, yeah I can't believe it even exists either.
So there's your freeze on login. I have added a check or two and now it doesn't seem to crash or to freeze anymore.
Have fun !
Marine
Here is the new version :
Executable for windows : http://rapidshare.com/files/120107732/RestrainedLife.zip
Sources : http://rapidshare.com/files/120106959/RL_Sources.zip
(I have sent them to Orchid but if you're in a hurry and can't wait for her to upload the new viewer you have a link at least).
If you're interested in the technical details read on :
The bug was "simply" due to the fact that the viewer renames shared objects as soon as they are worn, only if their name does not contain any information about the target attachment point. So far so good, it works like a charm. But when logging on the viewer needs to download all the items contained into the shared folder ("#RLV" for the moment), otherwise you would have to open every sub-folder by hand, one by one, after each login (if you didn't do so the scripts would not even be able to force you to attach them, since for your viewer they don't exist until download from the server, and it's done by opening the parent folder manually).
However, some items are "not complete" when they are downloaded, I frankly don't know what that means (likely that they are not fully downloaded but the name and UUID are known by the viewer, something like that) but attaching and renaming an incomplete object leads the viewer into an infinite loop. The actual name of the method is LLAppViewer::forceErrorInifiniteLoop(), for those who can look at the original code, yeah I can't believe it even exists either.
So there's your freeze on login. I have added a check or two and now it doesn't seem to crash or to freeze anymore.
Have fun !
Marine
Monday, June 2, 2008
Freezing at login
Several people are reporting a strange problem when logging on RL 1.11.*, they appear to freeze on login. I am very aware of this problem and am investigating, but so far no good, I'm not freezing even with dozens of folders full of items under #RLV, and in sims that do the deprecated call to fetchDescendents().
So please if you're having this problem, send me a notecard with your computer specs, the name of the sim you're logging on, the number of folders under #RLV and the number of items per folder (average). Even better, try to check your log file (under AppData\SecondLife\Logs) and look if you find the word "deprecated" once for every folder under your #RLV folder.
The reason I suspect for this bug is that the call to load the folders in advance (while logging in) is serialized and does not freeze the viewer but makes login waaaay too long. If it was not loading those folders you'd have to open them by hand. One by one. After every login. So this feature is kinda like a necessary evil.
So please if you're having this problem, send me a notecard with your computer specs, the name of the sim you're logging on, the number of folders under #RLV and the number of items per folder (average). Even better, try to check your log file (under AppData\SecondLife\Logs) and look if you find the word "deprecated" once for every folder under your #RLV folder.
The reason I suspect for this bug is that the call to load the folders in advance (while logging in) is serialized and does not freeze the viewer but makes login waaaay too long. If it was not loading those folders you'd have to open them by hand. One by one. After every login. So this feature is kinda like a necessary evil.
Subscribe to:
Posts (Atom)
Posts
