Posts by red51

A small new update is available now!

    Hey folks! We wish you a Merry Christmas and a Happy New Year! We hope you enjoy the holidays and have a great time! :)


    We would like to take the opportunity to give you a small status update of the new version. Right in time for Christmas we have a new screenshot for you:


    xmas.jpg


    The log cabin and fireplace were built with construction elements. As you can certainly see, lighting and shadows will improve considerably with the new version. In addition to that, we will use more detailed models (for the furniture, for example) and higher resolution textures.


    Apart from that, we decided to stick to FMOD as audio engine. We've implemented a voice chat recently, with the ability to post-process the voice data (e.g. when the player uses a megaphone or walkie-talkie).


    Unfortunately there will be no playable demo this year, because it's still too unfinished. However, we'll try to get a playable demo ready in early 2020.


    As always, if you want to get more information about the development progress, you can check out our roadmap on Trello: https://trello.com/b/t5Leypcj/rising-world-development


    Stay tuned for a thrilling year 2020!

    Hey Leute! Wir wünschen euch frohe Weihnachten und einen guten Rutsch ins neue Jahr! Wir hoffen, dass ihr die Feiertage genießt und eine tolle Zeit habt! :)


    Wir möchten die Gelegenheit nutzen, euch ein kleines Statusupdate zur neuen Version zu geben. Passend zu Weinachten haben wir einen neuen Screenshot für euch:


    xmas.jpg


    Die Blockhütte und Kamin wurden mit normalen Bauelementen gebaut. Wie man sicherlich sehen kann, werden sich mit der neuen Version vor allem die Beleuchtung und Schatten spürbar verbessern. Zusätzlich dazu werden wir detailreichere Modelle (zB für Möbel) und höher auflösende Texturen verwenden.


    Abgesehen davon haben wir uns entschlossen, weiterhin FMOD als Audio-Engine zu verwenden. Wir haben vor kurzem einen Voice-Chat implementiert, mit der Möglichkeit, die Voice-Daten nachträglich zu verändern (zB wenn der Spieler ein Megafon oder Funkgerät benutzt).


    Leider wird es dieses Jahr keine spielbare Demo mehr geben, da die Version noch zu unfertig ist. Wir versuchen aber, Anfang 2020 eine spielbare Demo vorzubereiten.


    Wie immer könnt ihr die aktuelle Entwicklung natürlich auf unserer Trello-Roadmap verfolgen: https://trello.com/b/t5Leypcj/rising-world-development


    Freut euch auf ein spannendes Jahr 2020!

    I have died twice because at the edge, while mounted, I do not get stopped like I do when running on my own

    Hmm... that's strange 8| Basically you should still get stopped when reaching the world border while sitting on a mount... do you always fall through the ground in that case? Does it happen at certain locations only (e.g. only in caves or other underground areas, or while walking on constructions like bridges etc)?

    The batch script first checks if the server_memory value is set in the server.properties file. Only if the memory variable isn't set, it will be set to 3072 mb in your case. However, usually the server_memory field does exist in the server.properties file (by default it's set to 2048 mb), so I'd recommend to change the memory value there as well ;)


    However, in your case it looks like there is only a 32 bit JRE installed on your server. Unless you're running a 32 bit OS, you can find the latest 64 bit version of Java here (download "Windows Offline (64-bit)"): https://www.java.com/en/download/manual.jsp

    I entered the values server_query_ip=0\0.0.0.0\my real IP as server_ip

    The best thing is to keep the default value 0, alternatively just remove that line completely from the server.properties file (it will be recreated with the default value then). However, the message Невозможно назначить запрошенный адрес does not seem to be related to the query_ip, instead it indicates that the actual server could not bind to the server_ip. This either happens if the port + ip is already in use, or if the entered ip is wrong (or alternatively if the server cannot "see" the public ip). In this case you can keep the field blank, then the server binds to all addresses.


    If the issue persists after setting server_query_ip back to 0 and changing the server_ip field to your public ip (212.33.x.x), or alternativey leaving it blank, please post a full server log here (the latest one from the "logs" subfolder) ;)

    Leider gibt es keinen Befehl, der direkt Chunk-Koordinaten akzeptiert. Du müsstest die tatsächlichen Koordinaten also ausrechnen (und die Werte dann mit dem goto Befehl benutzen). In der Java Version hat ein Chunk die Größe 16 x 64 x 16 (XYZ). Falls die Höhe des Chunks (Y) keine Rolle spielt, könntest du dich auf die X und Z Koordinate konzentrieren. Wenn du dich bspw. zum Chunk mit den Koordinaten X=2 und Z=-50 teleportieren willst, wären die tatsächlichen Koordinaten X = 2 * 16 = 32 und Z = -50 * 16 = -800, also könntest du goto 32 -800 in die Konsole eingeben ;)


    Wenn du F3 drückst, siehst du übrigens neben deiner tatsächlichen Position auch die Koordinaten des Chunks, in welchem du dich gerade befindest (in der 1. Zeile)

    Was mich noch interessiert: Werden die Stapelgrößen höher als bisher (100) anpaßbar sein? Auf 1000 oder so? Meinetwegen auch auf ne Million?

    Gute Frage... es kommt darauf an, wie sehr man bereit ist, "Mehrdaten" in Kauf zu nehmen ^^ Ich denke am sinnvollsten wäre es, wenn wir Stapelgrößen als 16 bit Werte speichern, dann wäre die theoretische Maximalgröße 65K. Aus spielerischer Sicht machen größere Werte vmtl. nicht viel Sinn (dann kann man auch gleich unendlich große Stacks aktivieren^^), und auch vom Speicherbedarf her ist das wohl noch der beste Kompromiss.


    Dieser Maximalwert wird dann aber vmtl. nur über die API einstellbar sein. Standardmäßig werden die Stapelgrößen wohl eher so wie jetzt ausfallen (vll etwas angehoben). Wenn es ingame eine Einstellmöglichkeit gibt, würden vll Grenzen wie 100, 500 oder höchstens 1000 sinnvoll sein.


    Vll ist es aber auch wesentlich sinnvoller, wenn wir uns in dieser Sache noch ein wenig in der Community umhören :D


    Wenn die Welt errechnet werden muss, kann das Spiel ein Benchmark für kommende Grafikkarten/ PCs sein. So könnte man festlegen, bis zu welchen Detailgrad und welcher Tiefe des Wassers bei welcher Auflösung des Monitors die Benchmark-Welt wie als Film durchquert werden muss.

    Das ist an sich keine schlechte Idee, aber leider nicht ganz trivial :whistling: Insgesamt hätte dieser Benchmark nur Aussagekraft für Rising World (da die Gesamtperformance ja von sehr vielen Faktoren abhängt - und Rising World natürlich andere Anforderungen an die Hardware stellt als andere Spiele [so spielt bei RW bspw. die CPU, RAM und Festplatte eine wesentlich größere Rolle als in vielen anderen Spielen]). Es wäre denkbar, eine Art kurzen Benchmark anzubieten, um automatisch die sinnvollsten Grafikeinstellungen zu wählen, da müssten wir mal schauen (wobei diese Art von Benchmarks, die es ja durchaus in manchen Spielen gibt, immer mit Vorsicht zu genießen sind).


    Wollten wir hingegen eher allgemeine Benchmarkergebnisse ermitteln (die allgemeine Gültigkeit hätten), wäre das nochmal eine ganz eigenständiges umfangreiches Thema. Bevor wir hier aber viele Monate reinstecken, würde ich lieber auf die vielen bereits existierenden Benchmarks verweisen :saint:

    Hey, sorry for the late response, I missed your post unfortunately :( However, please set the values as described in my previous post. It's important to set server_query_ip either to 0 (default setting), or your server ip (the public ip, i.e. 212.33.x.x), that should do the trick

    Hey :) Well, we're still not 100% certain, but this is our plan: We will very likely stick to Java when it comes to the Plugin API. Compared to other languages, this is probably the best choice (it's pretty fast, runs in a separate environment [so it doesn't interfere with the game], and has an excellent garbage collector [so much better compared to the Unity GC]). The game (and server) will be shipped with a custom JVM, so there will be no need for the user to install Java in order to run plugins. Maybe we will also add support for JavaScript in the long run, still not sure about that...


    We've already integrated a JVM in our project, and communication between the game and Java works very well (and pretty fast).


    Using Java also means large parts of the current API remain compatible (although there will be some rather small changes). However, unfortunately I can't say much about the UI yet :S Unity is currently working on a new UI API, and we're thinking about migrating to it - unfortunately it's still in preview, and I'm not sure if this new UI will be ready in time. Both UIs work quite different compared to our UI (in the Java version of RW), especially when it comes to coordinates and pivots. Their new UI would be similar to CSS flex (there are no actual pivots and no relative coordinates like in our current UI)...

    :D:D "DONTation links" lol :P What a pity, I would definitely spend some money, too ;) Unfortunately I don't have so many friends or family members to buy the game for them ... So if you ever change the "DONTation link" to a "DO donate link", please let us know ^^:thumbsup:

    Oh, lol, thanks for letting me know :D Fixed that typo now^^ And, of course, thanks a lot for your support! :thumbup:

    F4 enables the default mode (you you can access your inventory and use your items), F5 enables the terrain tools (change them by pressing 1-5, and change the materials with your mouse wheel), F6 activates the placement mode (press 1 for vegetation placement and 2 for block placement, then press i to select a plant or block texture), and F7 enables the removal tool (press 1 for vegetation removal, 2 for objects, 3 for construction, 4 for block removal, 5 to remove everything).



    If you don't see the creative mode toolbar, just go to the settings -> miscellaneous -> scroll down to the "Creative mode settings" and tick the "Show Toolbar" box :)

    I'm sorry to hear the other options didn't work =O Of course I can send you a Steam key, just send me a PM containing your username and your email (which was used to create the account), or alternatively send a mail with these information to steam@jiw-games.net :)

    Hmm... maybe try to download and install the latest Java 8 version for Mac (select "Mac OS X"): https://www.java.com/en/download/manual.jsp


    If that doesn't work, rightclick on the Rising World app and open contents -> resources -> java and open the "risingworld.jar"


    Alternatively I can also send you a Steam key so you can activate Rising World in Steam. The Mac version of RW on Steam works a little bit smoother :whistling:

    omg omg omg lol could this be a christmas present? have an experimental version for the new game?

    Hehe, well, that would be awesome, but unfortunately the playable demo isn't ready yet =/ It's still in an too early state any way too unpolished...


    is it possible to get more in depth for crafting and such? more grind in the crafting tree?

    We're definitely going to rewrite the crafting part from scratch. We want to introduce new workbenches and more dependencies (but we want to make sure that crafting doesn't become too grindy).
    However, if you have any specific suggestions about the crafting part, feel free to share them ^^


    and more block shapes

    Yes, there will be some new block shapes in the new version :) But first and foremost, all block shapes will be optionally resizeable (like current planks and beams)


    you really need to set give us your paypal link...i know that more people than just me would like to buy you a coffee or pizza while you work. you rock!

    Hehe, thanks a lot for your support! Unfortunately we don't have any donation links atm... :/


    Would be cool if we could manipulated blocks beams etc into all different shapes i.e manipulate the shape of squared blocks etc.

    This sounds interesting, unfortunately I can't say much about that yet... it's our intention to add some special tools to create curved walls, for example, but not sure about how much control we'll get when it comes to individual block shapes.


    Can we change this so invincible skeletons do not die? The reason being is we had several customized/locked skeleton NPCs that disappear after the 30hr mark (grim reaper, gatekeepers etc).

    Oh, I see. I will add this with the next update, however, unfortunately we have no ETA for the next update... nevertheless, in the meantime, I've created a small plugin which does exactly what you want (prevent invincible npcs from dying due to old age). It's a really lightweight plugin and has no impact on performance (it's only getting active if an npc is about to die). Just extract it into the "plugins" folder of the server and it should do the trick ;) I've also attached the source code here:


    Files

    • OldAge.zip

      (1.55 kB, downloaded 696 times, last: )

    Unfortunately it's not possible to change the furnace speeds, or more precisely, different furnace speeds/efficiencies are not implemented yet (that's why the speed value in the database is currently ignored)... however, you can change the fuel consumption. To check out if everything works properly, you could try to set fuelconsumption to a pretty high value (e.g. 1000), that should make a noticeable different (but be aware that the fuel level for active furnaces is only updated every 5-10 seconds).


    Changes to the database file affect every local world by the way (as long as the definitions.db has been replaced in the commons.jar while the game wasn't running) ;)

    Unfortunately the efficiency and speed values are not implemented yet, so every furnace has the same "efficiency" and "speed" right now. However, reducing the fuelconsumption to 1 should have an impact.


    If you make changes to the db file, there is no need to create a new world - the changes should become active in every singleplayer world. Just make sure to pack the definitions.db file into the commons.jar again (while the game isn't running) :)


    But this isn't really related to the Lua API (it's not possible to modify any definitions with the Lua API), so I think it's better to stick to the other topic ^^

    Basically there is no need to change the server_query_ip, so it's recommended to keep the default value 0. Alternatively you can set it to the same value as your server_ip (your public ip, i.e. 212.33.x.x).
    Never use your local IP (192.168.x.x) anywhere in the server properties, unless you want to play via LAN only ;)