Posts by red51

Thanks a lot for your feedback

Quote from zfoxfire

Whatever it is, it appears to be a singular object--not plural and un-owned.

Bigfoot confirmed

Quote from lenko

Kann nun wirklich nicht sein ,dass das Bausystem dann schon mit drinnen ist. Ich weiß nun wirklich nicht, ob ich schon soweit bin

Hehe, ja, absolut nachvollziehbar Aus Rücksicht auf die Community passen wir auf, nicht zu viele Features gleichzeitig reinzubringen

Quote from Smoka

Echt schade das es bis dahin schon fertig ist

Hehe, lol, danke für den Hinweis, natürlich fehlte dort ein "nicht"

Hey folks! We're currently focusing on getting the first demo of the new version ready as soon as possible. The first version will be rather a "walking simulator", but it will serve as foundation for future updates. And the demo will still give a good impression of the gameplay and the technical component (graphics, audio etc) of the new version.

The last weeks we've been further improving the terrain generation. The game now generates more realistic, but also much smoother landscapes (i.e. no more "bumpy" terrain). Biomes (including proper forests) and dungeons are still missing, but the world is already more varied than in the old version.

We've also been working on the new building part. Our goal is to keep the freedom of the old system, but improve it to a extent that building becomes a lot less painful. Apart from fixing some issues of the old building system, we've reworked the way how snapping works from scratch. You will be able to change the rotation pivot of an element, and you will also be able to snap the object to a pivot of another element. As a result, creating curved structures will be much easier.

Unfortunately the building part won't be ready for the first demo release, but it will be available in a separate update shortly after.

We also spent some time on a new auto-updater/launcher (for the Standalone version) and on a Linux build. Unfortunately it looks like Linux/Vulkan support isn't Unitys greatest strength, which is a bit disappointing. We've discovered some bugs which are out of our control - most of the rendering stuff is "black boxed" in Unity and the source code of the engine isn't available. Only thing we can do in this case is to forward these issues to Unity, however, if you experience any issues or crashes with the Linux version of the game, please don't hesitate to contact us.

As always, you find more information on our Trello roadmap

Hey Leute! Aktuell konzentrieren wir uns darauf, die erste Demo der neuen Version so bald wie möglich fertig zu bekommen. Die erste Version wird zwar eher ein "Walking Simulator", aber als Grundlage für künftige Updates dienen. Und die Demo wird dennoch einen guten Eindruck des Gameplays und der technischen Komponente (Grafik, Audio etc) der neuen Version vermitteln.

Die letzten Wochen haben wir weiter an der Terrain-Generierung gearbeitet. Das Spiel generiert nun realistischere, aber vor allem auch "weichere" Landschaften (also kein zerkluftetes, unebenes Terrain mehr). Biome (einschl. richtiger Wälder) sowie Dungeons fehlen zwar noch, aber die Welt ist bereits jetzt abwechslungsreicher als in der alten Version.

Wir haben ebenfalls am neuen Bausystem gearbeitet. Unser Ziel ist, die Freiheiten des alten Systems beizubehalten, es aber soweit zu verbessern, dass das Bauen wesentlich angenehmer wird. Abgesehen davon, dass wir einige Probleme des alten Systems behoben haben, haben wir auch die Art und Weise, wie das modulare Platzieren funktioniert, von Grund auf überarbeitet. Es wird möglich sein, den Rotationspunkt eines Elementes zu verändern, und man wird Objekte an verschiedenen "Andockpunkten" anderer Elemente anheften können. Als Resultat wird das Bauen von runden Strukturen und Kurven deutlich einfacher werden.

Leider wird das Bausystem noch nicht bis zum ersten Demo-Release fertig sein, dafür aber in einem Folgeupdate verfügbar werden.

Wir haben auch etwas Zeit in einen neuen Auto-Updater bzw. Launcher (für die nicht-Steam Version) sowie den Linux Build gesteckt. Leider scheint es so, dass der Linux/Vulkan Support nicht unbedingt Unitys größte Stärke ist, was ein wenig enttäuschend ist. Wir haben ein paar Bugs entdeckt, auf welche wir allerdings keinen Einfluss nehmen können - der meiste Teils des Renderings ist quasi eine "Black Box" innerhalb von Unity und der Source-Code der Engine ist nicht verfügbar (anders als bei Unreal). Das einzige, was wir in dem Fall machen können, ist die Bugs an Unity zu melden. Aber wenn ihr Probleme oder Crashes mit der Linux Version entdeckt, zögert bitte nicht, uns zu kontaktieren.

