Posts by red51

Unfortunately chest access isn't possible yet, but that will be implemented in the near future

Hier findet sich eine Erläuterung dazu: Hosting a multiplayer game

Es kommt drauf an, wie dein Freund sich zum Server verbinden möchte. Falls ihr beide bereits eine IPv6 Adresse besitzt, kann dein Kumpel versuchen, zu deiner IPv6 Adresse zu verbinden (diese findest du hier heraus: http://ipv6.whatismyv6.com/ ), allerdings müsst ihr beide das Spiel in Steam zuvor über den Startparameter "+ipv6" starten.

Ansonsten, wenn ihr über den regulären Weg, also IPv4 verbinden wollt, muss dein Freund sich zu deiner Remoteadresse verbinden: http://ipv4.whatismyv6.com/

Dazu ist es aber nötig, dass du in deinem Router die benötigten Ports weiterleitest (standardmäßig 4254, 4255, 4256, 4257, 4258 TCP und UDP).

Einfacher ist es hingegen, eine Software wie Tunngle oder Hamachi zu verwenden. Sofern ihr dort im selben Netzwerk seid, kann dein Kollege einfach zu deiner Tunngle-/Hamachi-Adresse verbinden

Quote from Lonelobo

In this version off the game its not possible to pick up certain stuff (wooden beams / modern lamps etc..), while other stuff can be picked up easly (scaffoldings...)

Right now construction elements (i.e. planks, beams) can't be deconstructed, this will be added in the future Apart from that, you can't remove certain objects, like lamps, although that's actually intended behaviour: Once electricity is implemented, lamps are going to require proper wiring and a power source, so in other words, it's going to require much more effort to use lamps. So since it's quite easy to use lamps now, we wanted to have at least a small limitation by preventing players from picking them up^^

Quote from Lonelobo

also in the future is the gui going to be remade?

Probably there won't be a full rework of the gui, but I guess we're going to enable people to customize it (especially when it comes to the position of certain gui elements)

Quote from Lonelobo

Also a realy small question: why did u (@red) programmed this game in java and not c++?

Basically @Miwarre hit the nail on the head: Java offers great portability.
Although Java has a bad reputation, it is unfounded. It had some serious flaws in the 90s, but since then, things have changed dramatically. In terms of performance, there wouldn't be a big difference between Java and C++ (although first we have to be clear about the term "performance": if we are talking about the speed of computations, there is no difference between the various high level languages, your CPU can calculate "1+1" always at the same speed^^). Although Java is a little bit more "limited" when it comes to memory management, due to its automated garbage collection process, one have to say it actually does a good job. Having full control of these things *might* result in a better performance (or better memory management) though, but this only applies if you know what you're doing. Many big C++ projects use garbage collectors as well, and I doubt they're doing a better job at all^^
The formula "higher abstraction == less control == worse performance" might be true in certain cases theoretically, but then we could also decide to write our applications in Assembly, for example
Speaking about memory, there is indeed a minor "disadvantage" in Java: The overhead of the VM, which is unavoidable. But this is nothing to worry about, it's maybe 50 mb or something like that, which shouldn't be a big deal nowadays. You have to keep in mind that every language has advantages and disadvantages.

Quote from Lonelobo

I dont think this game is limited at the graphics output atm, my system is literly doing almost nothing and i still get low fps

Your framerate depends on various factors. On the one hand, the performance of your CPU of course (not only the number of cores matter [and the "type" of a core, there is a difference between AMD and Intel, for example], also the clock speed, and especially the amount of work that is done per clock cycle), but also your graphics card, your RAM, your VRAM and your harddrive (and - of course - the state of your system, installed software etc).

Quote from Lonelobo

java is also know for not alowing 100% system usage thanks to its virtual machine.

This isn't true. Where do you get these information?

Quote from Lonelobo

not to mention vulkan for taking things the next level

Vulkan is still in an early state. Besides the fact that the Vulkan API wasn't available when we started developing RW, even now it wouldn't make much sense if a game fully relies on Vulkan. I'm confident that Vulkan is going to be great, but right now it's too early to concentrate on it. Furthermore, many old graphics cards don't even support Vulkan (Radeon 7000, 6000, 5000 series etc, Geforce 500, 400, 300, 200 series etc), and apparently there are several people out there who have even older hardware

Hehe, glad to hear the problem is solved

Hmm... yeah actually it would be quite useful in certain situations to have access to the bounding information of a model. We'll add some methods to calculate the bounding information, probably this will be available with the next update

That's a bug Thanks for letting us know, it will be fixed with the next update

Ich habe dieses Thema mal in den Diskussionsbereich verschoben, weil die Feature-Request Sektion nur für Features der API selbst gedacht ist (also Dinge, die die API anbieten oder können muss, zB neue Funktionen, neue Events etc), nicht für explizite Plugin Wünsche

Quote from Miwarre

An Area Protection plug-in is under work by me (see here) as well as, it seems, by the dev team themselves (they will probably beat me, but I am leaning a lot working on it, so I go on).

Hehe, no problem, even our Lua Area Protection script was only intended as an example, so it's always preferable to have an improved version made by the community

Also was zumindestens angedacht ist ist die Möglichkeit, Spieler auszublenden, also komplett unsichtbar zu machen. Dazu dient die Funktion player.setInvisible(boolean), welche seit der letzten Version zwar schon vorhanden, aber noch nicht ausimplementiert ist (daher wird sie erst ab dem nächsten Update funktionieren).
PVP ausschalten wäre am sinnvollsten über die Permissions regelbar. Momentan kann man die einzelnen Permissions leider noch nicht individuell ändern, allerdings kann man einen Spieler mithilfe der API einer anderen Permissionsgruppe zuweisen (zumindestens könnte man also behelfsweise den Spieler einfach erstmal einer anderen Permissionsgruppe zuweisen, welche PVP verbietet).

Right now none of these things are possible unfortunately, but we can implement it for the API

It's indeed easy to miss the message... but on the other hand, it might be annoying if the message stays there permantently (maybe it's intentional to have a full inventory, who knows)? We can at least increase the duration how long the message will stay visible (and maybe make the status message a little bit more visible). Maybe a small notification sound would also make sense (although on the other hand, this may be annoying too)

