Posts by red51

In aller Regel sollten alte Plugins eigentlich kompatibel bleiben, sofern sich bestehende Funktionen in der API nicht verändern. Sowas kann in Zukunft zwar u.U. passieren, besonders in der Anfangszeit, sollte aber nur äußerst selten vorkommen, wenn überhaupt.

Dazu musst du einfach auf Tools -> Libraries gehen, dort dann "RisingWorldAPI_1" und "RisingWorldAPI2" auswählen und den "Remove" Button drücken

There is no real polygon limit, but basically it's as @Miwarre said: The more polygons, the more the performance will suffer. It depends on what you want to bring into the game, and how many instances of this model you want to spawn. If you just have a small chair with 60,000 triangles (keep in mind that triangles matter - some modelling programs use quads as polygons, so in this case the actual polygon/triangle count would be twice as high as), it's definitely too much, especially when spawning the chair multiple times.
If you insert a giant castle model with 500,000 triangles (but there is only a single instance of the castle in the world), it's probably fine. The total polygon count matters. Low budget graphics cards may run into trouble when there are more than 1,000,000 triangles in a scene.

For a reference: Most objects (e.g. furniture) ingame have between 500 and 2000 triangles, trees have between 2000 and 7000 triangles (usually around 4000)

Das hört sich auf jeden Fall vielversprechend an

Quote from Blacky1004

Sicherlich könnte hierbei die ID reichen, jedoch wird es für den Betreiber schwierig werden entsprechende Preislisten zu erstellen, da man sich die Masse an Items und deren
ID schlecht merken kann

Also um von einer ID das dazugehörige Item zu bekommen (oder umgekehrt), muss man den Umweg über die Definitionsdatei der Items gehen. Die Klasse Item hat zwei statische Methoden getItemDefinition(short) und getItemDefinition(String). Zurück erhält man ein Item.Definition Objekt, welches dir alle nötigen Infos zum entsprechenden Item gibt (zB den Namen des Items):

short itemID = 23;  //Unsere ItemID
Item.Definition def = Item.getItemDefinition(itemID);


//Sicherheitshalber prüfen, ob nicht null
if(def != null){
    //Liefert den Namen des items zurück, in dem Fall "pickaxe"
    String itemname = def.getItemName();
}

Bedenke im Falle des Terrainevents, dass du immer ein "ore" Item zurückerhälst, mit der entsprechenden "variation" (in dem Fall zB -102).

PS: In der ersten Version der PluginAPI gab diese Fkt fälschlicherweise noch regelmäßig null zurück, lade die API ggf. nochmal erneut herunter falls dem so ist

Quote from Blacky1004

Zudem habe ich gemerkt, das ich zwar die ID erhalte, jedoch nur eine ID ich hab mal einen Screenshot gemacht, damit das besser verdeutlicht werden kann.

Ja, das ist wahr. Tatsächlich ist es über das TerrainEvent nicht möglich, einen Zugriff auf alle Items zu erhalten, die dabei herausspringen. In dem Fall wäre das Event eher ungeeignet. Besser wäre hier ein PlayerInventoryAddEvent (oder so ähnlich), welches leider noch nicht in der API vorhanden ist. Es wird vermutlich mit dem nächsten Update eingebaut (wobei ich das noch nicht genau sagen kann), dieses würde dann für jedes Item getriggert werden (also in deinem Fall wäre das einmal für Kupfer [mit dem Hinweis, dass die Stacksize 2 beträgt] und einmal für Stein). Auch wäre dort vmtl. ein Feld vorhanden, was die Herkunft des Items angibt (aufgehoben, gepflückt, abgebaut etc).

Did you add the path to the JDK to the "config.properties" (or "server.properties" when running a server)? At least that's needed when you want to compile the project on the fly^^ You have to set plugins_jdk_path to the path of your JDK, make sure you escape colons and backslashes. For example: plugins_jdk_path=C\:\\\\Program Files\\Java\\jdk1.8.0_91

