Posts by LordFoobar

Quote from diegomarino80gongo

just long press on "f" key, you will take in yopur inventory the station

I found that out some time after creating this thread. Just press the action key longer, until it picks up the item (I personally did bind it to "E" because it's shorter for my index finger). I tried to pick up blocks, but it didn't work.

I'm not sure if this has been discussed, but it is something that I'd find most useful; there should be some way to pickup an item previously placed. For example, placing a crafting station should allow to pick it up and reposition it somewhere else. Currently, all we can do is destroy it and build a new one.

Quote from red51

In singleplayer, the despawn times can be changed in the settings (see "Miscellaneous" -> "Corpse Despawn Time"). In multiplayer it can be changed in the server.properties file, as mentioned by @yahwho
The default value is set to 30 minutes (1800 seconds), but around 1 year ago, we had a much smaller default value (5 or 10 minutes). If you still have an old "config.properties" file in your game directory, there is probably still that low value set (while we may change certain default values with a new update, we usually never touch existing settings).

Alternatively you can check the "Keep Inventory" box in the settings, then you won't lose your inventory upon death

The problem is that I was playing on someone else's server, and there was no one around. I actually have no idea what the timeout is/was. I still find it cheap to have the inventory lost. Anyway. Perhaps this is out of your control, but still pisses me off, and does not encourage me to launch the game to waste my time like this.

And another point I forgot to mention; I was cooking some meat and there are absolutely NO WAY to tell if the meat is ready, but to look at it until it is cooked. And the time period between "cooked" and "burned" is very small. In other words, I burn the meat 50% of the time. On the other hand, as I was cooking the meat during the day, but then night came, I could not see if the meat was cooked because of the fire (and the meat is grey or something against the light of the fire), so I had to pick up the meat, notice that it was still raw, place it back, and had to wait again..... The time seemed to be reset!! Holy Crap! It took nearly half a day to cook the damn thing! Should be able to have some gauge, or some idea of when the meet'd be cooked. For example, have the character make a sound (like sniffing for smell) when the meat is ready, or whatever... better yet, have indicators saying that the meet is "rare", "medium", "cooked", etc. or something. It's just annoying.

I hadn't played this game for a while, so I fired it up about three hours ago.

Many things changed. Things got a little more complicated, and confusing. I spent a while figuring out how I could craft a chest (it was a basic crafting thing before if I remember correctly). And I just exited the game about 5 minutes ago out of frustration (again).

Pros

• Lots of new content, animals, crafting, etc.
• New ambiance music is nice
• Freezing over night is annoying, but realistic and nice
• Hunger does not go down as fast as before, and it avoids spending countless hours looking for food all the time
• Bleeding eventually stop, so when I got attacked by a bear, I did not just die out of my blood (though came very close to)

Cons

• Confusing crafting. I actually have ideas about that, but considering how my ideas felt in deaf ears before, meh (prove me wrong, @red51)
• I killed the damn bear, but by the time I went empty my inventory I came back (about 3 minutes)... the damn bear's body was gone!
• I placed some rocks to fill a hole... felt through anyway (the rock) and died with inventory full of things I had spent precious time collecting. When I came back (2 minutes later) my body was NO WHERE to be found. I lost everything. (I did quit at this point)

I did not play longer to evaluate anything else. It was pretty much : spend 3 hours crafting and collecting ores and resources, making tools, etc. then I died and lost EVERYTHING. It takes too long to craft some damn storage!!!

Anyway.

Quote from yahgiggle

am i understanding you have a area called Bobbinfish's ? and that it does not save or it disappears or something like that ?
if so the problem is with the ' try not to use things like ; ', . in the names keep them simple and it should be fine.

The problem is most likely because you do not escape the name of the area when you save it in the DB....

Have you heard of SQL injection?

Quote from Minotorious

Good thoughts. Let's see what red's opinion is on this

[snip]

What I did to prevent this was to add the whole GUI panel as an attribute (player.addAttribute(panel)) to each player when they log in to the server so this way all players have their own instance of the GUI and when I update/change it in some way for one player it doesn't update for all others.

Display More

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.

Of course, I fully understand the extra weight that this adds to the API, but I really think that this is for the best. And the game is still in alpha, let's not forget that. Changes are bound to happen, and better so early on than later.

Setting player UI to attributes is one thing that gave me a hint of the problem with player UI binding (and how plugins need to manually propagate and sync UI with the player...).

This is what I would have expected in a base UI component API for this game (note that I do not have the full implementation code source, so implemented what I managed to get from the decompiler)

package net.risingworld.api.uix;


import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.Stack;
import java.util.concurrent.atomic.AtomicInteger;
import net.risingworld.api.objects.Player;
import net.risingworld.api.utils.ImageInformation;
import net.risingworld.api.utils.Utils.GeneralUtils;


public abstract class GuiElement<T extends GuiElement<T>> {


    private static final AtomicInteger ID_COUNTER;


    static {
        ID_COUNTER = new AtomicInteger(1);
    }


    private int id;
    private Player player;
    private GuiElement parent;
    private ArrayList<GuiElement> children;
    private Stack<GuiElement> removedChildren;
    private float positionX;
    private float positionY;
    private boolean relativeX;
    private boolean relativeY;
    private float width;
    private float height;
    private boolean relativeHeight;
    private boolean relativeWidth;
    private PivotPosition pivot;
    private boolean clickable;
    private boolean visible;
    private float alpha;
    private int color;
    private int hoverColor;
    private int bordercolor;
    private float borderThickness;
    private boolean borderThicknessRelative;
    private ImageInformation screenMaskTexture;
    private boolean useScreenMask;
    private boolean mipmapping;
    private boolean dirty;
    public GuiElement(Player player) {
        if (player == null) {
            throw new IllegalArgumentException("Player not specified");
        }


        this.id = ID_COUNTER.getAndDecrement();
        this.player = player;
        this.children = new ArrayList<>();
        this.removedChildren = new Stack<>();
    }
    public int getID() {
        return this.id;
    }


    public Player getPlayer() {
        return this.player;
    }


    public boolean hasParent() {
        return this.parent != null;
    }
    public GuiElement getParent() {
        return this.parent;
    }
    public boolean addChild(GuiElement child) {
        if (child == null) {
            throw new IllegalArgumentException("Child cannot be null");
        }
        if (!children.contains(child)) {
            child.removeFromParent();
            this.children.add(child);
            this.removedChildren.remove(child);
            this.dirty = true;
            child.parent = this;
            return true;
        } else {
            return false;
        }
    }
    public boolean hasChildren() {
        return !this.children.isEmpty();
    }
    public List<GuiElement> getChildren() {
        return Collections.unmodifiableList(this.children);
    }
    public boolean removeChild(GuiElement child) {
        if (children.remove(child)) {
            child.parent = null;
            this.removedChildren.add(child);
            this.dirty = true;
            return true;
        } else {
            return false;
        }
    }


    public boolean removeFromParent() {
        if (this.parent != null) {
            this.parent.removeChild(this);
            this.parent = null;
            this.dirty = true;
            return true;
        } else {
            return false;
        }
    }


    @Override
    public int hashCode() {
        return this.id;
    }
    @Override
    public boolean equals(Object o) {
        return (o instanceof GuiElement) && (((GuiElement) o).id == this.id);
    }


    public void refresh() {
        this.updateElement();
    }
    public void destroy() {
        this.removeFromParent();
        //
        // TODO : implement cleanup
        //
    }


    public float getAlpha() {
        return this.alpha;
    }
    public T setAlpha(float alpha) {
        this.alpha = alpha;
        this.dirty = true;
        return (T) this;
    }


    public int getColor() {
        return this.color;
    }
    public T setColor(int color) {
        this.color = color;
        this.dirty = true;
        return (T) this;
    }
    public T setColor(float r, float g, float b, float a) {
        this.color = GeneralUtils.colorRGBAToInt(r, g, b, a);
        this.dirty = true;
        return (T) this;
    }


    public int getBorderColor() {
        return this.bordercolor;
    }
    public T setBorderColor(int color) {
        this.bordercolor = color;
        this.dirty = true;
        return (T) this;
    }
    public T setBorderColor(float r, float g, float b, float a) {
        this.bordercolor = GeneralUtils.colorRGBAToInt(r, g, b, a);
        this.dirty = true;
        return (T) this;
    }


    public float getBorderThickness() {
        return this.borderThickness;
    }
    public T setBorderThickness(float thickness) {
        this.borderThickness = thickness;
        this.borderThicknessRelative = true;
        this.dirty = true;
        return (T) this;
    }
    public T setBorderThickness(int thickness) {
        this.borderThickness = thickness;
        this.borderThicknessRelative = false;
        this.dirty = true;
        return (T) this;
    }
    public boolean isRelativeBorderThickness() {
        return this.borderThicknessRelative;
    }




    public int getHoverColor() {
        return this.hoverColor;
    }
    public T setHoverColor(int color) {
        this.hoverColor = color;
        this.dirty = true;
        return (T) this;
    }
    public T setHoverColor(float r, float g, float b, float a) {
        this.hoverColor = GeneralUtils.colorRGBAToInt(r, g, b, a);
        this.dirty = true;
        return (T) this;
    }    


    public boolean isClickable() {
        return this.clickable;
    }
    protected void setClickable(boolean set) {
        this.clickable = set;
        this.dirty = true;
    }


    public boolean isVisible() {
        return this.visible;
    }
    public T setVisible(boolean visible) {
        this.visible = visible;
        this.dirty = true;
        return (T) this;
    }


    public PivotPosition getPivot() {
        return this.pivot;
    }
    public T setPivot(PivotPosition pivot) {
        this.pivot = pivot;
        this.dirty = true;
        return (T) this;
    }
    public float getX() {
        return this.positionX;
    }
    public T setX(float x) {
        this.positionX = x;
        this.relativeX = true;
        this.dirty = true;
        return (T) this;
    }
    public T setX(int x) {
        this.positionX = x;
        this.relativeX = false;
        this.dirty = true;
        return (T) this;
    }
    public boolean isRelativeX() {
        return this.relativeX;
    }
    public float getY() {
        return this.positionY;
    }
    public T setY(float y) {
        this.positionY = y;
        this.relativeY = true;
        this.dirty = true;
        return (T) this;
    }
    public T setY(int y) {
        this.positionY = y;
        this.relativeY = false;
        this.dirty = true;
        return (T) this;
    }
    public boolean isRelativeY() {
        return this.relativeY;
    }


    public float getWidth() {
        return this.width;
    }
    public T setWidth(float width) {
        this.width = width;
        this.relativeWidth = true;
        this.dirty = true;
        return (T) this;
    }
    public T setWidth(int width) {
        this.width = width;
        this.relativeWidth = false;
        this.dirty = true;
        return (T) this;
    }
    public boolean isRelativeWidth() {
        return this.relativeWidth;
    }


    public float getHeight() {
        return this.height;
    }
    public T setHeight(float height) {
        this.height = height;
        this.relativeHeight = true;
        this.dirty = true;
        return (T) this;
    }
    public T setHeight(int height) {
        this.height = height;
        this.relativeHeight = false;
        this.dirty = true;
        return (T) this;
    }
    public boolean isRelativeHeight() {
        return this.relativeHeight;
    }




    public T setScreenmask(ImageInformation screenMask) {
        if (screenMask != null) {
            this.screenMaskTexture = screenMask;
            this.useScreenMask = true;
        } else {
            this.screenMaskTexture = null;
            this.useScreenMask = false;
        }
        this.dirty = true;
        return (T) this;
    }


    private void updateElement() {
        if (this.dirty) {
            //PluginGuiManager.updateGuiElement(this);
        }


        this.dirty = false;


        // client should store GuiElement instances in a WeakHashMap in order
        // to preserve it as long as possible and avoid recreating an element
        // when it is removed from it's parent, and set to another
        while (!this.removedChildren.isEmpty()) {
            this.removedChildren.pop().updateElement();
        }


        this.children.forEach((child) -> {
            child.updateElement();
        });
    }
}

And I would propose a few other methods to access various information about the player's screen. My goal is for this game to be easy for people coming from desktop UI design to actually work with something that is widely used, screen coordinates. Having a better API, with more control over positioning and sizes, plugins can use more responsive layout designs. (For example, changing the size of the fonts, making panels bigger when displaying lists in larger resolution, etc.)

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. Once the element is vertically positioned using a screen coordinate system (vertical axis pointing down, as it is for nearly all UI frameworks... because this is how humans read, from top to bottom), and it's size set, finding the proper x and y to lay out the texture is trivial. However, laying out a complex UI where elements are arranged from last to first is awkward for the designer. In short, there is no real reason to have a Cartesian coordinate system for UI design, especially when it has no bearing whatsoever on laying out textures during the rendering phase.

Also, note that the base element does bind with one player, and one player only. Why? because there is no sense in having a hierarchical object on the server (where the UI is declared) whose order is not in sync with the structure on the client (where the UI is rendered). 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? If UI elements are properly cached on the client and synchronized with the server, there shouldn't be memory leaks and performance should not be impaired by it whatsoever.

** Edit **

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 :

package net.risingworld.api.uix;


/**
 *          TopLeft           TopCenter          TopRight
 *             +------------------+------------------+
 *             |                                     |
 *             |                                     |
 *  CenterLeft +               Center                + CenterRight
 *             |                                     |
 *             |                                     |
 *             +------------------+------------------+
 *         BottomLeft        BottomCenter        BottomRight
 */
public enum PivotPosition {
    TopLeft,
    TopCenter,
    TopRight,


    CenterLeft,
    Center,
    CenterRight,


    BottomLeft,
    BottomCenter,
    BottomRight;




    private PivotPosition() {}
}

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?

Quote from Minotorious

tbf I have no idea why you are finding this an issue. It is really not that hard to figure out where the coordinates are, just a matter of willingness to get used to a different system.
The most straightforward way to design anything imo is bottom to top and left to right, I find the top to bottom to be the "weird" way

What plugin have you coded that uses the GUI API?

Also note that nearly half of the the listed plugins that do have a GUI are written by Miwarre... And only 2 or 3 others are significant enough that a change would break their UIx. All the others are basically only labels and single menu panels.

AFAIK OpenGL is the only system that handles coordinate this way.

• Any terminal handle position 0,0 as the top left character slot, i.e. from top-left to bottom-right
• WPF / Windows Form, Xorg / Wayland, etc. all handle from top-left to bottom-right just the same
• CSS handles absolute coordinates from top-left to bottom-right just the same
• JavaX / AWT / Swing handle position 0,0 as the top left pixel to the bottom right one, exactly as the others do.

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).