Quote from Captian_Cornball

got it, the sticky needs some updates, infiniteitems Isn't In it.

Thanks for letting us know, I've updated the sticky now

So finally I did some tests about that, unfortunately I wasn't able to reproduce the issue I tested all scenarios, i.e. setting position/rotation before adding the model, setting position/rotation after adding the model, calling moveTo() before/after adding the model etc.

Although I just tested it in singleplayer (and LAN). Do you run it in multiplayer eventually? I didn't test the behaviour when there is a latency between the server and the client.

Otherwise I have no idea why it doesn't work on your side... only thing I noticed is that the speed in the moveTo Method is quite slow, so when providing 0.01, the element barely moves. I guess we may change that. But everything else worked as intended.

Can you maybe provide a test-case or alternatively send me the code via PM?

Hmm... kannst du die entsprechende Zeile bzw. am besten den ganzen Code mit Hinweis auf die entsprechende Zeile einmal posten oder mir per PN senden?

Quote from Smoka

ca. ab den 6 Block von boden aus

Hab den Fehler reproduzieren können, danke für den Hinweis, das wird mit dem nächsten Update behoben

Quote from Miwarre

The question is that, unless I have overlooked something very obvious, I can have either the jump (with the remove-then-add-back trick) or no movement at all (with no 'tricks'), with nothing in between

If you want to move the element to the target position instantly, you can just use the "setPosition()" method, otherwise "moveTo()" for smooth movement. Apparently adding/removing the model to the client causes the issues you were having (I will look into this now). As a workaround, you may try to add a small delay to the moveTo() command (i.e. by using a timer), so add the element to the particular player, and trigger a timer to move it with a delay of 0.5 seconds, for example (just for testing purposes).

