Posts by red51
Latest hotfix: 0.9 (2025-11-05)
-
-
Welches Datein-Format muss diese Musik-Datei haben oder ist das egal?
Das Spiel bzw. die API unterstützt folgende Formate: .ogg, .mp2, .mp3, .midi, .mid, .wav

Allerdings sollte darauf geachtet werden, dass die Dateigröße nicht zu enorm ist (wodurch .wav bspw. ein schlechter Kandidat ist), da immerhin alle Daten vom Server zum Client übertragen werden müssen.
-
Sorry for the inconvenience! It was a problem with our servers, or more precisely, the problem wasn't caused by our servers, it was caused by the hive. Today was a bad timing, that's the reason why it took so long until this issue was sorted out
We will rework the hive in the next weeks to make it more robust and less error-prone.Nevertheless, everything should be online again. If you still experience any issues, please let us know

Please can you let me know if my account is still valid, I would hope it is being as I paid full price for this game
Don't worry, we never suspend or ban any accounts
Even if we shutdown our servers somewhere in the future (this will not happen so quickly), the game will still run. In order to play multiplayer under these conditions, servers just need to disable hive-verification on their side.There should really be some redundancy for the user authentication, this single point failure is annoying!
We already have a HA-cluster to make sure that a single server outage never interrupts the service. But this doesn't help if either the whole data center is offline (where our servers are located), or if the actual software running on these servers cause the problem...

