@zfoxfire: Afaik you can't move your own posts, either tell me which posts you want to move, or simply delete them 
Posts by red51
-
-
@red51 könnte man die Doku nicht in eine git rep stecken dann als offizielle Github rep machen ? Weiss nicht, ob wie viele hier schon mit Github gearbeitet haben, aber denke ist doch die leichteste Option die Doku auch zu akualisieren und man sie auch als Paket downloaden ;D
Also theoretisch wäre das möglich (ein Repository für Plugins ist aber sowieso geplant und auch in Arbeit), aber zumindestens für uns ergibt sich daraus kein direkter Vorteil beim Aktualisieren (wird eh zusammen mit dem Plugin ausgeliefert), auch beim User sehe ich noch keinen richtigen Vorteil ggü. der jetzigen Variante. Aber vll bin ich blind
i wanted to bring this up again ... a git repository would be great for modders have a place to store Their work.
A git repository for modders is in the works, we just don't want to make any changes on our servers while the game is in sale on Steam
Probably a git repository may go online next week.As for the api jar, a maven repository would be better than git
We will think about a maven repository^^
Was ich total hasse wenn ich oben auf Deutsch klicke dann sollte auch alles auf Deutsch erscheinen
Möglicherweise ist bei dir die Sprache noch auf Englisch gestellt? Beim Forenupdate vor wenigen Wochen sind leider einige Benutzereinstellungen auf den Standardwert zurückgesetzt worden, dazu gehört auch die Spracheinstellung. Wie @Skarafass schon sagt, du kannst das in deinem Profil anpassen. Gehe dazu hier hin, klicke auf die Englandflagge, wähle dort Deutsch aus, und drücke unten die grüne "Submit" Schaltfläche, das ändert die Sprache wieder auf Deutsch.
Red51 bitte gebe mir Schritt für Schritt an wie ich das Plugin bearbeiten soll.
Sofern du kein eigenes Plugin programmieren möchtest, ist diese Update erstmal nicht von Relevanz, wie @Garfield schon erwähnte
-
I agree that it, in the specific case of single-file plug-ins, placing the file in the main "plugins" directory would be easier
That's true. Originally I wasn't sure if this may cause some problems, especially if the plugin ships with some assets or third party libraries. However, I guess it doesn't matter. For assets, it might be a requirement to put them into the jar file. For third party libs, I guess it's no problem if they're in the "plugins" folder, or maybe we add a specal "libs" folder or something like that.
whether to natively support ZIP files or not [...] The ZIP file has to be expanded, sooner or later
Well, basically ZIP support isn't necessary. And yeah, the server has to unzip it anyway. Plus there won't be any advantages in terms of disk space usage. Originally it was intended to just have an easier way to "install" a plugin in singleplayer. Some people struggle to unzip a ZIP file (this happened several times in the past), so it would be easier for them if they move the ZIP file (it's still better to upload plugins in a ZIP file) into the plugins folder. But I guess it would be more preferable to have an installer for that...
the first time the application finds a "new" plug-in ZIP in the standard "plugins" directory, extracting into a specialized destination directory. This raises some issues as well, though.
Yeah that's true. I guess having an "auto-unzip" feature may cause more problems than benefits.
------------------------------
So to recapitulate this, I *guess* the best approach is having all plugin jars just into one single folder (the "plugins" folder), third party libs (I think most plugins don't use any third party libs at all) may go to a "libs" folder, and ZIP file support will be discarded (maybe we could put an installer on our todo-list).
-
if a plug-in needs to monitor a certain set of keys for its own purposes, it is practically certain that those keys should not carry out the in-game actions bound to them.
No doubt, but it's important to have an efficient way to do that without too many disadvantages (or uncomfortable behaviour for the player).
Is this what you mean by Player.disableClientSideKeys() ?
Yes, exactly. For example, if you call player.disableClientSideKeys(KeyInput.KEY_W, KeyInput.KEY_A, KeyInput.KEY_S, KeyInput.KEY_D), the W, A, S and D keys will be disabled on the clientside (probably most people use these keys for player movement, so in this case, the player would be unable to move his character anymore). Or if you call player.disableClientSideKeys(KeyInput.KEY_I), the player can't press I anymore (or more precisely, it has no effect, e.g. if the player uses this key to bring up his inventory, he can't do that anymore). This state lasts until you call player.enableClientsideKeys() or something like that.
However, the "PlayerKeyEvent" in the API will always be called, there is no way to disable that (with the exception of unregistering keys, or by setting the "listenForKeyInput" to false).This would both avoid any unnecessary forwarding (less traffic)
I guess this way we can already expect the least amount of traffic. Calling player.setListenForKeyInput() is very "cheap" (just a few bytes the server has to send to the client), however, it's not necessary at all. It is only useful if your plugin registers a lot of keys (or some keys which are frequently pressed, like WASD etc), but only need them in certain situations - this way you can enable or disable the "listenForKeyInput" when needed, so the player does not always spam the server with his key inputs (every single key input is more "expensive" [still quite cheap] than a "setListenForKeyInput" packet)
-
I can speculate that, normally, listening is off and key strokes can only be examined after the fact and not cancelled; while, by turning listening on, once key strokes are forwarded to the server, they can be cancelled at the expenses of a slower reaction time. Near?
It just determines if key inputs (only keys which were registered by calling Player.registerKeys(int... keys)) should be forwarded to the server or not. This way you can register all keys your plugin needs on startup, and enable/disable listening only when needed (in order to save some traffic, so the player does not send any unnecessary key input packets to the server).
Having the ability to cancel key inputs (i.e. as mentioned before, each input has to be verified by the server first) is unfortunately no option. Of course one could say "let the plugin decided", but even on a fast server with a good ping you get a noticeable delay (especially the input the player expects a direct response, like movement, scrolling etc). In the end, players will blame us and complain about "all my input is delayed"
The most performant option is probably indeed an Player.disableClientsideKeys() method^^ -
Why do I get this when I google "red51"??
-
Do you access the side door/hatch? Not the hatch on the back (this one does not work). When looking at the small hatch, your crosshair will turn into a chest icon. Pressing your interaction key (by default key F) opens the hatch, now you can place coal or lumber in it (hold it in your hand while looking at the hatch/hole, then press the secondary mouse button).
-
Theoretically: Yes. Practically: I recommend to look out for other models
These models were obviously never designed for games, they have way too many polygons. The trees have between 70,000 and 90,000 triangles, the ivy even has more than 900,000 triangles 
This is way too much for a game, or more precisely, way too much for a single plant in a game. Just as an example, the trees in Rising World have between 1000 and 7000 triangles.
Most of the online 3d pages offer models which are mainly designed for rendering purposes (so they often have many polygons). When rendering a video or a screenshot, it does not really matter how many polygons the scene has, even if the rendering process takes a whole day (remember that the game has to render the scene multiple times per second, if you have 60 fps ingame, the scene is rendered 60 times a second). -
I've moved the last posts to a different topic, since they were too much off-topic: https://forum.rising-world.net/index.php/Thread/4790
-
Genau, momentan kann die API noch keine Verbindung zu einer beliebigen Datenbank erstellen (sie bietet lediglich Zugriff auf die Weltdatenbank), aber trotzdem kann man unabhängig von der API mit Java eine eigene Verbindung aufbauen. Das benötigt allerdings die passenden JDBC Treiber. Man kann dazu aus dem Serververzeichnis die sqlite-jdbc-3.7.2.jar für SQLite Verbindungen und die mariadb-java-client-1.1.8.jar für MySQL Verbindungen in sein Plugin-Projekt laden (müssen später nicht mit ausgeliefert werden, da der Server diese ja bereits hat), diese ermöglichen alle Datenbankzugriffe.
Ein "einfacher" Weg über die API eine eigene Datenbankverbindung aufzubauen (oder eine eigene SQLite Datenbank anzulegen, ähnlich wie bei der alten Lua API) sind aber ebenfalls geplant
-
I thought the animations supported now were limited to basic scale, rotate, and translate. The kind of animations shown by the bug eating plant would require support for bones and complex animations. I thought that wasnt supported yet. But I do admit I know nothing about bones.
Sorry if one of my previous posts gave this impression. Animations are not supported at the moment, and I guess it will take some time until that's finally available. Right now it's as you said, limited to basic transformations (rotate, scale, translate).
Btw, I read the API again since the recent update and nothing is really standing out to me for getting the screen size.
The easiest way is to provide relative coordinates for the gui elements (usually the gui constructors and particular methods have a boolean flag which determines if the provided coordinates are absolute or relative). When providing 1.0f as relative size coordinate for example, it fills the whole screen of the player
And is the position coordinate at top left or bottom right of the gui? This is not documented.
It depends on the PivotPosition, by default this is set to "BottomLeft", so it's usually the bottom left. But if you change the pivot to the "Center", for example, the center of the gui element is used instead.
I see the documentation doesn't say much about that, this will be changed//edit: the javadoc has been updated, the setPosition() and setPivot() methods provide proper descriptions and an example now
-
Wo liegt das Limit denn?
Eigentlich bei 100
Du kannst auf die Übersicht gehen, dann siehst du links wieviele Konversationen du hast und wieviel Speicherplatz belegt ist. Du kannst dort auch alte Konversationen löschen, einfach einen Haken links neben der/den Konversation(en) setzen und dann unten auf "xx Konversationen markiert" klicken -> "Verlassen (xx)" -
Leider musten wir heute mal wieder feststellen, das es spieler gibt die lieber Sachen
klauen und Dinge kaputt machen als positiv aufzufallen und mitzuhelfen...Von diesen Spielern gibt es leider viel zu viele. Leider in allen Spielen
Grundsätzlich gibt es bei RW derzeit zwei "einfache" Möglichkeiten, dies zu verhindern: Entweder das AreaProtection Skript wird verwendet, damit lassen sich bestimmte Gebiete festlegen und einzelnen Usern zuweisen. Dadurch kann nur noch dieser User etwas in diesen Bereichen etwas abbauen, verändern, was aus Kisten nehmen etc, Griefer gucken in die Röhre. Alternativ kann über die Permissions festgelegt werden, dass neue Spieler grundsätzlich gar nichts dürfen (also nix abbauen, nix klauen), und es Entscheidung der Admins ist, sie nach einer gewissen Bewährungszeit mit mehr Rechten auszustatten.- Einfachere Bedinung zb. Häckchen machen bei Adminrechte für verschiedene Befehle.
An sowas können wir uns mal ransetzen wenn wir etwas Zeit übrig haben
-Passwortschutz bei Kisten jeder Art wo man Sachen lagern kann.
Später wird es sowas ähnliches mal geben, also zB Safes.
-Deaktivierung von Flugmodus! Mein Kollege hat schon an permissons rumprobiert und dabei ersten server geschrottet.
Dafür muss in der default.permissions Datei unter dem "general" Teil das "true" neben "fly" in ein "false" umgewandelt werden, sodass der Abschnitt so aussieht:
Änderungen an den Permissions Dateien sollten aber niemals den Server "schrotten"-Möglichkeit zb. duch Blaupause gebiet zu markieren, und alles dort in diesem Bereich auf Safe/unkaputtbar zu machen.
Das klingt eher nach einem Job für ein Lua Skript bzw. vorzugsweise für ein Plugin (was mit der API, die in den Startlöchern ist, möglich sein wird).
-Wenn ein Spieler gekickt wid od. gebannt, sollte automatisch sein gesamtes Inventar an Ort und Stelle liegen bleiben.
Das könnte man zwar grundsätzlich machen, auf der anderen Seite würde das aber auch dazu führen, dass der Server u.U. unnötig mit Items zugemüllt wird (es wird sich ja nicht immer um Diebstähle handeln). Als Admin ist es vermutlich besser, die fehlenden Items einfach via Command neu zu spawnen.
P.S. Auch wenn es bereits Scripte, permissons Befehle etc. dafür geben sollte,
Ich glaube hier flogen irgendwo mal solche Permissions rum, du kannst mir aber auch kurz sagen, was genau die Permissions können sollen oder wie sie aufgebaut sein sollen (verschiedene Gruppen etc., und was sollen die Gruppen dürfen, was nicht etc), ich kann kurz eine Permissions Datei für euch anfertigen
-
@Miacat: Es liegt definitiv nicht daran dass die Hardware nicht ausreichend wäre, ganz im Gegenteil, sie übertrifft ja bei weitem die Mindestanforderungen und sogar die empfohlenen Anforderungen
Dennoch können Hardwareprobleme oder Treiberkonflikte o.ä. selbst mit der besten Hardware auftreten.
Der Vergleich mit Battlefield oder CS kann leider nur bedingt herangezogen werden, es macht zwar das Szenario "es könnte ein Temperaturproblem sein" sehr unwahrscheinlich, aber diese Spiele stellen ganz andere Anforderungen an den Computer. Rising World lastet den Computer hinsichtlich der CPU und des Arbeitsspeichers mehr aus, das liegt einfach an diesem Genre (Battlefield und CS haben eine vorgefertigte Welt, daher entfällt da schonmal ein riesiger Brocken den Rising World hingegen für die Weltgenerierung benötigen würde). Das trifft übrigens auch auf Minecraft zu, man könnte sich zwar zu der Annahme hinreißen lassen, dass Minecraft keinerlei Anforderungen stellen würde oder selbst auf einem PC der 90er laufen müsste, aber auch hier ist die Anforderung an die CPU und vor allem an den Arbeitsspeicher deutlich größer als bei vielen anderen Spielen, die deutlich schöner aussehen
Und natürlich ein anderer kleiner Unterschied (aber mit großer Wirkung^^) ist die Tatsache, dass viele Windows Spiele DirectX verwenden, anstelle von OpenGL.Hast du die anderen Dinge denn mal geprüft (Ereignisprotokoll in Windows etc)? Melde dich ansonsten einfach mal via Steam o.ä. bei mir, dann können wir etwas genauer gucken, ob sich ggf. etwas finden lässt.
-
@Captian_Cornball: Working with the API requires some basic programming knowledge. Of course you don't have to dive into any of the advanced stuff in Java (e.g. for a simple plugin, you don't have to care about things like multithreading, networking, jni etc), but first you should be able to write simple Java applications (you could try to create a small calculator in Java, for example). Without going this way, there is probably no real chance (or at least this would be a very long and stony road) to understand how the API works, or use its full potential. There are several Java tutorials on the net which are available for free.
Once you feel ready for the API, you can check out some of the code snippets in the forum, e.g. this one: Create a Plugin
The javadoc also contains a few examples. If you have an explicit question, just ask it in the forum. Otherwise if this isn't sufficient, just wait until the API is fully released and the first plugins are available. -
If we have access in the API to apply a screen filter then one could be blinded or poisoned by such a plant
Basically you can indeed achieve this by using gui elements. You could create a colored panel which has the same size as the screen. By changing the alpha value you can also have transparency etc
I'm thinking about a filter applied to the main viewing area (actual rendered 3d content, seperate from the UI)
Maybe it's worth to consider adding access to various filter effects... but I guess that's something for the long run^^
I think what I would have to do is make a test model and send it to someone as an .obj or something and then they can walk me though how I would implement it... if that works I would make something more elaborate.
If you have a model ready just let us know, creating a small plugin which loads custom models isn't a big deal
Basically even the small example above should work (of course pathes etc. need to be adjusted). -
I am worried! Do you never sleep?
Hehe, sleep is overrated
But thanks for caring about me 
But not all plug-in GUI interaction with users needs to be modal; in fact, most of the applications I have in mind would work equally well (some even better) with modeless "dialogue boxes" (well, kind of...).
At least if mouse input is required a modal element would be useful. So the player can't mess up the gui by opening up the inventory at the same time etc.^^ But of course it's also possible (basically that's already possible, with the exception that you can't disable keys yet) to just have a panel which displays some options or instructions (i.e. "Press E to enable the elevator"). In this case it would be up to the plugin to decide when a key input actually has an effect (i.e. only when standing at a certain position).
-
I've uploaded a new version of the API which provides proper access to the WorldElements, GuiElements and the Timer
The download link is the same, the online javadoc has also been updated. -
@Garfield: Das hatte ich mir gedacht, allerdings ist das wie gesagt leider erst bald möglich.
----------------------
Es ist übrigens eine neue Version der API verfügbar, welche nun korrekten Zugriff auf WorldElements, GuiElements und dem Timer bietet
Der Download Link ist der selbe, die online Dokumentation wurde ebenfalls geupdated. -
Authentication should work now, sorry again for the inconvenience. If you still run into any problems, please let us know
