Posts by red51

    Für Texturen benutze ich so eine kleine Funktion um die readable zu machen

    Texturen können zwar in der Tat von der GPU zurückgelesen werden, das funktioniert allerdings nur clientseitig, der Server hat diese Möglichkeit leider nicht (da headless) :(


    Eine Place-Funktion wäre schön damit alles genau so funktioniert und natürlich die Maus-Tasten (PlayerMouseButtonEvent)

    Man müsste sich mal überlegen, wie man so ein "Place-Verhalten" sauber in der API anbieten kann :thinking: Dazu machen wir uns mal Gedanken ;)

    Einem PlayerMouseButtonEvent steht aber natürlich nichts im Wege^^


    Das währe erstmal nur für den Client selber(Ohne das zu Teilen als Poster oder so), an der Stelle wo ich das bräuchte, habe ich das Geladene PrefabAsset ... :thinking:
    Ich könnte da eine Temporäres Prefab erstellen, aber da wehren noch keine TextureAsset erst beim player.addGameObject ?

    So ein rein clientseitiges Handling bringt leider ein paar Probleme mit sich... wenn eine Textur nur clientseitig vorhanden ist, man aber trotzdem eine Referenz in der API hat, dann wirft das jede Menge Fragen auf, wenn diese Referenz bspw. einem anderen Spieler zugewiesen wird. Bzw. die API GameObjects sind ja ohnehin nicht spielergebunden, d.h. dieselbe Referenz kann mehreren Spielern zugewiesen sein. Würde man nun nur clientseitig die Textur auslesen und irgendwo zuweisen, würde das bei anderen Spielern nicht wirklich funktionieren... so ein API Verhalten wäre sehr inkonsistent :/


    Einfacher und sinnvoller ist es bei einem Prefab eigentlich, die benötigten Texturen direkt beim Vorbereiten des Plugins (in Unity) mit ins AssetBundle zu packen - dann kann die Textur uneinschränkt geladen und in der API verwendet werden. Die AssetBundles können ja nicht nur Prefabs speichern, sondern auch Texturen, Meshes etc.


    Ja sollte ausreichen :D ich habe ein Würfel Mesh in die Handbekommen und da überkarm mich die Idee, einen Ingame Würfel zu machen :nerd: um gemeinsam zu Würfeln

    Wenn du nur einen Würfel haben möchtest, dann kannst du auch die Model Klasse verwenden - denn das ModelAsset unterstützt zumindest bereits das Laden eines Meshes aus dem Spiel. Ein paar generische Meshes (zB ein "Cube") sind dort auch direkt exposed:



    gerne auch mit Registrieren(wenn es Sinn macht)

    Wie meinst du das genau?


    interessant wehre da auch isPressd() und ein isDrag() oder vieleicht isHold() damit mann den Plazier Timer umsetzen kann

    Eine isPressed() Funktion würde das Event auf jeden Fall bekommen (d.h. das Event würde beim Drücken sowie Loslassen der Maus getriggert werden, ähnlich wie beim PlayerKeyEvent).


    Beim Draggen müssten wir uns mal Gedanken machen... vll wäre hier ein separates Event denkbar (PlayerMouseDragEvent o.ä) :thinking:


    Ich habe das Pfenomän Festgestellt das nur das aller erste disableClientsideKeys Funktioniert, die Liste scheint dann Fest zu sein, ich habe das auch nur mit einem Plugin getestet

    Oh, tatsächlich :wat: Offenbar wird nur der erste Key übernommen... das ist so nicht gewollt, das werden wir mit dem nächsten Update beheben :saint:


    Settings_LogWorldEvents=False :thinking: oder habe ich den erst jetzt wargenommen

    Das ist tatsächlich schon etwas länger drin :D


    Nur für den Reguleren betrieb vieleicht auch ausschaltbar machen, vieleicht noch Settings_LogPlayerEvents, Settings_LogPluginEvents hier wehre auch eine 4. Farbe schön (Rot Fehler, Gelb Warnung, z.b. Türkis Plugin, Weiß Server) oder wenn man später noch die Plugin Ausgaben noch Färben könnte

    Wie meinst du das genau?


    Was das Färben von Plugin-Ausgaben angeht, meinst du die Ausgaben in der Konsole?


    Das sieht mir nach einem Rundungs/Konvertierungs Problem aus, in Java konnte ich das mit dem (int) (long)Long.parseLong lösen.

    Ich weiß leider nicht genau, was du meinst? :monocle:


    Sowas ist gut, beim Thema Texture2D, gibt es da auch etwas zum Mischen oder Überlagern per Maske?

    Der obige Code von Kryssi_79 kopiert die Textur so wie sie ist von der Grafikkarte zurück zur CPU (aber wie gesagt, das funktioniert leider nur clientseitig, d.h. nicht serverseitig, wo die API ausgeführt wird - die API kann an diese Daten also nicht so einfach rankommen). Um eine Textur in ihrem Aussehen zu ändern, muss sie entweder explizit mit einem bestimmten Shader gerendert werden (das stößt in Unitys HDRP aber auf ein paar Probleme und Einschränkungen), oder aber du musst die Pixeldaten manuell überschreiben.


    Wenn Bedarf dazu ist, könnten wir in der API grundsätzlich auch die Möglichkeit bieten, Texturen prozedural zu erstellen - ähnlich wie beim MeshAsset. Dann könntest du prinzipiell jedem Pixel einen eigenen Farbwert zuweisen.

    1. Manche Boote verschwinden und sinken unter die Oberfläche ab. ;(

    Auf dem Bild sieht es eigentlich so aus, als wenn das Boot korrekt auf der Wasseroberfläche schwimmt? :thinking:


    2. Leider ist es auch nicht möglich die Boote zu versetzen. Mit toggleterrain habe ich zwar ein Anfaßsymbol aber das Boot ist nicht bewegbar. Durch Draufschlagen beim Versuch das rote Schlauchboot zu zerstören, ist dieses wieder an die Oberfläche gelangt. Das Holzboot ließ sich mit F7 Objekt zerstören, nicht entfernen, das Draufhauen zum Zerstören unter Wasser hat auch sehr lange gedauert. Extrem lang.

    Boote können leider nicht direkt gelöscht werden (außer durch Kaputthauen). Das F7 Werkzeug betrifft leider nur platzierte Objekte wie Möbel etc., nicht aber Fahrzeuge bzw. Boote...


    Wir könnten den Schaden pro Schlag bei Booten im Creative-Modus ggf. etwas erhöhen.


    3. Im Kreativmodus dauert der Zusammenbau von Booten genauso lange wie im Survivalmodus. Das müsste viel schneller gehen. :verysad:

    Das können wir ändern, allerdings kannst du mit dem spawnvehicle Befehl auch direkt ein Boot spawnen ;)

    Actually you can already override built-in UI elements ;) You can use Internals.overwriteUIStyle() for that. Just create a new Style object, set the properties you want to override, then assign the Style. To get the path to a built-in element, you can use the uidebugger console command - this enables you to hover an element with your cursor and see the path to the element in the top left corner of the screen. Rightclick on an element to copy the path to clipboard. To disable the UI debugger again, hit the x next to the path (of that doesn't work, press ESC, then hit the x).


    Unfortunately you can't get the path to certain elements, but in this case, you could provide the layer name as parameter to the "uidebugger" command - this prints all paths (use page up/down to scroll) ^^


    Changing the background image of the inventory screen would look like this:

    Java
    Style style = new Style();
    style.backgroundImage.set(TextureAsset.loadFromFile(...));
    style.backgroundImageTintColor.set(1f, 1f, 1f, 1f);
    Internals.overwriteUIStyle(player, "inventoryLayer/inventoryContainer", style);


    Example screenshot: https://www.rising-world.net/a…682-example-internal-jpg/

    Gibt es hier noch etwas zu beachten um das Material zu setzen?

    Der Pfad bei setMaterial() ist so leider nicht korrekt, denn die Funktion sieht vor, dass der Pfad zum Child-Objekt angegeben wird. Bei .obj oder .fbx Dateien ist das leider etwas schwer zu bestimmen... in erster Linie ist diese Funktion auf Prefabs ausgelegt, die in Unity erstellt wurden (wo du den Child-Elementen dann direkt einen passenden Namen geben kannst).


    Für Modelle ist später eigentlich dann das Model Objekt die bessere Wahl - dort wirst du auch direkt ein Material zuweisen können ;)


    Könnte diese Funktion auch die Typen mit angeben oder würde sie nur die Prefab's angeben?

    Würde es gleich eine Komplette liste mit Unterordnern sein oder wie ein Verzeichnis?

    Die Typen anzugeben ist leider etwas komplizierter, da dazu sämtliche Assets einmal in den Speicher geladen werden müssen. Allerdings ist anhand des Datennamens der Typ oft schon erahnbar (zB ist ein Prefab i.d.R. als ".prefab" gespeichert, ein Material als ".mat" usw).


    Die Funktion würde den jeweiligen vollen Assetpfad zurückgeben, also der Pfad, mit dem man das Asset aus dem Bundle laden würde.


    Wehre es möglich den Mesh Render und sein Materials auszulesen, speziell die Base Map?

    Nein, derzeit leider nicht, da das fertige Modell erst beim Client existiert und der Server keinen Zugriff darauf hat. Dazu kommt das Problem, dass Meshes oder Texturen nicht zwangsläufig "readable" sind, d.h. die eigentlichen Mesh- oder Texturdaten können nicht immer ausgelesen werden.


    In den Prefab's sollte man kein Rigidbody benutzen, das verzieht die LocalePosition und ist nicht Muliplayer Tauglich, eine Syncrone Physik kommt aber noch? :D
    Oder fehlt nur die getWorldPosition()?

    Sowas gibt es leider nicht out-of-the-box... wenn wir sowas vom Spiel aus anbieten wollen, müssten wir uns einmal überlegen, wie man das am besten in die API integrieren kann :thinking: Was wir sonst einbauen könnten wäre eine "getWorldPosition()" Funktion, die allerdings dann mit einem Callback arbeiten muss (da die Position erst vom Client ausgelesen und dann zum Server geschickt werden muss). Dann könnte man mit der API zumindest seine eigene Synchronisierung umsetzen^^


    Ich hätte noch gerne noch Analog zum PlayerKeyEvent einen PlayerMouseEvent

    Jap, das ist wahrscheinlich gar nicht so verkehrt, also zumindest für Maustasten (dann quasi ein PlayerMouseButtonEvent oder so) ^^


    Hi red51 mMir ist aufgefallen das player.disableClientsideKeys(Key.Escape); nicht klappt, laut dem Log Disable 1 clientside keys [60] from plugin ToolsAPI (1) gibt es auch keine Probleme

    Hmm... das kann ich bei mir leider nicht reproduzieren :thinking: Mit "player.disableClientsideKeys(Key.Escape);" hat die ESC-Taste keine Funktion mehr (weder um Menüs zu schließen, noch um das Ingame-Menü aufzurufen). Was genau funktioniert denn bei dir in dem Fall nicht?

    Das ist merkwürdig, da kann ich leider nichts zu sagen, weil mir keine Änderung einfällt, die dafür ggf. verantwortlich sein könnte :thinking:


    Ein Befehl, um alle Objekte eines bestimmten Typs anzuzeigen wäre aber generell nicht schlecht, ich packe das mal auf unsere Liste ;)

    Meinst du die maximal erlaubte Größe der Blaupausen? Oder die Anzahl an Elementen, die eine Blaupause enthalten darf? Oder meinst du die Anzahl an Blaupausen, die platziert werden dürfen? ^^


    Grundsätzlich wird das in den Permissions über die "blueprints" Einstellungen gesteuert: Mit placelimitsession wird festgelegt, wieviele Blaupausen pro Session platziert werden können, mit maxelements wird die Maximalzahl an Bauteilen festgelegt und mit maxsize die maximale Größe. Um die Werte auf unbegrenzt zu setzen, kannst du -1 eintragen:


    JSON
    "blueprints": {
    placelimitsession: -1,
    maxelements: -1,
    maxsize: -1
    }

    Was kommt den alles zum nächsten Update? Erze? Werkbänke? Wäre gut zu wissen auf was ich mich freuen kann

    Das Hauptaugenmerk beim nächsten Update liegt auf Postern und Schildern, allerdings wird es auch einige neue Objekte geben ;) Ansonsten kann ich leider noch nicht viel weiteres dazu sagen, denn insgesamt hängt es davon ab, wie weit wir kommen und wieviel wir fertig bekommen, ohne, dass das Update unnötige lange auf sich warten lassen muss^^


    Mit dem API Zeug kann ich nichts anfangen, interessiert mich auch nicht.

    Ich will Inhalte von den jeder Spieler was hatt nicht nur gewisse.

    Naja, der Sinn hinter der API ist eher der, dass Leute damit (hoffentlich) interessante Mods bzw. Plugins erstellen, die dann möglichst vielen Leuten zur Verfügung stehen :) Es ist natürlich logisch und nachvollziehbar, dass nicht jeder die API verwenden kann und will, aber wir wollten diese auch möglichst früh bereitstellen, damit Plugin-Entwickler genügend Zeit haben, tolle Plugins zu erstellen^^

    Die Inventory-API ist leider bislang so gut wie gar nicht implementiert, daher fehlen noch einige Funktionen und auch von den bestehenden Methoden funktionieren die meisten nicht... :/ Das werden wir aber auf jeden Fall noch ändern ;)

    Probably it is possible to have some sort of delay for these changes, and after some time values will smoothly become game controlled again if the plugin will not update them again.

    Or it can be possible to get default values calculated by the game and operate them on plugin side

    Getting the default values is a bit tricky, because that's solely calculated client-side atm... so reading these values from the client require a callback, which is a bit cumbersome to use but also has some overhead (especially when reading this frequently)...


    Having some delay for the changes is probably better, but that also requires the plugin to override the values frequently (resulting in some overhead again due to the sync packets that need to be sent to the client)...


    Not sure if it's maybe sufficient to have a way to set a relative value instead. E.g. a color the fog gets multiplied with. So if the player goes into a cave (which makes the fog darker automatically), that would also affect the color set by the plugin. In addition to the "multiply" mode, we could also add an "additive" or "overwrite" mode to add or overwrite the color (maybe with a "weighting" parameter to control how much it should overwrite the game values) :thinking:


    Or alternatively we may use a concept similar to Unitys HDRP volumes: We may add a similar object to the API where you could overwrite fog data, lighting, colors etc, then you could set a weighting for this volume and a priority. Such a volume could be either local (defined by an Area), or global (then the priority and weighting controls how much your settings should overwrite the default values of the game) ^^


    Probably it can be a custom function that will look for LOD component in GameObject and if it found one will change it or put into internal list to control later (for example when setting are changed). If the function will be not called the LOD will stay same as in prefab, and when called it will be synchronized with the game

    Oh, basically you could add an LOD component already, it should at least work with the LOD bias graphics setting. But unlike vanilla elements, it does not get culled if out of view bounds...


    Maybe we could add a setting where you could determine if the game object should be always visible or bound to the view distance (or detail view distance) ;)


    That's good, so we will be able to override built-in definitions, but what about completely custom? Like new types of wether or objects?

    You will also be able to create new definitions that way :) However, for custom items, there is some additional information required (to handle animations etc properly).


    Looks like events will be more compatible with each other, while custom module should be a bit faster. If the system will have events then different plugins can apply their own changes to world separately: for example one plugin can alter cave generation and another one can change ocean. If this will be done in modules they should be somehow connected with each other and "know" about changes done by other plugins, otherwise there will be only one plugin that can change world in the pack

    Custom world gen modules would be indeed faster, but may be also a bit trickier to use (especially if there are multiple plugins which register their world gen modules). In case of events, that wouldn't be a big issue at all, because if multiple plugins listen for that event, they will automatically see changes done by other plugins (depending on the execution order of plugins).


    We have to think about that. Actually we have already done some preparations for a "GenerateWorldPartEvent" some time ago (basically it's in the API, but it's not exposed and not fully functional yet). It's called everytime a new "world part" (which is basically a world section with a size of 512x512 blocks, i.e. 16x16 chunks) is generated. A plugin could use this event to load custom heightmaps, for example, or overwrite terrain materials or plants etc ^^

    In der CSV Datei sollten Informationen enthalten sein die für Konsolenbefehle (item, object ...) wichtig sind,

    für die API / Modder wichtig

    und nützlich für die Wiki z.B. Name oder Beschreibung (falls im Spiel vorhanden)

    Hmm... ich bin mir ehrlich gesagt noch nicht ganz sicher, welche Informationen die CSV Datei genau enthalten soll^^ Kannst du mir die Daten evtl. auflisten oder mir einen Beispieleintrag zeigen? ^^

    Es geht hauptsächlich um die Wandfackeln, die jetzt möglicherweise erst beim Annhähern sichtbarer werden?

    Wie gesagt, daran hat sich nichts geändert. Es geht bei der Änderung nicht um das eigentliche Licht, was die Fackeln von sich geben, sondern nur um die visuelle Flamme ;)

    Guter Hinweis, das werden wir mit dem nächsten Update ändern ;) Dann wird - sobald das Event von einem Plugin verwendet wird - die Meldung nicht mehr ausgegeben. Zusätzlich wird das InputEvent dann auch Cancellable, d.h. wenn man das Event optional abbricht, dann werden auch die eingebauten Commands nicht mehr abgearbeitet (falls man zB lieber sein eigenes Handling möchte)^^

    1. Ability to control some post effects for players - fog color, fog intensity and ambient light. This will make possible custom underground and underwater rendering, probably some custom effects on specific biomes and so on.

    It's our intention to expose that to the API, but we're still not 100% sure how the game should handle that specifically (because these values may change depending on the player position and the weather).


    Maybe it's sufficient if the API just gets an option to override that? I.e. setting the fog intensity through the API prevents the game from changing that value anymore...

    Probably it's indeed necessary to have this setting per player (instead of a global World method) ^^


    2. Ability to attach same LOD parameters to assets as the game uses with same distances. This should make plugin graphics configurable together with game graphics and will make LOD configuration easier.

    Not sure how such an API should look like... maybe the game could cull these elements automatically (depending on the view distance settings), but the API may get a method to override the view distance (maybe set a relative factor)?


    3. Custom definitions. I think that it was planned earlier (and probably for final API version), so I just included it here. This will be a really powerful feature that will finally make custom things possible.

    Yes, that's definitely planned :) The idea is that you could change any field in a definition class, then call "synchronize()" to sync the changes with the server and the clients. This may look like this:


    Java: Note: This doesn't work yet!
    //Make a workbench weak
    Objects.ObjectDefinition def = Definitions.getObjectDefinition("workbench");
    def.strength = 1;
    def.synchronize();


    Basically any field from our internal definitions are exposed to the API, so you could change anything that way.


    But this isn't implemented yet. The methods are already in place, but they don't work atm.. but it's on our to-do list ;)


    4. Different world generation events to change and modify ho chunks are generated and populated

    This is also planned ;) We're still not 100% sure if it's better to have events (when a chunk or world part is generated) or a way to implement and register a custom world generator module (where you could just override methods like "getTerrain()" or "getChunk()") :thinking:

    1. wäre es möglich mit der neuen API für Unity Version

    eine Möglichkeit zu bekommen eigene Konsolenbefehle einzubauen ?

    Ich meine die Konsole die ich mit ^ aufmache und nicht über Chat und PlayerCommandEvent

    Schwieriges Thema :D Derzeit ist es ja so, dass es noch eine Trennung zwischen Spielbefehlen (Konsole) und API Befehlen (Chat) gibt. Aber grundsätzlich wäre es eine Überlegung, über die Konsole auch PlayerCommandEvents zu bekommen. Es müsste dann aber vmtl. zunächst auf den Spieler ein "registerCommand()" o.ä. aufgerufen werden, damit die Konsole diesen Befehl auch kennt und auch optional die Vorschläge (die bei der Eingabe eines Commands auftauchen) anzeigen kann etc.


    Es würde dann wohl auch das PlayerCommandEvent getriggert (das bräuchte noch eine Methode, um herauszufinden, ob der Command aus der Konsole oder dem Chat stammt) :thinking:


    2. kannst Du bitte mehr Befehle wie printkeybindings einbauen ?

    Welchen Befehl bräuchtest du denn konkret? ^^

    dann hast Du wahrscheinlich eine bessere Grafikkarte als ich :D ... ich denke Deine Vermutung wird richtig sein und bei mir deswegen mal diese oder jene Kerze ausgeht.

    Naja, das Spiel geht dann davon aus, dass es sich um eine schwächere Grafikkarte handelt, wenn sie weniger als 2.5 GB VRAM hat oder wenn es sich um einen integrierten Intel HD Grafikadapter handelt ^^


    Wenn ich mich zu Beispiel entscheiden würde, die Sichtweite etwas runter zu setzen, oder Wolken abzuschalten, dann könnt ich doch vermutlich im Gegenzug den Partikeleffekt rauf setzen!? Ich nehme mal an, das passiert ohne die Einstellungsmöglichkeit derzeit nicht automatisch? :thinking: Dann wäre diese Option natürlich super :)

    Ja, auf jeden Fall, daher ist so eine Option natürlich idealerweise in den Einstellungen verfügbar :)


    Jetzt weiß ich wenigstens warum es bei mir in der Stadt dunkler geworden is, dachte an einen Fehler meinerseits gedacht und fragte mich natürlich, ob ich wirklich überall Lampen vergessen habe. :( Ich habe im Mittelalter Wandfackeln gesetzt und es war schlagartig überall viel dunkler.

    Oh, eigentlich sollte das auf das eigentliche Licht keinen Einfluss haben, das wird separat gehandhabt (abhängig von der Licht-Einstellung in den Grafiksettings - das war aber schon vor dem Update so). Es geht also nur um den Partikeleffekt, also die Flamme selbst (die zwar kein Licht von sich gibt, aber natürlich selbst trotzdem im dunkeln sichtbar ist) ;)