• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

opensimulator grids

Ralf Haifisch

Aktiver Nutzer
Hallöle,

es scheint nun langsam eine erste Konzentration und die ersten ernsten kommerziellen Projekte zu starten.

Der erste Anbeiter mit Finanzsystem, Vollzeitkräften und auch aus SL Anbieter (Primadonna, Textures are us, ..) gibt es mit legendcity.

Bei einem der grossen öffentlich Testgrids (Deepgrid) hatte ich so paar Tendenzen erkannt und einen der Betreibet mal angetriggert...

---
Hi Ralf,

We’re actually sort of shifted to supporting OSGrid instead.

OSGrid provides the same ‘connect your regions’ and is more regularly updated and maintained.

Regards,

Adam

---

Hier gibts also offenbar ne Bewegung hin zu OSGrid, das dürfte für ne Weile das größte und professionel unterstützte sein - allerdings eher für "Englischsprecher".


Grüzzi,
Ralf
 
Dies gilt aber nur solange avatare noch nicht vollstaendig von grid zu grid fliegen koennen. und daran wird mit hochdruck gearbeitet. und dann schliessen kleine grids aus dem boden ...
 
wie ??

nicht können ? das Modul gibts doch... ich hatte es testhalber schonmal up - verbruachst halt eine Gridregion...


Denke, werde es über Weihnachten produktiv nehmen...


Testgrid SL - OSGrid ist ja auch noch offen.

Stabil ist anders gut - da gibts nen geilen Fehler, aber alle Seiten werkeln dran.

Ich denke dennoch, dass groessere Grids im Moment zielführender sind - und wenn dann eine Interessengruppe was aufmacht und direkt TP an ein paar andere Grids etabliert, dann prima.


cu
Ralf
 
es mag sein das der teleport funktioniert aber spaetestens beim inventar/assets wird es schwierig im moment .... ich glaube auch nicht das sich das in den letzten 30 tagen grundlegend geaendert hat.

solange das auch nicht funktioniert kann man schon noch davon sprechen das es noch "nicht funktioniert"

jeder user moechte schliesslich dann ueberall seine sachen zur verfügung haben.

kleine grids werden dann ganz einfach aus dem boden schiessen, weil jeder seine assets dann selber verwalten will.

gruss BD
 
ist ja weniger ne technische frage... die ist ja mit dem modul für lokale assets gelöst..

ich denke die einzige ungelöste ist die UUID-Konflikt Frage (ich sage nur clear cache).


Aber der größere Aspekt dürfte die Abstimmung der grids sein der Vertrauen bis Vertrag betrifft - aber da denke ich auch , dass offene Grids und private Interessengemeinschaften schneller dabei sind.

cu
Ralf
 
aehm, ohne jetzt rum zu klu8gscheissen, aber auch OSGrid empfiehlt sowohl den inventory als auch den asset server vonOSGrid also zentral zu nehmen. wenn sich jetzt innerhalb des letzten monats nichts grundlegendes getan hat, dann ist das auch sinnvoll, da sonst das Inventory nicht auf allesn sims zur verfügung steht. sprich wenn ich einen asset und/oder invebntory server bei mir hier unterm tisch stehen habe und auch meine sim und mich bei osgrid andocke dann kann ich mein inventar nur auf meiner sim nutzen und wenn ich was in mein inventar lege (von einer anderen sim) dann sieht das so aus als waere es in meinem inventar ist aber nicht wirklich angekommen.

und deswegen muss das protokoll erst dezemntrale asset/inventory servr unterstuetzen und dann wird jeder zu seinem grid des vertrauens gehen (SLI-Grid ;) ) oder sich selbst ein asset/inventory aufbauen ...


gruss BD

ps: willste nicht ne sim an SLI-Grid anbinden ?
 
no - ich habe mich in kleienren umgeschaut, auf bei SLI - osgrid ist die kleinste Nummer (u.a. aber auch aufgrund guter Entwicklerkontakt) die mich im Moment interessiert. Wobei ich gestehe, dass das Englisch in Foren und IRC und Meetings nicht alle erfreut. Aber: die deutsche Gemeinde wächst, in den letzten 14 Tagen werden so 15 deutsche regionen online gegangen sein. Gerstern habe ich wieder 2 auf nem Server eines User klar gemacht und fürs Wochenende stehen noch 4 in Pipeline. Das sind auch Projekte mit content.

Und das über Assetserver zu regeln wird wohl in diesem Jahrhundert nicht mehr passiern.