Thanks for the test case! It was indeed an issue with the labels, however, it has been fixed now (only a clientside update)

Thanks for the error log Please have a look if this issue still occurs with the latest version (0.7.3.2)

Der erste Fehler java.lang.NumberFormatException: For input string: "-784,53" besagt, dass die eingegeben Koordinaten in einem falschen Format sind. Grundsätzlich werden bei Koordinatenangaben keine Kommata verwendet, sondern nur Punkte (es müsste als -784.53 sein).
Der zweite Fehler hingegen sollte mit dem nächsten Update behoben sein

Ich möchte vorweg sagen, dass die Plugin API deutlich mehr ist, als nur die Möglichkeit, das eine oder andere Modell in die Spielwelt einzufügen. Das ist lediglich eine der Möglichkeiten, die die API bietet. Die Plugin API kann mehr oder weniger als Mod-API bezeichnet werden, da sie bereits weit über dem hinaus geht, was andere Spiele üblicherweise unter Plugins verstehen. Und tatsächlich ist die API aktuell die einzige Möglichkeit, die Entwicklung von Mods voranzutreiben.
Der Durchschnittsspieler kann zwar nicht viel mit der API anfangen, wohl aber mit den Resultaten, die die API bringt. Dass irgendwo Koordinaten eingegeben oder Befehle verwendet werden liegt nicht an der API, sondern daran, wie die entsprechenden Plugins ausgelegt sind. Die API bietet alle Möglichkeiten, umfangreiche GUIs anzulegen. Man muss aber auch bedenken, dass erst sehr wenige Tage seit dem Release vergangen sind, daher ist es auch verständlich, dass die bisherigen Plugins die API noch nicht ausschöpfen (schließlich beansprucht die Entwicklung von Plugins ebenfalls viel Zeit). Die API läuft im übrigen stark darauf hinaus, dass eigene Rezepte und Gegenstände ins Spiel gebracht werden können (sowas wird später alles über die API laufen - bzw. die API schafft dafür die Voraussetzungen). Wir würden das sogar so schnell wie möglich einbauen wollen, wenn nicht bereits einige Leute aufgrund der fehlenden Dungeons ihre Messer wetzen würden

Natürlich kann man auch sagen, dass einem völlig egal ist, was die API hervorbringen kann. Es gibt auch genug Leute, die bei Minecraft keinen Wert auf Mods legen, und ausschließlich das Vanilla Minecraft spielen. Mich beschleicht aber das Gefühl, dass die Mehrheit der Spieler es anders sieht, nämlich viel Wert auf Mods legt (das würde sonst die langanhaltende Popularität von MC nicht erklären können, oder die florierende Modding Community um große Spiele wie Skyrim oder Arma herum, oder allein die Relevanz des Workshops in Steam).

Und dass nicht jedes Update zwangsläufig das von jedem Spieler Interesse weckt, ist auch nichts neues. Es gibt ja fast bei jedem Update jemanden, der den Neuerungen nichts abgewinnen kann. Es gab Leute, die keine Biome brauchten, Leute, die kein Wasser brauchten, Leute, die die alte Grafik von vor Oktober 2015 bevorzugten, Leute, die keine Gegner brauchen usw.
Im Grunde kann es gar kein Update geben, welches alle Leute zufrieden stellt. Aus diesem Grund zählt für uns auch viel eher das Endresultat, nämlich das "fertige Spiel" (bzw. der Zustand, an dem alle Features, die wir uns vorgenommen haben, implementiert sind). Es kann passieren, dass in der Zwischenzeit ein paar "langweilige" Updates kommen, effektiv bringt uns trotzdem jedes Update näher ans Ziel. Wir entwickeln die meisten Updates nicht "aus einer Laune heraus", sondern tatsächlich ist die Reihenfolge, in der Updates kommen, durchdacht. Natürlich berücksichtigen wir dabei, dass es nach Möglichkeit immer wieder mal etwas neuen Content geben muss (würden wir sonst nur 1 Jahr lang Bugfixes machen, würden sich vermutlich viele Spieler darüber massivst ärgern), und auch bestimmte Updates haben wir vorgezogen, weil die Nachfrage danach besonders hoch war.

