Posts by LordFoobar

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

Quote from Minotorious

ok the null pointer exception probably happens because this line: Item item = chest.getItem(1); returns a null item and then the item.getName().equals("bandage") compares the name of a null value i.e. a null again with the word bandage

Yes. When comparing something in Java, you are better to compare a constant with a variable, or check if the variable has a value first. One of :

if (item.getName() != null && item.getName().equals("bandage")){

or better

if ("bandage".equals(item.getName()){

But in your case, since getName() may be the cause of your NPE, you must check for null, so

if (item != null && "bandage".equals(item.getName()){

Is it possible to see the source code for this plugin? I could try to reverse engineer the jar, but I'd appreciate sharing the source code so others can learn how you did it and even improve upon it (it is CC licensed after all).

The current implementation lacks an access state. Namely, plugins know when a chest is accessed (opened), but not when the chest is closed. Therefore, I propose extending this event with a simple flag

public class PlayerChestAccessEvent extends PlayerObjectEvent implements Cancellable {


    boolean cancelled;


    public PlayerChestAccessEvent(Player player, commons.objects.ObjectElement object) { }


    public PlayerChestAccessEvent(Player player, short objectid, byte variation, int cx, int cy, int cz, short px, short py, short pz, short rx, short ry, short rz, int info, byte status) { }


    public int getChestID() { }


    public boolean isChestOpen() { }


    public boolean isCancelled() {  }


    public void setCancelled(boolean cancel) { }
}

The new method isChestOpen() would return a boolean true or false whether the player opens or close the chest. Current script would need to check this flag to make sure that any logic is not executed twice, potentially breaking some internal state. I do not believe that an extra event is necessary, and the potential breaking change is a reasonable risk since it shouldn't affect too many plugins, and those can even benefit from this flag at the same time.

Rationale

There is no way to detect when a player close a chest.

Quote from Bogus

Hello Lord Foobar ;D

Nice to see you and a warm comback ;D

Thanks!

I have a lot of things to catch up with! I'm still pretty busy, but I will have some time to spare this winter (hopefully!). Meanwhile, @yahgiggle has been filling in for me quite nicely, True loyal gamer he is!

If I can help with plugins (Java) in any capacity, I will see to help.

Cheers!

I recently discovered a way to smelt more ore than I should, as evidenced by this screen capture, where all sulfur ingots were taken out from these two furnaces, from the same batch. I should have got 120 ingots (60 each), but got 140 instead. Yesterday, I got 152.

So, yeah, unless this is a known "feature", I'm all for it!

(Note: sorry for low res image... I just installed Manjaro and Shutter, and realized that it took screen caps using JPEG compression... )

Quote from Miwarre

A first announce to disclose that I am working on a Java plug-in for Area Protection and Management.

It is not a port, it is a complete rewrite from scratch. I am trying to go as much visual and GUI-ish as possible, so the progress is not very quick. A couple of screen shots to show some of the work so far.

There will be only ONE chat command, which will bring up this main plug-in menu (with clickable items):

[...]

The New Area command opens the area selection tool to create the new area; details about the area being created (centre location and sizes along the two coordinates) are displayed in real time in the info panel:

[...]

The idea is to be backward compatible with the existing areas, if possible, but this plug-in will allow to set the permissions of each area individually.

Stay tuned!

Display More

This is awesome! If you want, I could add you to the Github organization, and this would allow others to create issues (improvements, suggestions, bugs, etc.) and collaborate on the code.

Every programmer understand this :

Quote

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

--Rick Cook, The Wizardry Compiled

... testing games is a tedious task

Quote from zfoxfire

Did anyone just get a 12 MB update for rising world? I see no announcements and I've been getting a lot of 0 byte updates for random games which I think is just a Steam bug. I dont see any anouncements on here however.

Uhh.. nevermind. I still have version 0.6.5.1. I'm pretty sure that's the current version.

Yeah, @red51 will most likely announce any update before it is actually pushed, to make sure those with a server can update, too!

Quote from Benjaminn

Almost 1 month later and still no water update, what a game.

Quote from Trillnar

It has actually been 4 months since the last major update of any consequence. The last one being the biomes released last Christmas. With only 1 person doing most of the coding, it is going to take a very long time before the goals are reached . You will find that a lot of the early access games on Steam are only written by one or 2 people . Blockscape, stars one , synthetic world , and kingdoms to name a few. I do not know why water is taking so long but that is the way it is going to be. We just have to wait and see what happens. Unless red gets help, there will be a very long wait for a lot of the stuff that is mentioned in the roadmap. One person can only do so much. We are all going to just have to wait patiently.

If you missed my post about why updates sometimes take longer than in other games, here it is. This is not an extensive post and I didn't go into the complexities of game development, and I encourage you to do your own research instead of claiming absolute knowledge or complaining about things on something you clearly don't grasp. In a world of fast food, fast play, fast freakin' everything, one loses perspective on the complexities that this world offer all around; some people's jobs is to make easy something that is diametrically opposite from it, be grateful for that. Professional athletes and artists becomes who they are with dedication, patience and time, and such is the same with game development. Read the comments on the games that have "mixed" opinions on Steam, and you'll see that the argument of "devs not listening to the players" and "some updates are breaking things" is common. Sometimes, these argument are legit. Sometimes, they are just coming from whining, self-righteous gamers. Don't be like the latter. It is far better to handle discontent than frustrations from one's user base. Think about it.