Ich habe z.B. in SL über 10.000 mehr oder minder komplexe Inventory-Items. Ein Backup (keine generierung von UUID, keine causeln SELECTS inner DB) dauert bei mri Stunden.

Der Abgleich der Assetdaten würde zwischen zwei grids also ewig dauern - ausser man greift in die gegenseitigen Assetserver (Stand heute unmöglich wegen möglichen UUID Konflikten) oder synchronisiert diese (wer soll/will es bezahlen, abgesehen vom rechtlichen) oder baut nen Drittanbeiterserver für alle.

Ich sehe das lokale Asset. letztlich bewährtes Konzept in vielerlei Sicht.

Keiner nimmt sein Haus im RL mt auf Reise. Man packt nen Reisekoffer.
Der kann klein oder grosß sein - und man kann alles wieder mitnhemen oder etwas dalassen.

Das ist dann auch gleich die Alternative zu Second Inventory und klärt deine Frage nach Zugriff anderer.

cu
Ralf
 
irgendwie reden wir an einander vorbei.

Es muss KEIN Abgleich der Assetserver entstehen. jedes Grid hat seine Asset Inventory Server connect jetzt user a von grid a zu grid b wird dem grid mitgeteilt das fuer die session des user a das inventory bei grid a zu suchen ist. laed der user a im grid b sein intentar in eine sim wird eh eine neue UUID generiert.

ob also in assets inventory oder usertservern die gleiche UUID herscht ist egal, da usar a -> grid a -> UUID eindeutig ist zu grid b > UUID.

was ich auch nicht verstehe, das du auf der einen seite sagst das geht nicht, aber dann wiederum das sich dezentrale assets durchsetzen, wie passt das zu einander?

gruss BD
 
der usecase den du beschribst ist technisch möglich, wird aber nicht stattfinden.

simple dinge, wie z.B. Kosten:

nu könnten alle user aus SL nach grid is teleporten. es würde auf den assetserver in SL verwiesen. wir spielen in grid x.

prima: linden betreiben also den Server dafür und haben die Bandbreite der Regionen die asset-requests stellen auf der rechnung. nur das Geschäft/die User sind extern. ich hoffe einfach, dass du als Geschäftsmann so ein Modell auch verbieten würdest. An Texturen mag ich nicht denken.

Andererseits: möchtest du als Gridbetreiber, dass die Gefühlte Bewertung deines Grid vom langsammen Assetserver der Konkurenzgrids abhängt ?

Legale, Fiscale und vertragliche Dinge lassen wir da mal aussen vor.


Und bei geht und geht nicht verstehe ich deien Frage nicht - ich vermute, dass bezieht sich auf mein Reisegepäck.

Der Usecase:

Ich bewohne Grid A
will nach grid B reisen
will dort angezogen sein und tanzen --> inventar
kopiere mir die passenenden Assets in meinem client in den ordner "lokales inventar" und damit auf festplatte (der client/das grid limitiert die grösse des Ordner, sagen wir mal 50 items)
ich teleporte zu grid B
kann man inventar dort nutzen + das lokale.
will ich lokales dort zu gridinventar machen, ziehe ich es vom lokalen ins gridinventar.


Aber denk mal über die Reisegpäckanalogie nach.

IT ist was seltsammes. Menschen denken alles ist ohen Kosten lösbar. Und IT´ler schaffen Lösungen die zwischen obskur, unfinazierbar und frei von Anwendung sind - häufig aber oversizt.

IT-Historie:
vor dem PC: Tischrechner, Block, Bleistift - ich habe meien Statistiken ausgrechnet.
Dann kam ein Apple mit Multiplan (Excel, für die jüngeren) ins Büro.
Also: Problem exisitierte , neue Lösung: prima

Dann begann IT zunehmen Probleme zu erfinden, zu denen es keine realen Prozesse gab. Oder Lösungen, zu denen man die Probleme erstmal finden muss.


I.d.R. kommt man in der Prozessanalyse extrem gut weiter, wenn man die Beispiele mal ohne IT durchdenkt --> so kommt das Reisebeispiel auf den Plan.

;-)


Aber: wir könnten mal zwischen den tagen den TP zwischen unseren Regionen in verschiedenen grids anwerfen. Der Code lies sich gestern zumindest compilieren.


cu
Ralf
 
ueber das teleportieren von grid zu grid sind wir uns doch sicherlich einige das dies funktionieren wird.

wenn ich also teleportiere nehme ich miene sachen nicht mit sindern gridb holt die sachen von grid a.

