This sounds like a driver issue. I'd recommend to install the latest sound drivers for your system.
Do you use the Steam version or the Standalone? What Linux distro do you use?
Posts by red51
A new update (0.9.2) is available now!
Latest Hotfix: 0.9.2.1 (2026-05-13)
Latest Hotfix: 0.9.2.1 (2026-05-13)
-
-
Do you use the Steam version or the Standalone (from our website)? If you're using the Steam version, maybe post your SteamID (or a link to your Steam profile here), or alternatively send it via PM to me or via email to support@jiw-games.net
If you're using the Standalone, please post your username
-
java.net.BindException: Cannot assign requested address: bind
It looks like the ports are already in use - is another instance of the server or a LAN session of RW running in the background eventually? Check out the task manager (go to the "Processes" tab) and kill any "java.exe", "javaw.exe" or "risingworld.exe" processes (or alternatively, restart your computer).
Btw., you're currently using a 32 bit version of Java. If you have a 64 bit operating system, I'd recommend to download and install the 64 bit version of Java -
I mean that I was wondering if it's possible to allow 'Guests' access to create an area with the max size of X blocks.
Unfortunately that's not possible, at least it's not possible with the current version of the AreaProtection script
But we can add a method to the new plugin API which restricts the max size of an area - so maybe the upcoming AreaProtection plugin (or any community solution for that) could take it into account. -
It's most likely caused by the & character, it's a special character which needs to be escaped (replace it with "&"), so the link should look like this: hostingmasters.co.uk/clientarea/cart.php?a=confproduct&i=0
If it still does not work, please post the full xml here (or alternatively send it via PM)

-
Well, actually all sounds are working, however, the Player.playGameSound(String soundname) method (which does not take a position parameter) does not work as intended: it is supposed to use the current player position, instead if does not use a position at all (so the sound plays at position 0 0 0). This will be fixed with the next update, in the meantime, just use the Player.playGameSound(String soundname, Vector3f position) method instead

