MW wrote:
> I've just added some very initial support for reading Hypergrid link
> data from xml files, that includes support for the xml files being on
> a webserver.
>
> The xml file has a format like:
>
>
>
>
>
>
>
>
>
>
>...
>
> ...
>
>
> And to make a reg
I realise they're epoch times, it just seems a little odd to have them
instead of database native date/time types. I wondered if there was a
compatibility reason or something...
Number of times accessed makes it easy to sweep for assets that were
accessed once and then discarded, which is g
OK, let's get this hypergrid link-fest party started!
To cope with the viewer bug problem, I will have 2 regions in the UCI
Grid positioned at 3000,3000 and 7000,7000, respectively, so that people
can go back & forth between grids in the 1000's and grids in the
1's. I will post their addre
We will have a Hypergrid exhibit at the Birthday weekend Event, setup assisted
by Diva.
http://simzee.com/birthday_party.html
I would have no problem in leaving that region alive after the Event as a
OSGrid active tutorial. Tho the Wiki is clear re 4096 , I agree a see it will
help.
Bri Hasp
due to a viewer bug, all the HyperJump should be within the 4000,4000 range
maybe it will be nice to create some kind of "hypergrid" area common on all
the grids, somethinkg like a reserved area for hyperjump
sm
On Thu, Jan 15, 2009 at 8:45 PM, Ai Austin wrote:
> At 19:19 15/01/2009, MW wrote:
Thanks for the comments
1. The stuff in the LLClient section would be mostly within the one
client thread. The async callback in GetAsset will follow the flow
chart after AssetLayers Decoded through one iteration. That's the
only place in the llClient section where the thread context is
nebulo
At 19:19 15/01/2009, MW wrote:
>I've just added some very initial support for reading Hypergrid link
>data from xml files, that includes support for the xml files being
>on a webserver.
>
>The xml file has a format like:
>
>
>
>
>
>
>
>
>
>
>
>...
>
> ...
>
>
>An
Thank you for the technical assessment Mike, and for everyone's comments so
far. I've added a few notes and clarifications inline.
> -Original Message-
> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
> boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey
> Sent: Thu
The integers for create_time and access_time are "epoch times", where the
beginning of the epoch is 1/1/70.
To convert one uses the mysql function from_unixtime(create_time) or
from_unixtime(access_time) to see a YY-MM-DD-HH-MM-SS format.
On OSGrid, we now have about 1,000,000 entries in the as
Eugen Leitl kirjoitti:
> On Thu, Jan 15, 2009 at 02:10:13PM +0900, Mike Mazur wrote:
> As an aside from the peanut gallery, it would be nice to have asset
> storage in a distributed cryptographic filestore like Tahoe
> http://allmydata.org/~warner/pycon-tahoe.html
>
that has been my understand
I've just added some very initial support for reading Hypergrid link data from
xml files, that includes support for the xml files being on a webserver.
The xml file has a format like:
...
...
And to make a region load it and create the links, you use the con
Any chance of a number of times accessed field for assets, in addition
to the access_time field?
While I'm looking at the assets table, is there any specific reason
why creation/access times are stored as integers rather than using
actual date & time types?
On 15 Jan 2009, at 00:24, Mike Ma
On Thu, Jan 15, 2009 at 02:10:13PM +0900, Mike Mazur wrote:
> Hello,
>
> I'd like to present my analysis of the Cable Beach[1] design & code,
> with the aim to eventually use it as the official OpenSim asset and
> inventory server.
As an aside from the peanut gallery, it would be nice to have ass
Mike Mazur wrote:
> Hello,
>
> I'd like to present my analysis of the Cable Beach[1] design & code,
> with the aim to eventually use it as the official OpenSim asset and
> inventory server.
Hey Mike. Thanks very much for doing this summary. Here are some comments.
Sorry these are grouped toge
Teravus Ovares wrote:
> Greetings all those interested in OpenSimulator development,
>
> I have compiled the following flow chart as a proposal for the
> process, the system separation, and the thread contexts of image
> requesting and would request the community's comments on it.
>
> You can fin
Hello,
LSL vehicle scripts currently won't work as-is, since the
vehicle-related functions are basically stubs for now. Also, since
OpenSim is using a different physics engine back end than SL, it's
unlikely that 100% compatibility with LSL vehicle scripts will be
achieved any time soon, if at all
the LSL is all going very well indeed, thanks to the developers for
all the work on this. Many scripts I bring over from SL work fine
first time now. But my vehicle scripts simply give a compile error
saying wrong script engine in use. I am using
physics = OpenDynamicsEngine
meshing = ZeroMes
Ai Austin wrote:
>1) Region seems to be handled simply. If you FIRST introduce a
>region via an XML file with a given UUID, it takes that on. So
>UUIDs can be preserved in the new environment (or indeed on test
>setups on salty builds ahead fo a real deployment as I do). You
>cannot ALTER t
As you can see from my recent inputs we have been having a clear out
of out Opensim after running an early Grid 18 months ago, then a
standalone with 12 regions for 2008 and now with a (fresh start)
UGAIM grid setup, 12 regions on same server, add in regions on other
servers, and even trying hy
Hi,
On Thu, Jan 15, 2009 at 7:34 PM, Ai Austin wrote:
>>In a grid where you control all the regions and databases, it should be
>>feasible to write a tool that can discover inaccessible assets.
>>...
>>AFAIK the texture remains in the DB forever.
>
> [...]
>
> A command console level thing to per
Thanks Mike, thatsa giood summary and what I thought...
> From what I understand, nothing is done to old inaccessible assets.
>There is some difficulty in determining which assets are inaccessible.
>The reasons include:
>
>- assets can be referenced in scripts by UUID (so I heard)
>- assets may be
21 matches
Mail list logo