Wie immer findet ihr mehr Informationen auf unserer Trello Roadmap

Lol, no, I'm not an atheist I hardly believe the word "xmas" is primarily used by atheists Yet we don't want to put the game in a religious context

Ihr habt aber auch strenge Wort-Definitionen Mein Vokabular für vage Zeitangaben ist langsam echt aufgebraucht

Unfortunately the behaviour of the sledgehammer (and crowbar) isn't determined by the HitDamageDefinition atm Currently the ability to remove blocks without destroying them is hard-coded. This will change in the new version though. Currently the only workaround would be to emulate this behaviour by modifying the world (and spawning the appropriate block) manually via API, but that's a bit tricky.

However, the ability to cut grass is already exposed to the hit definition, so it should be possible to create a more powerful weed whacker, for example

Aktuell gibt es dafür leider keine Events, aber die neue Version wird dafür ein passendes Event haben

Derzeit kann man die Änderung dieser Werte nur abfangen, indem man selber prüft, ob sich die Werte zwischenzeitlich geändert haben (zB in einem Update-Listener oder in einem Timer).

Eine Erhöhung dieser Maximalwerte war im Spiel zwar teilweise mal umgesetzt, aber nie vollständig implementiert, daher ist das über die API leider nicht direkt möglich. Auch hier wäre der einzige Workaround, Änderungen an diesen Werten selber abzufangen und zu beeinflussen (zB statt die maximale Health zu erhöhen, den jeweils erlittenen Schaden reduzieren).

In der neuen Version wird sich das wahrscheinlich teilweise ändern. Variable Maximalwerte werden dort zumindest schon für HP, Stamina und Atem (also wenn man sich unter Wasser befindet) berücksichtigt, allerdings noch nicht direkt verwendet. Für ein künftiges Skill-System wäre das aber vorteilhaft, daher wird das voraussichtlich dort noch rein kommen (und dann würde auch die API Zugriff darauf bekommen).

Quote from yahwho

Just checking in on this. Is there an event for this yet?

Unfortunately this event isn't available in the Java version yet It's still on our to-do list for the new version though

Quote from Deirdre

Wird es den Lua-Wrapper noch geben?

Das kann ich nicht sagen, theoretisch möglich wäre das schon, kommt ein wenig auf die Nachfrage drauf an. Eigentlich wollen wir Lua aber nicht unbedingt als Skript-Sprache für RW pushen, da hier viel Performance verschenkt wird (Hauptproblem ist die fehlende Multi-Threading-Funktionalität, die für RW extrem wichtig ist). Aber auch wenn wir den Lua Wrapper anbieten, müssten bestehende Lua Skripte voraussichtlich trotzdem etwas angepasst werden, damit sie mit der neuen Version kompatibel sind

Quote from PatrickBronke

red51 , Wan ist bald?

Vermutlich irgendwann in den kommenden Tagen Wir haben in den letzten Tagen etwas länger als geplant am neuen Standalone-Launcher gesessen (betrifft zwar nicht die Mehrheit der Spieler, aber muss ja trotzdem gemacht werden^^). Im Laufe der kommenden Woche dürfte die Ankündigung soweit sein.

Quote from lenko

Mich würde Mal die WASSER Frage interessieren. Wird es da auch gleich Wasser geben ? Wie sieht es mit dem Fließverhalten aus ? Mir würde das Fließverhalten so wie bei mc komplett reichen. Würde heißen das es dann so 6-7 Blöcke weit fließen kann, aber auch das wenn man am Ufer gräbt, sich der Wasserspiegel automatisch angleicht was ich am wichtigsten dabei finde.