Of course, mathematics use the bottom left coordinate of a 2D plane as origin, sure! But, then again, art uses yellow blue and red to mix colors, too!

My point is, it is awkward to lay out controls on a vertical axis from bottom to top... then read these control from the other way around! And the answer is simple : negate the Y coordinate to make it more convenient for UI design to lay the controls! Or am I really the only one finding an issue with this?

So what if it breaks a handful of plugins? What about the dozens that will follow and be stuck with the design??

Currently, positioning and sizing UI elements is done using relativePosition and relativeSize arguments. Such as in

GuiPanel panel = new GuiPanel();
panel.setPosition(x, y, relativeSize);
panel.setSize(width, height, relativeSize);

The issue with this is that it is impossible to individually set the x, y, width or height individually as relative.

So I propose a significant, but reasonably back compatible change in the API. For example :

public class GuiElement {


  // Current API


  public void setPosition(float x, float y, boolean relative) { ... }


  // SUGGESTED API
  public GuiPanel setPosition(float x, float y) { ... }
  public GuiPanel setPosition(int x, int y) { ... }
  public GuiPanel setPosition(float x, int y) { ... }
  public GuiPanel setPosition(int x, float y) { ... }


}

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).

Note: with this implementation, the constructor may remain empty (i.e. the current 6 argument one may be marked as deprecated and would call either setPosition(float, float) or setPosition(int, int))

