It's not exclusively about Snowglobe.
With OpenSimDev around..hmh. OSVDev could be a good name.
On Wed, Feb 3, 2010 at 06:51, Ryan McDougall wrote:
> How about snowglobe-dev, as there are other people making
> SL-compatible viewers as well.
>
> Cheers,
>
__
Or, as I mentioned, the parcel object bonus has an influence on a
script memory bonus, that would work similiar the parcel bonus does.
Dependant on total land mass person X owns in the sim. The parcel can
hold more objects/Memory than it normally could, but it can't go above
the total objects/Memor
But in your example, the script uses the max of the sim til the avatar
comes in. The script will crash, as the avatar takes his own share of
memory, and the script suddenly has less than it actually uses (not
what it -could- use but doesn't).
Scripts -will- be able to check available memory, that
And the script instantly crashes because suddenly it holds more data
than it can when the avatar enters the sim? The alternative would be
for the script to keep the memory it uses..but that would defeat the
purpose of script limits, as now the sim would use up more memory than
the 300mb it is suppo
P.S. no, this increased memory count was supposed to only apply to LSL
scripts, as they want to ultimately fade them out. Mono scripts will
have their actual memory usage counted when it comes to the limits
On Thu, Dec 17, 2009 at 15:30, Ambrosia wrote:
> The idea of this was mentioned alre
The idea of this was mentioned already in an office hour from earlier
this year. 64-128k
was the mentioned amount there.
As for the other items..Babbage is approachable, I don't think they
are off the table.
What I would personally suggest is to simply directly tie the memory
limit multiplier
to t
Just to make a few things clear about memory limits and how they work:
* 300mb will be divided between land and avatars in each sim. Fixed
size per avatar, and per square meter.
* Each avatar will have their own memory pool for attachments
* Each parcel will have its own memory pool depending on i
On Fri, Oct 23, 2009 at 12:12, Stickman wrote:
> Is it possible to see the "size" of an asset? Size may exist in
> various forms, such as "in memory" size, "on disk" size, and
> "bandwidth used." Are textures stored in memory in a compressed state,
> or do they have a a byte per pixel?
Naturally
And another thing to add, if the passwords are supposed to be binary
encoded, one can use
http://en.wikipedia.org/wiki/Base64
to store this encrypted binary data in a text-safe manner.
___
Policies and (un)subscribe information available here:
http://wi
On Wed, Jul 15, 2009 at 13:31, Ambrosia wrote:
> A note here,
>
>
Additionally, storing the data outside the normal custom settings.xml
means that the client'd have no set amount of alt login information it
could store. 1, 5, 10, 20. An alt_info.xml that gets loaded on startup
in
A note here,
I strongly, -strongly- suggest against reading and storing the alt
information in the normal custom user settings.
Remember, any options that any other client one might use does not
know about get removed from the custom settings.xml, on start of said
client.
Simply store the alt ac
Thank you, Stickman.
Some people don't seem to have any idea that while SL lacks many
'special effects' of modern games,
it has vertexes/trianglecounts that make some other games look very
very pale in comparison.
Not that this is necessarily a good thing, mind you. It is partially a
reason why SL
I have two bugs in mind that I consider to be affecting the general
populance, and being noticable by even new users. They'd be the
occasional rendering of avatar parts as transparent (in some cases
across half the face :P), pie menu failing on non-prim avatar parts at
times.
I guess I can start s
This is news to me as well. Rendering limits? Which? I personally have
not noticed anything that I might recognize as a new rendering limit?
On Wed, Jun 17, 2009 at 16:02, Harleen Gretzky wrote:
> Can you elaborate on what the new rendering limits are?
>
>
> On Wed, Jun 17, 2009 at 9:35 AM, Kent Q
I'm not quite sure the viewer will ever effectively take advantage of
64bit systems.
It's just not a piece of software that -can- take an effective
advantage, unless exept maybe things like 64bit integers and such.
Which actually also can be done in 32bit software, ironically, and I
doubt the ram u
Personally I have given up on boost hell and VS express 2008 a while
ago. It just was too frustrating, too kludgy-hacky, and the fixes on
the wiki just brought up new errors. VS 2005 worked, as usual,
flawlessy, as does the Linux build.
Given that VS Express 2005 isn't even offered for download an
All in all I think, a function to return all avatar keys in the sim
falls into the exact same category as the proposed functions to
enhance llSetPos() with a new function that works in the whole
rezspace:
People already achieve those effects. With workarounds, client
modifications, massive paralle
On Mon, May 18, 2009 at 04:16, Nexii Malthus wrote:
> I think rather than keeping the problem on the LSL side, it would be more
> suitable for being a viewer-side feature entirely that replaced the
> necessity of such silly HUDs and Gadgets. Finally removing the source of the
> problem alltogether
You can use it without shadows, that's the beauty. Once RenderUseFBO
and RenderDeferred are enabled, simply deactiavate
RenderSunShdaows(?). I think that was the debug param. And voila, you
have the deferred renderer without any shadowing. I however don't know
if shadow calculations aren't still go
Hi there!
Have you installed Cygwin?
if so, when you installed it, did you check 'Yacc' and 'Bison' under
the 'Development' category of packages?
If you did so, did you install Cygwin under C:\cygwin? The project
file uses it as the default location for bison and yacc, last I
checked, tho I think
On Thu, Apr 30, 2009 at 15:06, Thomas Grimshaw wrote:
> Roll on VideoLAN. :) It's about time we integrated a player that didn't
> suck.
>
> ~T
>
Seriously.
On a note, with the FLOSS exception not including the licenses for
Quicktime, FMOD and Vivox..I sense a massive oversight on part of LL
here
, Ambrosia wrote:
> Quote:
>
> 'The viewer is licensed under the GPLv2 with an additional FLOSS
> exception. This FLOSS exception allows linking to GPL-incompatible
> libraries.'
>
> On Thu, Apr 30, 2009 at 14:25, Argent Stonecutter
> wrote:
>>
>> On 20
Quote:
'The viewer is licensed under the GPLv2 with an additional FLOSS
exception. This FLOSS exception allows linking to GPL-incompatible
libraries.'
On Thu, Apr 30, 2009 at 14:25, Argent Stonecutter
wrote:
>
> On 2009-04-30, at 04:37, Ambrosia wrote:
>> I just re
> Be a little careful of quicktime, on Macs its part of the operating
> system/standard distribution so linking against is fine under the GPL,
> on windows its certainly not part of the operating system so your in
> danger of GPL issues here right away on on mac platforms.
I just realized that we'
On Thu, Apr 30, 2009 at 11:05, Ambrosia wrote:
> That's what the LGPL is for, unless I'm mistaken
Note:
Actually I am mistaken. LGPL allows a LGPL'd library to be linked to a
proprietary app, not vice versa.
___
Policies and (un)sub
> Be a little careful of quicktime, on Macs its part of the operating
> system/standard distribution so linking against is fine under the GPL,
> on windows its certainly not part of the operating system so your in
> danger of GPL issues here right away on on mac platforms.
>
> Robin
>
Hmh. From wh
On Tue, Apr 28, 2009 at 05:59, Tateru Nino wrote:
> Also: distribution with Quicktime support, FMOD, the art assets, the fonts.
> (I believe I know the correct answer to the latter two - but we may as well
> get it all clarified in one go, right?)
>
> Have we missed any pieces?
I think those, alo
Greetings!
This hasn't let go of me all day, and I hope to find some
enlightenment here about the issue.
As often repeated, and stated on the wiki (by a third party), the lib
Kakadu and the Vivox components of the SL viewer can not be freely
distributed in 3rd party clients.
Now, an issue with a
>
> Indeed, I was referring to the latter. The former is what EBML might
> be a candidate for.
>
Then again, EBML is not as flexible.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the polici
> I think you're confusing LLSD[1] with the Binary UDP Message System[2].
> Different things for different use cases.
>
> [1] http://wiki.secondlife.com/wiki/LLSD
> [2] https://wiki.secondlife.com/wiki/Protocol#Binary_UDP
>
Indeed, I was referring to the latter. The former is what EBML might
be a
> There's been much discussion on the MMOX mailing list about LLSD vs google
> protocol buffers.
>
> I'm not sure that the rejection was concerning that particular form of
> serialization or merely concerns
> about insisting that we use that particular way of describing the
> on-the-wire protocol.
Speaking of saving bytes, it was mentioned on this list a longer time
ago, and for some reason rejected:
The idea of using Google Protocol Buffers instead of the currently
rather unflexible implementation of LLSD.
http://code.google.com/intl/de-DE/apis/protocolbuffers/
The protocol buffers serve
Greetings,
I was wondering, before I file a JIRA,
can anybody confirm and/or reproduce the following bug with the 1.23 trunk code:
* Take a notecard that contains an embedded object. Not a texture, not
a script, but an actual object.
* Try to take said object out of the notecard.
My observation is
Vector:
see the file doc/asset_urls.txt
in there are URLs to the artwork and libs you need to add.
On Fri, Mar 6, 2009 at 07:36, Vector Hastings wrote:
> Thanks for everyone's help!
>
> The new tarball seems to fix that problem, now I'm onto umpteen of these:
>
> "CMake Error: Cannot find sourc
There, I added a check for 'ubuntu' in /etc/issue.
If present, it attempts to automatically use sudo instead of su - -c
Script link is the same.
:3
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please r
Yes, I'm aware, hence why I mentioned replacing it with sudo and
removing the '&& exit'
in the comments. Theoretically the script could just check /etc/issue
for Ubuntuness or Debian.
On Thu, Mar 5, 2009 at 18:39, Glen Canaday wrote:
>
> Nice. Trying it out now.
>
> Ubuntu has root disabled by de
Greetings SLDEViants!
I made a bash script that compiles a standalone 1.23 trunk build on
Apt/dpkg based systems.
It's tested on Debian Lenny, and takes care of everything, getting
packages (Including the toolchain and subversion),
downloading the trunk, adding fixes and 3rd party libraries, befo
n 2.5 might cause some messages when running develop.py, but
say it -should- run fine.
Try grabbing the GL package manually, comment it out, and see if you
get MD5 errors on the other libraries as well.
On Thu, Mar 5, 2009 at 11:05, Ambrosia wrote:
> On Thu, Mar 5, 2009 at 10:59, Vector Hasting
On Thu, Mar 5, 2009 at 10:59, Vector Hastings wrote:
> I'm attaching the full log below, but seems like I'm stuck on:
>
> "RuntimeError: Error matching md5 for
> http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008
> 0613.tar.bz2"
>
> I don't know much about this, but looks
On Thu, Mar 5, 2009 at 09:24, Ricky wrote:
> FYI: I fairly closely follow the build directions I posted on my user page
> at http://wiki.secondlife.com/wiki/User:Cron_Stardust the only exception
> to this is that I've disabled a patch and had to tweak a source file due to
> a bad #if or three...
Open up the debug settings, and search for
RenderShadowClipPlanes(?)
Put in values like 50 150 300 and you will find the distance at which
shadows show to be increased,
be aware tho that they might be a little more rough up close. The
other settings I tinkered with, but in the end left at the
def
Hokay, first off, don't grab the shadow-draft-2 branch.
Grab normal trunk instead. The shadow code got merged into it, and
it's basically the base for the 1.23 viewer. Any further changes in
the shadow code will probably take place in that one.
After doing so, just run the python configure -G VC80
No, the shadow codce is in trunk, not viewer_1-22.
But, I'd not worry...the compile steps for trunk are the very same as
for the viewer_1.22 branch,
so the wiki 1.22 steps apply to it. I've successfully built the trunk
under Microsoft Visial Express 2005 now.
On Tue, Feb 24, 2009 at 03:49, Vector
Exactly :>
Thanks for the explaination of that one!
On Mon, Feb 23, 2009 at 13:11, Robin Cornelius
wrote:
> On Mon, Feb 23, 2009 at 7:32 AM, Ambrosia wrote:
>> Greetings Vector,
>>
>> To my knowledge, shadows are now in the trunk branch, so you might
>> want to tr
Greetings everybody,
I just filed a JIRA on an XML parsing error in the current 1.23 trunk,
and was wondering if anybody else encountered the error;
See https://jira.secondlife.com/browse/VWR-12161
This started to happen after the latest big update introducing the
merger of the shadow branch fil
Greetings Vector,
To my knowledge, shadows are now in the trunk branch, so you might
want to try and compile that one. For me it worked with the latest
lldkdu.dll, tho at least under windows, it seems to have trouble with
parsing the avatar_skeleton.xml. I wonder if anybody else gets that
issue. C
The main issue with enhanced lsl-to-client communication, like in
RestrainedLife that was mentioned as an example, is..
The change of behavior runs deep. RestrainedLife is not about the UI,
but direct client behavior for all sorts of things.
All effects and behavior that one'd want to be executed
Joy:
Make a new folder, somewhere.
Copy the contents of your build-vc90/release/* (or debug, or
relwithdeb) folder into that one. The only exception are the
secondlife-bin.* files aside of the .exe, you don't necessarily need
those.
Also put the following files from the indra/newview/ folder in:
les.xml
>
> Not in any build directory.
>
>
> On Mon, Feb 2, 2009 at 12:21 PM, Lear Cale wrote:
>>
>> Thanks, Ambrosia :)
>>
>> ALL_BUILD was the default project. I changed it to secondlife-bin.
>>
>> In properties for secondlife-bin, I don'
Lear:
When trying to start the client from the MSVC, do these steps first:
Right click the secondlife-bin project, and set it as the startup project.
Then go into the project properties, and set
\indra\build-VC80\release\ (or debug, or relwithdeb) as the working
directory.
then try again. Basica
The shadow branch has recently been merged into main-render-11.
As for healthy inventory sizes, I have a 12k inventory, and haven't
had any issues in over a year.
I know it can strike anytime from what I heard, but it's just my experience.
On Mon, Feb 2, 2009 at 17:16, Nik Radford wrote:
> Lol,
>From the experimentations of a friend with the viewer I can say that,
yes, DirectX only handles the vram detection and joystick handling in
the viewer. Of course the latter could be a big deal, as I suppose the
Space Navigator ties directly into that. Removal of the DirectX
dependency is easy enou
On Wed, Jan 28, 2009 at 16:32, Anna Gulaev wrote:
> Ambrosia wrote:
>>
>> indra/build-*/newview/release/ <- everything in that folder
>
> That folder contains the incremental linker file and the debug database. Do
> I need those? Seems to run without them, though I di
On a note, you don't need to copy all folders along with the .txt
files from the indra/newview folder.
'app_settings', 'fonts', 'character' and 'skins' suffice.
To sum it up:
indra/build-*/newview/release/ <- everything in that folder. might be
'relwithdebinfo' or 'debug' instead of release. bui
> On Tue, Jan 27, 2009 at 01:27:51AM +0100, Ambrosia wrote:
>> Well, consider it then tested and failing ;)
>>
>> As I said, the debug console shows no issue. It, for all intents and
>> purposes tells:
>>
>> "LLAudioEngine::startInternetStream:
>>
eaming audio
> implementation from the media manager, which on Linux is
> GStreamer and on Win32 and OSX should be QuickTime, but I don't
> think the latter has has been formally tested.
>
> Ambrosia wrote:
>> Interesting.
>>
>> Is GStreamer now a requirement fo
gt; Dana Fagerstrom wrote:
>> Not sure this is your problem but check your viewer log and make sure
>> you have a GStreamer mp3 decoder installed. In the log and without the
>> decoder, GST will report that it can't find an appropriate plug-in.
>>
>> D
>>
>&
Greetings SlDeviants! ;P
This is a request to those who might have compiled clients
successfully with OpenAL and have then running.
I've run into a peculiar issue:
Audio streams based on the MP3 file format will seemingly not play.
Debug shows a successful run of "LLAudioEngine::startInternetStre
That would mean alot of internal change, as the object's scripts
should not run in this case. No on_rez, no triggering, and such. We're
talking about a huge effort here, and IMO LL already has their hands
full on various issues.
However, there's a small pet project for you. If you don't mind the
s
Make sure not to ship llkdu.dll, the 'fonts' folder, the fmod files,
and the vivox/voice dlls.
In 1.22, fmod can be replaced with openAL, which is free to use and
distribute, and the fonts (3 .ttf files) should in my opinion be
replaced with open sourced/open commons versions. That would, in the
e
On Thu, Dec 4, 2008 at 10:50, karen.chow <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
> I have made some changes to the SL viewer source code and successfully
> compiled it using Visual C++ 2005 Express Edition. I have followed the wiki
> to compile my code, and I have built it using RelWithDebInfo, and
-bin
project despite being compiled with OpenAL.
On Wed, Dec 3, 2008 at 20:12, Ambrosia <[EMAIL PROTECTED]> wrote:
> Sorry, I have to correct myself.
>
> The issue is one of alut.h including alc.h and al.h in the following manner:
>
> #include
> #include
>
>
arises after the fix is
LLAudioEngine_OpenAL::WIND_BUFFER_SIZE_SEC not being initialized in
the class in the line 75 of audioengine_openal.h
static const float WIND_BUFFER_SIZE_SEC = 0.05f; // 1/20th sec
Sorry for the confusion if I caused any.
On Wed, Dec 3, 2008 at 20:01, Ambrosia <[EM
Greetings!
Just wanted to let you know, after the trunk update with the new
OpenAL implementation, it seems like the actual OpenAL library files
are missing.
CMake does not grab them, nor are they in the lib package.
See the missing \libraries\include\AL folder/directory. Currently you
will have
Greetings,
if anyone, be they Linden or resident, is available, can you check if
you can login to JIRA currently?
My login attempts seem to fail, however everything works fine when I
try the same on the SL website.
Did some database setting go booboo? :>
--Chalice Yao
__
<256.0,256.0,4096.0> I'd say. Makes it easy to autoadjust to new
building heights sometime in some future.
Also, yeah, I'm all for adding this function, even if no sim size
changes will be done anytime soon. It doesn't hurt to add, and will,
over the years, remove the issue with scripts not being
Well, I presume the number is inspired by the maximum 8bit value :>
That and it's what they started out as, and by now that number is used
in lots of parts of the viewer code, the sim code, and LSL scripts all
over the grid. Changing the size now would have to be a very careful
process, given that
Well, is the folder, by chance, named 'Dev' on your system? :>
Try renaming the actual folder to 'dev', or if that is already the
case, to 'Dev'
Not quite a fix per se, but perhaps a workaround.
I don't know why it happens. I have uppercase letters in my path to my
viewer source.
On Wed, Oct 22
The big lib that tends to get put in from the LL-releases that boosts
performance is lldku.dll (and/or whatever the Linux version uses.
lldku.so?). Just copy that one into your viewer's main folder and try
again. We can only hope that one day libjpeg will be on par in speed.
On Wed, Oct 22, 2008 a
You'll notice that one path says 'dev' while the other says 'Dev'.
Call it a hunch, but I think cmake, even under windows, is probably
case sensitive.
On Wed, Oct 22, 2008 at 04:47, Alissa Sabre <[EMAIL PROTECTED]> wrote:
> I'm having a build problem on Windows.
>
> I'm working on 1.21.6 using Vis
Greetings!
Is anybody still getting mails from jira-notify?
My last one is from the 18th, and weekends usually are the most busy
time when it comes to JIRA.
Something seems b0rked here.
--Chalice Yao
___
Policies and (un)subscribe information availabl
Greetings,
thought I'd point out the just-created JIRA on this:
http://jira.secondlife.com/browse/VWR-9784
I've been waiting for the past few trunk updates, figuring it might be
an intentional change for some backend changes,
but it's been the status quo for a short while now. Scripts simply
can
Um, Gordon.
Rob said 3rd party viewer creators can contact him and ask for the
source code in advance.
Which will be released to the public tomorrow, so either way tomorrow
3rd party coders can patch the fix into the most ancient viewers there
are.
While I understand the frustration about no imm
Greetings!
This is mostly aimed at Soft Linden, but for those who are interested,
check the latest trunk changeset:
http://svn.secondlife.com/trac/linden/changeset/1193
Among the things that caught my curiosity is binary support for llsd,
and what seems to be an Agent Inventory Service.
What we
74 matches
Mail list logo