jetzt stellst du die frage zu geld .... sicherlich werden intergrids geld pro user fuer das betreiben des grids verlangen ... fureher oder spaeter ...

in dem angebot was ich hier mal gepostet hatte, steht auch drin, dass externe sims fuer die benutzung des grids geld bezahlen sollen (ist noch nicht so) aber so wuerde das dann werden, weil es eben finanziert werden muss.

was die sicherheit von texturen angeht, die sind natuerlich a nur solange sicher, solange sie nicht einer fremden sim hochgeladen werden, das ist auch jetzt im osgrid oder anderen grids so.

aber man kann ja auch UUIDS direct ansprechen, das wird dann sich sicherlich mehr durchsetzen um seine assets eben nicht auf die sim zu laden.

vieleicht muss man dann auch nach user und asset/inventory groesse variabel bezahlen ...

das eine hat meiner meinung nach mit dem anderen ncihts zu tun.

und ich als geschaeftsmann vertrete dennoch opensource und soziale gerechtigkeit ich mag keine geldgier, dennoch muss es bezahlt werden ...

man sollte aber entwicklung und forschung nicht vom geld abhaengig machen ....

alles eine frage der gesellschaft aber das fuehrt hier zu weit.

gruss BD
 
Blackie Demina schrieb:
jeder user moechte schliesslich dann ueberall seine sachen zur verfügung haben.

Mir würde es schon genügen, für eine Fernreise das zu behalten, was ich am Körper trage. Also eine Art temporäre Kopie aller Kleider, Körperteile, Attachments und HUDs, die man trägt.
 
Hi Mona,

ja - darum ging es bei lokalem Inventory.

Geht ja heute auch: SI anwerfen, saugen aus Grid A auf Festplatte, hochladen in Grid B. Sprich Inventar liegt auf deiner Festplatte.

Nu baut man dieselbe Funktion in nen Viewer ein.

Das werden wir nächstes Jahr sehen (außer der Entwickler der es zugesagt hat fährt vor den Baum).


cu
Ralf
 
Hi Blackie,


"ueber das teleportieren [libary:7ab0c1dd70]Eine Reisemöglichkeit in [SecondLife] um schnell von einem Ort zu einem anderen zu [reisen].[/libary:7ab0c1dd70] von grid zu grid sind wir uns doch sicherlich einige das dies funktionieren wird. "


--> klar, im Juli geschehen - http://blog.secondlife.com/2008/07/08/ibm-linden-lab-interoperability-announcement/
Ein Grund, weshalb osgrid heute TRUNK fährt, gell. Dort ist OGP eingeflossen.


"wenn ich also teleportiere nehme ich miene sachen nicht mit sindern gridb holt die sachen von grid a. "

--> ein mögliches model, nicht das favorisierte aus den erwähnten Gründen
--> wenn man es im OPG realisieren wollte, müsste man es hier einreichen: https://jira.secondlife.com/browse/SVC-3156
OPG sieht es nicht vor. http://wiki.secondlife.com/wiki/Open_Grid_Public_Beta/FAQ "Your inventory will not come with you, and you'll appear as the 'ruthed' or default avatar on external virtual world regions."

--> Das Opensim Inventory-Model REST kennt keine Funktion zum "Abgleich"... http://opensimulator.org/wiki/REST

--> es gibt drei Ansätze
a) "Proxy by local" - was zu den beschriebenen wirtschaftlichen Themen führen wird - aber schon die
Technik ist die ich auch für nächste Tage favorisiere http://opensimulator.org/wiki/Hypergrid
Sprich: Teleport [libary:7ab0c1dd70]Eine Reisemöglichkeit in [SecondLife] um schnell von einem Ort zu einem anderen zu [teleportieren].[/libary:7ab0c1dd70] von A zu B , aus B wird auf den Asset-Server in A zugegriffen - eine lokale Kopie im Cache
erzeugt - und in Grid [libary:7ab0c1dd70]Begriff für das [SecondLife] Server-Netzwerk[/libary:7ab0c1dd70] B Assetserver hochgeladen.
b) lokale Assets (ggf. auch ergänzend) - selbe Idee wie vorher, nur zeitversetzt und ohne Eingriff in Server zu regeln.
Auf Basis z.B. libsl zieht man während man in Grid [libary:7ab0c1dd70]Begriff für das [SecondLife] Server-Netzwerk[/libary:7ab0c1dd70] A ist eine Kopie ins lokale Inventory.
In Grid [libary:7ab0c1dd70]Begriff für das [SecondLife] Server-Netzwerk[/libary:7ab0c1dd70] B schiebt man es wieder hoch.
Entsprechen featurerequest gibts bei allen wichtigen Viewer, bzw. auch immer mal wieder im opensim-dev IRC .
man könnte sagen Second Inventory integriert.
c) zentrale Assetdienste (die genau den von dir beschriebenen Transfer verhindern)
"In the proposed architecture, control of assets is moved from grid owners to content owners"
http://opensimulator.org/wiki/AssetServerProposal
Auch Erweiterungen zum inworld-scripting sind dazu bereits eingereicht, z.B.
osRezFromURL(string url, vector pos, vector vel, rotation rot, integer param) - calls on_rez

