So far, barring any LL concepts, we have (as far as I know so far!) two
designs of plugin system:
1: Socket-based plugins - as suggested by Morgaine.
2: D-Bus or similar existing IPC tool.
3: C++ Dynamically Shared Objects - my suggestion.
Morgaine's design has a couple advantages that I can think
I agree 100%. Yet, as this topic is about the different faces of client
code, having the terms well-defined will help in the future. We are both
agreed that there are sandboxed and non-sandboxed parts, and each has it's
purpose. I just wanted to establish common terms, with some generic
examples
When logging into OpenSim with Snowglobe I see a lot (dozens) of these
messages in the log file:
2010-03-08T00:33:18Z WARNING: LLInventoryPanel::modelChanged:
d24c5c7b-4d64-45eb-9286-91fb0f307b24 is in model and in view, but STRUCTURE
flag not set
What does this message mean? Am I sending invento
On Sun, Mar 7, 2010 at 6:58 AM, Michael Schlenker
wrote:
>
> Am 07.03.2010 um 15:39 schrieb Obsidian Kindragon:
>
>> Hi all,
>>
>> I've a quick question regarding the new llSetLinkPimitiveParamsFast()
>> function in 1.38.0. Why did LL opt for a new function instead of just
>> removing the delay fr
My apologizes, turns out the problem was entirely between my keyboard
and my chair.
On Sun, Mar 7, 2010 at 7:52 PM, Latif Khalifa wrote:
> I'm trying to implement the new MoaP capabilities in my text viewer
> Radegast. However the two new CAPs, ObjectMedia and
> ObjectMediaNavigate are not grante
User perceptions are completely orthogonal to the engineering issues here
though, Ricky. We could certainly make all use cases look entirely uniform
from a user perspective if we wanted to, but we don't advocate that because
the security and responsibility issues are so different in the two (and o
Latif,
In taking a quick look at the code granting those CAPs, there's nothing
conditional on the viewer string. There may be other flags that need to be
set at login, though, and I don't see anyone from the MoaP team around at
the moment to ask. The CAPs can be disabled on a per sim basis, so y
I'm trying to implement the new MoaP capabilities in my text viewer
Radegast. However the two new CAPs, ObjectMedia and
ObjectMediaNavigate are not granted by the seed capability of the
simulator.
Is the login server disabling those capabilities based on a version string sent?
Latif
_
Since recent discussion has been on script limits you might want to take a
look at this jira I wrote up for a better display of which prims in an
objects are using resources:
http://jira.secondlife.com/browse/SVC-5467
-Jonathan
___
Policies and (un)subsc
Carlo, both you and Morgain make very good arguments as to why various parts
I separated are, technically, the same. However, while I understand that
Dynamic Scripts (loaded from serverside) and UserScripts are completely the
same thing (just like in a browser, the JavaScript loaded from
the serve
Code is proprietary unless stated otherwise by the maker. Abandoned code
does not mean public domain code, this would be a violation of copyright to
release protected source code to the public without the agreement of the
owner first. Whether they are still active in SL or not does not matter.
O
About that: "Creator out of SL; no source code"
But we know the "source" is still bound to the prims, a la SL.
Has LL ever done anything about helping recover abandoned code, in some way?
- JB
On Sun, Mar 7, 2010 at 10:45 AM, Garmin Kawaguichi <
garmin.kawagui...@magalaxie.com> wrote:
> I supp
I suppose that's just because the LSO code has changed and there are
thousands objects no modify having the creator out of SL : not possible to
compile the script(s)
GCI
- Original Message -
From: "Obsidian Kindragon"
To:
Sent: Sunday, March 07, 2010 3:39 PM
Subject: [opensource-dev]
On 2010-03-07, at 08:39, Obsidian Kindragon wrote:
> I've a quick question regarding the new llSetLinkPimitiveParamsFast()
> function in 1.38.0. Why did LL opt for a new function instead of just
> removing the delay from the current llSetLinkPrimitiveParams()
> function?
Because code that curren
On 2010-03-07, at 08:20, Carlo Wood wrote:
> On Sat, Mar 06, 2010 at 11:19:43PM -0800, Ricky wrote:
>> Client Plugins
> Ok, although I'd prefer if-- for example-- media plugins run in a
> sandbox;
> think about the recent mention of the quicktime exploit.
The kind of sandbox you can usefully en
On 2010-03-07, at 07:50, Carlo Wood wrote:
> Lets assume that the *average* script uses
> 8 to 16 kB of real memory. LL's design allocates
> 64 kB regardless, leading to an overhead of
> 400 to 800% (meaning they need to buy 5 to
> 9 times the memory that is theoretically needed).
This is not the
On 2010-03-06, at 20:02, Frans wrote:
> In response to the OP. I agree the UI will have to present that
> information differently. As it is now people will merely make a
> decision on memory usage and choose LSL scripts, and remove mono
> scripts. Likely negatively impacting their own experie
Am 07.03.2010 um 15:39 schrieb Obsidian Kindragon:
> Hi all,
>
> I've a quick question regarding the new llSetLinkPimitiveParamsFast()
> function in 1.38.0. Why did LL opt for a new function instead of just
> removing the delay from the current llSetLinkPrimitiveParams() function?
> I can't c
Hi all,
I've a quick question regarding the new llSetLinkPimitiveParamsFast()
function in 1.38.0. Why did LL opt for a new function instead of just
removing the delay from the current llSetLinkPrimitiveParams() function?
I can't conceive any case where removing the delay from the current
funct
On Sat, Mar 06, 2010 at 11:19:43PM -0800, Ricky wrote:
> Client Plugins
Ok, although I'd prefer if-- for example-- media plugins run in a sandbox;
think about the recent mention of the quicktime exploit.
> Client Extensions - Interpreted code packages placed in a special folder in
> the
> client
Lets assume that the *average* script uses
8 to 16 kB of real memory. LL's design allocates
64 kB regardless, leading to an overhead of
400 to 800% (meaning they need to buy 5 to
9 times the memory that is theoretically needed).
In that light, I gave it some more thought, and
think something as co
Ricky, there's nothing major wrong with your classification, but you make
two breakdowns which actually have no clear demarcation between them:
- Your "Client Plugins" and your "Client Extensions" are actually one and
the same thing, merely representing two different use cases of the same
As far as I understand it a script (the item you manipulate in-world) is a
bytecode (a compiled version of your code without the comments, the spaces
and the returns) loaded into the sim, plus its simple, constant-size
variables (integer, floats), all of which forming the stack. Then you have
all t
May I ask a probably dumb question here? It's probably been answered but I
can't find the answer now.
Presumably a script uses two resources, the byte code in its assembly and a
slab of memory allocated for its stack/heap. And am I right that the former
can be shared between multiple copies of a
I agree completely, Marine.
We're being given a choice of two options which together make no sense, and
worse, represent an undue burden on scripters and a regression into the
distant history of Computing.
The system should define a *large* but *hard* limit to the maximum memory
allocated per scr
Well we have two mutually exclusive solutions here.
Either Mono scripts are given a hard memory limit that we (the scripters)
can change within the scripts, with all the overhead work that it implies
(i.e. modifying hundreds of scripts before issuing an update, and having to
know upfront how much
26 matches
Mail list logo
