Posts by red51

Basically the CIMG format is just a PNG image with some additional data (e.g. information about the uploader, original image name and dimensions etc).

The first two bytes contain the "image version" (just ignore this), and the next four bytes contain the actual data length (number of bytes). When writing a plugin, you could use this code to turn a CIMG-File into a PNG byte[] (using the API Utils class):

//Your CIMG file
File cimg = new File(path-to-cimg-file);


//Read the file bytes
byte[] bytes = Utils.FileUtils.readBytesFromFile(cimg);


//Wrap bytes
ByteBuffer buffer = ByteBuffer.wrap(bytes);


//First two bytes determine img version (ignore this)
short imageVersion = buffer.getShort();


//Next four bytes describe data length
int len = buffer.getInt();


//Read PNG data
byte[] pngData = new byte[len];
buffer.get(pngData);

The next update will contain a method to convert a (png) byte array into a buffered image and vice versa. But it's fairly simple to convert a byte[] into a buffered image (using the javax ImageIO class). This code turns our "pngData" byte[] into a buffered image:

try(ByteArrayInputStream bis = new ByteArrayInputStream(pngData)){
    BufferedImage bufferedImage = ImageIO.read(bis);
}
catch(IOException e){
    //error occurred
}

This is unfortunately a bug: if an item which uses a certain attribute was added to the inventory, the attribute was only stored serverside and not properly synced with the client. As a result, the client received a "broken" item, but as soon as the inventory was re-synced with the server (which happens in certain situations, e.g. if the client or server detect the desync, or if the player reconnects to the server), the item was fixed.

This annoying bug will be fixed with the next update

Unfortunately it's a little bit tricky to create texture packs. It's important to use the same format as the original texture. This old topic contains some more information about the required file format: Important notice about Texturepacks
It would be easier if the game was able to convert any image format into the particular target format, but we were unable to add this feature in the past due to patent issues. AFAIK the patent in question expired in the meantime, so maybe we could rework the whole "texture pack creation" process to provide a more "straightforward" approach

