Posts by red51

    No, sorry for the confusion: I was actually referring to a speed parameter for the moveTo() method. This is what the method header will look like: public void moveTo(Vector3f position, float speed, boolean adaptToSurface)


    But the speed parameter is not related to the max speed of the vehicle itself. For instance, if you set a speed parameter of "10", it will work the same for all vehicles (it doesn't matter if you call this for a rowboat or a rib, they will simply move with a speed of 10) :)


    And another question MoveTo will have only (x,z) coordinates or (x,y,z)? I suppose is first case and for y adapt by water/terrain?

    You can provide an x, y and z coordinate. If the adaptToSurface parameter is true, the game will try to adapt the vehicle to the nearest surface. It wouldn't be sufficient to only have an x,z coordinate, because it's still possible to have water/terrain at different elevations (e.g the ocean, water in caves, maybe someone builds a floating island with a lake on it etc) ^^


    In your case, if you only want to enable traveling over the ocean, it would be fine to just provide 90 as y coordinate (no need to take waves into account etc).

    Besorgen muss man die Materialien ja trotzdem, und wenn die Materialien hier nur für Blaupausen und nicht fürs normale crafting verwendet werden können wäre es jetzt auch nicht sonderlich OP. So Eine Kiste könnte ja auch so groß wie ein Schiffscontainer sein :D mit mehr slots als aktuelle kisten + stacks bis 32K.

    Aber die Kiste selber ist ja OP, wenn sie quasi unendlich Stauraum bietet. Warum sollte dann noch jemand eine normale Kiste craften bzw. ein Lager mit mehreren Kisten bauen, wenn eine einzelne Kiste ohnehin unendlich Stauraum bietet?


    Vielleicht kann man aber auch sowas wie "Materialpakete" einführen. Wenn ich ein MAterialpaket für Steine crafte, ist das 1 item und über die haltbarkeit wird die anzahl der steine bzw. dessen verbrauch geregelt. diese steine können dann nur für Bauprojekte verwendet werden und nicht mehr für normales bauen. So könnte es ein rezept geben das 10 20 50 oder 100k steine zu einem Steine-Baumaterial-Paket zusammenfasst. Pakete mit voller haltbarkeit könnten ja theoretisch auch wieder stacken. Nur so ein Gedanke.

    Das ist eigentlich gar keine schlechte Idee. Ich kann das leider nicht kurzfristig einbauen, aber ich behalte es auf jeden Fall mal im Hinterkopf ;)


    Dennoch hab ich meine Zweifel was die Verfügbarkeit von Material angeht. Ich spreche da aus Erfahrung und bin da noch nicht mal derjenige aus der Community mit den größten Blaupausen. Aber das kann SEHR schnell den Platz des Inventars sprengen

    Die Rohstoffanforderung ist wie gesagt eigentlich wirklich nur dann sinnvoll, wenn naheliegende Kisten zusätzlich herangezogen werden. Denn ja, viele Blaupausen benötigen so viel Material, dass es bei weitem nicht ins Inventar passt. Wenn Kisten jedoch herangezogen werden ist das Problem durchaus lösbar (außer wir reden wirklich von Mega-Blaupausen, die viele Millionen Elemente enthalten - hier sehe ich aber auch keine andere richtige Lösung). Wenn das Einbeziehen der Kisten noch rechtzeitig zum Update reinkommt würde ich die Rohstoffkosten wohl standardmäßig aktivieren, ansonsten nicht.


    Und da es ja kein "Rezept" gibt, ist auch die Übersichtlichkeit (was brauch ich eigentlich) nicht gegeben. Man müsste immer wieder die BP am Tisch aufrufen, falls das da überhaupt gelistet wird?

    Da habe ich zwischenzeitlich eine Übersicht zum HUD hinzugefügt, wo die benötigten Rohstoffe aufgelistet werden (und wieviele man bereits hat), man muss also nicht immer zum BP-Tisch laufen (wo die Rohstoffe aber auch aufgelistet sind) ^^


    Ich fände es sinnvoller die Kosten für die Blaupause selbst nach oben zu setzen, als grundsätzliche Hürde. Und dann automatisch diese Baustelle erzeugen zu lassen, bei der man dann beim draufgucken sieht was noch fehtl. Aber auch da nicht 1:1 das Material, sondern z.B. 50% des Steins der verbaut wurde, 20% des Eisens, usw. Objekte muss man fertig gecraftet hinzufügen.

    Ist wahrscheinlich eine Glaubensfrage, was besser ist :saint: Wenn die Kosten stärker in die Blaupause selbst fließen und dafür die Rohstoffkosten vergünstigt werden kann das auch wieder Fragen aufwerfen... welche Rohstoffe sind schwieriger zu beschaffen? Vmtl. dann für die Blaupause selbst, aber dann ist man als Spieler evtl. auch versucht, möglichst nur noch große Blaupausen zu platzieren, um die "teure" Blaupause selbst nicht zu vergeuden. Kleinere Blaupausen aus der Community (zB für kleine Dekogegenstände) werden dann natürlich auch unverhältnismäßig teuer (durch den Grundpreis der Blaupause) und dadurch ggf. uninteressant, während Mega-Blaupausen durch die Rohstoffersparnis besonders vergünstigt werden :thinking:


    eben drum - was verlangt die Baustelle wenn ich ein Haus mit Terrain geplaupaust habe und die Berechtigung aber das Setzen von Terrain verbietet - kein Terrain, weil es nicht gesetzt wird?

    Bislang wird die Permission tatsächlich berücksichtigt, d.h. die Terrainkosten werden dann nicht berechnet, wenn Terrain nicht erlaubt ist.

    Schwieriger wird es nur bei Area-Permissions. Angenommen eine Blaupause überlappt eine Area: Lt. Standardpermission darf zB Terrain platziert werden, in der Area jedoch nicht, dann würde das Spiel trotzdem die vollen Terrainkosten abrechnen, obwohl das Terrain in der Area nicht platziert wurde. Das ist leider ein Schwachpunkt, der wahrscheinlich erst dann wirklich behoben werden kann, wenn die o.g. Geister-Blaupausen bzw. Baustellen eingebaut sind.


    Pflanzen die man nicht ernten kann, sollten nicht als Material "verlangt" werden, sondern enthalten sein - ein Blumenkasten ohne Blumen geht ja gar nicht.

    D.h. du meinst sie sollen dann durchaus kostenlos platzierbar sein?


    Objekte die man aufheben, aber nicht craften kann können verschwinden - weil man sie wiederfinden und platzieren kann.

    Ich könnte mir vorstellen, dass nicht jeder damit happy ist, wenn plötzlich der Content einer Blaupause fehlt. Vor allem wenn eine Blaupause aus dem Forum heruntergeladen wurde =O


    Da wäre dann wahrscheinlich fairer, wenn das Spiel bei den Resourcen hier nicht die Grundrohstoffe des Objektes erfordert, sondern das Objekt selber. Das wäre vll auch eine allgemeine Frage, was besser ist (bei Blöcken bin ich nicht so überzeugt davon, wie oben schonmal geschrieben, bei Objekten hingegen ist das vmtl. halb so wild, da es hier nicht so viele Varianten gibt) :thinking:


    Und was die POI Bauten betrifft die man nicht aufheben kann bin ich unschlüssig - einerseits hab ich auch gerne einen Hochsitz auf meinem Gelände - andererseits werden POIs abgewertet wenn man sie in zig Spielerbereichen wiederfinden kann. Vielleicht kann man mal dafür sorgen, dass man sowas auch "aufheben" kann. :thinking:

    Das mit dem "Abwerten" ist tatsächlich ein valider Punkt... hier wäre ggf. eine Einstellung sinnvoll.


    Ich habe eben gesehen, dass am Blaupausentisch das Wörtchen "Rohstoffe" bereits enthalten ist ^^ War das schon immer so :thinking:

    Ja, ich habe vor einiger Zeit mal angefangen, Rohstoffe einzubauen, aber die Berechnung der Rohstoffe hat sich doch schwieriger gestaltet als erwartet, daher ist das erstmal auf Eis geblieben (und die Liste daher leer) :D


    Was wäre, wenn der Blaupausentisch zu einer Werkbank mit Inventar werden würde. So dass man die erforderlichen Rohstoffe dort hinterlegen kann.

    Das war ursprünglich sogar die Überlegung, es hat aber ein gewaltiges Frustrationspotenzial: Wenn der Wert in der Blaupause selbst steckt, d.h. ein Spieler hat vll Hunderttausende oder Millionen Rohstoffe herangeschafft, um die Blaupause zu craften, wirft sie dann aber versehentlich aus der Hand und findet sie nicht wieder (oder stirbt und findet die Leiche nicht mehr), ist der Ragequit eigentlich vorprogrammiert ^^

    After taking a closer look at this, I think I'd prefer a new moveTo()-Method, considering that the "Vehicle" class will represent more than just boats in the future. The moveTo()-Method will then get a universal "adaptToSurface" parameter, which not only adapts the boat/vehicle to water/waves, but also to terrain (in case you're moving a boat/vehicle on land). Unlike setPosition(), it will maintain a constant speed (which can be changed via parameter). It will also update the vehicle pitch and roll (but not the yaw) automatically.


    This should make it possible to create quite realistic boat rides :)

    This sounds very interesting! :) :thumbup:


    1. **Rotation convention.** Are the quaternions stored exactly as Unity consumes them? Empirically, negating X and Y of the quaternion (equivalent to conjugating through a Z mirror) reproduces the game for rotated elements. Is that the intended interpretation, or is there an engine-side step we're missing?

    Yes, the game just stores the raw x, y, z and w components of the quaternion (exactly as Unity uses it). It's the world rotation of the element.


    2. **Negative sizes.** Some elements carry negative size components (e.g. cones with size (-0.05, 0.15, -0.05)). We take negative scale to mean "mirror the mesh" — is that correct?

    Yes, a negative size mirrors the mesh along the particular local axis.


    3. **Surface editing.** For cylinders we know surface_scale.x is the top/bottom radius ratio. We also see surface scale on plain blocks: a 0.5×1.5×0.5 block with surface_scale (0.5, 1, 0.5) whose top face must shrink to 0.25×0.25 to meet a pyramid on top — the numbers match exactly. How do surface offset and surface scale combine for arbitrary construction types, and which face(s) do they act on?

    The information about which vertices are moved isn't stored in the blueprint or code, instead it's stored in the base mesh of the construction element (in the UV2 channel). The surface offset is applied like this:

    vertex = (vertex * elementScale + surfaceOffset * sign(elementSize)) * surfaceScale


    The surfaceScale is also applied to the elementScale after performing the calculation above.


    4. **Arcs and arc corners.** Arcs (types 15/16/17 in definitions.db) come out flipped in every blueprint we test. Their meshes have an origin offset from the bounding-box center (e.g. 0.318 in Z for the arc), and definitions.db lists pivotaxisflip = Z with pivotincluderotation = 1 for them. Does the game anchor these constructions at the mesh's original pivot rather than the bounding-box center? And does pivotaxisflip imply a mirror at render time?

    Constructions are anchored at the mesh original pivot, not the bounding-box center.


    5. **Rotation snapping.** Some elements store quaternions a few degrees off axis-aligned, yet they appear perfectly axis-aligned in game. Does the game snap construction rotations to 90° multiples?

    No, the game does not perform any rotation snapping, neither when placing nor rendering the elements. The game uses the raw quaternion without any modifications.


    6. **Format documentation.** Is there any official documentation of the .blueprint format you would be willing to share? The project is personal and non-commercial; the viewer stays strictly offline and we don't redistribute any game assets.

    I've posted the blueprint format a long time ago, it's unfortunately a bit difficult to find: RE: Blueprints Format (Unity)


    But the next update will slightly change the format. If I remember, I'll update the post (otherwise, please remind me) ^^

    Zurzeit ist es ja so, dass ich eine leere Blaupause verbrauche, wenn ich etwas im Spiel Gebautes blaupause - Die verschwindet dann ins Nichts, bzw. in den Blaupausentisch.

    Könnte sie nicht auch wieder im Inventar erscheinen mit dem Inhalt den ich gespeichert habe? Das würde ja vermeiden, dass ich 2 leere Blaupausen brauche, wenn ich in

    dem jeweiligen Spiel etwas speicher und es dann noch mal direkt setzen möchte (im survival) :thinking:

    D.h. du möchtest dass beim Erstellen einer Blaupause du direkt eine "gecraftete" Blaupause (wie du sie am Blaupausentisch erhalten würdest) ins Inventar bekommst?


    Aber auch im Kreativmodus geh ich meist in den Blaupausen Ordner um dort das zuvor gespeicherte wieder abzuholen - und sobald ich etwas gespeichert habe, dauert der Zugriff auf die BP wieder recht lange (als ob das Spiel alle BP noch mal neu laden muss) ... daher bin ich mir nicht sicher, ob die gespeicherte BP direkt im Inventar erscheinen kann.

    Das wiederholte Öffnen selber sollte eigentlich relativ fix gehen, nur beim ersten Laden oder wenn es Änderungen am Ordner gab (zB durch eine neu erstellte Blaupause) werden die Blaupausen neu eingelesen... am längsten dauert dabei eigentlich gar nicht das Einlesen (das ist < 10% der Zeit), sondern benötigt UI Toolkit zum erstmaligen Rendern der Liste. Hier ist theoretisch aber noch Optimierungspotenzial ^^


    vielleicht braucht es sowas wie Materialcontainer die wie kisten sind aber nur Materialien aufnehmen können, dafür ohne Stack Grenzen. Wenn man wieder was raus nimmt bekommt man die übliche Stack Größe zurück.

    Wäre so eine Materialkiste nicht OP, wenn sie quasi unbegrenzt Materialien aufnimmt? Das Problem ist leider nur, dass unendliche Stack-Größen bisher nicht vorgesehen sind :/ Bisher wird der Stack pro Item gespeichert und auch pro Item definiert... theoretisch könnte eine Kiste das überschreiben, aber der Stack wird als vorzeichenbehafteter Short gespeichert (max Stack wäre also ~32K)


    Auch eine native Währung geben :thinking:

    Die wird es auf jeden Fall noch geben :D


    Das mit der Baustelle finde ich sehr gut. Du könntest eine minimal Anforderung einbauen, damit die überhaupt entsteht. Und wenn x echtzeit Tage nix hinzugefügt wurde, verfällt die Baustelle. Würde das zumüllen verhindern.

    Ja, das wäre absolut sinnvoll, ich packe das mal auf die Liste :)


    Ist in der Blaupause z. B. Eine Tür enthalten, braucht man keine Tür im Inventar, sondern Holz und Eisenbarren?

    Genau.


    Wie ist das mit terrain? Wenn ich einen kleinen Hügel blaupause, dann muss ich dad äquivalent dazu in Erde und Steinen haben?

    Ja, das ist tatsächlich so vorgesehen (da man das Terrain ja sonst auch wieder abbauen kann und sonst unendlich Rohstoffe erhalten kann) :saint:


    Was ist mit dem Objekten die Wir bisher nur finden aber nicht craften können, aus poi z. B.


    Und Blumen?


    Oder so wasser in der bp enthalten ist?

    Bislang sind Objekte, die nicht gecrafted werden können, kostenlos... idealerweise müsste für jedes Objekt ein Crafting-Rezept hinterlegt werden, vll bekomme ich das noch fürs Update hin (oder das wandert in einen Hotfix o.ä).


    Bei Bäumen werden Baumstammstücke + Setzlinge fällig. Bei Pflanzen jeweils ihr Setzling, falls es für eine Pflanze nichts gibt, sind sie derzeit auch kostenlos (aber auch das müsste eigentlich geändert werden).


    Wasser wird auch einfach kostenlos platziert. Ggf. wäre es hier sinnvoller, dass man Eimer mit Wasser im Inventar haben muss :thinking:


    Terrain sollte meiner Meinung nach außen vor bleiben. Denn selbst wenn eine Blaupause Terrain enthält ist nicht gesagt, dass man dieses auch mit der BP platzieren darf (im Multiplayer).

    Da gibts allgemein eine placeterrain Permission für (unter "blueprints") :)


    Objekte die man nur finden kann würde ich einfach "verschwinden" lassen; dann muss man sie halt neu finden und Platzieren.

    Das wäre auch eine Überlegung... ich muss mal schauen, was da ab besten ist (oder ob es ggf. eine Option dafür geben könnte) ^^

    Diese Vorschau-Lösung wirds aber leider noch nicht ins nächste Update schaffen, da das einen etwas größeren Umbau erfordert... die Vorschau selber (oder alternativ die Baustelle) müsste in der Welt gespeichert werden, da sie ja vmtl. auch über Sessions hinweg verfügbar sein müsste (gerade große Blaupausen erfordern ja viele Rohstoffe)... müsste eigentlich idealerweise auch im MP für andere Spieler angezeigt werden (damit diese zB mitwirken können, oder auch um einfach nur zu wissen, dass da bereits ne Blaupause hinkommt). Hier müsste man aber auch sicherstellen, dass ein Spieler nicht einfach zum Trollen viele "Geister-Blaupausen" platziert (ist ja bis zu dem Punkt quasi kostenlos) :thinking:


    Mit dem nächsten Update werden aber erstmal nur (optional) beim Platzieren die Rohstoffe fällig, d.h. ohne die nötigen Rohstoffe wird man die Blaupause nicht platzieren können. Ich versuche zum Update noch einzubauen, dass Kisten in der Umgebung herangezogen werden können (im MP würden nur eigene Kisten berücksichtigt werden), ggf. mit Visualisierung, dann könnte die Rohstoffbedingung evtl. auch standardmäßig aktiviert werden (nur im Survival natürlich, und auch ausschaltbar). Man müsste dann wie gesagt zum Platzieren die Rohstoffe entweder im Inventar haben oder in eine nahegelegene Kiste packen. Es würde auch noch eine Anzeige beim Platzieren dazukommen, welche Rohstoffe benötigt werden und wieviele man schon hat.


    Was die Blaupause selbst angeht, evtl. wäre es auch sinnvoll, dass sie Papier benötigt. Eigentlich könnte man sie (mit dem Rohstoffverbrauch) dann auch durchaus wiederverwendbar machen ^^

    Tatsächlich gibt es mit dem nächsten Update eine optionale, rudimentäre Rohstoffanforderung für Blaupausen :D Vorgesehen ist, dass im Blaupausen-Menü die benötigten Rohstoffe immer angezeigt werden, aber standardmäßig werden diese Rohstoffe momentan nicht benötigt bzw. verbraucht. Man kann das Feature zwar optional aktivieren (ggf. nur in der config, bin da noch unsicher), birgt bei gewaltigen Blaupausen aber wirklich krasse Anforderungen (schnell mal 100.000 Stein oder mehr). Was noch nicht drin ist ist eine Verwendung der Rohstoffe aus nahgelegenen Kisten, das müsste eigentlich zwingend noch eingebaut werden :thinking: Ich habe aber auch eine User-Blaupause, die über 30 Mio Stein benötigen würde... das werden schon sehr sehr viele Kisten :dizzy:


    Derzeit würde die Bedingung, dass alles im Inventar sein muss, den Survival bei eingeschalteter Option auf kleinere Blaupausen beschränken (Mega-Blaupausen wären dann eher Creative-Content). Wenn die Verwendung naheliegender Kisten es evtl. noch reinschafft würde das deutlich entschärft... ist dann aber nicht 100% optimal: Der Spieler müsste die Kiste(n) vorübergehend dort platzieren, wo die Blaupause ungefähr auch hinsoll.


    Die vmtl. bessere Lösung für den Survival-Modus wird sein, dass Blaupausen künftig weiterhin kostenlos sind (bis auf Papier), die Blaupause aber beim Platzieren (falls der Spieler nicht genug Rohstoffe in der Tasche hat) erstmal nur eine Baustelle erzeugt, zu welcher die fehlenden Rohstoffe dann Stück für Stück herangeschafft werden können.


    Aktuell ist es übrigens so, dass das Spiel die Rohstoffe wirklich auf die Grundrohstoffe aufbröselt. Ich habe es erstmal anders probiert (dass der Spieler also die tatsächlichen Blöcke haben muss), aber das war besonders bei großen Blaupausen echt schwierig (tausende verschiedene Blockformen und Texturen)...


    Den Blaupausentisch würde ich nur ungerne an die moderne Werkbank koppeln oder nur als Loot auffindbar/freischaltbar haben. Das würde manche Spieler von Blaupausen ausschließen (zB die Spieler, die eher aufs Mittelalter fokussiert sind, zumal im Multiplayer bestimmte Objekte auch deaktiviert werden können). Bei Loot gibts auch die Spieler, die wirklich Pech haben und nie eine Blaupause finden. Für manche Spieler sind Blaupausen ja kein reines "nice-to-have" Feature, sondern wirklich wichtig (und manchmal auch aus Datensicherungsgründen gar nicht so verkehrt) ^^


    Was hingegen höhere Kosten für die Blaupause selbst angeht: Das stand ja schonmal im Raum und ist durchaus eine schnelle, einfache Lösung, fühlt sich aber auch etwas falsch an (warum brauche ich Gold/Wolfram/Alu usw. um ein Stück Papier herzustellen?). Ich hätte das dann ggf. schöner gefunden, wenn das an Händler gekoppelt wird (sodass man Blaupausen dort kaufen muss - der Händler könnte dann entsprechend viel dafür verlangen). Händler habens aber leider auch noch nicht reingeschafft und momentan sieht es so aus, als würde das Rohstoff-Problem früher gelöst werden als dass Händler dazukommen :saint:

    Backups are only determined by the world name, so the ingame "Restore Backup" option will only list worlds from the "/Backups/Worlds/" folder with the same name. Unfortunately there is currently no ingame option for restoring a world with a different name.


    However, alternatively you can also just copy the World fom the backup folder into your regular Worlds folder (in your case that would be C:\Program Files (x86)\Steam\steamapps\common\RisingWorld\Worlds\). Make sure to rename the world and remove everything that's not part of the world name, i.e if the backup folder is called New World-1776691575-0.9.1_15, rename it to New World after copying it to the Worlds folder ;)

    Hey, that's a good point! Currently the waves are not taken into account, so setPosition() would still work, but it would cause the boat to temporarily hover above water or submerge. The API will provide a method to calculate the wave height at a specific location, but this will only help if you call vehicle.setPosition() very often (providing the final water position which also takes the waves into account)...


    We could change the setPosition() method to take waves into account automatically, but I'm not sure if that would be a good idea... right now this method allows you to set an arbitrary position (you can even set a position on land or in the air). Maybe a new "setPositionOnWater()" method would be better in this case? :thinking:


    Or maybe we change setPosition() to teleport a vehicle instantly, and add a new "moveTo()" method (which optionally takes waves into account)? This could be a cleaner solution... IMO the current behaviour isn't very intuitive anyway (I'd expect a vehicle to move to a new position instantly when calling setPosition())... the "moveTo" method could then get a few parameters, e.g. to determine if the boat should automatically adapt to waves or if a player should still be able to take control over the boat. Maybe that would be the best solution? ^^

    Sorry for my late response! But thanks a lot for the log :) Unfortunately I couldn't reproduce this issue on a Steam Deck, so it's apparently not related to SteamOS itself, instead it might be an issue between the graphics card and graphics driver :thinking: I'd recommend to check if a SteamOS update is available (which would update Mesa/RADV).


    But there are also a few other things you could try: Currently the Windows version is running through Proton, you could try to select a different Proton version (e.g "Proton Experimental" and see if that helps). If that doesn't work, you could switch to the native Linux version of the game (select the "Steam Linux Runtime" or disable the Steam Play Compatibility checkbox in the game properties in Steam). Does the issue still occur?


    If you want to stay on Proton, you could alternatively force Vulkan by adding the -force-vulkan launch option to the game. Proton will natively use Vulkan (avoiding the DXVK layer), so that might also fix the issue. But unfortunately the Proton/Windows version runs a bit worse under Vulkan...


    As a last resort, you can forcefully disable GPU skinning (which might be responsible for this issue). Unfortunately you can only do that manually: To do that, go to the game directory into the "Data" subfolder and open the "boot.config" with a text editor. Set "gpu-skinning" to 0, then save the file. Does it work then?


    If you still run into this issue after switching to Vulkan or the native Linux build (or after changing the gpu-skinning option), it would be helpful if you could send another report :)

    Männliche Frisuren sind derzeit die IDs 50 bis einschl. 68, weibliche Frisuren sind IDs 100 bis einschl. 119.

    Ich versuche aber idealerweise auch die SkinDefinitions zu exposen, da das direkte Arbeiten mit IDs immer heikel ist (falls die sich später mal ändern sollten o.ä) ^^

    Die Skin-Methoden sind leider nicht sonderlich intuitiv :/ Intern wird eine "SkinDefinition" gesetzt (leider noch nicht in der API exposed), diese jedoch repräsentieren generisch ein Skin-Merkmal (Haarschnitt, Bart, Tattoo usw). D.h. die IDs für Frisuren beginnen nicht bei 1, sondern dort, wo sie in der "skins" Tabelle (in der definitions.db) definiert sind, d.h. männliche Frisuren beginnen bei ID 50, weibliche Frisuren bei ID 100.


    Erschwerend kommt hinzu, dass die Methode eine ungültige ID einfach verschluckt. Wäre schöner, wenn sie wenigstens ein Bool zurückgeben würde (das kann ich auf jeden Fall ins nächste Update packen) :thinking:


    Vll macht es Sinn, dass diese Methode die ID je nach Geschlecht ummappt, sodass die ID immer bei 1 beginnt (und bei männlichen Charakteren den ersten männlichen Haarschnitt und bei weiblichen Charakteren entsprechend den ersten weiblichen Haarschnitt gibt)? Wäre allerdings eine Breaking-Change (fraglich jedoch, wieviele Plugins davon bisher wirklich Gebrauch machen)


    Es gab doch für die Npcs mal einen Befehl "edit npc invicible oder invulnerable" . (Java-Version). red51 Funktioniert das nicht mehr?

    Das kann entweder über das editnpc Fenster gesetzt werden (eine Checkbox unten) oder alternativ wäre der Befehl edit attribute invincible. Ist allerdings für die Plugin API so nicht zugänglich, da gibt es eigene Methoden, um Npcs unverwundbar zu machen ^^

    Achso, ja also die Hashes kann ich auf jeden Fall auch noch reinpacken (neben CreatorUID und -Name). Würde dann vmtl. FNV nehmen. Wäre allerdings nicht kollisionsfrei, d.h. es besteht eine (extrem) geringe Chance, dass ein gänzlich anderer Blueprint denselben Hash hätte. Ich könnte separate Hashes für Constructions, Objects und Plants reinpacken, dann ist das Kollisionsrisiko schon höchst unwahrscheinlich ^^


    Ich hatte ja auch mal überlegt einen Blaupausenhandel zu ermöglichen bei dem man Blaupausen auf dem server von anderen kaufen kann, aber dazu müßte es möglich sein blaupausen hoch und runter zu laden :D nur das du das evtl bei der mittelfristigen Überarbeitung im Hinterkopf hast

    Ja, sowas wäre tatsächlich nicht schlecht :D Ich behalte das auf jeden Fall mal im Hinterkopf!

    Das Problem ist, dass die Blaupause nur bedingt serverseitig repräsentiert wird. Der Server kennt zwar die Metadaten der Blaupause, aber die einzelnen Elemente werden erst im Zuge des Platzierens an den Server gesendet (auf viele Pakete verteilt, die erst gesendet werden, wenn die Place-Events grünes Licht geben) :|

    Ich möchte mittelfristig die Blaupausen mal überarbeiten, dann könnten die Daten auch im Event übergeben werden, das wird aber vmtl. noch etwas dauern...


    Dinge die die CreatorID könnten relativ problemlos eingebaut werden. Was würdest du noch benötigen? Wie meinst du das mit den Hashes, meinst du ein Hash der alle Bauelemente beschreibt (um zu prüfen, ob zwei Blaupausen inhaltlich identisch sind, also dieselben Elemente enthalten)?

    seltsam - Steam Client funktionieren alle Enter Tasten bei mir. Einzelspiel und Server. Mit Proton experimental. Hingegen die Standalone nutzt ja "weiß ich nicht was" (irgendwas aus dem Betriebsystem?) :thinking:

    Mit Proton wird die Windows-Version verwendet. Dabei werden auch alle Windows-spezifischen Dinge von Proton emuliert (DirectX usw), d.h. unterm Strich ist es dann so, als würde man unter Windows spielen. Und da mit Proton auch tatsächlich die Windows-Version ausgeführt wird (und nicht mehr die Linux-Version des Spiels) treten Linux-spezifische Bugs meist nicht mehr auf ^^

    Die Standalone hingegen läuft ganz klassisch nativ unter Linux.

    Spielst du unter Linux Desmagu ? Du SonoBionda spielst ja unter Linux, oder? Das Problem wurde unter Linux tatsächlich schon beim letzten Update gemeldet. Es ist leider ein Bug in Unity bzw. UI Toolkit (es wird nur nach eingegebenem Character geprüft und nicht nach gedrückter Taste, obwohl im selben Code ein paar Zeilen vorher bei Tab-Eingabe sogar noch eine Warnung steht, dass explizit unter Linux nicht nach dem Character geprüft werden soll -.-). Meine Hoffnung war eigentlich, dass mit einer neueren Unity Version das Problem behoben ist, sieht aber schlecht aus... ||

    Ich werde versuchen, mit dem nächsten Update einen Workaround dafür einzubauen. Kurz noch ein paar Rückfragen: Was passiert, wenn du Enter drückst? Gar nichts, oder wandert der Cursor zum Zeilenanfang? Und funktioniert Numpad-Enter?

    Sorry for my late response! Apparently all skinned mesh renderers are affected (i.e every model that is animated)... this very much sounds like an issue with the graphics driver (AFAIK SteamOS uses Mesa/RADV) :thinking: Ideally send a report, it will most likely contain more information about what's going on. To do that, please load a world, go to an invisible npc (or just make sure something invisible is on the screen^^), then press ESC and hit the red report button :)

    Yes, the Java version has indeed much lower requirements, but it's basically an entirely different game (but playing together works the same way). For the standalone, the Java version has a separate launcher (so you have to put it into a separate folder on your hard drive). But I realized that the Java launcher is missing from the download section for some reason :wat: I've fixed that now, but you can also find it here ;)