was die sicherheit von texturen angeht, die sind natuerlich a nur solange sicher, solange sie nicht einer fremden sim hochgeladen werden, das ist auch jetzt im osgrid oder anderen grids so.

--> die sind nur solange sicher, solange sie nicht benutzt oder angezeigt werden. Dazu brauchts ja keinen Copyboot sondern z.B.
die Debug-Schnittstelle von OpenGL und ein wenig freeware... Texturen [libary:7ab0c1dd70][Bilddateien] welche über ein [Objekt] gelegt werden kann. Neue [Texturen] müssen vor einer Verwendung auf einem [Objekt] in [SecondLife] für ca. 10 [L$] hochgeladen werden[/libary:7ab0c1dd70] im Überfluß.


aber man kann ja auch UUIDS direct ansprechen, das wird dann sich sicherlich mehr durchsetzen um seine assets eben nicht auf die sim zu laden.

--> Ein Beispiel für die UUID-Thematik die immer aufpopt währe übrigens auch hier: http://forge.opensimulator.org/gf/p...er/?action=TrackerItemEdit&tracker_item_id=54
--> aber direkt ansprechen ? wenn es GUID´s wären, dann vom Konzept her ja. Aber UUID´s aus meiner Sicht eher nicht.


vieleicht muss man dann auch nach user und asset/inventory groesse variabel bezahlen ...
--> stimme ich vollkommen zu.


das eine hat meiner meinung nach mit dem anderen ncihts zu tun.
bzw
man sollte aber entwicklung und forschung nicht vom geld abhaengig machen ....
--> klingt mir persönlich zu sehr nach perpetuum mobile... irgendwer muss die Party zahlen...


Ich könnte nu noch was C# code aus den angesprochenen Modulen nachwerfen, u.a. viewer-patche für Versuche zu lokalem Inventory. Ich gehe aber davon aus, du hast ne libsl.


Insofern mag ich zu dem Diskussionsthema jetzt schliessen.


cu
Ralf
 
Ralf Haifisch schrieb:
Sprich Inventar liegt auf deiner Festplatte.

Nu baut man dieselbe Funktion in nen Viewer ein.

Das werden wir nächstes Jahr sehen (außer der Entwickler der es zugesagt hat fährt vor den Baum).

Second Inventory ist im Prinzip ein Copybot, der die Permissions beachtet. D.h. du kannst nur Sachen kopieren, die du selbst gebaut hast. Für Builder, die nie irgendetwas in SL konsumieren, ist das sicher toll, für den Rest von SL, also 99%, ist das sinnlos.

Wer hat gesagt, ein Copybot wird in den Viewer eingebaut? o_O
 
danke für die Nachhilfe...

ansonsten erfreut dich Punkt a) aus der nachfolgenden Antwort an Blackie , die Technik ist Stand heute realisiert. Erfordert aber Kooperation der beteiligten.

copybot.. naja.. der libsl-client kann das alles eh und die library ist offen und wir auch von den SI-Jungs genutzt... und auch von copybot. Wo ist der Punkt ? Das offene Protokoll haben Lindens verusacht. Die Lösung werden wir aber nicht kurzfirstig sehen, dazu brauchts ne DRM-Lsöung , die braucht noch min. 2 Jahre.

Ich selber ziehe ja durch einige Grids und gebe zu: es gibt Objekte, da mag man sich ärgern. Aber ich habe ausreichend Objekte die ich mit SI weiternutzen kann. Wobei die Selbstbeschränkung auf "full perm" (völlig unitalienisch) ja nirgends in Stein gemauert ist. Der Viewer müsste nur die Rechte einhalten - und das über alle Grids die du besuchst.

Du findest die Dikussionen um die Implementierung in Mailinglisten udn Bugtracker/feature request der grossen freien Viewer. :)

cu
Ralf
 

Users who are viewing this thread

Zurück
Oben Unten