Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
On Sun, 17 Feb 2013 01:25:36 +0100, Martin Fürholz wrote: Hello Henri, first: no I cannot reproduce the issue with small prims. They are resized in a viewer with my fix from 0.01, 0.01, 0.01 (whis is the minimum prim size in the LL viewer) to 0.014, 0.014, 0.014 perfectly, just exactly like in the current SL release viewer. I DO CONFIRM THAT THE BUG ***###DOES###*** HAPPEN WITH LL'S LATEST VIEWER V3.4.5.270263 (like it did happen with all former v3.4 and v3.3 viewers: I didn't test older ones). Perhaps you have different settings than mine and not seeing it, but this bug DOES exist ! Second: as far as I've been told LL does not take code from you from what-ever reason, The reason is that I refuse to give to LL my real life (snail-mail) address and phone number for such a puprpose as signing a CA: it is ILLEGAL in France (and EU) to require such private information for such a purpose (the required *private* information is excessive for the purpose: my RL name and signature is all what LL needs): what would LL do with my phone number anyway (that is on red list by the way: only my family and close friends got my phone number !) ? I can't understand half of spoken English (especially when spoken by Americans), and I can't speak it properly (some may find French accent cute in English, but believe me, mine is not cute the least !). LL says it must abide the French (and EU) law by requiring their residents to pay the VAT (this is untrue as well: that law about VAT on Internet was made so that *competiting* EU companies would not be disavantaged in regards on companies not having to charge a VAT, but the law doesn't say that companies *without a comptetion* should charge it !!! Basically, LL's EU customers are paying taxes twice (US taxes, that is included in the price of everything LL charges to residents, *and* EU VAT) !... On the other hand, LL doesn't respect the least laws protecting the privacy of their foreign customers and would like me to go by their, ILLEGAL rules ! Sorry, but no thanks ! so it won't be of help if you write or email any extensions to my fix on this list. In the contrary it will make it impossible for me to do any even common-sense changes to it, as LL (as far as I can tell) doesn't accept any changes from people who don't have a CA on file with Linden Lab, even if those changes are fixes of very obvious bugs and even if they are common sense-fixes or even if they are industry-standard. A bugfix is NOT copyrightable, unless it would involve a full rewrite or significant change of the whole algorithm: the changes I proposed are TRIVIAL: if you really are anal, you could even change my proposed if (a != b) code for if (a - b != 0) LOL ! Get **REAL**, please, and stop seeing problems were there is NONE !!! I would like you to contact me directly, instead. Yes, I know this type of hypocrisy and practiced it several times with Oz so to push nasty crash bug fixes in LL's code: I could also tell another TPV developer in private what bug fixes I found and ask them to pass them to LL... But it's pure hypocrisy and I'm getting TIRED of it all ! Mind you, I was also the one who brought attention on this bug, and in this very list, and even proposed a first (partial) bugfix for it a few weeks ago: https://lists.secondlife.com/pipermail/opensource-dev/2012-December/009424.html https://lists.secondlife.com/pipermail/opensource-dev/2013-January/009450.html Beside, this fix DOES interest other TPVs developers that are NOT compelled to reject my contributions in their viewer, because *their* viewer is not LL's (even if they share the same base): most, if not all TPVs got code that I contributed (and I'm not even speaking about trivial bug fixes) and I keep being asked from time to time for my agreement for adding some GPL patch I made in the past into today's v3-based TPVs (the agreement here is just for the GPL to LGPL change, not for CA stuff). In fact, if you look in LL's viewer contributions.txt file, you will even see my name there... and the list of contributions is not even complete (each time I contributed a patch on the JIRA, I never updated the contributions.txt file myself but let Lindens do it if they felt like it (especially since trivial bug fixes are hardly worth mentioning), so the list only contains the few contributions for which the Linden who integrated my patch did bother updating that file themselves). It was back in a time, when the Open Source concept was better understood and respected by LL... This fix is meant as a fix for the LL viewer, and not for your own Third-Party-Viewer. It's meant to be part of any viewer, unless you keep it in a private list that only CA contributors can read from and post in *and* that you close the sources of the patched viewer ! The viewer code is LGPL, meaning that any viewer with a compatible license (such as GPL viewers like mine) *can* include any part of its code. That's the exact purpose of OPEN
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
On Sun, 17 Feb 2013 10:59:47 +0100, Martin Fürholz wrote: Hello, me and others cannot reproduce your 'nipple bug', neither with your 'cool nipples' from the marketplace, nor with the test setup you've given in your earlier mail. You can deny all you want, but I do know what I am seeing on my screen... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
On Sun, 17 Feb 2013 13:27:22 +0100, Henri Beauchamp wrote: On Sun, 17 Feb 2013 10:59:47 +0100, Martin Fürholz wrote: Hello, me and others cannot reproduce your 'nipple bug', neither with your 'cool nipples' from the marketplace, nor with the test setup you've given in your earlier mail. You can deny all you want, but I do know what I am seeing on my screen... Henri. And as a final proof: http://sldev.free.fr/misc/ResizeBugProof.ogv (note: it's an OGV video: VLC can read it, if your standard player can't). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
Hello Henri, thank you for your video. I was able to 'kind-of' reproduce it partially in LL Viewer 3.4.5 (270263). The prim doesn't visually resize to it's full size, it's 10% smaller than it should be until I zoom out and back it. I will try to fix that and update the repository. Tyvm. I cannot find a Jira issue for that bug, could you please file one? Thank you. -Ursprüngliche Nachricht- From: Henri Beauchamp Sent: Sunday, February 17, 2013 3:01 PM To: MartinFürholz Cc: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL On Sun, 17 Feb 2013 13:27:22 +0100, Henri Beauchamp wrote: On Sun, 17 Feb 2013 10:59:47 +0100, Martin Fürholz wrote: Hello, me and others cannot reproduce your 'nipple bug', neither with your 'cool nipples' from the marketplace, nor with the test setup you've given in your earlier mail. You can deny all you want, but I do know what I am seeing on my screen... Henri. And as a final proof: http://sldev.free.fr/misc/ResizeBugProof.ogv (note: it's an OGV video: VLC can read it, if your standard player can't). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
On Sun, 17 Feb 2013 16:08:37 +0100, Martin Fürholz wrote: Hello Henri, thank you for your video. I was able to 'kind-of' reproduce it partially in LL Viewer 3.4.5 (270263). The prim doesn't visually resize to it's full size, it's 10% smaller than it should be until I zoom out and back it. In fact, something could well influence this bug: the frame rate... The higher the frame rate, and the most likely the buggy test will fail in updateXform() (since the prim is smoothly resized server-side and viewer-side, at high frame rate, the scale difference between the current and the past frame will be (worngly) considered neglectable because of that buggy test)... Since I've got frame rates in the 100+ (up to 200 FPS with the Cool VL Viewer in that skybox where I made the video), I'm probably more impacted than someone with 20 FPS... I will try to fix that and update the repository. Tyvm. Thanks. I cannot find a Jira issue for that bug, could you please file one? Sorry, I stopped using the JIRA for reporting viewer bugs (I keep using it for server bugs, since there's no other channel to do it for them) after LL closed it, making it impossible for anyone else than the JIRA issue creator and Lindens to read the reports... I don't have time to loose, and I lost enough time and energy on this issue already (especially for something so trivial !). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ --- Review request for Viewer. Description --- At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp updateXform to decide whether a scale change requires an immediate rebuild or not. This addresses bug BUG-1709. https://jira.secondlife.com/browse/BUG-1709 Diffs - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/617/diff/ Testing --- See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/617/ --- (Updated Feb. 17, 2013, 7:02 p.m.) Review request for Viewer. Description --- At high framerates tiny prims get stuck upon interpolation when they are resized via script. I fixed that by comparing the original scale versus the new target scale (instead of comparing the original scale versus the new interpolated target scale), in lldrawable.cpp updateXform to decide whether a scale change requires an immediate rebuild or not. This addresses bug BUG-1709. https://jira.secondlife.com/browse/BUG-1709 Diffs - indra/newview/lldrawable.cpp fbbee98b7512 Diff: http://codereview.secondlife.com/r/617/diff/ Testing (updated) --- See test plan in Jira: https://jira.secondlife.com/browse/BUG-1709 Repository: https://bitbucket.org/MartinRJ/bug-1709 Thanks, MartinRJ Fayray ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges