Posts by red51

    Thank you for replying so quickly :thumbup:

    I forgot to mention I have a Asus router and my ports are set to 4254 TCP and 4255:4259 Both (TCP UDP) is that correct.:thinking:

    If you're using the default server port (4255), you have to forward ports 4254, 4255, 4256, 4257, 4258 and 4259 TCP and UDP in your router ;)

    On this website you can check if port forwarding was successful (make sure the server is running when checking the status of the individual ports): https://www.yougetsignal.com/tools/open-ports/

    Yep, I'm just trying to figure out exactly how far I can take my plugin rebuild before the new API release. If it's just a matter of tweaking some ID numbers I should be safe to crack on.

    Yeah, the spawnNpc() methods and the Npc class will mostly stay identical :)


    I agree that having a way to add custom ores would be great 8):thumbup:


    We still need some sort of pipeline to load custom elements (like custom plants, animals, items, but also things like ores maybe). We need to think about a proper abstraction for this... unfortunately I can't say much about that at this stage :silenced:

    Thanks a lot for sharing your findings! :):thumbup::thumbup:


    If you will travel far above world you will see that the world looks like a planet with blue atmosphere with galaxies and stars around in the sky

    Hehe, I'm surprised that barely anyone has found the orbit yet :lol: The orbit is a specific location (similar to hell). Atmosphere slowly fades away at Y 4000, and at Y 5000, you're entirely in orbit. This also has an effect on ambience sounds and gravity (it is a lot lower there - this is noticable when throwing items away).


    However, this area is still work-in-progress - that's why the planet looks a bit dull there. This will definitely change in the future :D Maybe we will also enable people to build there, but that's a low priority feature right now ^^


    Since when you can leave the planet =O 8|

    Basically this is possible since the original demo release :D But unfortunately there isn't much to do there yet :saint:

    First of all the error... from rw_server.exe - System Error. The code execution cannot proceed because MSVCR120.dll was not found.

    If you want to run the server from the exe, you need to install MS VCRedist 2013. Basically the exe is just there if someone wants to launch the server through the Steam client. Otherwise it's recommendable to to run the server through the "win_startscript.bat" instead (there is usually no need to install VCRedist in this case) ;)


    The thing I don't understand is this part ./steamcmd.sh

    This is basically just relevant on Linux (I've updated the post to clarify that a bit) ^^


    On Windows, you can just run the "steamcmd.exe", then login via login anonymous (or use your Steam account credentials) and download the Java server via app_update 339010 validate. Once you're ready, you can log off via quit.


    in the Command Prompt window it responds back with, force_install_dir must be entered before you login.

    Hmm... that seems to be a new requirement :thinking: Apparently Steam has changed that a few months ago... thanks for bringing this to my attention!


    It's just a warning, however, so changing the install dir after login still works. And as mentioned, the "force_install_dir" command is merely optional (only relevant if you want to install the server to a different location), so there is no need to use it ^^

    While peaking through the config files I've noticed this


    input_vehicle_changeseat=KEY_X

    input_vehicle_engine=KEY_I

    input_vehicle_geardown=KEY_Q

    input_vehicle_gearup=KEY_E

    Oh, it looks like you're accidentally using the wrong config file - the one from the Java version :saint: Please make sure to open the config.properties file from the "_New version" subfolder :D I know it's a bit confusing currently while both


    In the Java version, the vehicle-keys were mainly used for the RIB btw... The vehicle-related keys are also present in the new version, but they're still unused there (because we neither have vehicles nor boats yet).


    It may be a little funky to control vehicles. I even shared it with a potential modder/modeler, they found it funky

    Can you elaborate on that? :wat: Do you refer to the RIB in the Java version? ^^ Or do you mean the default bindings for vehicles are a bit problematic in general?

    Das wird tatsächlich möglich sein, wie yahwho schon sagt: Das Spiel sammelt bereits diverse Statistiken über den Spieler, darunter zB auch die Strecke, die ein Spieler zu Fuß zurückgelegt hat, oder per Fahrzeug, oder im Flugmodus usw.

    Einen Gesamtwert gibt es zwar leider noch nicht (fügen wir aber vll noch hinzu), d.h. man müsste die einzelnen Distanzen zusammenrechnen (also gelaufene Distanz + geschwommene Distanz + geflogene Distanz etc), das ist aber problemlos möglich ;)


    Die Player-Klasse wird dafür in der neuen API eine getStatistic() Funktion erhalten, die einen int Wert zurückgibt (bei der Strecke ist das immer die Anzahl an Blöcken, die der Spieler bisher zurückgelegt hat).

    Hehe, it's indeed our intention to add hang gliders to the game :saint: We will probably start working on that some time after the world generation update. I'm also curious about how well it will work with the physics engine, but it's already promising - I'm sure it will be a lot of fun :D


    In general, it would be nice to have more flexible ways of movement. Considering mountains can be a lot higher in the new version compared to the Java version (up to 4 times higher), it would be a good idea to put a bigger focus on such ways of movement. That would also include other things like hot air balloons, grappling hooks etc.


    Btw, I'm not aversed to a fantasy-approach either - e.g. some sort of wings that could be found in dungeons (which would basically just act as a "fancy glider", but a bit more flexible). This may be something that could make looting more rewarding.

    But this is something we definitely need more feedback about... maybe we'll do a survey once the new version is a bit more fleshed out ^^

    Q.1. Hostile humanoid NPCs. Is the aim to bring back hostile humanoid NPCs in the same form as the existing ones? By this I mean the variants that are currently used. (E.g. Bandit with bow, skeleton with armour). I guess what I am getting at here is, are they going to be an exact replica (from an API point of view) or are they going to change?

    Well, that's a good question :D Do you mostly refer to the API calls which take the variant id (e.g. "spawnNpc()")? Variants will probably be mostly the same (but I can't say for sure, it depends on the actual items and clothes we're going to add to the game), but maybe NPCs will get new type IDs (which are also relevant when using the "spawnNpc()" API-method)...


    Q.2. Ore. Are the ores going to stay the same, or are there going to be more variants / removal of certain ores (E.g. no longer any mithril reintroduction of cobalt?).

    We only want to introduce ores which will actually be useful for the player, or more precisely, we only want to add ores that are required for crafting ^^ Otherwise it's can be a bit frustrating for players if they find a new ore, but there is nothing they can do with it.


    Once we have some proper items that can be made out of cobalt or mithril, we would actually reintroduce these ores :)


    Q.3. Diamonds. I'm sure(?) I have read somewhere that you intend to add diamonds to the game. Is this going to be added as an additional ore (from an API call point of view). And if so, are you planning on adding any others and will these be released with the world generation update that includes other ores? Or, is this a long term objective and won't be implemented yet.

    Yes, we have plans for gems and diamonds. They will be added as separate items, so they're not part of the terrain (and therefore they won't be considered ore). But this won't be part of the world generation update unfortunately, so it's rather a long term objective :saint:


    Q4. Final question, will weather still remain global, or will localised weather be possible?

    Probably there won't be local weather for the time being :( Biomes will have an impact on the global weather though (similar to how it worked in the Java version), e.g. rain will turn into snow in cold biomes and will be absent in deserts.

    Hi, one more question about world generation before you close this thread, there will be possibility to use height maps to generate terrain in the future?

    Yes, a custom world type is planned where you can provide your own heightmap - but unfortunately we have no ETA for that yet (it won't be part of the initial world gen update) :hushed:


    We also have plans for the plugin API to take control over world generation btw ;)

    Das System ist leider nicht unbedingt selbsterklärend.

    Naja, es gibt durchaus einige Spiele, die das so machen :saint: Wir könnten aber zusätzlich noch ein "Als Favorit markieren" zum Kontextmenü hinzufügen (also beim Rechtsklick auf den Eintrag), ist aber auch irgendwo etwas doppelt gemoppelt ^^


    Ich habe Höhenunterschiede im Terrain. Ich habe nichts geändert, dieser Höhenunterschied ist auch mit dem Tool nicht erreichbar.

    Ohne die weißen Streifen wäre mir das Ganze überhaupt nicht aufgefallen.

    PresenceRusher hat Recht, der Bereich wird nicht richtig gerendert bzw. die Chunks dort können nicht generiert werden - dort sind nur die "LOD Chunks" geladen (erkennbar daran, dass die Gravel-Textur eine etwas andere Skalierung hat). Die sind standardmäßig etwas tiefer als die normalen Chunks (aus diversen Gründen), meist fällt das aber nicht auf, da die i.d.R. weiter weg sind.

    Vmtl. befinden sich in den Chunks irgendwelche Sachen, die fehlerhaft sind (wodurch die Generierung fehlschlägt). Hast du dort schonmal Bauteile platziert und ggf. mit dem "edit" Befehl geändert?


    Ansonsten könnte aber ein Report hilfreich sein: Lade am besten zunächst die Welt, begib dich zu diesen fehlerhaften Chunks und sende anschließend den Report :)

    Again, a good place to see examples are Skyrim (For walking with 'V' key), Mount & Blade: warband (For horse), Kingdoms (For horse), and others. I'll list them as I recall them again, if it's a big issue or not.

    Actually the new version has an "AutoRun" feature, but it's not fully ready yet. It needs to be set up manually and unfortuantely the player does not sprint automatically (so he just moves with his regular movement speed). To use the "AutoRun" feature, just open the "config.properties" file in the game directory with a text editor and bind "Input_AutoRun" to the desired key (e.g. "key_v" if you want to bind it to V), then save the file and run the game. If you press V now, the player will start moving automatically.


    But as mentioned, this feature definitely needs more fine tuning :D Once it's fully ready, it will be exposed to the ingame settings menu ;)

    As mentioned by Desmagu , we're currently working on the world generation update :)


    Hopefully!! :D And I'm just wondering if water in some sort of form will also be included? as some of the elements have been included recently in the roadmap, but maybe it's still too early for that as well:?:

    Water will be indeed part of the world gen update ;) But probably we will split the world gen update into two smaller updates. In this case, water will be part of the 2nd one.

    red51 klar verstehe ich was du meinst. Und wenn das Menü "Bauformen" heisst, dann würde das wirklich nicht passen. Das Menü heisst aber nicht "Bauformen", sondern "Bauen" - und da gehören Fenster (und genau genommen Türen) dazu.

    Vom Namen her stimmt das schon, aber die "Bauen" Kategorie ist nunmal ganz anders aufgebaut (nämlich erst die Texturauswahl, dann die Form-Auswahl - was fürs Bauen ja auch meist sinnvoll ist), daher finden Fenster und Türen dort leider keinen Platz. Da Kategorie müsste eigentlich "Bauformen" heißen, aber "Bauen" ist ein schönerer und zugänglicherer Begriff ^^


    Weder Türen noch Fenster lassen sich in die "Bauen" Kategorie einbinden, ohne, dass es lieblos reingeklatscht aussehen würde. Was wie aber schon gesagt denkbar wäre ist eine eigene Kategorie "Türen & Fenster", um die beiden aus "Einrichtung" herauszuziehen.


    Und ob es ressourcenschonender ist lieber alle (!!) Fensterformen auch als Bauteil verfügbar zu machen, anstatt einfach die Fenster ins Bau-Menü aufzunehmen kannst wohl nur du als Entwickler sagen :)

    Von den Resourcen her spielt die Anzahl an Bauformen, die es im Spiel gibt, keine Rolle. Ich würde aber nicht alle Fenster nochmal zusätzlich als Bauform einbauen (das wäre doppelt gemoppelt und erst recht nicht stringent), sondern lediglich nochmal einen hohlen Block (als Gegenstück zum normalen Fensterrahmen). Und natürlich nur ohne Sprossen (sonst haben wir ja wieder einen normalen Fensterrahmen) ;)


    Wobei ich gerade deinen Hinweis auf die Gehrung der Fenster interessant finde. Ich benutze die wirklich öfter und mir gefällt es dass sie sich abheben von anderen Bauteilen. Also gerade diese andere Texturausrichtung. Das wäre bei der Blockform ja nicht so?

    Die Bauform hätte leider diese Gehrung nicht :/ Das wäre sonst schwierig i.V.m. manchen Texturen umsetzbar (wie gesagt, beim Fensterrahmen ist das bei diversen Texturen bereits sichtbar - da diese Texturen aber nicht direkt vom Spiel im Crafting-Menü für Fenster angeboten werden, sehe ich darin kein so großes Problem).


    Diskutieren wir hier eher um Feintuning, das auch später noch eingebaut werden könnte? Verzetteln wir uns und zwangsläufig auch Red hier etwas mit dem "zanken"? Verlieren wir bereits den Blick fürs Große und Ganze?

    Das ist ein guter und wichtiger Punkt: Egal wie wir uns jetzt entscheiden, es ist ja nichts in Stein gemeißelt. Wenn sich später herausstellt, dass irgendwas doch nicht so gut ist, dann kann es natürlich jederzeit nochmal geändert werden. Und sofern es keine fundamentale Änderung ist, ist sowas auch meist schnell gemacht :)

    red51 Ich verstehe den Sinn eines hohlen Blockes nicht ganz. Was ist der Vorteil gegenüber einem Fensterrahmen? Ich kann mir den hohlen Block gut als Zwischenstück für eine Säule vorstellen, anstatt wie früher entweder 4 Teile um eine quadratische Säule zu legen, oder mehere Rahmen übereinander zu platzieren. Das müsste mit Size aber auch funktionieren, oder ist der hohle Block für die Spieler gedacht, die es einfach ohne Commands haben wollen?

    Ein hohler Block wäre wie ein Fensterrahmen ohne Sprossen, nur dass er sich nicht wie ein Fensterrahmen verhält (Glas reagiert nicht darauf, er bietet alle Texturen und wäre frei skalierbar). Und er hätte standardmäßig eine Größe von 1x1x1 (nicht wie Fensterrahmen, die eine Standardgröße von 2x2x0.2 haben). Quasi wie der hohle Zylinder, nur eben in eckig statt rund ^^


    Wenn Lehm sich dermaßen anders verhält, bedeutet das wohl, dass es nicht auf die Schärfe der Textur wie in der Java-Version ankommt, sondern jede Kategorie anders auszusehen hat?

    Lehm verhält sich nicht anders, aber diverse Texturen (zB Dachziegel oder die Metalltextur 765) haben allgemein eine andere Ausrichtung (das gilt für alle Blockarten). Fensterrahmen sind aber ein Spezialfall, da der Rahmen bewusst so aussieht, als seien die Ecken auf Gehrung geschnitten - das funktioniert nicht so gut i.V.m. manchen Texturen.


    Auf Lehm trifft das aber wie gesagt nicht zu. Ich reite nur die ganze Zeit auf den Lehmtexturen herum, weil das eben welche sind, die meiner Meinung nach nicht zu Fensterrahmen passen (von der Logik her).