Wasser wird es in der Demo leider noch nicht geben, bisher haben wir noch nicht viel am Wasser gearbeitet Der erste Release mit Wasser wird aber dafür dann direkt dynamisches Wasser beinhalten. Unser bisheriger Zeitplan (kann sich natürlich noch ändern) sieht so aus, dass wir jetzt zunächst die erste spielbare Version auf Vordermann bringen (hier und da noch Feinschliff am Terrain und Vegetation, und noch viele Kleinigkeiten [zB zumindest ein einfaches Settings-Menü usw]), danach steht das Bausystem im Vordergrund (also es in eine Release-fähige Form bringen), und dann möchten wir uns um die Spielerfiguren und Item-Animationen kümmern (in dem Bereich gibts noch einige ungeklärte Fragen). Danach kommt der Multiplayer zum Abschluss (prinzipiell ist der schon drin, aber es fehlt noch richtige Player-Sync und ein dedicated Server), und vmtl. wird es dann in Richtung Wasser und sowas wie NPCs gehen.

Quote from Deirdre

Rising World sieht so realistisch aus, warum denn dann beim Wasser zurückstecken? Hat dieses Spiel doch gar nicht nötig, auch wenns länger dauert.

Ich würde mir auch realistisches Wasser wünschen, aber wie Avanar und lenko schon sagen, das ist in dem Umfang leider (noch) nicht möglich. Dazu müssten einzelne Wasserpartikel (oder Tröpfchen, wie Avanar beschreibt) simuliert werden. Es wären zwar vmtl. auch hinreichend gute Ergebnisse möglich, wenn diese "Tröpfchen" etwas größer ausfallen (sagen wir mal 5x5cm), aber sowas ist im großen Stil leider nicht umsetzbar. Es gibt zwar viele nette Wasserdemos auf YT, aber hier gehts immer nur um sehr kleine Bereiche. Es wäre also mit heutiger Hardware auf jeden Fall umsetzbar, dass man eine Wanne voller "realistischem" Wasser hat, oder vielleicht ein ganzer Teich. Alles darüber hinaus stößt aber an die Grenzen. Ein ganzer See mit "realistischem" Wasser, der leerläuft und eine Höhle flutet, wäre schlicht unmöglich (zumindest in dieser Form).

Bei RW kommt hier sogar noch ein anderes Problem hinzu: Die Änderungen müssen irgendwie gespeichert werden. Wenn die Auflösung des Wassers also so genau ist, dass jeder einzelne (große) Tropfen gespeichert wird, würde das enorm viel Speicherplatz benötigen. Wenn ein "Wassertropfen" 0.05 Blöcke groß wäre (würde gehen, wäre aber schon ein sehr großer Tropfen), wären das pro Block 20x20x20, also 8000 "Tropfen". Wasser würde fürs Speichern also bis zu 8000x mehr Speicherplatz benötigen. Im Multiplayer kommt hier die Synchro hinzu, die Tropfen müssten also auch synchronisiert werden (und verursachen entsprechend bis zu 8000x mehr Traffic).

Sowas ist wie gesagt mit heutiger Hardware im kleinen Maßstab möglich, aber nicht für ganze Spielwelten. Und wenn eine persistente Welt oder Multiplayer hinzu kommt, sieht es erst recht düster aus

Quote from Black Knight

How to place different water in Unity

