Posts by red51

    Momentan hat das Raster eine absolute bzw. feste Ausrichtung - also quasi wie in der Java Version. Wir haben auch schon mit einem drehbaren Raster herumexperimentiert (bzw. damit, dass sich das Raster autom. am betrachteten Objekt orientieren soll), aber das funktionierte in der Praxis leider bislang nicht so gut :| Das Problem ist, dass die einzelnen Positionen des Rasters (also die Plätze, wohin ein Block einrasten würde) bei einem gedrehten Raster logischerweise komplett anders ausfallen. Auf diesem Bild sieht man das so einigermaßen: Die Blockpositionen (wohin die Blöcke einrasten würden) sind bei dem 45° gedrehten Raster teilweise ganz woanders - was mitunter recht irritierend ist.



    Falls das Raster automatisch ausgerichtet werden würden, dann würde auch eine Situation wie auf dem nachfolgenden Screenshot etwas unübersichtlich: Denn bei Rundungen - die aus mehreren Segmenten bestehen - würde sich das Raster quasi ständig drehen, da jedes Segment ja eine geringfügig andere Drehung hat.




    In der neuen Version kommt noch ein weiterer Faktor hinzu: Es gibt keine Blöcke mehr im klassischen Sinne. Blöcke hatten in der Java Version ja den "Vorteil", dass das Arbeiten mit ihnen sehr einfach war (da sie ja immer an ein festes Raster ausgerichtet waren). Die Mehrheit der neuen Spieler wird damals wohl sofort mit Blöcken zurecht gekommen sein (was bei den anderen Bauelementen wie Planken und Balken nicht unbedingt der Fall war) ^^

    Damit das Bauen in der neuen Version aber für neue Spieler (oder auch Gelegenheitsspieler) nicht zu kompliziert wird, wird das Raster dafür sorgen, dass sich das Bauen quasi so anfühlt, als würde man mit Blöcken bauen. Hier bietet sich natürlich ein festes Raster an (bzw. zumindest ein Raster mit einer festen Orientierung). Selbstverständlich wird man das Raster - wie in der Java Version - weiterhin verkleinern oder auch ganz ausschalten können...


    Insgesamt lässt sich also festhalten, dass ein drehbares Raster einige Probleme mit sich bringen würde, zumindest bei einem Spiel wie RW. Wir werden in Zukunft damit nochmal ein bisschen herumexperimentieren, vielleicht gibt es ja einen Weg, das zumindest optional anzubieten. Bis dahin wird das Raster wohl aber erstmal fest ausgerichtet bleiben :/



    Aber (großes Aber!): Das neue modulare Andocken wird in der neuen Version deutlich mächtiger als in der Java Version. Wir haben das für das Bau-Update auch nochmal überarbeitet. Wenn du also zB ein angefangenes Haus mit einer 45° Drehung hast, dann kannst du das modulare Andocken verwenden, um ganz einfach weitere Blöcke anzufügen. Jeder Block hat verschiedene Andockpunkte und nach dem Andocken kann der Block auch nochmal zusätzlich gedreht werden. Damit sollte auch ein schräg ausgerichtetes Haus selbst ohne Raster recht einfach zu bauen sein :)

    Did you purchase the game on Steam, or did you purchase a Steam key from our homepage? If you've purchased the game on Steam, we have unfortunately no control over refunds or anything related to Steam accounts - this is solely handled by Valve (and they take a cut for this in return). However, if it's a Steam key from our homepage, we can of course turn that into a Standalone version. In this case, feel free to send me a PM about this or send us a mail to support@jiw-games.net :)

    Ok, I did add the RAM to 8000 and that worked. I installed the 64 bit version of Java 8 and restarted computer. I ran the bat file and all was successful. However, I do not see the server name in multiplayer.

    I'm glad to hear the server runs now :)

    About the server not showing up in the list: In the worst case, it may take up to a few minutes until the server shows up (depending on the status of the Steam master server), although usually it should be visible within a few seconds. However, do you run the server on your local machine? If the server does not show up in this case, this may be caused if either a wrong ip is set for the server, or if the ports are not forwarded (especially the http query port, which is serverport-1 [e.g. if you use the default 4255 port, the http query port is 4254]).

    For the ip, if you're behind a router, it's important to keep the server_ip field in the server.properties file blank - this forces the server to bind to all addresses. For the ports, you can use this tool to check if they're open: https://www.yougetsignal.com/tools/open-ports/

    Just run the server (otherwise the tool will always tell you the ports are closed), then check if the ports are reachable (at least make sure the http port is reachable, which is 4254 if you're using the default server_port setting). This page contains more information about the ports the server uses: Dedicated Server Setup


    If the server still does not show up in the server list, please upload the latest server log here (which can be found in the "Logs" subfolder in the server directory), and maybe also upload your server.properties file. If you don't want to post these files here, feel free to send them via PM to me

    If you run the server on your local machine and it does not show up in the server browser, this usually happens if either a wrong ip is set for the server, or if something went wrong with port forwarding. Make sure to keep the server_ip field in the server.properties file blank (or more precisely, only put your public ip there if you're not behind a router) - then the server binds to all addresses.


    If the field is already blank, you can check if port forwarding actually worked on this website: https://www.yougetsignal.com/tools/open-ports/

    Just run the server, then enter the port in question on the website. If you've set up port 2455 as server_port in the properties file, the server automatically uses port 2454 for http queries (which are crucial for the server to show up in the list), so make sure to check this particular port.


    If the tool tells you the port is closed, either the port forwarding didn't work, or something else is blocking the connection (antivirus program, firewall etc) :thinking:

    Will the stand alone server for the unity version be offered through steamcmd and if so will there be a different download number so we can still get the java version of the server?

    The dedicated server for the new version will be available as separate beta branch via SteamCMD (but unlike the game, this branch will overwrite an existing Java version of the server, so it's recommended to install the server for the new version to a separate directory) ;)

    Maybe we will also offer the dedicated server files as separate download on our website, but we're still not sure about that.

    Eine direkte Zeitangabe traue ich mich lieber nicht zu machen :D Auch eine "Mindestdauer" könnte evtl. von manchen als tatsächliches Erscheinungsdatum interpretiert werden, daher halte ich mich auch hier lieber zurück :saint: Der größte Teil des Bau-Updates ist aber schon geschafft.


    Da hast du wohl recht, ich denke hier wäre dann eher die bessere Frage nach dem Was und nicht nach Wann. Mich würde es mal interessieren, was so alles in Trello momentan für das nächste Update getan werden muss. Vielleicht könnte man in Trello eine Markierung "Next" machen, mit der die Kategorien markiert sind, an denen für das nächste Update gearbeitet wird.

    Leider ist es ein wenig schwierig, konkrete Aussagen darüber zu treffen, was noch unmittelbar für das Update erledigt werden muss :| Da wir so ein kleines Team sind, sind verbindliche Vorausplanungen sehr schwer. Selbst bei großen Firmen wie bspw. Unity - wo mehrere Hundert Entwickler beschäftigt sind - verzögern sich geplante Features manchmal um mehrere Monate oder gar Jahre :wat:

    Wie Avanar schon treffend feststellt, ist die Entwicklung nicht linear. Manchmal ergeben sich in der Entwicklung ganz neue, unvorhergesehene Baustellen. Oder wir ziehen kurzfristig ein anderes Feature vor, das eigentlich für später geplant war - insbesondere wenn sich doch die eine oder andere Abhängigkeit zwischen den Features ergibt.


    Beispiel: Obwohl wir uns momentan zwar in erster Linie auf das Bau-Update konzentrieren, haben wir die letzten Tage ausschließlich dem Multiplayer gewidmet (obwohl der Multiplayer erst nach dem Bau-Update kommen soll). Der Hintergrund war schlicht der, dass wir für einige Tests bzgl. des Bauens dringend einen funktionierenden Multiplayer benötigten.


    Konkret kann man aber als grobe Orientierung diese beiden Karten auf Trello verwenden: Constructions und Building-Tools. Wenn beide ein grünes Label haben, dann wird das Update nicht mehr lange auf sich warten lassen :D


    wait... wir bekommen bau und multiplayer? zusammen?????

    Nein, leider nicht, ich würde beide Updates lieber etwas trennen, da beides relativ umfangreiche Updates sind und das dann das Aufspüren und Beheben von Bugs erschweren würde^^ Die gute Nachricht ist aber: Der Multiplayer funktioniert, und auch der Netcode, den wir schon vor ca. 1 Jahr implementiert haben (aber nie wirklich testen konnten), funktioniert soweit - hier war unsere größte Sorge, dass der noch unerwartete Probleme bereiten würde :D Der Dedicated Server braucht noch etwas Feinschliff, und vor allem auch diverse Sachen beim Synchronisieren der Spieler und Items (vor allem hinsichtlich der Spielerfigur und Animationen). Nach dem Bau-Update wird das MP-Update nicht all zu lange auf sich warten lassen.

    Was ich noch vergessen haben zu erwähnen, sind die fliegen. Die werden eine ziemlich gute Atmosphäre auf der Müllhalde sein ;) Und ich hoffe das sowas mehr davon geben wird.

    Der Fliegenschwarm, der sich in der Demo ein Stückchen hinter der Hütte versteckt, wird später tatsächlich in erster Linie bei Leichen und langfristig ggf. auch in der Nähe von Kisten mit verdorbenem Essen spawnen :D Wir können den Schwarm aber via Command auch als spezielles, platzierbares "Objekt" anbieten (quasi wie der "technical smoke" in der Java Version) ^^

    I'm running the win_startscript as the application to start it. When I do I get this......

    This indicates the JVM could not reserve enough memory. Usually this happens if there is only a 32 bit Java version installed on a 64 bit OS - please make sure that the 64 bit version of Java 8 is installed ;)

    The fireworks indeed spawn every time you load the world (and as long as they're in your view frustum) ^^ They were an early experiment with GPU particles, but we kept them in the demo (same as the playground) :D It's indeed our intention to use them for proper fireworks in the future.

    Wie Avanar schon sagt, die Unity Demo wird zusätzlich zur Java Version installiert - d.h. du kannst auf diese Weise jederzeit zwischen der Java und Unity Version hin- und herspringen, ohne, dass irgendwas manuell geändert oder heruntergeladen werden muss. Du kannst den Unity-Branch also aktiv lassen, hierüber wirst du sowohl Updates für die Unity Version, als auch etwaige Updates für die Java Version erhalten.


    Du kannst aber den Beta Branch natürlich verlassen (falls du bspw. etwas Festplattenspeicher einsparen möchtest) indem du bei den Beta Branches einfach "None" oder "Keine" auswählst - damit springst du wieder auf den ursprünglichen Standard-Branch (die klassische Java Version) zurück ;)


    Falls du aber Interesse an den künftigen Updates der Unity Version hast, dann würde ich empfehlen, den Unity Beta Branch aktiv zu lassen ;) Ein häufiges Hin- und Herwechseln zwischen verschiedenen Branches kann Steam manchmal durcheinander bringen.

    Ich finde den Vorschlag von Ludy super. Denke auch das die Schichten von Wüste abgesehen teilweise viel zu dick ist.

    Oh, sorry Ludy , bin auf den ursprünglichen Post leider nicht mehr eingegangen :( Jedenfalls wäre ein Tool womit verschiedene Schichten eingestellt werden könnten interessant, allerdings müsste man sich auch hier überlegen, wie eine sinnvolle Steuerung aussehen könnte (ohne den Durchschnittsspieler damit komplett zu überfordern) :thinking:


    Für den Anfang könnte es vielleicht auch helfen, wenn diverse Texturen (zB Gras) beim Malen immer nur entlang der Oberfläche aufgetragen werden - man also zwar einen großen bereich zum Malen wählen kann, aber die tieferen Schichten nicht durch zB Gras ersetzt werden.


    Ich würde das Raster wenn es möglich ist gern noch deiner als in der java haben. Grad im creativmodus wäre es toll wenn wir das Raster noch viel kleiner machen könnten, angepasst an die kleinste Möglichkeit.

    Grundsätzlich ist die minimale Rastergröße in der neuen Version bereits kleiner als in der Java Version ^^ Die Mindestgröße in der Java Version ist 0.0625 (1/16), während die Mindestgröße in der neuen Version 0.03125 (1/32) beträgt.


    Es wäre schön wenn man auch F5-1 mit einer Unterste / Höchste Ebene Funktion haben könnte.

    Ich habe es wie gesagt mal auf unsere Liste gepackt, aber die größte Hürde ist hierbei in der Tat eine sinnvolle Steuerung, ohne das bestehende System (womit nicht jeder Spieler klargekommen ist, also die bisherige Höhenlimitierung) zu sehr zu verkomplizieren :monocle:


    Außerdem füge bitte zu meiner Wunschliste hinzu das ich gerne noch mehr Formen beim Terraforming hätte. Vielleicht auch sowas wie "Zufall" oder so. Gäbe sicher interessante Gebilde

    An was für Formen hättest du dabei genau gedacht?


    Formen im Terraforming, dass ist nun wirklich interessant. Es wäre schon toll wenn man es drehen könnte. Somit kann ich das Viereck auch als Dreieck nutzen.

    Das Problem ist hier die Auflösung des Terrains: Das Terrain ist ja quasi in Blöcke unterteilt (1x1x1 von der Größe her), hier sind keine wirklichen Zwischenschritte oder so möglich. Drehungen wären also nur äußerst eingeschränkt möglich und auch hier würde es schnell Situationen geben, in denen eher "stufige" Kanten rauskommen :thinking:


    Wir hatten zwar damals für die neue Version über eine Verdoppelung der Terraingenauigkeit nachgedacht, aber das hätte den Speicherverbrauch um den Faktor 8 nach oben getrieben (und hier hat die neue Version aufgrund der deutlich größeren Sichtweite und maximalen Höhe der Welt ohnehin schon wesentlich mehr Overhead als die Java Version) :dizzy:

    Wäre das hier nicht besser es soweit es geht über die permissions zu steuern, dann sollte die Frage überflüssig sein.

    Über die Permissions könnte man lediglich bestimmen, ob ein Spieler mit einem Verkäufer interagieren darf oder nicht. Ob Verkäufer vorhanden sind muss ja für alle Spieler gleich gelöst werden - hier wäre wie gesagt nur eine globale Servereinstellung bzw. vielmehr eine Welteinstellung geeignet ;)


    Ich hoffe das wurde nicht schon irgendwo beantwortet, aber wird es mit dem Bau-Update noch eine Änderung in der aktuellen Demowelt geben, oder kommt lediglich die Baumechanik als neue Funktion dazu, mit der man sich dann austoben kann?

    Ich weiß noch nicht, ob die Demowelt in ihrer Form bestehen bleibt. Die dortigen Gebilde sind nicht direkt mit richtigen "Bauelementen" erstellt (sie mussten ja noch für die Demo fertig werden, allerdings waren Bauelemente zu dem Zeitpunkt noch nicht wirklich implementiert), d.h. sie könnten entweder weiter bestehen bleiben (und wären weiterhin unzerstörbar und nicht einfärbbar), oder wir schreiben einen Konvertierer dafür (wofür aber wieder Zeit draufgehen würde) :thinking: Ich bin mir da also noch nicht ganz sicher... vll wird es auch einfach eine etwas angepasste Welt geben.


    Ein richtiges "Weltupdate" (womit die Welt erweitert wird und auch endlich richtige Wälder kommen) wird aber erst nach dem Bau-Update bzw. auch nach dem Multiplayer-Update kommen.


    Wie viele Texturen werden wir denn im nächsten Update zur Verfügung haben red51 ? Wahrscheinlich erstmal keine 100, aber ich hoffe ja nicht, dass es nur bei den vier Stück bleiben wird. Glastexturen wären wünschenswert, sonst hätten wir ziemlich traurige Häuser ohne Fenster.

    Das kann ich leider noch nicht sagen :| Wir wollen uns zum Schluss um die Texturen kümmern, wenn die Baumechaniken usw. stehen. Das System ist "theoretisch" darauf ausgelegt, bis zu 250 Texturen zu bieten, allerdings werden wir so viel wohl nicht ausschöpfen (man muss hier auch den RAM und VRAM Verbrauch im Blick behalten, da die Texturen deutlich hochauflösender sind als in der Java Version). Das heißt aber, dass wir grundsätzlich problemlos neue Texturen nachliefern können, ohne, dass es zu Problemen mit bestehenden Welten kommt. Sicherlich wird das erste Bau-Update aber mehr als 4 Texturen haben ;)

    red51 Die Frage nach dem Size-Befehl ging eigentlich immer nur um die kleinen Maße für Tierkäfige oder Zäune. Da spricht doch nichts dagegen, dass das auch im Survival möglich ist?

    Ja, die Mindestgröße für Bauelemente werden im Survival- und Creative-Modus gleich sein. Lediglich bei Objekten (Möbel, Türen etc) wird der Survival-Modus striktere Mindestgrößen haben ^^

    red51 Mein Raster lässt sich nicht auf diese kleine Größe herunterskalieren. 6x6 Blöcke würde ich mal vermuten oder größer. Ich bin auch nicht generell gegen das Tool, ist mir lieber als world edit, ^^

    allerdings hat world edit diese Area oder Blaupausen Markierungsmöglichkeit

    Ich rede doch die ganze Zeit vom Area-Tool :nerd: Bitte starte einmal die Java Version, gehe in den Creative-Modus, drücke F5 und dann die 4: Damit aktivierst du das Area-Tool, von welchem ich in den vorherigen Beiträgen gesprochen habe :D Das ist quasi genau das gleiche Tool, welches auch für Blueprints verwendet wird, oder eben auch von WorldEdit.

    Es wird sehr viel über neue Survival Implementierungen gesprochen. Npc Verkäufer, Geld. Im Singleplayer mag es interessant sein, sich für Geld bei Npcs Dinge wie in Minecraft kaufen zu können, auf Servern mit Survival Angeboten auch. Wenn der Server dieses Angebot nicht nutzen möchte, können diese Optionen bei Erstellung der Welt deaktiviert werden? Können diese Optionen im Nachhinein ohne weiteres btw. ohne neue Welterstellung geändert werden?

    Ich weiß nicht, inwieweit Bau-Server dadurch negativ beeinflusst werden sollten? :thinking: Wie Avanar schon sagt, aktuell arbeiten wir ja explizit am Bauen und haben hier viele Änderungen und Neuerungen vorbereitet, die die Freiheit beim Bauen deutlich erweitern werden.

    Nichtsdestotrotz braucht das Spiel langfristig dringend mehr Survival-Features, denn RW war nie als reines Bauspiel gedacht.


    Wie ja schon zuvor gesagt wird man NPCs bzw. Verkäufer ausschalten können. Inwieweit das nachträglich aktiviert/deaktiviert werden kann weiß ich allerdings noch nicht, vmtl. wird das für solche Fälle dann über einen Command gelöst werden (ähnlich wie der disablenpcs Command).


    Mit Bauservern meinte ich, dass es viele Leute gibt, die nur bauen wollen und sich nicht erst mühsam die Mats dazu erfarmrn müssen.

    Schon die Demo hat doch bereits einen Creative-Modus und die Möglichkeit, Items via Command zu spawnen. Warum sollten wir das wieder entfernen? :huh:

    The warning seems to be incorrect, there is nothing wrong in using final bytes in if-else statements :D So it looks like a bug in the IDE... Which version of Netbeans do you use? I'm not getting this warning in Netbeans 8.2, but Netbeans 11.2 shows me the same warning :monocle:

    You could either ignore this warning or just disable it (by hitting the light bulb on the left side). Or just use ints in this case - unless you're creating big arrays, the memory difference is negligible ^^

    Wie ist es denn mit dem Size-Befehl im Survival? Auf dem Server wurde immer danach gefragt, aber dazu mussten die Permissions oder Gruppen geändert werden.

    Den size-Befehl gibts auch im Survival, wie schon in der Java Version, allerdings erlaubt der Befehl auch hier nur Eingaben innerhalb der im Survival zulässigen Min- und Max-Größen. Sprich in der neuen Version bspw. ist size 4 4 4 sowohl im Survival als auch Creative-Modus möglich, hingegen size 16 16 16 nur im Creative-Modus.


    Wenn ich ein Holzplanke oder Holzbalken mit 15.99 x 15.99 in der Hand halte, sehe ich dieses Bauteil nicht mehr.

    Achso, naja, das ist in der neuen Version bereits "behoben" - das gilt allerdings nur für den Creative-Modus. Die Sache ist, dass man in der Java Version (sowie im Survival-Modus der neuen Version) Bauteile nur innerhalb eines begrenzten Radius platzieren kann (in der Java Version ca. 7-8 Blöcke weit) - ausgehend vom Mittelpunkt des Bauteils. In der neuen Version besteht so ein Limit auch (hier 10 Blöcke), allerdings nicht im Creative-Modus - hier können Bauteile in einem Umkreis von 100 Blöcken platziert werden.


    Der Gedanke beim Survival-Modus für diese Limitierung ist eben, dass der Spieler Bauteile nicht übertrieben weit von ihm aus platzieren können sollte.


    ?

    Oh, sorry, der letzte Teil des Satzes ist wohl verlorengegangen :saint: Ich habe meinen vorherigen Beitrag entsprechend editiert und den Satz vervollständigt :drunk:

    Im Grunde genommen ja. Allerdings finde ich World edit viel genauer und meines Erachtens einfacher was Höhe und Breite anbelangt. Dieser Zahn im Vordergrund lässt sich mit F5 nicht erschaffen, da das Tool größere Formen vorgibt. Die Gebilde auf der linken Seite sind mit world edit erstellt, der Rest mit dem Tool. Zu 99% entsteht bei mir eine Stufe.

    Hmm... das ist eigentlich auch alles mit dem "Area-Tool" (F5->4) erstellbar :thinking: Hier ein Bild vom Zahn (den meintest du doch, oder?), der mit dem Standard Area-Tool des Spiels erstellt wurde:


    Ich rede nicht vom normalen "Mal-Werkzeug" (1, 2 u. 3), sondern wirklich explizit von dem Bereichs-Werkzeug oder Area-Tool (4), mit welchem du eine Area auswählen und dann mit einem gewünschten Material füllen kannst (oder alternativ mit ENTF entfernen kannst). Das WorldEdit Skript verwendet unter der Haube eigentlich dasselbe Area-Tool (bzw. das ist das einzige derartige Tool, was über die Lua API zugänglich ist) :monocle:

    Well, actually the block isn't really removed if the event is cancelled - it just looks like the item is missing :D In the Java version, the client and server inventory were updated independently: When placing an item, the item is first removed from the clientside inventory, then the "place item" packet is sent to the server which invokes the API event, then - if the event wasn't cancelled - the item also gets removed from the serverside inventory and the item is placed in the world.

    Cancelling the event prevents the item from being removed from the server inventory, but at this stage, it is already removed from the client inventory (strictly speaking, this results in a desync between client and server inventory). If the client closes and opens his inventory again, the game detects the desync and requests the inventory from the server - this restores the missing item (so at the end of the day, the player actually didn't really lose the item).


    The reason for this overly complicated implementation was to keep the latency and bandwidth as low as possible. Tbh, this wasn't the best idea, since this implementation is error prone and doesn't work well with the API (resulting in the issue you've mentioned).

    However, inventory and item handling works completely different in the new version - the client inventory only gets updated after the server inventory was actually updated (no longer resulting in desync if you cancel such an even through the API) - so yes, this will be "fixed" in the new version ;)