About the blueprints: when a blueprint is stored, the game does not store the actual textures, instead it stores the underlying block ID. For example, ID 182 is a metal texture. If you're now using a texture pack which replaces ID 182 by a wood texture, and you're creating a blueprint containing this texture (ID 182), another player (who isn't using your texture pack) would just see the original metal texture instead when placing the blueprint.

I've moved this topic btw.^^

Hmm... when placing the beams, did you use the modular placement (i.e. the snapping feature [return key])? You said the beams showed up eventually after minimizing the game, does this mean the beams showed up without having to reload the world (or restarting the game)?
Is the bug still reproducible (maybe even at this particular location)?

Renting a game server is definitely an easy solution, but of course there is no need to do that (since you already have a VPS). Just use screen as mentioned in my previous post, or alternatively check out the solution posted by @Devidian, this will solve the issue

Just to avoid any misunderstandings, this isn't an official RW page. Actually we don't have an official RW facebook page, instead we're just using our main facebook page

This sounds like you're not running the RW server on your local machine, right? In this case you have to keep the server running of course (i.e. your dedicated server which runs the RW server), but there is no need to keep your PC online. You can use screen to detach the server process and keep it running in the background. If screen is installed on your server, you can just run the linux_screen.sh script

Quote from Bogus

Ja die Dockleiste verschwindet ja jetzt, aber das Problem ist die toolbar unten, die halt nicht ganz angezeigt wird.

Achso, oh sorry das habe ich gar nicht so richtig wahrgenommen Ist das denn erst durch die neue Grafikkarte passiert?
Ggf. kann das weiterhelfen: https://askubuntu.com/a/125582

Quote from lenko

Also ich bin mir jetzt etwas unsicher, einerseits möchte ich ja auch bauen und wenn ich jetzt meinen Weg mit Pflasterseinen einfach malen kann würde ich das wohl nicht so toll finden

Naja, zumindest so manche altertümliche Pfade lassen sich mit dem Bausystem teilweise nur schwer umsetzen - besonders wenn es bspw. eher in die Richtung geht, dass es ein einfacher, kurviger Pfad durch den Wald sein soll. Also wenn ich zB an sowas denke:
https://c8.alamy.com/comp/D3NA…mi-cobblestone-D3NA86.jpg
Oder gar an sowas: https://i.pinimg.com/736x/bb/f…amera-slr-tree-swings.jpg

Hier hätte eine passende Terrain-Textur zumindest durchaus eine Daseinsberechtigung. Ob es hingegen wirklich sinnvoll ist, sie reinzubringen, ist eine andere Frage...

Quote from lenko

Anders schaut das schon aus, wenn wir über andere Texturen, sagen wir mal einen Mix aus dem was da ist hätten um einen Weg oder Straße im Mittelalter oder Altertum zu malen

Wie meinst du das genau?

Quote from lenko

Insgesamt ist unsere Natur ja recht schön ABER viel zu sauber. Also ich meine damit das ja nichts rumliegt, keine Äste oder Blätter bezw Steine

Das ist leider wahr, aber das könnte über Texturen nur schwer gelöst werden... zumal größere Objekte (zB Äste) als Textur nicht gut aussehen würden, hier wären 3D Modelle sinnvoller. Tatsächlich ist das aber auf unserer ToDo-Liste, also dass generell vereinzelt Steine und Felsen sowie Äste in der Natur spawnen. Das würde nicht nur die Optik verbessern, sondern auch andere Spielelemente (man müsste nicht mehr mit einem Startwerkzeug spawnen, sondern könnte dieses durch das Sammeln von Ästen und Steinen erst craften usw)

Quote from Smoka

Also, dass eine neue Welt nur mit dem Stadard texturen erstellt wird und man hat dann die möglichkeit belibige texturen hinzuzufügen und zu verwenden. wie z.b. pflasterstein oder ein waldweg
Das denn genau so für Block Texturen.
Sozu sagen, es gibt Leere Slots für texturen, die erst nutzbar sind, wenn man eine textur auf den slot zugeordnet hat.

Das ist tatsächlich ein schwieriges Thema, auch wenn diese Lösung an sich wünschenswert wäre... Natürlich ist der größte limitierende Faktor der, dass wir immer nur eine begrenzte Menge an Texturen haben können. Jede zusätzliche Textur erhöht den Arbeitsspeicherverbrauch und schmälert die Performance. Das ist bei einer einzelnen Textur zwar halb so wild, aber es gibt bestimmte Grenzen, deren Überschreitung einen besonders starken Einfluss auf die Performance hätte. Bei Terrain-Texturen haben wir das fast erreicht, bei Block-Texturen ist noch ein kleines bisschen Luft. Aber wir versuchen uns da auch ein wenig Reserve zu lassen, für den Fall, dass wir später ohnehin noch bestimmte Texturen noch hinzufügen müssen.

Wir können natürlich theoretisch ein paar Slots als Platzhalter drin lassen die man dann durch eigene Texturen ersetzt, aber viel Spielraum hat man dadurch ja leider nicht. Besonders beim Terrain, wo fast alle "Standard-Texturen" ja sowieso von Natur aus irgendwo in der Welt verwendet werden (zB Schnee, Sand, Höllengestein usw).

Man könnte natürlich die Block-Texturen reduzieren, um zumindest hier etwas Platz zu schaffen, aber der Entfall von bestehenden Texturen ist ja auch mit einigen Problemen verbunden

Quote from Deirdre

Zu den Texturen - Schnee gibt es ja bereits, wäre schön, wenn das auch auf Dächern, Wegen, Holzplanken usw. also wie Sand nutzbar wäre.

Meinst du Schnee als Block-Textur, also dass du bspw. einen Block oder eine Planke etc. mit einer Schnee-Textur spawnen kannst?

Schwierig... also eine isDirty() Funktion können wir ggf. hinzufügen. Das Problem ist, dass es prinzipiell 3 Arten von Chunks gibt (einmal ein klassischer Chunk [x, y und z Koordinate], welcher die Terrain & Block Daten enthält, dann ein LOD Chunk [nur x und z Koordinate] welcher eine grobe Repräsentation des Terrains in Form einer Höhenmap enthält, und dann noch ein spezieller Chunk [auch nur x und z], welche alle Objekte, Pflanzen usw. enthält). Nach jetzigen Stand werden die Tiere gespawnt, wenn ein solcher Chunk geladen wird (und der Chunk unberührt bzw. ist bzw. "isDirty()" false zurückgeben würde). Allerdings gibt es in der API derzeit nur einen eher abstrakten Zugriff auf die Chunks, und auf letztgenannten Chunk-Typ noch gar keinen Zugriff

Auch eine reset() Funktion packe ich mal auf unsere Liste, da aber sowas nicht vorgesehen ist (und auch derzeit kein Mechanismus vorhanden ist, dass ein Client einen Chunk komplett neu lädt), bin ich mir nicht sicher, ob sowas rechtzeitig zum Update verfügbar sein wird...

Ein NPCSpawnEvent ist aber bereits in der API vorhanden: https://javadoc.rising-world.n…ts/npc/NpcSpawnEvent.html
Damit können jetzt schon die Spawns geändert bzw. festgelegt werden, was spawnen darf und was nicht

Quote from lenko

Wie schaut es eigendlich mit Ordner für die Bilder aus

Du kannst die Bilder durchaus in einem Unterordner im Serververzeichnis platzieren und dann einfach den Pfad so in der journal.xml angeben. Also zB: <image name="journal/images/ts3-icon.png" width="256" height="256" page="right" posx="0.5" posy="0.5" pivot="center"/> (wenn die Bilder in einem Unterordner "images" in einem Ordner "journal" im Serververzeichnis liegen würden).

Ich sehe aber gerade ganz nebenbei, dass offenbar der "pivot" nicht stimmt wenn man "center" angibt... das ist offenbar passiert, als die neuen Pivot-Positionen vor einiger Zeit in der API hinzukamen Das wird mit dem nächsten Update behoben, ich wollte dich nur vorwarnen, dass wenn du momentan als Pivot "center" verwendest, sich die Position des Elements mit dem nächsten Update etwas verschieben wird...

Es ist wichtig, dass das <image> Element nicht innerhalb eines anderen Textes (oder anderen Bildes o.ä) platziert ist. In dem Fall müsstest du Zeile 11 und 12 austauschen, damit <image> eigenständig wird. Oder du löschst das Text-Element (Zeile 9-12), da dort ja in dem Fall eh nichts drin steht

Wie @lenko schon sagt, ich denke dass im Februar oder spätestens Anfang März das Update fertig ist

Quote from Deirdre

Aber ein Update im Jahr ist wirklich zu wenig. Dann halt mal ein paar neue Pflanzen zwischendurch. Update hochladen, Steam neustarten. Wegen mir nur irgendein Mini-Update

Es ist schade, wenn das wirklich auf ein Update reduziert wird... aber wie @SonoBionda schon sagte, es waren tatsächlich 5 Updates, welche teilweise tiefgreifende Änderungen brachten (auch wenn die Updates vll nicht jedermanns Sache waren, waren es vom Aufwand her wesentlich umfangreichere Updates als manche Updates der Vergangenheit). Eigentlich waren es sogar 18 Updates, wenn man die Mini-Updates und Hotfixes dazuzählt (im Gegensatz zu anderen Entwicklern schreiben wir dafür aber i.d.R. keine neue Ankündigung, sondern ergänzen die vorherige, damit die News-Übersicht nicht komplett zugekleistert wird)

Dass das jetzige Update so lange dauert ist wirklich ärgerlich, das ist aber überwiegend durch die zerstörerischen Änderungen bei Steam im Oktober verursacht (der Ansatz, neuen Kunden tendenziell nur noch AAA Spiele und absolute Topseller zu präsentieren), wodurch unsere Verkäufe "über Nacht" stark eingebrochen sind. Unser Ziel ist es nicht, ein bestimmtes Update so schnell wie möglich zu veröffentlichen oder ein bestimmtes Feature so schnell wie möglich zu implementieren, sondern es geht uns um das Endresultat - nämlich die "finale Version" (wenn man das so bezeichnen kann) von Rising World in zumindest halbwegs absehbarer Zeit fertig zu bekommen. Die Änderungen bei Steam machen das auf dem klassischen Wege unmöglich (oder wir müssten uns irgendwie mit Nebenjobs und zusätzlichen Aufträgen irgendwie über Wasser halten, was aber die Entwicklung von RW noch viel mehr verlangsamen würde, was dann wirklich "ewiges Early Access" bedeuten würde). Und das Projekt über den Haufen werfen wäre logischerweise auch absolut inakzeptabel. Wir haben also die letzten Monate viel Zeit damit verbracht, einen "Plan B" für die Zukunft von RW auszuarbeiten und schonmal alle Weichen dafür zu stellen. Die gute Nachricht ist, dass wir eine Lösung habe, die langfristig sicherlich die absolute Mehrheit der Spieler zufriedenstellen wird. Die schlechte Nachricht ist, dass dadurch das Update zwischenzeitlich fast komplett auf der Strecke blieb, wodurch wir jetzt natürlich mit dieser langen Wartezeit konfrontiert sind...

Ein Mini-Update können wir aber leider nicht rausbringen. Einerseits wäre das taktisch unklug, denn viele Spieler wären dadurch sicherlich irritiert und würden (verständlicherweise) den Eindruck bekommen, wir hätten jetzt so viele Monate für "eine Handvoll neue Pflanzen oder Möbel" gebraucht. Andererseits ist das Spiel jetzt eher im Zustand "Baustelle" wo an vielen Stellen rumgeschraubt wird, d.h. NPCs funktionieren noch nicht so ganz usw. Es würde viel Arbeit bedeuten, hier den alten Zustand wiederherzustellen nur damit ein paar Kleinigkeiten für ein Mini-Update dazugepackt werden können

Quote from SonoBionda

An dieser Stelle würde ich gerne noch mal nachfragen, ob die Möglichkeit besteht, den kreativen Paintmodus mit mehr Texturen zu versehen (bspw. Pflasterstein)? Sowas würde mir als Miniupdate sehr große Freude bereiten

Also das Problem ist, dass das Terrain leider nur die "klassischen" Terrain-Texturen enthalten kann (also Gras, Sand, Stein, Erde etc). Die Blocktexturen können wir leider nicht auf dem Terrain darstellen... wir könnten vielleicht ein bisschen tricksen und ein oder zwei zusätzliche Terrain-Texturen hinzufügen, evtl. wäre Pflasterstein eine Überlegung wert (da sowas ja durchaus für Wege sinnvoll wäre). Allerdings muss so eine Änderung gut durchdacht sein, da wir die Textur hinterher nicht mehr so einfach entfernen können und evtl. den "Platz" für eine andere, wichtige Textur brauchen (ein neues Erz o.ä)... aber Pflasterstein wäre vll trotzdem nicht verkehrt. Vielleicht äußern sich ja noch ein paar andere Leute dazu, ob Pflasterstein hilfreich wäre oder nicht, ggf. können wirs dann ins nächste Update packen

Quote from Devidian

ich glaube wenn ich eine jar in plugins/ordner/jar.jar packe wird er im log meckern das die jar keine plugin.yml hat

Ja, das ist leider das Problem =/ Das Spiel würde denken, es handle sich um ein eigenständiges Plugin, und es wird eine Fehlermeldung geworfen (was an sich zwar kein großes Problem darstellt, aber dennoch unschön ist). Wenn sich die .jar aber in einem Unterordner befindet sollte das kein Problem mehr sein

Hmm... ich konnte das Problem leider nicht reproduzieren, da aber in den letzten Wochen einige Änderungen beim internen Handling von Modellen und Texturen vorgenommen wurde kann es sein, dass dieses Problem damit bereits automatisch behoben wurde. Falls das Problem also nach dem nächsten Update noch bestehen sollte, lass es mich bitte wissen

Quote from missvampy

I downloaded some blue prints and made a folder for them. But they won't show in the journal .please help.

Also make sure that you don't extract blueprint files after downloading them Some zip programs reconize the blueprint file as a zip archive, but extracting it destroys the blueprint. Just download the blueprint files and put them into the "Blueprints" folder (as mentioned by @Minotorious and @Lady_whynot) without opening the file.

It's unfortunately some unintended behaviour. When a player walks towards a wall, the camera near plane will be changed (to prevent the player from looking through walls). However, this greatly reduces the precision of the depth buffer, resulting in a lot of z fighting (the flickering you were experiencing)... we will fix this issue with the next update

Sorry for the late response! Unfortunately the log file you've attached to the first log does not contain the plugin error... maybe you can upload the correct server log, it will contain more information about which plugin caused this issue (and why this issue occurred)

Üblicherweise werden die Dependencies in den "lib" Ordner im Plugin-eigenen Unterordner gepackt (also tatsächlich zB "/plugins/PLUGIN/lib/externe.jar"). Du kannst bspw. auch irgendwo einen zentralen Ort für eine shared Lib festlegen (zB "/plugins/sharedLibs/externe.jar"), dafür musst du aber die Manifest Datei im Plugin selbst bearbeiten. Öffne dazu deine Plugin .jar mit einem Zip-Programm, gehe in den META-INF Ordner und öffne die "MANIFEST.MF" Datei. In der Zeile "Class-Path" wird normalerweise der Pfad zur Lib festgelegt, i.d.R. als relativer Pfad. Du kannst aber auch einen absoluten Pfad angeben, zB Class-Path: file:///C:/RisingWorld/shared/externe.jar

Absolute Pfade sind natürlich äußerst unpraktisch wenn du das Plugin ausliefern möchtest, also kannst du auch einen relativen Pfad angeben und auf ein Parent-Verzeichnis verweisen. Wenn deine Lib also zB in "/plugins/shared/lib/externe.jar" liegt, könnte der Classpath so aussehen: Class-Path: ../shared/libs/externe.jar

Da Änderungen an der Manifest-Datei aber jedesmal vorgenommen werden müsssen, wenn du das Plugin updatest, würde es sich hier anbieten, bpsw. direkt das build-Script in Netbeans (bzw. der IDE deiner Wahl) anzupassen

Mit der Grafikkarte hängt das Phänomen nicht zusammen, eher mit dem Betriebssystem... hast du denn evtl. mal die o.g. Einstellung in Ubuntu ausprobiert?