You can play offline and still connect to your server. But then you are an unknown player, which does not help much.
Usually the player name will be stored locally, at least if the client was able to connect to the hive in the past. But multiplayer servers reject players if there is no connection to the authentication server (this behaviour can be disabled, as mentioned, but it's not recommendable).
-
Sorry für diese Probleme, das Problem kam von unseren Servern bzw. genau genommen nicht von den Servern, sondern vom Hive. Wir suchen noch nach der Ursache. Heute war ein denkbar ungünstiger Zeitpunkt für sowas, darum hat alles etwas länger gedauert
Wir werden den Hive in den nächsten Wochen umschreiben und auf ein weniger fehleranfälliges System umstellen.Jedenfalls sollte jetzt alles wieder laufen!

-
Oh, du hast Recht, habe gar nicht bedacht dass Notepad++ Windows-only ist
Aber es ist tatsächlich sinnvoller, einfach die Standardkommentare zu entfernen (nachdem man sie einmal gelesen hat sind sie ja nicht mehr soo wichtig) 
-
Sorry für die späte Antwort! Besteht das Problem weiterhin? Grundsätzlich deutet diese Meldung darauf hin, dass die Welt nicht erstellt werden konnte. I.d.R. bedeutet das, dass entweder ein Antivirenprogramm die Welterstellung verhindert hat, oder dass keine Schreibrechte für den entsprechenden Ordner vorhanden sind.
Was für ein Antivirenprogramm verwendest du genau? Manche Antivirenprogramme (zB Comodo) führen unbekannte Software automatisch in einer Sandbox aus, d.h. das Spiel hat keine Schreibrechte. Gelegentlich kann es auch helfen, das Spiel stattdessen als Administrator auszuführen (Rechtsklick auf die exe -> Als Administrator ausführen)
-
Mir ist das auch aufgefallen. Ich wollte es erst auf meinen ISP schieben, da dieser scheinbar auch öfter mal Routing-Probleme zu unserem Hoster hat, aber wenn das Problem mit der Langsamkeit bei anderen ebenfalls auftritt, wird das eine andere Ursache haben. Wir werden mal schauen, woran das liegt

-
Sorry for my late response, too much things going on in the past days

So I propose a significant, but reasonably back compatible change in the API. For example : ...setPosition(float x, float y)...setPosition(int x, int y)...
Basically this sounds like a good idea, but I see two problems coming with this change. On the one hand, I'm afraid that this is more error prone: People might accidentally use float values instead of integers and vice versa. E.g. something like setPosition(10f, 100); would give an unintended result (apparently the user wanted to use absolute coordinates, but accidentally provided a float value). Or another example where things could get mixed up easily: setSize(100 * 0.5f, 500);
But on the other hand, the biggest issue comes from the result of the new getPositionX() and getPositionY() functions: If I use the position of an element and set it for another element, I expect the element to actually use exactly the same position. For example, this code would not work as intended:
It's just too confusing that when setting coordinates based on the getPosition() or getSize() functions are always considered as relative coordinates (unless we cast them to int explicitly).The idea behind setPosition is so that the method would return this and allow for method chaining. E.g. element.setPosition(0, 0).setSize(1f, 10) (i.e. position at pixel 0,0, and give a size of 100% width by 10 pixels).
Is chaining really necessary for GUI elements? There are actually some objects out there where chaining is quite helpful in my opinion (e.g. buffers), but I think chaining makes the readability of code (at least for something like this) worse. I don't have the impression that this code (just an example) is well-arranged and readable:
element.setPosition(0, 0, false).setSize(100, 200, false).setPivotPosition(PivotPosition.Center).setColor(0xFF0000FF).setBorderThickness(2, false).setBorderColor(0x00000000);The argument of keeping a Cartesian coordinate system (vertical axis pointing up, as it is in OpenGL) based on texture mapping is not a strong one.
Basically the main argument is that we want to stick to the OpenGL specification, which considers the vertical axis pointing up. Sticking to specifications is always recommendable in my opinion. But especially when accessing texture coordinates or when using shaders, people have to stick to the OpenGL conventions. If we decide to change the vertical axis, how can we justify that change when people still have to use regular OpenGL coordinates for all other things? For example: If I want to use post-processing effects (which are not yet implemented), the whole screen is rendered to a texture. Now I want to add a certain effect behind a GUI element (e.g. having a transparent panel, and the world behind it should use blurred or inverted colors). Right now I could just use exactly the same coordinates of the GUI element in my shader, but if we change the vertical axis, it would be necessary to flip the y value manually. This isn't intuitive and we really want to keep these things consistent

vertical axis pointing down, as it is for nearly all UI frameworks... because this is how humans read, from top to bottom
OSX also considers the bottom left corner of the screen as origin, and it looks like most CAD software also uses the bottom left screen corner as origin. Having the origin in the top left corner makes sense for texts, but a GUI usually consists of more than that, especially a GUI for a game.
For example, a checkbox component child to a panel does not have the same state on Player1 than on Player2, so why would the parent panel be updated on both players at the same time?
I agree to that, at least when it comes to elements which have a certain state (which depends on the user), e.g. GUITextFields or GUIFileBrowsers. We will think about changing that^^
A keen eye will have observed that I did not import PivotPosition, and this is because I added some constants to it, in order to facilitate positioning of some elements :
It is actually our intention to add more pivot positions. This was also suggested by @Miwarre some time ago, but this requires some changes to our internal GUI (which does not yet take these new pivot positions into account). It's on our list, I guess that change will be available in the near future

Yeah, the problem is that changing the UI component also means breaking all plugins, this is why I proposed the "uix" (or any other different namespace) name for this implementation. Much like how Java had AWT, then switched to a different framework called Swing later on.
Hmm... so you want to have two types of GUIs in the API?
I think it's definitely preferable to improve the existing GUI instead of adding another, separate GUI to the API. -
Ich empfehle dir, unbedingt einen Editor mit Syntax-Highlighting zu verwenden (zB Notepad++), dann fällt meistens relativ schnell auf, wo der Hund begraben liegt

In dem Fall hast du - wenn ich das richtig sehe - in Zeile 9 den Kommentaranfang <!-- eingefügt, allerdings wird dieser bereits in Zeile 11 wieder geschlossen (durch den Standardkommentar, der vorher schon da war). Damit bleibt der schließende </text> Block in Zeile 15 weiterhin bestehen, aber da kein öffnender <text> Knoten mehr vorhanden ist (da auskommentiert), ist der XML Syntax fehlerhaft und die Datei kann nicht gelesen werden.
Die Lösung wäre also, entweder jede Zeile einzeln auskommentieren, oder die Kommentare in Zeile 11 und 16 zu entfernen

-
It looks like this happened after one of the latest updates
This will be fixed soon (sorry @reydelreyes)^^ -
You can basically change nearly every keybinding in the game^^ The most important key bindings can be changed in the settings menu, all other keys (with a few exceptions, e.g. the ESC key) can be changed in the game config file.
I've attached two screenshots of the current keybindings that can be changed directly in the game. In your case, when using arrow keys to move, it would be necessary to change the object placement settings (see 2nd screenshot).However, if you run into any hard-coded keys which cause problems, just let us know

-
Das freut mich zu hören

-
Are some NPC related API functions planned? For example a PlayerHitNpcEvent?
Oh, actually I don't know why there is no such event
This will be added with the next update 
-
angesetzte Teile sind nicht sichtbar, weg geschlagene Teile sind immer noch da
Passiert das im Multiplayer? Dann klingt das nach einem Kommunikationsproblem zwischen Client und Server. Ansonsten kann sowas auch auftreten, wenn extrem viele Bauteile verbaut sind (bzw. normalerweise werden die Änderungen doch noch sichtbar, doch das kann - je nach Rechenleistung - etwas dauern).
jetzt habe ich noch feststellen müssen das ein gekiptes Teil, oder ein Blueprint sich nicht mehr senkrecht (Nummernp. Nr.5) stellen lässt.
Du kannst die Tastenbelegung in den Einstellungen ändern. Dazu unter Einstellungen -> Steuerung -> Platzieren -> die Belegung von "Element zurücksetzen" ändern. Standardmäßig ist das auf Backspace gesetzt, zuvor konnte man aber zusätzlich mit Numpad 5 die Rotation ebenfalls zurücksetzen. Da sich diese Zweitbelegung jedoch nur in der config.properties Datei ändern ließ, und da mehrere Leute offenbar versehentlich ihre Rotation mit Numpad 5 zurückgesetzt haben, wurde diese Belegung entfernt (du kannst aber natürlich "Element zurücksetzen" dennoch ohne Probleme auf Numpad 5 mappen)
-
Du hast Recht
Die generischen Typen einzelner Funktionen scheinen durch die Obfuscation entfernt worden zu sein (sodass server.getPlayers() bspw. nur noch eine Collection ohne Typ zurückgibt [demnach standardmäßig vom Typ "Object"], was im normalen Betrieb kein Problem ist, aber beim Kompilieren einen Fehler zurückgibt - zumindest sofern diese entsprechenden Funktionen verwendet werden, daher hatte bei meinem vorherigen Test auch alles funktioniert) 
Das wird mit dem nächsten Update behoben, danke für den Hinweis! Im Anhang findest du aber vorab schonmal eine korrigierte "plugin-api.jar", diese musst du nicht in die IDE einbinden, sondern die Datei im Spielverzeichnis austauschen. Diese findet sich im Rising World Verzeichnis (steam/steamapps/common/RisingWorld) unter "data/jiw". Danach sollte das Kompilieren aus dem Spiel heraus wieder anstandslos funktionieren (fertig kompilierte Plugins funktionieren aber auch so)

-
Das sollte eigentlich weiterhin funktionieren, ich habe es gerade sicherheitshalber nochmal getestet

Hat sich evtl. der Pfad zum JDK verändert? Normalerweise dürfte das Spiel dazu entsprechende Informationen ausgeben, poste am besten einmal den Log hier (falls du im Singleplayer testest, stelle game_debug_console in der config.properties Datei auf true, starte das Spiel und lade eine Welt, anschließend entweder den Inhalt der Debugkonsole kopieren und hier posten, oder alternativ den letzten Log aus dem "Logs" Unterordner im Spielverzeichnis)

-
The point is, while it may make sense for 3D coordinates, 2D is usually for UI and other platformer games, and except some scrolling shoot'em-up, pretty much all games play from top to bottom and left to right (because of gravity and how the great majority of the world read from left to right; it's easier for the eyes and hand coordinates).
Basically the UI is a 3d coordinate system (with z representing the depth value, or more precisely, the rendering order), since the UI is handled by OpenGL. Reading from left to right makes sense and we have no intentions to change that, but I'm still not sure about flipping the Y axis
I think the best thing is to stick to the OpenGL conventions.Especially in the long run it's our intention to offer shader support for the API, probably also for GUI elements, but at least support for post-processing effects (so people can manipulate the current screen which is rendered to a texture). If we really change the Y axis for GUI elements, this would result in *a lot* of confusion, since shaders still have to use the OpenGL convention...
BTW: nevermind also that the mouse coordinates are using the same screen coordinates (i.e. 0,0 is the top left corner) But, hey! whatever, right?
What do you mean exactly? I just tried the player.setMouseCursorCoordinates() function as well as the getters of PlayerGuiElementClickEvent, all of them use correct coordinates (i.e. 0|0 is the bottom left corner)

