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.
First, positions are from the bottom left corner of the screen (i.e. x=0, y=0 is the bottom left corner of the viewport), which is counter intuitive with the top left positioning of just about every UI managers. I understand that this is an OpenGL issue, but why not translating these values (i.e. inverting the Y's) instead of making it awkward for the plugin developers?
OpenGL handles the screen coordinates this way, i.e. 0|0 is the bottom left corner of the screen. Without taking into account that DirectX handles this differently, I'm not sure if the OpenGL way isn't even more intuitive at least for newcomers: people would probably consider the screen being a 2-dimensional coordinate sytem (even though this is technically wrong), and in school we learn that the origin of a 2d coordinate system is in the bottom left corner.
It's a pity that there are differences out there how screen coordinates are handled, but since RW is an OpenGL application, I'm not sure if it's a good idea to change the coordinates. Especially since changing that would break every existing plugin which uses gui elements
Second, PivotPosition is also reversed. Where PivotPosition.BottomLeft makes a container align from the top left corner!
Hmm... I just checked it and it works as intended The pivot position sets the position of the pivot of the particular gui element, e.g. when changing it to BottomLeft, the bottom left corner of the gui element is used for the pivot position (i.e. the actual position of the gui element refers to the pivot position).
Example:
This code (PivotPosition BottomLeft) gives this result (as intended):
Changing the PivotPosition to TopLeft, we get this result:
Changing it to BottomRight:
And changing it to TopRight:
Did you encounter a different behavior with other gui elements?
The banned list is kept in the world database, although we're thinking about moving it to a separate text file.
About the "blacklist": You have to create a separate text file called "blacklist" in your server directory. There you can add blacklisted players (one name per line). Also make sure that settings_blacklisted in the server.properties file is set to true
OK First bug report. After setting a blueprint, if you decide you need to remove it and use undobluprint in the console in allotted time, not everything disappears
Actually there was a similar bug report a few months ago (related to the undo-command), unfortunately I wasn't able to reproduce this issue yet How much time did pass until you used the undo-command (after placing the blueprint)? Can you maybe send me the blueprint file in question (via PM)?