Die Plugin API respektive Mod API war schon lange überfällig. Tatsächlich hätten wir das viel lieber schon vor 1 Jahr rausgebracht (aber dann wären wir vor 1 Jahr in derselben Situation gewesen^^). Wenn die neue API verteufelt wird oder als unnötig erachtet wird, müsste man selbiges über die bestehende Lua API sagen (die ja vor geraumster Zeit schon eingebaut wurde, zu einem Zeitpunkt, als noch viel mehr Features fehlten). Und tatsächlich mag der Durchschnittsspieler auch damit nichts anfangen können, doch hätte es nie eine API gegeben, wären bis dato alle Server ungeschützt bzw. das reinste Grieferparadies. Ich schätze, sowas würde den Spielspaß deutlich mehr zerstören und viel mehr Frust verursachen, als die Einführung der neuen API. Ich fürchte, ohne die damalige Entscheidung, überhaupt eine API im frühen Stadium einzubauen, wären wir heute nicht da, wo wir jetzt sind.

Nun muss man zur Lua API dazu sagen, dass uns diese seit einiger Zeit bereits ein Dorn im Auge ist. Rückblickend war es eine Fehlentscheidung, eine Lua API einzubauen, hier hätte es von vornherein eine Java API sein müssen. Doch solche Dinge sind sehr facettenreich, und viele der Effekte der API konnten wir erst mit dem Aufkommen der ersten nennenswerten MP Server beurteilen (zu dem Zeitpunkt, als die Lua API eingeführt wurde, gab es quasi keine MP Server).
Die Lua API ist momentan der Flaschenhals vieler MP Server, und limitiert die Spielerzahlen (in erster Linie dadurch, dass Lua keinen Multithreading Support hat, das Spiel und der Server aber von sowas abhängig sind). Die neue API ist deutlich performanter, dieser Vorteil wird sich aber erst dann in voller Gänze bemerkbar machen, wenn die Lua API komplett rausgeflogen ist.

Quote from wolle158

ABER…es gibt genügend Leute die einfach nur ein tolles Game haben wollen wo sie weder Programmierkenntnisse haben müssen noch Talent um ihre gewünschten Möbel im CAD zu bauen. Sie wollen interaktiv mit den Gegenständen die im Spiel sind arbeiten. Siehe Minecraft mit deren Schaltungen, Rollmaterial und vielen weiteren Aktionsmöglichkeiten.

Man muss die API als eine langfristige Investition betrachten Bei MC selbst ist das Grundspiel auch sehr mager (es hat sich dadurch, dass es ständig weiterentwickelt wird, zwar viel getan, doch würde man den Zustand während der Alpha oder von mir aus auch der Beta heranziehen, so zeichnet sich ein ganz anderes Bild), erst die Mods bringen oder brachten viel Abwechslung (Mods sind bei MC auch bereits so selbstverständlich geworden, dass der gemoddete MC Zustand manchmal als Originalzustand angenommen wird).
Man darf die jetzigen Plugins nicht als Reflektion der Fähigkeiten der API sehen. Zwar sind die ersten Plugins, die jetzt erschienen sind, schon wahnsinnig toll (vor allem wenn man die wirklich sehr kurze Zeitspanne betrachtet, nach der sie nun erschienen sind), aber sie sind im Grunde nur der Anfang.

Quote from Smoka

Ich vermisse die Entdeckungslaune, das Sammelfieber, das umsleben fürchten und sich auf die Schlacht vorbereiten.

Dem stimme ich voll und ganz zu. Survival ist uns wichtig, und wir wollen diesen auch so schnell wie möglich einbringen. Das hängt in erster Linie von der Fertigstellung der neuen Spielerfiguren ab, denen wir uns aber erst nach den Dungeons wieder widmen können. Aber das ist im Grunde ein gutes Beispiel dafür, wie unterschiedlich die Meinungen sind: Es gab vor nicht all zu langer Zeit noch die Aussage im Forum, dass Survival eher unwichtig sei, und wir uns lieber um andere Dinge kümmern sollten^^ Genauso gibt es bei Steam aber auch Personen, die sofort rot sehen, wenn wir "wieder" irgendeine Bausache ins Spiel bringen (wohingegen andere sich neue Möbel oder Blöcke wünschen).