Why?
The idea is that all relative positions and sizes are between 0 and 1 (floating values) and all absolute positions (i.e. pixel positions) are between 0 and some arbitrary maximum values (integer values because there is no such thing as a sub-pixel). Therefore, having an API that can allow such flexibility will help creating better user interfaces.

Consequently, isRelativePosition should be replaced with isRelativePositionX and isRelativePositionY, etc. And with these values, it does not matter if getPositionX returns a floating numerical value, because we can know whether these values are relative of absolute. To remain back compatible, isRelativePosition should return true if any x or y are relative, but should be marked as deprecated.

Is it just me or I am a bit confused with relative size and positions of GUI elements?

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?

Second, PivotPosition is also reversed. Where PivotPosition.BottomLeft makes a container align from the top left corner! If the Y positions were reversed, these values would be more accurate.

I understand that this will break a few plugins implementing GuiElement, but should this be kept much longer and break more things down the road? Unless the system is set with a right-to-left (RTL) locale (e.g. Arabic), all coordinates should be from the top left corner of the parent viewport, meaning that 0, 0 is always the pixel at the top left of the viewport. Therefore :

• PivotPosition.TopLeft (default) sets the element at position x and y (currently, it is set to parentHeight - y and height goes up vertically)
• PivotPosition.TopRight sets the element at position x - width and y (currently, it is set to parentHeight - y and height goes up vertically)
• PivotPosition.BottomLeft sets the element at position x and y - height (currently, it is set to parentHeight - y - height and height goes down vertically)
• PivotPosition.BottomRight sets the element at position x - width and y - height (currently, it is set to parentHeight - y - height and height goes down vertically)