But this only works for sound effects, you can't play music that way.Btw, also take into account that most sounds have a limited number of playing instances (this is only relevant as long as the sound is actually playing - unless it's a loop sound, it will be released automatically after playing).
About a "killAllSounds()" method, basically we could implement it, but it's getting problematic when using multiple plugins (since such a method would kill all sounds). I think it's better if you just keep a reference to your sound id (it's anyway only necessary for loop sounds)
-
To accomplish this, we need to know the position of a player's face on the screen
The head has a fixed offset, so it's not a problem to calculate it from the existing player position. Although this offset may change when the new playermodels are implemented... maybe we will add a "getHeadPosition()" or something like that for reasons of convenience

I guess additional player methods needed would be something to get the distance between two players so we can determine whether the other person is within "hearing" range.
As @Miwarre said, you can already calculate the distance between two players. The "getPosition()" method returns a Vector3f, which has built-in methods to get the distance or the squared distance (to avoid the square root, as @Miwarre mentioned). So you could do something like:
Display MoreJava -
Originally this "double tap F2 to return to the surface" was implemented for servers which have fly mode disabled. The intention was to have a way to return to the surface when falling through the ground

-
Probably it's the textures.jar in the data/assets folder.
Here is an alternative download link for this file, just extract it and replace the existing textures.jar file in your assets folder: https://download.rising-world.…/20161210/textures074.zip
If it still does not work, please let us know -
Well, a chunk is not as tall as the world, right?
Indeed, a chunks consists of 16x64x16 (xyz) blocks, the world consists of 19 chunks (vertically)
Maybe a chunk value "hasDungeon" can be set in each chunk where a dungeon is generated into
Yes, that would work, however, it would be necessary to convert existing worlds (since current databases don't take such a flag into account yet), and I really want to avoid world conversions if possible (since there is always a chance that something may go wrong)
I'm not sure if the "findbase" command is really worth the effort...
However, if someone decides to setup his base in a dungeon (or maybe in an abandoned cabin in the woods, which is also considered as a "dungeon"), the "findbase" command would be unable to find it if we really use a "hasDungeon" flag
I figure the dungeon is going to be subtracting stone anways for each chunk it exists in as the world generates so maybe that can be set and then be viewable by the API
Yes, at least underground dungeons. But what do you mean exactly with "can be set and be viewable by the API"?
-
Makes sense
With the next update, the "onEnable()" method will be called after all plugins have been loaded. To be on the safe side, we will also add an overridable "onLoad()" method, which will be called once the plugin is loaded (although in most cases you probably don't need the "onLoad()" method, since nearly all initialization stuff can still be done on the "onEnable()" method - for that reason, "onLoad()" will be non abstract, so your plugins don't have to override it) -
Hmm yeah the dungeons will be indeed a problem for the "findbase" command, since dungeons just consist of regular blocks, construction elements, objects etc. Although dungeons never consist of very much blocks or construction elements per chunk, so unless you just had a small base, I guess it's still possible to find it with the "findbase" command.
Nevertheless, I guess it makes sense to modify the findbase command a little bit, so you can look for certain objects, for example.But something like " ownership" of objects is planned, this would be quite useful for stuff like the AreaProtection script/plugin, for example
-
Well, converting a resource to a file is tricky. Basically the file doesn't really exist, since it's part of the jar (the OS treats the jar as a single file).
Usually you would load a resource by using the getResourceAsStream(), which returns an InputStream. However, unfortunately there is currently no way to turn it into an "ImageInformation" or "ModelInformation" object (well, ofc you could store your resource as a file, and then load the file, but that's crap).I guess we will add a new constructor to ImageInformation/ModelInformation which accepts an InputStream. Maybe we will also add a convenient way to load a resource directly. I hope we get that ready for the next update

-
Das hat mich in den letzten Tagen auch genervt
Wird geändert! -
Well, the server performance doesn't suffer very much from posters. Only thing you have to keep in mind is the used bandwith when a client downloads an image. A client only downloads images which are in his proximity, and only if there isn't already a cached version of the image in his game directory.
However, when it comes to the clientside performance, things are getting more critical: Basically every "visible" image has to be loaded into the player's RAM (direct memory) and VRAM. If there are too many different images close to each other, some players (who don't have that much RAM) may run out of memory. Here it's important to limit the maximum image size per user (you can do that in the permissions). You have to keep in mind that a 1024x1024 px image consumes 4 times more memory than a 512x512 image, for example. So having many small images isn't a big deal (e.g. having 1000 32x32 px images consumes less memory than a single 1024x1024 px image), but it becomes a problem when using many big images.
To cut a long story short: Don't worry too much about posters, it really depends on where those images were placed (if a player has a lonely house far away from everything else it's really not a problem when he uses many images), and also the max image size matters.
Btw, the file size on your harddrive does only matter when it comes to the bandwith. When loading an image into memory, we can't use compression yet (due to patent reasons), so the memory consumption per images is much higher than the actual file size (it's basically like storing a .bmp image).
-
Sorry for my late response! We did not release any updates recently, so maybe it was just Steam updating some dependencies or whatever

-
I would just like to mention that you always have to be careful about the reloadplugins command. Unloading and reloading classes during runtime is definitely not intended in Java, so there is always a chance that this leads to strange behaviour. Basically this command is mainly there for having an easy way to test plugins without the need to restart the game/server.
-
Actually we need a better implementation of the cloud saving. There is only a limited filespace available per user, so we have to be careful about what we store. Since some people have several worlds with loads of images, this may exceed their cloud storage.
Once we have more time, we will give the user more control about the cloud saving, i.e. he can determine which worlds he wants to store in the cloud (and also determine if images should be stored as well or not).However, changing the way how missing images are displayed is on our list
So proabably there will be just an "N/A" image or something like that -
This is more or less the way I have taken: I sub-class GuiPanel (the nearest type among the ones existing) to add specific child elements with specific relationships among them. A show(player) method adds the GuiPanel directly via Player.addGuiElement() and, in addition, a loop adds each child, again via Player.addGuiElement().
This sounds like a good approach. Maybe we can also add a protected "onAttach()" method (or something like that) which will be called once a gui element is added to the player screen. If you sub-class a GuiPanel then, for example, you could just override this method, and add all childs via Player.addGuiElement() (so it wouldn't be necessary to call a specific method like show())
-
Well, this doesn't work unfortunately. If you try to add a custom GuiElement to the player screen (or what's the reason behind sub-classing the GuiElement class?), the client doesn't know how to display it. Currently every API GuiElement is covered by a "real" element in our underlying gui, so if you create a custom GuiElement in your plugin, the client doesn't know what to do
It's more preferable if you just create a regular class which consists of your particular GuiElements. Instead of adding it to the player gui directly (by calling Player.addGuiElement()), you might add a method to your gui class instead (something like "addToPlayerGui(Player)" for example) which adds the particular gui elements manually.