Quote from Smoka

Meiner Meinung nach hätte die API einer andere prioität haben sollen

Wie gesagt, wir hätten sie sogar gerne noch viel früher eingebaut. Aber nun hatten wir damit angefangen, und wollten es auch endlich durchziehen. An mehreren Dingen gleichzeitig arbeiten lässt sich zwar manchmal nicht vermeiden, ist aber immer etwas suboptimal.

Quote from lenko

MC ist meiner Meinung nach auch nur wegen der Modder und der Vielseitigkeit der Plugins überhaupt noch am leben

Das ist vollkommen richtig. Auf Youtube finden sich fast nur Videos von gemoddetem Minecraft. Für mich persönlich spielen Mods eine große Rolle (das taten sie schon immer), mitunter beeinflusst der Umstand, dass ein Spiel Mod-Support hat, sogar die Kaufentscheidung. Wobei man sagen muss, dass Rising World schon immer modfähig war, die API (was im Grunde nur wenige Spiele bieten) diese ganze Sache lediglich deutlich vereinfacht.

Quote from Skarafass

Meine Meinung, wäre es nicht Sinnvoller, wenn für uns normale Menschen Inhalte eingefügt werden (Nicht einfach nur Objekte) und die Leute vom Planeten "0101" sich via Testversion (Bei Steam Beta) mit den Dingen, mit denen "wir" noch nix anfangen können, rumspielen können?

Wir hätten die API auch der Allgemeinheit vorenthalten können. Das hätte andere Updates aber keineswegs beschleunigt, denn immerhin ist die Entwicklung einer API sehr zeitaufwändig. Sie also vor der Öffentlichkeit zu verbergen würde einerseits viele Leute davon abhalten, sie überhaupt zu benutzen, und andererseits würde die Kritik dann hier eher in die Richtung gehen, warum es kein neues Update gibt, bzw. einige Schlaumeier würden das mal wieder als "Beweis" ansehen, dass wir die Entwicklung ja schon längst eingestellt hätten (kam in der Vergangenheit schon zu Genüge vor)

Quote from Garfield

Ich persönlich habe momentarn den eindruck gewonnen, das die Jungs von JIW mit der Plugin-API einiges auf den Endbenutzer abwälzen wollen um sich so aus der Verantwortung zu ziehnen.
z.b Game Content was man sich ja wunderbar mit der API hinzufügen kann.

Das klingt ja eher negativ^^ So betrachtet müsste man eigentlich jedem Spielentwickler oder Publisher danken, der Mods von vornherein verhindert bzw. aktiv gegen Mods vorgeht oder sogar ganze Communityseiten, die sich um Mods drehen, stilllegt (was es alles schonmal gab). Im Gegenzug wären die Spieleentwickler, die möglichst viel Anpassungsspielraum, einen Leveleditor oder eine API anbieten, ja eher die faulen Säcke, die lieber die Community arbeiten lassen
Wir sehen es zwar so, dass es in Zukunft sicherlich das eine oder andere Plugin geben wird, welches die Wartezeit zu neuen Updates verkürzen kann. Nichtsdestotrotz hat die API absolut keinen Einfluss auf unsere geplanten Features. Auch wenn es bald eine Aufzugmod oder voll funktionstüchtige Fahrzeuge gibt, solche Dinge werden so oder so später ihren Einzug ins Spiel halten.
Es gibt allerdings ein paar Features, welche wir ungerne direkt ins Spiel integrieren, sondern lieber über die API lösen. Als Beispiel wäre hier AreaProtection genannt. Selbst hier gab es schon Personen, die uns schwere Vorwürfe gemacht haben und dem Spiel schlechte Reviews gaben, weil wir AreaProtection nur als Lua Skript anbieten und nicht direkt ins Spiel integrieren (ehrlich gesagt ist es für uns sogar deutlich einfacher, sowas wie AreaProtection direkt ins Spiel zu integrieren anstatt es über ein Skript zu lösen), doch wir legen hier einfach viel Wert darauf, dass sowas individualisierbar bleibt. @TutMeistensNix hatte damals mal eine sehr interessante Abwandlung davon entwickelt, die es ermöglichte, Grundstücke (also Areas) zu kaufen, ohne Mithilfe es Admins. Das (und im Grunde auch viele andere Abwandlungen oder Anpassungen) wäre nicht möglich gewesen, wenn AreaProtection direkt Bestandteil des Spiels gewesen wäre.