Unfortunately this has nothing in common with actual water This is basically just a static surface that looks like water, but it has no behaviour like water. In fact this video just shows how to drop a ready-to-use asset (which wouldn't be compatible with RW anyway) into the scene editor

Rising World has a randomly generated world, which means the world is generated at runtime. It's not available in the editor (because the world always looks different, depending on the selected seed). The scene in our editor is basically completely empty

So in RW, water has to be generated programmatically. And it has to be actual "3D" water (if this makes any sense). While most games with a static, pre-designed world can simply declare the whole area below a certain elevation (e.g. sea level) or below a surface as "water", this wouldn't work in RW (since there could be always a cave under a pond, for example).

Biggest issue is to implement flowing water though. RW has a modifiable environment, so water has to react to a changing environment. Flowing water is computationally very expensive, especially in a multiplayer world (where everything has to be synced with other players). There aren't many games out there that have to deal with this issue, so of course there is no solution for this available somewhere "out-of-the-box"

Quote from lenko

Ich würde auch gern einen oder mehrere Wasserfälle in Rising World sehen, vieleicht gibt es da ja mal die Möglichkeit das man Wasserfälle in verschiedenen Größen als Objekt setzen kann, somit wäre der Wasserfall zwar statisch aus einer Textur, für mich aber eine klare Alternative

Das wäre definitiv umsetzbar Natürlich bis zu einem gewisssen Grad eingeschränkt, aber in vielen Situationen dennoch geeignet. Wir könnten darüberhinaus auch ein "Wasser-Objekt" anbieten, also quasi nur eine einfache, skalierbare Wasseroberfläche. Die würde sich zwar nicht wie Wasser verhalten, aber wie Wasser aussehen. Damit könnte man zumindest auf kleineren Flächen Wasser "faken" (zB Wasser in einer Badewanne, oder in einem Eimer, oder einer Tränke etc).

Quote from james1bow

i can say that some models do crash it. i have been using this plugin to test .obj and .dds textures for the customitemloader before i worry about the itemdef and icon files. ive had some .obj files not allow the server to boot as well it will load it then crash the server and not allow it to restart. i could try to find the error logs if it would help in any way

Can you maybe send me one of the models in question (+ the according texture) via PM? If there is an issue with the model, maybe it's something the game can catch (so at least it doesn't crash anymore) If you have an additional error log, that would also be helpful

Quote from PresenceRusher

Heißt es dann, dass ich mit einem Plugin ein Auto programmiere und das Plugin auf einem Server installieren kann wenn die API die Funktion dafür hat?

Wenn die API das unterstützt, dann ja Wobei es natürlich auch immer einen gewissen Spielraum gibt, den man dabei hat. Denn auch wenn es in der API keine direkte "FügeAutoHinzu()" Funktion gibt, so kann man versuchen, das anderweitig umzusetzen: In dem Fall könnte man zB das Modell eines Autos laden (das kann die API bereits) und darauf warten, dass ein Spieler damit interagiert. Das Plugin könnte sich nun für diesen Spieler merken, dass dieser in einem Auto sitzt, und die Spielerposition entsprechend regelmäßig updaten (an die Position des Fahrersitzes setzen). Wenn der Spieler nun zB die Vorwärtstaste betätigt, dann könnte man das Auto-Modell (mitsamt) Spieler nach vorne bewegen, beim Lenken entsprechend drehen usw. Bis hierhin ist alles auch mit der jetzigen API bereits möglich. Schwieriger wird es, das Auto an das Terrain anzupassen und Kollisionen richtig zu behandeln (wenn der Spieler zB gegen eine Wand fährt). Hier sind zwar einzelne Funktionen für sowas bereits in der API (zB raycast()), aber das wird trotzdem kompliziert - und stößt teilweise an die Grenzen. Neue Funktionen, die im Laufe der Zeit zur API hinzukommen, werden das sicherlich einfacher machen, aber es würde sich bei so einem Unterfangen trotzdem um ein sehr umfangreicheres Plugin handeln.

Anders sieht es aus, wenn es bereits Fahrzeuge im Spiel gibt: Dann kann die API eher die Funktionen dazu bereitstellen (womit die Umsetzung eines solchen Plugins 100x einfacher wird). Dann könnte ein Plugin zB sein eigenes Modell einfügen, das Verhalten an das eines im Spiel bestehenden Autos anpassen, und das wars dann auch schon So funktioniert das derzeit zB mit den Custom Items: Man kann recht einfach eine neue Spitzhacke oder ein neues Schwert einbauen (weil es sowas bereits im Spiel gibt), aber wenn man einen Flammenwerfer einbauen möchte, wird es kompliziert (weil es keine noch Mechanik für sowas im Spiel gibt).

Du musst dir das immer so vorstellen, dass die API quasi nur bestehende Funktionen bereitstellen kann. Wenn du eine Funktion in der API aufrufst, kümmert sich das Spiel im Hintergrund um den Rest. Daher kann die API prinzipiell nur das bereitstellen, was das Spiel auch bereits kann.