-
Can you maybe post the full hs_err_pid file here? Or alternatively send it via PM to me?

It looks like an OutOfMemory-Error, but to find out what's going on exactly, the full log would be helpful^^
-
only a vague idea what this means
Hmm... when did it happen exactly? Did this bug only occur once, or do you encounter it frequently? Is there maybe a way to reproduce it?
Maybe you can provide the according errorlog file, to do that, please go to your game directory and have a look for a recent file called "errorlog". You can either post the file here, or alternatively send it via email to support@jiw-games.net
-
I was reading in the pinned article that when you set blacklist to true it would create the file itself.
You mean the "Overview of server.properties" thread? Yeah the wording was indeed a little bit misleading, I've changed that to make it more clear

What is the chances of putting in the IP of the player?
I'm not sure if banning the IP address is a good idea. At least when talking about IPv4 addresses, most people usually only keep their IP for ~ 24 hours (until their ISP assigns a new IP to them). So in most cases, banning an IP address would only help for a few hours, but may also result in innocent people being banned as well (since someone else might get this IP in the future).
I had a player banned through rcon and he just came back in.
If the server is busy (and can't keep up with updating the world database) or if the database is busy, there is a small chance that a player who just got banned might join the server again if he's fast enough. In this case it would help to just kick the player again.
You can find out if the server has problems updating the world database by typing getserverinfo sql into console from time to time. There should be usually 0 pending "Tasks", and if there is a number higher than 0, it should only last for a few seconds.