Great things can be done with the current API (even if other issues do exist with the GUI API), and positioning should be fixed.

Quote from red51

That makes sense Although I'm not sure if adding a separate event might be favorable eventually... since the PlayerChestAccessEvent is cancellable, closing a chest must also be cancellable (if it's handled by the same event).

I tried to counter that argument, and I cannot find a solid objection. Because a player can simply disconnect from the server, and reconnect to go around any cancellation. Then again, if a plugin is well coded, this shouldn't be a problem, and being able to cancel closing a chest could be a good way to implement a confirmation method (given that closing a chest can programmatically be executed). For example, prevent users from closing a chest if not all items have been transferred to inventory. Or, for example, dropping items and receiving credits after closing the chest. Or, for example, a script that will automatically empty chests and transport items elsewhere when it is closed (no need for players to mule the inventory manually). Etc.

If closing a chest can be cancelled, of course players can disconnect, and reconnect, but if the logic and states are properly managed, this can be done in a way that is unfavorable to the players.

The entire issue of the panel transparency was my setup, and how I tried to handle the UI from a generic lib (as a separate project) that I linked from the plugin. Netbeans made me believe that it compiled both projects, when it really didn't. So I thought something was odd because I had inconsistent states when making modifications. I ended up resolving this by "Clean and Build" both projects separately. I have asked on SO for help to automate that, but the only solution given so far is Maven... and I really don't like Maven

