Arriba-Sim: Binärdownload für Metropolis (inoffiziell)

1246711

Comments

  • Mareta Dagostino
    Mareta Dagostino
     Member edited 2:23AM
    Hallo, danke für eure Rückmeldungen! :)

    @Primus: Wenn du den Quellcode des Scripts öffnest, fangen die fraglichen Befehle mit "os" an statt mit "ll". Alle solche Befehle müssen in deiner Opensim.ini freigeschaltet sein.

    @Eryn: Du brauchst mir die Funktionenliste aus dem Metropolis-Beispiel nicht schicken, sie ist auskommentiert bereits in OpenSim.ini eingefügt.

    @Spike: Leider bleibt die Arbeit, die gelieferte OpenSim.ini an die persönlichen Vorlieben anzupassen, niemand erspart. Ich habe versucht, aus verschiedenen Beispielen das beste zu ziehen, aber allen kann ich es nicht gleichzeitig Recht machen. Übrigens benutze ich nicht mal selber mein eigenes Beispiel, weil meine persönlichen Vorlieben gewiss nicht mehrheitsfähig sind. Ein paar Beiträge weiter vorne habe ich die Unterschiede zur Beispieldatei im Metropolis-Download aufgelistet, mit jeweiliger Begündung warum ich abgewichen bin. Zusätzlich sind der Übersichtlichkeit wegen alle Parameter auskommentiert, die eh auf den Defaultwert eingestellt sind.


    Nachdem die Wünsche in den beiden Foren sehr unterschiedlich sind, und auch Freaky die Defaults im Arriba überarbeiten will, lege ich für die nächste Zeit eine Variante dazu:
    -> OSFunctionThreatLevel = None
    -> alle Einzelfunktionen aktiviert wie im Metropolis-Beispiel
    Alles andere ist genauso, wie in der OpenSim.ini im bin-Verzeichnis der Zip-Datei. Bitte gegebenfalls einfach umbenennen und über die OpenSim.ini drüberkopieren. Falls ihr in eurer OpenSim.ini bereits Anpassungen gemacht habt, geht es aber wahrscheinlich schneller, in der eigenen Datei vor den OSSL Befehlen selber die Semikolons wegzumachen, statt die ganze Datei wieder nach Unterschieden zu durchsuchen.

    Download: OpenSim.ini.ExampleWithMetroOSSL

    Liebe Grüße,
    Mareta
  • Freaky Tech
    Freaky Tech
     Member edited 2:23AM
    ich habe mich mal mit der Bewertung des Threat Levels heute auseinandergesetzt.

    Dabei habe ich den folgenden Stand auch im Git implementiert:

    die folgenden Rechte sind grundsätzlich vorhanden:
    osSetTerrainHeight => Terraforming allowed
    osGetTerrainHeight => always on
    osTerrainFlush => estate manager or estate owner
    osRegionRestart => estate manager or estate owner
    osRegionNotice => estate manager or estate owner
    osSetDynamicTextureURL => always on
    osSetDynamicTextureURLBlend => always on
    osSetDynamicTextureURLBlendFace => always on
    osSetDynamicTextureData => always on
    osSetDynamicTextureDataBlend => always on
    osSetDynamicTextureDataBlendFace => always on
    osConsoleCommand => estate manager or estate owner
    osSetPrimFloatOnWater => always on
    osTeleportOwner => always on
    osGetAgents => always on
    osMovePen => always on
    osDrawLine => always on
    osDrawText => always on
    osDrawEllipse => always on
    osDrawRectangle => always on
    osDrawFilledRectangle => always on
    osDrawFilledPolygon => always on
    osDrawPolygon => always on
    osSetFontSize => always on
    osSetFontName => always on
    osSetPenSize => always on
    osSetPenColor => always on
    osSetPenColour => always on, deprecated
    osSetPenCap => always on
    osDrawImage => always on
    osGetDrawStringSize => always on
    osSetRegionWaterHeight => estate manager or estate owner
    osSetRegionSunSettings => estate manager or estate owner
    osSetEstateSunSettings => estate manager or estate owner
    osGetCurrentSunHour => always on
    osSunGetParam => always on
    osSunSetParam => estate manager or estate owner
    osWindActiveModelPluginName => always on
    osSetWindParam => estate manager or estate owner
    osGetWindParam => always on
    osParcelJoin => estate manager or estate owner
    osParcelSubdivide => estate manager or estate owner
    osParcelSetDetails => parcel owner (except owner, group, claimdate)
    osList2Double => always on
    osSetParcelMediaURL => parcel owner
    osSetParcelSIPAddress => parcel owner
    osParseJSONNew => always on
    osParseJSON => always on
    osMessageObject => always on
    osMakeNotecard => always on
    osGetNotecardLine => always on
    osGetNotecard => always on
    osGetNumberOfNotecardLines => always on
    osAvatarName2Key => always on
    osKey2Name => always on
    osFormatString => always on
    osMatchString => always on
    osReplaceString => always on
    osLoadedCreationDate => always on
    osLoadedCreationTime => always on
    osLoadedCreationID => always on
    osGetLinkPrimitiveParams => always on
    osForceCreateLink => always on
    osForceBreakLink => always on
    osForceBreakAllLinks => always on
    osIsNpc => always on
    osNpcSaveAppearance => npc owner
    osNpcLoadAppearance => npc owner
    osNpcGetOwner => npc owner
    osNpcGetPos => npc owner
    osNpcMoveTo => npc owner
    osNpcMoveToTarget => npc owner
    osNpcGetRot => npc owner
    osNpcSetRot => npc owner
    osNpcStopMoveToTarget => npc owner
    osNpcSay => npc owner
    osNpcShout => npc owner
    osNpcSit => npc owner
    osNpcStand => npc owner
    osNpcRemove => npc owner
    osNpcPlayAnimation => npc owner
    osNpcStopAnimation => npc owner
    osNpcWhisper => npc owner
    osNpcTouch => npc owner
    osOwnerSaveAppearance => always on
    osGetMapTexture => always on
    osGetRegionSize => always on
    osKickAvatar => etstate manager or estate owner
    osGetHealth => always on
    osGetAvatarList => always on
    osUnixTimeToTimestamp => always on
    osGetInventoryDesc => always on
    osInviteToGroup => prim owner has group invite permission
    osEjectFromGroup => prim owner has group eject permission
    osSetTerrainTexture => estate manager or estate owner
    osSetTerrainTextureHeight => estate manager or estate owner
    osIsUUID => always on
    osMin => always on
    osMax => always on
    osGetRezzingObject => always on
    osListenRegex => always on
    osRegexIsMatch => always on


    die folgenden Funktionen müssen explizit über opensim.ini freigegeben werden:
    osSetRot => threat level very high
    osTeleportAgent => Threat Level severe
    osAvatarPlayAnimation => threat level very high
    osAvatarStopAnimation => threat level very high
    osGetAgentIP => threat level high
    osGetScriptEngineName => threat level high
    osGetPhysicsEngineType => threat level high
    osGetSimulatorVersion => threat level high
    osGetGridNick => threat level moderate
    osGetGridName => threat level moderate
    osGetGridLoginURI => threat level moderate
    osGetGridHomeURI => threat level moderate
    osGetGridGatekeeperURI => threat level moderate
    osGetGridCustom => threat level moderate
    osNpcCreate => threat level high
    osAgentSaveAppearance => threat level veryhigh
    osGetRegionMapTexture => threat level high
    osGetRegionStats => threat level moderate
    osGetSimulatorMemory => threat level moderate
    osSetSpeed => threat level moderate
    osCauseDamage => threat level high
    osCauseHealing => threat level high
    osGetPrimitiveParams => threat level high
    osSetPrimitiveParams => threat level high
    osSetProjectionParams => threat level high
    osForceAttachToAvatar => threat level high
    osForceAttachToAvatarFromInventory => threat level high
    osForceAttachToOtherAvatarFromInventory => threat level severe
    osGetNumberOfAttachments => threat level moderate
    osMessageAttachments => threat level moderate
    osSetContentType => threat level high
    osDropAttachment => Threat level moderate
    osForceDropAttachment => threat level high
    osDropAttachmentAt => threat level moderate
    osForceDropAttachmentAt => threat level high


    Eventuell geht aus der unteren Liste noch die ein oder andere in eine Neubewertung.

    Allerdings hat sich bei der Bewertung auch gezeigt, dass die gesamte Bestands-Bewertung einer Überprüfung bedurfte.
  • Primus
    Primus
     Member edited July 2014
    Danke Mareta,

    das waren schon mal entscheidende Hinweise zusammen mit der Erklärung von Eryn komm ich nun schon weiter. Das Problem ist nun das das Script nicht einfach nur im Threat Level low laufen kann sondern es möchte in den Serve level

    wenn ich die Fehlermeldung richtig interpretiere:

    OSSL Runtime Error: osTeleportAgent permission denied. Allowed threat level is Low but function threat level is Severe

    also habe ich also das Argument: Allow_osTeleportOwner = true

    nicht nur ein kommentieren sondern auch in den entsprechenden Level geschoben. ;; *** Threat-Level=Severe
    Leider hat das nicht funktioniert...


    danke für Eure Hilfe

    Primus
  • Mareta Dagostino
    Mareta Dagostino
     Member edited 2:23AM
    Primus wrote:
    Muss ich also das Argument: Allow_osTeleportOwner = true nicht nur ein kommentieren sondern auch in den entsprechenden Level schieben?
    Nein, in der Ini-Datei was in einen anderen Thread-Level zu schieben bringt nichts. Das sind ja nur Kommentare, damit wir Residents nicht jeden Parameter einzeln im Wiki nachschlagen müssen. Freaky hat oben eine Liste mit den derzeitigen Defaults in Arriba gesendet (danke), er überarbeitet die Threadlevel in Arriba gerade.

    zum Einschalten der Teleporter würde ich empfehlen:
    Allow_osTeleportAgent = ESTATE_OWNER, ESTATE_MANAGER

    Dann dürfen das die Scripte der Landbesitzer, aber keine seltsamen Spaßvögel aus dem Hypergrid.
    EDIT: Achte auf das "Agent", Du hast mit Allow_osTeleportOwner den falschen Parameter erwischt. ;)
  • Eryn Galen
    Eryn Galen
     Moderator CreativeGroup edited 2:23AM
    Danke Mareta, genau das ist, was Primus braucht.

    @Spike: Dir und anderen wie dir empfehle ich, aus deiner ini Datei den gesamten OSSL Block in eine separate Textdatei zu verschieben und dann bei einem Update in die neue ini Datei zu kopieren. Wenn Freaky nun den Block einmal überarbeitet, wird dir ein einmaliges Kontrollieren jedoch nicht erspart bleiben. In der Regel ändern sich die OSSL Befehle aber nicht häufig. Die letzte Änderung ist meiner Erinnerung nach Monate her...
  • Spike Sol
    Spike Sol
     Member edited 2:23AM
    Hallo Eryn,

    wäre es nur der ossl-Block, gäbe ich dir recht. Es ist aber vieles andere mehr, die Max Primgröße, Shoutdistanz, Voiceeinstellungen, Clampsize, MapTiles, um nur einiges zu nennen.

    Warum muss ich Zeile für Zeile kontrollieren, wenn es möglicherweise gar keine oder nur eine kosmetische Änderung gegeben hat.

    Ist es da nicht viel einfacher zu sagen: "Schaut mal da und da nach, da muss von "true" auf "false" gestellt werden.

    oder so ähnlich.

    Dann gehe ich rein, stelle das um, und es dauert 1 Minute. Anderenfalls bin ich gut eine halbe Stunde mit der Kontrolle beschäftigt. Und das wäre dann nur die OpenSim.ini.

    Das hab ich die letzten 5 Jahre nicht machen müssen, und da fang ich auch jetzt nicht mit an.

    Warum muss ich jedesmal suchen, wo wer was geändert haben könnte und dann die für mich in Frage kommende Relevanz prüfen?

    Dazu kommt ja auch der Kontrollaufwand, im Falle das sich gar nichts geändert hat! Das weiß ich ja im Vorfeld erstmal gar nicht.

    Warum kann nicht der, der etwas ändert, bescheid sagen, was er geändert hat?

    In Unternehmen nennt man das "Workflow" und ist ziemlich gut angekommen, in der Praxis. Geht das hier nicht?

    Das kommt mir ein bisschen so vor, wie ein Blinder, der versucht einen Zauberwürfel zu lösen, und seinen Nachbarn immer fragt: "Stimmt es so?" "Nein" Stimmt es so?" "Nein" "Stimmt es so?" "Nein"....

    Spike
  • Uwe Furse
    Uwe Furse
     Member edited 2:23AM
    Spike Sol wrote:
    Warum kann nicht der, der etwas ändert, bescheid sagen, was er geändert hat?

    Für so was dient eigentlich das sogenannte Changelog / Änderungsprotokoll


    Moin !
  • Eryn Galen
    Eryn Galen
     Moderator CreativeGroup edited 2:23AM
    Ja, ich weiss, was du meinst, Spike. Ich nutze für so etwas zwei Fenster und lehe mir alte und neue ini nebeneinander. Damit kann ich gleichzeitig meine "Karteileichen" entfernen, sollte es nötig sein.
    Uwe hat Recht, es 'sollte' im Changelog vermerkt werden, wenn die ini geändert wird.
    Solange das nicht der Fall ist, gibt es die elegante Möglichkeit, seine ini zu behalten und in das neue Verzeichnis zu kopieren. Es kann dir aber keiner abnehmen, nachzuschauen, ob es Änderungen gegeben hat.

    Eine weitere, doch nur für einigermassen sichere Leute im Umgang mit Opensim wäre, so es denn genügend Abweichungen vom Standard gibt, eine weitere ini Datei zu kreieren, in die man alle Spezialfälle schreibt, diese in das include Verzeichnis packt und ganz am Schluss der Opensim.ini einen entsprechenden include Befehl schreibt. Da die ini von oben mach unten gelesen wird, sollten die eigenen Spezialangaben die Standardangaben überschreiben.
    Das empfehle ich aber nur Leuten, die sich genug auskennen und bei denen sich die Anlage einer weiteren ini Darei vom Aufwand her lohnt.
    Sonst ist das Durchgehen der ini Datei nämlich zwecks Prüfung gar nicht so schlecht ...
  • Mareta Dagostino
    Mareta Dagostino
     Member edited 2:23AM
    Bei mir sind es auch ziemlich viele Stellen immer, die angepasst werden müssen. Forced Primgrößen, Vivox, Mapkacheln, klassische Primwolken, und und. Keine Beispieldatei passt darauf, ich bin schon froh wenn die Reihenfolge der Blöcke gleich bleibt.

    Zum Vergleich nehme ich immer Notepad++, da kann man schön mit einer eingebauten Funktion zwei Textdateien vergleichen ... zumindest solange die Reihenfolge ungefähr gleich bleibt. Sonst kopiere ich die Blöcke erstmal in die "richtige" Reihenfolge und vergleiche dann nochmal.

    Zum Thema Changelog: Dafür müsste es ja erst mal eine einheitliche Referenzdatei geben, gegen die man die Unterschiede feststellen könnte. Und einen Freiwilligen müsste es geben, der diese Sisyphusarbeit regelmäßig und zuverlässig übernimmt. Da die "optimale OpenSim.ini" immer auch eine persönliche Geschmacksfrage ist, werden verschiedene Beispiele verschiedener Autoren sich unterscheiden. Dann wird auch noch voneinander abgeschrieben, Blöcke werden nicht zwingend überall in der gleichen Reihenfolge übernommen, und es wird vergessen Parameter wieder auszukommentieren, wenn sie auf den Defaultwert zurückgeschaltet werden.
  • Freaky Tech
    Freaky Tech
     Member edited 2:23AM
    Genau auf diese Geschichte mit den völlig sinnfrei verstandenen Rechtesystem des Allow und Creator sowie Threat Level habe ich angefangen aufzuräumen.

    Etliche der OSSL-Funktionen haben ohnehin weitergehende Checks bereits besession. Somit haben diese selbst diesen Rechtesystem bereits nicht vertraut.

    osConsoleCommand z.B. konnte man nicht neben Estate Owner bzw. Estate Manager noch anderen ermöglichen.
    Gleiches gilt für osRegionRestart.

    Die Liste von mir ist die die seit gestern im git enthalten ist. Auf Anmerkung habe ich heute auch die folgende Bewertung bereits seit heute geändert:

    osGetGridNick => always on
    osGetGridName => always on
    osGetGridLoginURI => always on
    osGetGridHomeURI => always on
    osGetGridGatekeeperURI => always on
  • Mareta Dagostino
    Mareta Dagostino
     Member edited July 2014
    Die Arriba ist übrigens eine Developer-Version, also etwa vergleichbar mit der 0.8.1 von OpenSim. (Genau genommen hat Arriba noch gar keine Version.) Das ist in ständigem Fluss! Wer sich mehr Stabilität wünscht, braucht hier ja nicht mitzuspielen und kann die Produktiv-Version von den Admins der Metro nehmen. Die ist gut getestet, läuft stabil und ändert sich nur alle paar Monate mal.
  • Uwe Furse
    Uwe Furse
     Member edited 2:23AM
    Hallo Mareta und Freaky, habe die Version mal ins Grid gekeult, alles I.O.
    Schlanke Bude, schön fluffig, so muss das sein ... Danke !

    Cheers !
  • Uwe Furse
    Uwe Furse
     Member edited 2:23AM
    Zum Thema Usability für den Einsteiger / -> opensim.ini

    Einige kompetente Avatare befassen sich täglich mit der Bude.
    Warum werden da nicht mal Informationen in deutcher Sprache eingepflegt / reingekeult ?
    Deutsche Kommentare / kurze Erklärungen, zu den einzelnen Funtionalitäten.
    Metropolis ist doch primär, ein deutsches Grid, oder ?

    Ansonsten, würde ich die opensim.ini etwas anders strukturieren. Da wird man
    doch als Neu-Einsteiger, von möglichen Optionen, welche man im Grunde gar nicht braucht
    und technisch vieleicht überhaupt nicht versteht, quasi erschlagen.

    #Software Ergonomie #Keule

    Moin !
  • Mareta Dagostino
    Mareta Dagostino
     Member edited 2:23AM
    @Uwe: Durchaus ein Problem ist Zeit! Zweisprachigkeit verdoppelt den Zeitaufwand fast, denn die verschiedenen Dateien müssen ja halbwegs synchron gehalten werden. Mit dem Tutorial auf meiner Webseite, das übrigens auch die OpenSi.ini zweisprachig erklärt, habe ich das leidvoll erfahren.

    OpenSim.Ini: Derzeit muss ich schon einige verschiedene Versionen pflegen:
    - meine eigene für die eigenen Regionen
    - Beispiel für die reguläre 0.8 auf der Tutorialseite
    - (Webseiten mit Erklärungen auf deutsch und englisch zu diesem Beispiel)
    - Beispiel für Arriba
    - drei ingebaute Dateien im Ubuntu-Istaller (Standalone, Metro, OSgrid)
    - (termporäres Beispiel mit OSSL-Funktionen eingeschaltet)
    Zu Vergleichszwecken beobachten muss ich dafür:
    - Beispiel aus dem Metropolis Download
    - Beispiel aus dem OSGrid Download
    - Beispiel aus Dorenas World

    Mit dem hier diskutierten Download habe ich eine Beispieldatei beigelegt, wo so viele Parameter wie sinnvoll auf die Defaultwerte gesetzt und auskommentiert sind. Meine Intention dabei war es, Anfängern das Leben zu erleichtern. Welche Diskussionen es ausgelöst hat, dass ich "einfach mal eigenmächtig" nicht die ganze Tabelle von OSSL Funktionen in diesem Beispiel freigeschaltet hatte, hast Du ja mitbekommen.

    Nehmen wir an, Du möchtest eine OpenSim.ini übersetzen, welches Beispiel nimmst Du denn dann? Aktualisierst Du das dann regelmäßig, auch wenn das nächste OpenSim-Update zeitlich gerade ungünstig ins eigene Leben passt?
  • Sheera Khan
    Sheera Khan
     Moderator edited 2:23AM
    Huhus,

    ja, die Diskussion um Deine "Eigenmächtigkeit" finde ich auch sehr demotivierend, denn Du wolltest den Leuten die Konfiguration ja eigentlich nur erleichtern indem Du sinnvolle Einstellungen als Standardvorgaben vornimmst. Die Entwickler von OpenSim bzw. Arriba machen nunmal Voreinstellungen für die Parameter und die kann man eben ändern, wenn man davon abweichen möchte. Ich finde es z.B. reichlich panne, dass eine neu installierte OpenSim-Region Terraforming für jeden freigibt!

    Bei der gegebenen Struktur der Konfig-Dateien sehe ich auch keine sinnvolle Lösung für das Problem, denn die notwendigen und die möglicherweise erwünschten Einstellungen sind über viele Dateien verstreut und auch innerhalb der verschiedenen Dateien keineswegs gebündelt. Bei der Vielzahl an Einstellungsmöglichkeiten kann man das auch kaum hinbekommen, denn jeder hat andere Anforderungen und Wünsche an die Konfiguration.

    Vielleicht könnte man aber eine neue, zusätzliche Konfigurationsdatei schaffen, die die persönlichen Vorlieben des Serverbetreibers enthält, und die bei der Auswertung der Einstellungen dann die höchste Priorität hat. Dann müsste man nur diese Datei rüberkopieren in die neue Version, und alle Einstellungen auf die man Wert legt, werden dann übernommen ohne in x-anderen Dateien nachschauen zu müssen, welche Standardwerte denn dort drinstehen.

    Eine Alternative wäre vielleicht ein (webbasierter) Konfigurationsgenerator, der einem eine individuelle .ini-Datei generiert. Als Voreinstellungen wählbar wären dann z.B. OpenSim-Standard, Arriba-Standard, Dorenas World, Metro, OSG, oder verschiedene Sicherheitsstufen und eben "benutzerdefiniert", wo derjenige die Einstellungen selber vornehmen kann. Aber das ist ganz schöner Aufwand für wenige Experten, die die Konfiguration auch problemlos selber ändern könnten ^^. Eine solche Sache zu entwickeln würde sich aber nur lohnen, wenn es denn auch einen entsprechenden Bedarf gäbe.

    Ciaoooooo

    Sheera
Sign In or Register to comment.
© Copyright 2018 - Metropolis Metaversum
All times are GMT