Quote from Miwarre

As far as I can imagine things right now, a very precise movement sync across the different players is not necessary

It's not even possible*, especially due to the network latency (a player with a ping of 10 ms will receive the "moveTo()" message much earlier than a player with a latency of 100 ms, or image a player suddenly has a lag which causes a delay of a few seconds), but also things like framerate are relevant (the movement itself is framerate-independent, but it affects the processing of network messages [if the client receives a moveTo message, it will be processed in the next tick, in order to keep it synchronized with the rendering]... so a player with 200 fps will start processing the moveTo() message quicker than a player who only has 5 fps).

*Precision could be increased if the server keeps sending the current location of the model to the client, but this may cause a lot of traffic. I'm not sure if the result is worth it.

Quote from Miwarre

This is the kind of consistency which would be useful to have

Well, if the server calculates the moveTo() position as well, this wouldn't necessarily increase consistency (at least among different players), it would only be helpful if a plugin actually needs to now the exact position after calling the moveTo() method

If you don't want to allow infinite resources, you have to add the infiniteitems key to the deny block (and put to whatever you want to allow into the "allow" block):

creative:
    allow:
    - default
    deny:
    - infiniteitems

Das ist eine lustige Geschichte, setFlying() war bereits vollständig implementiert (sind eigentlich nur marginale Änderungen), ich musste aber einen kleinen Bugfix veröffentlichen, sodass ich alle Änderungen kurzerhand rückgängig gemacht habe (da sonst der neue Client nicht mit aktuellen Servern kompatibel wäre, und da es nur wenige Zeilen waren machte es keinen Sinn, die Versionskontrolle zu bemühen). Nach dem Kompilieren war leider ein Neustart der IDE nötig, und die rückgängig gemachten Änderungen wurden nicht wiederhergestellt (wie ärgerlich). Je mehr das eigentliche Update dann Richtung Release rückte, desto weniger Beachtung konnte den API Funktionen gewidmet werden, sodass setFlying() in die Tiefen Abgründe der Vergessenheit geriet. Leider hat sich diese Funktion (mit einigen, wenigen anderen Dingen) vor dem Auskommentieren in Sicherheit bringen können, sodass sie zwar nicht im Changelog auftaucht, aber trotzdem in der API zur Verfügung steht.
Das nur so als kleine Lagerfeuer Anekdote

Lange Rede, kurzer Sinn: Die Funktion wird leider erst mit der nächsten Version verfügbar sein

Quote from TheMrMik

Irgendwie funktioniert es nicht bei mir..
Es passiert einfach nichts.

Sind ggf. mehrere Plugins aktiv? Andere Plugins, die ggf. andere Keys registrieren? Ich sehe nämlich gerade, dass das durchaus problematisch ist, da andere Plugins (oder auch Aufrufe an andere Stelle im Code) diese Einstellung überschreiben Das muss geändert werden. Bis dahin als Workaround am besten alle fremden Plugins entfernen und bei eigenen Plugins darauf achten, dass die "registerKeys()" Methode des Spielers nur ein einziges mal an einer Stelle aufgerufen wird...

Unfortunately the API has no way to access the localized names of an item (basically the API always runs serverside, and the server doesn't have any localization). We can, however, add a clientside command to get the according item name from a localized name (so you can at least find out the correct item name), but there would be no way to trigger this command programmatically
Alternatively we could offer a callback method for that (so the server asks the client for the name), but the result would depend on the game language of the client (and it would be very awkward solution)

Oh... that's indeed an issue. The internal attributes map only gets created once a plugin sets an attribute, unfortunately the hasAttribute() method doesn't take this into account, so calling this method before any plugin has created at least a single attribute for this plugin raises an exception X/

Another workaround (instead of checking getAttribute() for null) would be to set a dummy attribute when the player connects or spawns.

I'm sorry for this issue, it will be fixed with the next update!