ZB über ein Plugin eigene Sounds abspielen ist möglich (weil das Spiel weiß, wie man Sounds abspielt), aber bspw. Gamepad-Support über ein Plugin einbinden ist nahezu unmöglich.

Von den Dingen, die das Spiel kann und weiß, versuchen wir, so viel wie möglich über die API zugänglich zu machen, aber fehlende Funktionen fallen meist erst dann auf, wenn man selber ein Plugin schreibt (was wir aus Zeitgründen ja nicht so häufig machen). Dafür haben wir entsprechend die API-Wünsche Sektion^^

Die Grenzen zwischen Mods und Plugins sind manchmal fließend, und auch der "Mod" Begriff wird häufig weit gefasst. Auf RW bezogen kann man es sich aber so vorstellen:

• Eine Mod wäre eine Modifikation der Spieldateien. D.h. irgendjemand würde zB das Spiel dekompilieren, irgendwas am Code ändern, und die geänderten Dateien dann quasi als "Mod" zur Verfügung stellen. Hier sind generell keine Grenzen gesetzt. Nachteil ist, dass mit nahezu jedem Update des Spiels die Mod inkompatibel wird (sofern die modifizierten Spieldateien vom Update betroffen sind). Außerdem muss für den Multiplayer jeder Spieler (sowie der Server) die gleiche Mod installiert haben. Mehrere Mods parallel zu benutzen ist auch immer etwas schwierig, vor allem, wenn die Mods die gleichen Spieldateien oder Stellen im Code verändern. Zudem ist das Erstellen einer Mod auch ziemlich kompliziert, da der dekompilierte Code schwer leserlich ist und über keinerlei Dokumentation verfügt
• Plugins hingegen verwenden die vom Spiel bereitgestellte API. Die API ist quasi eine Schnittstelle, die bestimmte Spielfunktionen nach außen trägt (und Plugins auch über versch. Ereignisse informiert, zB wenn ein Spieler Schaden bekommt usw) und über die die Plugins dann mit dem Spiel kommunizieren können. Vorteil ist, dass Plugins nach Spiel-Updates in den allermeisten Fällen kompatibel bleiben (es sei denn die API verändert sich). Auch reicht es im Multiplayer aus, wenn das Plugin auf dem Server installiert ist, da es ohnehin nur dort ausgeführt wird (und der Server sich um die Synchronisierung mit den Clients kümmert). Mehrere Plugins zu verwenden ist auch weit weniger problematisch als bei Mods, und Plugins zu erstellen ist - im Vergleich um Erstellen einer Mod - tausendmal einfacher, da die API einfach aufgebaut, öffentlich einsehbar und gut dokumentiert ist. Nachteil von Plugins ist, dass nur Dinge gemacht werden können, die die API auch bereitstellt. Derzeit erlaubt die API zB Custom Items einzubinden, aber zB noch keine Custom NPCs. Die API wird aber mit jedem Update umfangreicher und bietet mehr Freiheiten. Auch haben wir dafür die Sektion im Forum "API Wünsche" eingerichtet, in welcher Plugin-Entwickler auf fehlende API-Funktionen aufmerksam machen können

Modding (also klassisches Modding) war in RW schon immer möglich und wird auch immer möglich bleiben, aber hierfür sind fundierte Programmierkenntnisse, viel Zeit und Geduld sowie Nerven aus Stahl nötig. Daher ist unsere Priorität, die Plugin-API voranzutreiben.

Die neue Version ist zwar in C# und C++ geschrieben, aber für die Plugin-API werden wir weiterhin auf Java setzen. Wir haben uns zwar lange Gedanken dazu gemacht, aber Java bietet in diesem konkreten Fall mit Abstand die meisten Vorteile:

• Java ist schnell, also spürbar schneller als Skriptsprachen wie zB Lua. Zwar nicht ganz so schnell wie C++, aber mit einer C++-API hätten wir wohl die Büchse der Pandora geöffnet (einerseits ist der Umgang mit C++ schwieriger als mit Java, das würde vmtl. viele Leute abschrecken, andererseits können schon minimale Fehler in Plugins das Spiel zum crashen bringen - ohne, dass man herausfinden könnte, dass der Fehler von einem Plugin verursacht wurde)
• Java läuft quasi in einer eigenen Umgebung, d.h. wenn ein Plugin Amok läuft, wird nicht sofort das Spiel in Mitleidenschaft gezogen (*natürlich kann ein Plugin das Spiel trotzdem durcheinander bringen, aber zwischen Spiel und Plugins ist quasi ein sehr großer "Sicherheitspuffer")
• Die alte API kann weitestgehend übernommen werden und auch bestehende Plugins müssen nur minimal angepasst werden, damit sie mit der neuen Version kompatibel wird. Das gilt auch für die Dokumentation, die haben wir im Laufe der Zeit mit vielen Beispielen gefüllt, und es wäre doof, wenn man wieder bei 0 anfangen müsste
• Java ist als vollwertige Programmiersprache deutlich mächtiger als die meisten Skriptsprachen. Es gibt richtiges Multi-Threading (was allein für das Spiel enorm wichtig ist), richtiges I/O Handling, Netzwerkfunktionalitäten, und wenn man es wirklich Ernst meint auch die Möglichkeit, Java mit C++ bzw. nativen Libraries zu koppeln und mit ihnen zu kommunizieren

Über Java ist es grundsätzlich aber auch möglich, Skriptsprachen einzubinden. Wir haben damals begonnen, einen Lua-Wrapper als Plugin zu schreiben (damit wir Lua endlich hätten rauswerfen können, durch den Wrapper hätten Leute aber weiterhin Lua Skripte laden und benutzen können). Wenn man das benutzt fallen die Geschwindigkeitsvorteile natürlich wieder weg (denn die Skriptsprache wäre dann wieder der Flaschenhals), aber der Vorteil von Skriptsprachen ist natürlich, dass diese einfach zu bedienen sind

Thanks Celtic Hummingbird

Quote from Celtic Hummingbird

On the water textures. Can you use the ones in the java version?

Well, basically water in RW isn't just a texture, instead it's a result of multiple render passes (to achieve the final look, including depth-based transparency, refractions, reflections etc) We'll probably take a similar approach for the Unity version, but rendering works totally different there. In addition to that, shaders use a different language in Unity (HLSL [the DirectX shader language] instead of GLSL [the OpenGL shader language]), so we have to rewrite them from scratch anyway^^

I have no idea why these methods were never added to the Java version I'll put it on our to-do list

Objekte werden fast ausnahmslos tatsächlich durch ein einzelnes Item repräsentiert (das "objectkit") und haben daher immer dieselbe TypID. Die eigentliche Objekt-ID ist hingegen im "ItemAttribute" hinterlegt. Das "Item.Attribute" ist abstrakt, davon gibt es aber die Ableitungen "Item.ObjectAttribute" (für Objekte), "Item.ClothingAttribute" (für Kleidungsstücke) und "Item.CustomItemAttribute" (für CustomItems).

In deinem Fall suchst du das "Item.ObjectAttribute", worüber dann die Methode getObjectID() zugänglich ist (die die Objekt-ID zurückgibt). Also:

Item.Attribute attr = item.getAttribute();
if(attr instanceof Item.ObjectAttribute){
    Item.ObjectAttribute obj = (Item.ObjectAttribute) attribute;
    
    //Dies ist deine gesuchte Objekt-ID
    short objectTypeID = obj.getObjectID();
    
    //Die Objekt-Variation ist in der Item-Textur gespeichert (standardmäßig 0)
    int objectVariation = item.getVariation();
}

Die Objekt-ID könntest du nun zB mit der ID aus einer ObjectDefinition vergleichen um herauszufinden, um welches Objekt es sich genau handelt

Quote from Deirdre

I'm not really used in model using, but is there a way to pretent i. E. To show false models at start up?"otherwise the game could fail

This wouldn't necessarily help regarding the issue raised by the OP (depending on what's considered a "false model"), but irrespective of that, I agree that it would be helpful if the game could at least detect "broken" models. However, this is only possible to a certain degree - the game (or more specifically the server, where the plugin is actually executed) could only check a few basic things. Not sure what's happening right now if a broken model is loaded, does the game actually crash? IIRC there should be just an error message in the console