Well, the plugin I intend to write involves complicated GUIs, and the thought of having to manually add every single GuiElement is what I call a pain. Since elements are hierarchical, I expected that adding the parent would propagate the children to the player also, just as any typical UI manager would handle this situation. I mean, each GuiElement has a parent, but no way to know the presence of children (!!) despite the addChild and [removeChild methods. I mean, I do not know the internal implementation of GuiElement, but it seem odd to me that users would be responsible to preserve the states of elements added to players.

I mean, the method is simple, player.addGuiElement(element) sends it's footprint, including children, to the player. Voilà. If a child is added or removed from the GuiElement, then it should simply be added again to the player to be updated. Since the GuiElement has an ID, it is easy to sync UI elements with the player. There is no need to manually drill down GUI elements, manually making this synchronization.

GuiElement.addChild(GuiElement child)

JavaDoc

"Note: Even if you adds an element as a child to another element, you still have to add every element to the player manually (see Player.addGuiElement(net.risingworld.api.gui.GuiElement)). Maybe this will change in future releases./

Question

But why? If player.addGuiElement(element) is already doing the job, why aren't every added children notified also? Same thing when removing an element?

Damn NetBeans!

WIth Eclipse, third party projects are build alongside, but NetBeans don't bother to update third party sources when building a project, and happily take existing Jars even of the third party sources have changed.

So much wasted time on this!

For example, is there any reason why this :

public class MGuiWindow extends GuiPanel {
  public MGuiWindow(String title, float x, float y, boolean relativePosition, float width, float height, boolean relativeSize) {
    super(x, y, relativePosition, width, height, relativeSize);
    this.setColor(0, 0, 0, 0.5f);
    this.setPivot(PivotPosition.BottomLeft);
  }
}


GuiElement element = new MGuiWindow("Test", 0.1f, 0.1f, true, 0.8f, 0.8f, true);


player.addGuiElement(element);

Produces this :

While this :

GuiElement element = new GuiPanel(0.1f, 0.1f, true, 0.8f, 0.8f, true);
element.setColor(0, 0, 0, 0.5f);
element.setPivot(PivotPosition.BottomLeft);


player.addGuiElement(element);

Produces this :

It would be nice to have a proper GUI example. Just a demonstration reel in order to show a few components implementation. Because, right now, I struggle with how GuiElement s work together. For example, I try to have a semi-transparent panel, but always end up with a black and opaque rectangle. Then I try to add a label inside that rectangle, but nothing shows. Then I try to resize these components, but have no idea if the relative size is relative to parents or the entire screen, etc.

In short, GUI design is a pain.

If the file is only a few hundred Kb or less, just load it entirely and keep each line in an ArrayList<String>. Because the cost of reading a file vs keeping a few Kb in memory is really an obvious choice, here.

Quote from Minotorious

I doubt these plugins are in fact under the CC licence. I haven't seen it mentioned anywhere that any of the common CC, ShareALike or GNU rules obligatorily apply.

But if the developer is nice enough they might share the code

Though considering Miwarre has been away for quite a long time, I think it would take you less time to reverse engineer the jar that to wait for his answer.

This is the content of the GPS's plugin.yaml file :

name: GPS
main: com.vistamaresoft.gps.Gps
version: 1.3.1
author: Maurizio M. Gavioli aka Miwarre
team: VistaMare Software
description: "To aid the player in world navigation and positioning.
Allows to set a home point and up to 15 waypoints; displays current
player position and optionally distance and radial to home/waypoint."
license: Creative Common by-sa
website: http://www.vistamaresoft.com

Notice the CC license