Re: [opensource-dev] Review Request: VWR-25923 Unnecessary capability request spam
I agree very much about extensive testing of changes in key-functionality like voice. Lots of teleporting is the right thing to do for this patch (see the jira for more a more detailed list of things that I think need to be adressed). About Inventory failures and being disconnected from the sim, just to repeat here what we already where talking about in irc: neither iteration of the patch does anything inventory or disconnecting from the sim. To check the "you never know" factor I tried the build from a) my viewer-development branch with patch iteration 2 applied and b) Imprudence 1.3.2 with neither of both iterations applied. I got 1 time disconnected with a) , 2 times almost and 1 time disconnected with b). That all looks very much like a simulator - or network issue close to the sim to me. However good to address that, too, since for proper testing one needs to be able to make a distinction if a patch is causing a failure or the current state of the service. Armin jaeger_...@hotmail.com wrote: > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/333/#review819 > --- > > > When I applied this latest patch to firestorm, which is based off of > LL 2.5.2, I kept getting timed out when TPing from a mainland area > and a DD of 256 to other regions. I tried multiple times TPing from > the area around help island public to magnum sandbox 4 or to help > people island. In every case I timed and was logged off after the TP > was completed, as the viewer was cleaning up and closing connections > to the old regions. I don't have this problem with the first > iteration of this patch. I feel this scenario needs to be tested > with this latest patch on v-dev tip to make sure this doesn't happen > there as well. > > The account I used only has 4 friends, and around 24 items in the > inventory in addition to the library. It also only has 2 attachments > (a hud and the firestorm bridge) and is one of the noob outfits. I > also am running on an i7 2600k, 16GB ram, ATI 6970, and 20/5mbit FIOS > connection. > > - tankmaster.finesmith > > On June 24, 2011, 4:45 a.m., Jonathan Yap wrote: > > --- > > This is an automatically generated e-mail. To reply, visit: > > http://codereview.secondlife.com/r/333/ > > --- > > > > (Updated June 24, 2011, 4:45 a.m.) > > > > > > Review request for Viewer. > > > > > > Summary > > --- > > > > This is a patch by ArminWeatherHax. I am creating the request to > > help speed this fix along in the system. > > > > > > > > Ways to reproduce: log into a simulator. > > Reproduces: always > > Affects: any version supported, probably all 3rd party viewers but > > Kokua (and Imprudence, soon). > > > > What happens: > > In each idle cycle the voice client requests the > > "ParcelVoiceInfoRequest" capability, thats each time a HTTP GET. > > See LLVivoxVoiceClient::stateMachine() after comment // Check for > > parcel boundary crossing > > > > Expected: > > On parcel/region change request the capability once. It's not the > > region that rezzes in, but the avatar, so do the request for the > > capability not earlier than the agents region signals > > capabilitiesReceived() true. After that you are sure if the region > > returns an empty url you can give up for that region. > > > > Not sure about the impact on lag - requesting and returning an url > > is not much data transmitted, though its a pretty big number of > > people doing it over and over per second (no matter if they have > > voice on or off). > > > > > > > > > > going once again through llviewerregion I see its fortunately not > > each time a HTTP GET, just once when the agent connects to the > > region. Though the patch still saves all the lookup if the cap is > > there while it can't be possibly. > > > > > > This addresses bug VWR-25923. > > http://jira.secondlife.com/browse/VWR-25923 > > > > > > Diffs > > - > > > > doc/contributions.txt 04e2a3ddca51 > > indra/newview/llviewerregion.h 04e2a3ddca51 > > indra/newview/llviewerregion.cpp 04e2a3ddca51 > > indra/newview/llvoicevivox.h 04e2a3ddca51 > > indra/newview/llvoicevivox.cpp 04e2a3ddca51 > > > > Diff: http://codereview.secondlife.com/r/333/diff > > > > > > Testing > > --- > > > > > > Thanks, > > > > Jonathan ___ 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] An SL appliance...
Lee ponzu schrieb: > Does the Linux viewer use X? If you DISPLAY SL on another computer > running an XServer, does it behave OK. > > If so, could you assemble a small Linux host with a high end GPU and > then DISPLAY SL on a different computer on the same local network? > > ponzu so far I used yukon only for local opengl capture, but if its network streaming works comparably well I guess https://github.com/wereHamster/yukon/tree/rewrite and its dependency https://github.com/wereHamster/seom/tree/packetized-stream is fine to DISPLAY SL on a remote computer in a reasonable fast local network. Armin ___ 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] Mesh decomposition using hacd
I' ve been successfully uploading meshes on OSGrid with your library, Wolfpup, and I'm confident it will work in SL soon, too. Great work, thank you for that ! :) Armin ___ 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] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp
I just came along that, too. It only happens with a release build, commit that introduced it is 4880a28422be (viewer-development). I worked around it by passing -Wno-array-bounds to the compiler (see here: https://bitbucket.org/ArminW/kokua-merge-3.0.0/changeset/f4a68595e9b6 ) for now. Hope that helps Armin > Ubuntu 32 GCC 4.4 > > Any idea's y'all. Im pretty much clueless about programming but with dumb > newbie luck I was able to compile if I changed > > verticesp->mV[3] = 0.f; > to > verticesp->mV[2] = 0.f; > > Compiled but particles looked bad (duh..) > > Any help would be great :) > > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp: In > member function ‘virtual void LLVOPartGroup::getGeometry(S32, > LLStrider&, LLStrider&, LLStrider&, > LLStrider&, LLStrider&)’: > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:332: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:334: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:336: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:338: > error: array subscript is above array bounds ___ 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] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp
> The underlying code segment here needs a rewrite. This is one of the rare > cases where GCC is actually complaining for a very valid reason. /me agrees absolutely. Is there already a Jira around (I searched, but didn't find one, but that might be just bad luck)? Armin ___ 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] Mesh viewers and tcmalloc issues
> That define is really only used for some statics code in > llallocator.cpp. It does > not influence if tcmalloc is used or not. its not clear where/why/when it is used - any code path includuing tcmalloc on linux 32bit isn't compiled, though the viewer crashes if it isn't linked, which in my opinion at least needs a comment *that* just linking it makes a difference. Even better would be a comment with e.g. a link to furher information about *why* just linking it makes a difference. For Linux 64bit not linking tcmalloc makes no difference (anything is aligned anyway, and I didn't see any difference in speed). Armin ___ 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] Gstreamer issue.. how to debug?
Am Tuesday 20 December 2011 17:19:34 schrieb Mike Chase: > If I run > > gst-launch-0.10 playbin uri=http://96.44.147.34:7078 > > This works fine. >From the replies I see you are running a 64bit Linux - so your systems gst-launch-0.10 is a 64bit executable and loads 64bit libraries. For that it has no diagnostic value for debugging a 32bit executable (SLPlugin) which tries to load 32bit libraries. The best thing you can do is to closely watch debug messages about unresolved symbols to find out which 32bit gstreamer parts, plugins, dependencies are missing (e.g. usual suspects are libhttpsoup and libgnomevfs, however there are probably more missing). If you are anyway compiling the viewer yourself, probably its easier and faster to compile a 64bit viewer. If you want I can make a patch for using the Imprundence/Kokua prebuilt 64bit libraries, and point you to 2 patches of Nicky Dasmijn which fix the viewer code for 64bit. Armin ___ 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] Inventory Patch you should integrate
Am Wednesday 11 January 2012 10:07:55 schrieb Henri Beauchamp: > Oops... > > There was a bug in the patch I sent for v1 viewers (I forgot to replace > mFolderAdded(FALSE) with mFolderAdded(folder_added) in the constructor > of LLInventoryCopyAndWearObserver). > > Attached to this email is the fixed patch. > > Henri. Thank you for porting, Henri! And yes, it would be very good to have somwhere to test in the betagrid, there are a couple of things I think it would good to have an eye on: * in LLFloaterOpenObject::moveToInventory it looks to me that at least a LLCategoryCreate object gets leaked if a null category_id is returned, however all the // If we get a null category ID, we are using a capability in // createNewCategory and we will handle the following in the // callbackCreateInventoryCategory routine. if (category_id.notNull()) seems to contradict whats actally happening in LLInventoryModel::createNewCategory: null id returned on 2 possible failures, non-null in all other cases including success. * LLInventoryModel::createNewCategory returns a non-null id, even though requesting the cap failed if : - one or both of callback or user_data == NULL (ok, that is both rather unlikely) - the cap url is empty (e.g. the capability response didn't arrive (yet)). About that Im not so sure that it can not happen: buy new avatar, tp to busy sandbox on a busy weekend and have a bad network route anyway, rezz - open - copy and wear directly after teleport ... not sure yet how to simulate that in the betagrid, but I want to see what happens before it does to users. Armin ___ 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: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
Am Saturday 28 January 2012 00:37:44 schrieb Jonathan Welch: > Yes, because the coarseupdate packet holds many positions, it is not > just 1 packet per avatar, but as many as can be packed into the > coarseupdate packet as will fit. So it is not possible to alter this > packets' format in any way. Doing so would break all existing viewers > that expect it to have its current format. Old viewers have all sorts of issues if their code isn't maintained anymore, most of them are way more important. Imagine the Z- byte transformation was made non-linear: that would still give better results than we have right now, be a small change to new viewers, have low impact on old viewers, and generate no extra network load. Example: (1*1 + 2*2 + 4*4 + 8*8 + 16*16 + 32*32 + 64*64 + 128*128)m = 21845m range. Armin ___ 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] Linux 64bit non-standalone (was: Linux toolchain update... testers needed.)
Oz Linden (Scott Lawrence) wrote:
> There is no plan to do this.
>
> There is also not a plan not to do it.
>
> I don't know whether or not the new build systems this was created on
> are any better set up for 64 bit building than the old one they will
> replace were (I'll find out). However, even if they are, doing the
> work to rebuild and retest all the components and the viewer itself
> is not a priority for Linden Lab. If it happens that the build
> systems are already going to be 64 bit capable, and some open source
> developer (or team) wants to take on doing the job, I can coordinate
> the requisite access.
I'm building Linux 64bit non-standalone viewers since 2 1/2 years now,
in gerneral once all libraries where in place there has been most of
the time no extra work - its just a Linux version with different
libraries. Looking at the download couter, a bit more than half of all
Imprudence Linux users are using the 64bit version).
The patch I'm using for autobuild is trivial
https://bitbucket.org/ArminW/autobuild-kokua/changeset/d653428ae98e -
to build 64bit export AUTOBUILD_PLATFORM_OVERRIDE=linux64 ("linux64"
is inherited from viewer 1 time, there have been some package
references in the install.xml file).
Adding a linux64 project to the viewer isn't that much of a difference,
see for example Boroondas draft repository:
https://bitbucket.org/boroondas/viewer-development-linux64-draft .
I added also a linux64 project to many of the 3p libslibrary, though not
yet all of them, see https://bitbucket.org/ArminW . Probably some bits
and pieces would need changing if someone wants to prepare versions for
LL use, but for sure for that purpose they can already save a lot of
time in the way they are now. If someone or a team wants to take the
job of getting them through the codereview process I'm glad to
contribute my work as is.
Armin
___
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] Using Boost & the viewer
what Cinder said + for avoiding the boost/thread/pthread/condition_variable.hpp:53: warning: unused variable 'res' #include Armin ___ 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] step by step guide to compiling snowglobe
Robert Martin schrieb: > the biggest problem as such is some parts of the compile run seem to > require chicken blood and sheep entrails. I personally have a 3-legged black cat, but that might be a Linux specific helper and explain little differences in mouse handling. (scnr) ___ 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] Third party viewer policy: commencement date
> I am simply pointing out that they are NOT compatible with the GPL. GPL compatible or not - the sentence "The Snowglobe Viewer [...] this viewer may be somewhat less stable than the official Second Life viewer"( http://viewerdirectory.secondlife.com/ at 2010/03/10 00:06 GMT+1) is a slap into the face of anybody contributing bugfixes to the secondlife codebase. Armin ___ 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] Snowglobe 2.0^H^H^H1.3 way forward?
Boroondas Gupte schrieb: > On 03/12/2010 07:37 PM, Carlo Wood wrote: > > Is there anything added to 2.0 code that actually is an > > improvement over snowglobe 1.3 ? > > X11-like copy-paste (by selecting and middle mouse button) but it's partially broken in viewer0.2. Also 90% of the code is already in SG1.3 since SNOW-222 was applied, if you are interested I search the patch that adds the missing 10% to SG1.3 ... er ... and of course it's also in Imprudence for a little while already :) Armin ___ 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] Snowglobe 2.0^H^H^H1.3 way forward?
Soft Linden schrieb: > On Fri, Mar 12, 2010 at 10:30 AM, Carlo Wood wrote: > > On Fri, Mar 12, 2010 at 08:47:57AM -0800, Soft Linden wrote: > >> With larger features like mesh coming along, know that you'll be > >> signing up for an awfully large chunk of porting work though. > > > > Last time I asked there was nothing being done about mesh. > > There were no plans and certainly no code! > > This was publicly demo'd at SLCC: > http://www.youtube.com/watch?v=swh6gY_dEH0 > > I don't know what's been announced since then and don't have a close > relationship with the graphics guys. I'd hit Runitai's office hours > if you want to know the current state of everything rendered. e.g. that: SLDev Mailing List "Kent Quirk (Q Linden)" wrote On Jan 14, 2010, at 06:55: On Jan 13, 2010, at 11:42 PM, Dale Mahalko wrote: > There are other important questions to ask about SL 2.0. > > Will the mesh implementation... NO. I don't know how the mesh rumor got started, but it's already been stated in this thread that 2.0 will NOT include mesh support. All the questions are interesting, but they don't apply yet. > > If LL's history is any indication, SL 2.0 will just assume by default > that everyone has a 50 megabit Internet connection, and if you have a > mere 256 kbit you are not going to be able to do much of anything. > (Where's the official support for an organizational-level proxied > asset/texture cache? I've pretty much given up hope that LL will ever > care about its limited-bandwifth users with a huge number of people on > a limited pipe, like at schools.) Well, I'd like it if you wouldn't give up hope. It's a hard problem, and you're not likely to see much change in viewer 2.0. But with the advent of lighter-weight computing devices at all levels, we do have to evolve a more bandwidth-flexible set of protocols, and it's an issue that has become a regular part of our thinking as we consider the future. Q ___ ___ 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] Snowglobe 2.0^H^H^H1.3 way forward?
Yasmin Adams schrieb: > oh yes please! > > X11-like copy-paste (by selecting and middle mouse button) > > > :-) http://jira.secondlife.com/secure/attachment/37076/SG1.3mmbpaste.diff :) ___ 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] TPV - Nope
Nicholaz Beresford schrieb: > In fact I won't even log in again under the new terms > and have canceled my accounts today. +1 See you around in the rest of the Metaverse :) Armin ___ 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] opensource-dev Digest, Vol 3, Issue 40
Daniel wrote: > No, the real issue is that some people _THINK_ LL is trying to give > TPV developers legal liabilities. This is about interpretation and > not facts. Unless I missed something LL has never stated anything > about legal liabilities, it's solely based on some peoples personal > interpretation of the TPVP. this is, in fact, also an interpretation and not facts. Not favouring one of those interpretations over the other, just being descriptive. Armin ___ 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] Banning by client
Tigro Spottystripes schrieb: > AFAIK only LL (and someone intercepting network communications) knows > what channel some client is using Yes and no - it is also transmitted with the useragent of the build-in webbrowser. Armin ___ 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] SpaceExplorer on Linux
Hi, just updated for Imprudence Jan Cigars libndofdev with a one-line patch adding 3dconnexion-SpaceExplorer detection. Source is up here: http://imprudenceviewer.org/download/libs/source/libndofdev-0.2.1-source.tar.bz2 :) Armin ___ 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] opensource-dev Digest, Vol 7, Issue 56
Oz Linden (Scott Lawrence) schrieb: > On 2010-08-20 9:35, Daniel wrote: > > What I would*really* like to see as a builder, and someone with > > two widescreen monitors, is the ability to drag floaters completely > > outside the perspective view area. For me, they just get in the > > way of seeing what I am doing. How much work would be required to > > enable that I have no idea. > > I'd really like that one too, and I don't even really qualify as a > builder. > > Unfortunately, it doesn't qualify as 'easy', but it is marked as a > High priority item on the Snowstorm backlog. https://jira.secondlife.com/browse/SNOW-375 is a great approach for that. Using Dzonatas interface I do not only have my (for example) chat floater on a different screen, the differet screen is also attached to a different computer. Pretty cool, really. :) Armin ___ 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] Update Linux Build Documentation, please?
Aleric Inglewood schrieb: > Thanks. I guess it makes sense to make a page that is less confusing, > especially for people who do not want to build standalone. You > shouldn't throw away anything (except the old stuff at the bottom). > I think it would be very good to avoid duplicates too: probably best > to just refer to a different page for stuff that applies to both > standalone and non-standalone, so that it won't exist twice on two > different pages! + think about renaming the "non-standalone" build to something easy to understand and what it actually is. "default" for example. Armin ___ 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] Project-MESH viewer
Nyx Linden wrote: > We just pulled from viewer-development yesterday actually, but we had > already released the initial beta viewer. > We try to stay reasonably up to date, but we don't merge the latest > changes every day. > > Don't worry we will stay synced! > > -Nyx Its anyway awsome - ty and all working on it :) Armin ___ 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