Quote from Deirdre

Fortschritt? Weiß nicht, ich fühle mich eher benachteiligt, da ich mit Herz und Seele baue.

Warum bist du durch die API benachteiligt? Im schlimmsten Fall zieht man keinen Nutzen aus der API und hat auch kein Interesse an zukünftigen Mods, aber warum ein Nachteil? Wir möchten irgendwann auch das Bausystem überarbeiten, welches dadurch von der Handhabung einfacher wird. Wäre das auch ein Nachteil?

Quote from Deirdre

Ich kann aus Erfahrung mit Mods nur sagen, dass zu viel zu viel ist.

Wie gesagt, jeder hat unterschiedliche Ansichten was die Relevanz von Mods angeht. Und logischerweise kann man ein Spiel auch schnell "kaputt modden". Aber nur, weil man es theoretisch übertreiben kann, indem man sich alle erdenklichen Mods installiert, sollten lieber gar keine Mods angeboten werden?

If you want to enter a text, you always have to use single quotes ('), i.e. your INSERT statement should look like this: INSERT INTO MailPeople ('player_name', 'recipient_name', 'time', 'text', 'read') VALUES ('Recipiant', 'fromwhom', 'booger', 'Booty Call', 0);

@DedoFull: Thanks for the feedback, I'm happy to hear it works now

Please use the code tag for posting any source code, otherwise the indentings get lost, which makes the code difficult to read:

When writing a plugin, it's also helpful to have a look at the output console, since it will print errors in case something goes wrong. On a server, just check the server output, on the client (when playing singleplayer), you can set "game_debug_console" in the config.properties file to true.

In this case the INSERT statement throws an SQL exception, since no column "text" was found. The first CREATE statement does not create a column "text" (it neither creates a column "read")

How to install a plugin

This is the default way to load a plugin.

Usually all plugins belong into the plugins folder in your Rising World directory (if this folder does not exist, simply create it). If you're running the Steam version of the game, you can find the Rising World directory in "Steam/steamapps/common/RisingWorld". If you're running a multiplayer server (i.e. a dedicated Rising World server), find (or create) the "plugins" folder in your server directory accordingly.

Every plugin requires a separate subfolder which contains the necessary plugin files (at least a ".jar" file and maybe some other optional files). Example:

Rising World
|
|____plugins
|    |____MyPlugin1
|    |    |____myplugin.jar
|    |
|    |____MyPlugin2
|         |____myplugin2.jar
|         |____someexamplefile

Now if you load a world (or start a server), it should load all your plugins in the plugins folder.

Information for developers: You can reload your plugins without having to restart the game or the server by typing "reloadplugins" (or "rp") into console (or send it as an input to the server), this unloads and reloads all plugins (i.e. the onDisable() and onEnable() methods will be called, in addition the "PlayerConnectEvent" and "PlayerSpawnEvent" will be triggered again for every player who is currently online). Please keep in mind that this is only intended for testing purposes!

Optional: Compile a plugin by the game/server automatically
Highly recommendable for developers

It is possible that the game/server compiles your plugin "on the fly". This is an easy way to test your plugins without the need to compile it and move the files manually. All you have to do is to create an empty subfolder in the plugins folder (with the name of your plugin) and put a "projectinfo.txt" file there, this file contains a field name (the name of your plugin), path (the path to the "src" folder in your plugin project directory, or more precisely, the path to your source files) and optionally assets (the path to your assets [models, images etc], if you use any assets). Example:

name: MyPlugin
path: C:/Projects/RW-MyPlugin/src
assets: C:/Projects/RW-MyPlugin/assets

Additionally you have to set up the path to your JDK in the config.properties file, or server.properties when running a server ("plugins_jdk_path"). Keep in mind that you have to escape colons and backslashes, e.g. plugins_jdk_path=C\:\\\\Program Files\\Java\\jdk1.8.0_91

Make sure there is no .jar file in your plugin subfolder, otherwise the .jar will be loaded instead.

Optional: Load class files

It is also possible to load separate class files instead. Again you just have to set up an empty subfolder in your plugins folder (with the name of your plugin) and move all your class files there. Now also put a "classinfo.txt" file there, which only requires the name of your plugin (e.g. name: MyPlugin).

A small update is available which finally fixes some respawn issues in multiplayer and also some plugin-related problems when a player disconnects. Multiplayer servers also need to be updated

Es gab nochmal ein kleines Update welches endgültig die Respawnproblematik löst sowie ein Problem bzgl. der Plugins gelöst, wenn Spieler disconnecten. Server müssen ebenfalls geupdated werden

Mit "getTerrainID()" erhälst du im Grunde die "Block ID", also die ID des Materials (Stein, Erde, Kohle etc). Das ist noch kein explizites Item. Generell gibt es nur einen einzigen Itemtyp, der mit der TerrainID was anfangen kann, nämlich das "Ore" Item (über die Textur wird dann festgelegt, ob es sich um ein Erz, um Stein, um Erde etc handelt).
Wenn du nun also ein Item Erz Objekt erhalten möchtest, benötigst du erstmal die ItemID des "Ore" Items. Das könntest du über Item.getItemDefinition("ore") machen (alternativ bereiten wir noch eine Liste mit IDs vor). Der Einfachheithalber kann ich dir die ItemID auch nennen, das ist nämlich die ID 100

Um nun ein Item zu spawnen kommt es darauf an, ob du ein Item in der Welt spawnen möchtest, oder ins Inventar des Spielers. Das Spielerinventar bietet die Funktion insertNewItem(), ansonsten für ein Weltitem, bietet das World object die Funktion spawnItem()

Im Update von Montag gab es tatsächlich diesen Bug, also dass man nicht mehr respawnen konnte. Das wurde allerdings mit dem letzte Update bereits behoben. Besteht das Problem immernoch? Verwendest du als Spielversion die 0.7.3.1?

Das Teleportationsproblem ist seit der letzten Version behoben, allerdings betraf das ohnehin nur Situationen, wenn man sich irgendwo hin teleportiert hat, bzw. wenn man auf einem Server (aber auch nur, wenn viel gebaut war) respawnt ist (der erstmalige Spawn nach dem Connecten war davon nicht betroffen).
Ansonsten ein generelles in der Luft spawnen deutet darauf hin, dass der Spawnpunkt offenbar auf diesen Punkt gesetzt ist. Hier kann es hilfreich sein, einmal in einem Bett, Zelt oder Unterschlupf zu schlafen, um den Spawnpunkt zu aktualisieren

Once an element is defined as "clickable", you will receive a PlayerGuiElementClickEvent once a player clicks on it. To enable to player to click on it, you have call player.setMouseCursorVisible(boolean) (remember to set it to false again once the cursor is no longer needed, since the player can't move as long as the cursor is visible)

Quote from zfoxfire

this should be bundled in the Rising World game download so we can reference the latest released version as its updated. Then we can simply point our IDE to the library and javadoc and not have to worry about downloading jars.

Good idea. Actually the plugin API is in the game folder (in data/jiw/plugin-api.jar), just the javadoc is missing. Guess we will add it with the next update (or maybe put it into a separate folder in the game directory, we'll see)