Posts by Minotorious

the permission system is not related to the API, and yes it is very basic to allow/deny general features.

the plugin API can do what you are asking.

public void onPlayerDestroyTerrain(PlayerDestroyTerrainEvent event){
	Player player = event.getPlayer();
	Item item = player.getEquippedItem();
	if (item != null){
		if (item.getName().equals("pickaxe"){
			event.setCancelled("true");
		}
	}
}

PS: you should also do the same or add checks for other items you don't want people to use like the mining drill etc.

Are you using windows? if yes then Notepad++ adds two characters to signify the end of line this is most likely the problem, if you change the end of line delimiter to the Unix one only then it should work.

about the numbers I don't really know I would have to test to check it out

can you upload the permissions file, without it we can't really help you here

btw if you do:

world:
    deny:
    - destroyterrain
    allow:
    - *

then the allow all (*) overwrites your deny so they can do the "destroyterrain" action. To avoid that you need to do it like this:

world:
    allow:
    - *
    deny:
    - destroyterrain

Quote from Miwarre

In practice, you would prefer ORing the permissions of overlapping areas rather than ANDing them as now. The change in the code would be trivial, but are we sure this other solution is more general than the current one?

Even the example you quote might be approached in another way: does the large area have restricted chests all over its extent? Chances are the restricted chests would be in specific positions, as the public chests would be. So, it should be possible to define the large area with free chest access and ore (or more?) smaller areas for the restricted chests without chest access (rather than the other way around you describe).

We would definitely prefer the OR instead of AND. Let me give you another example, I have a big area that noone can build in and I want to have 10 small areas in it one for each out of 10 players so that they can build only in their sub-area. With the current AND method I would have to add all of the players in the big area (which will mean they can also build in parts of the big area outside of their small area) and then deny 9/10 players access to the other 9 players' areas. Not really convenient imo.

Here is a small drawing illustrating what I mean:

I think he is asking for this bit @Miwarre

Quote from Miwarre

Compatible with the old Area Protection 3 LUA script: existing areas are kept as it can read the old data base directly.

@Smudger This is literally the first line in the features list in the first post of the thread and written in bold letters. How on earth did you not see it?

Quote from Miwarre

Well, Java is not particularly slow (and anyway faster than LUA!).

I meant it in the sense that Java is much slower than C++ for example

Quote from Miwarre

The point is that, for each area, it has to be computed if the point when the action happens is within the area or without (which implies up to 12 comparisons); then for each area the action is within there are 3 Map lookups, 2 player attribute lookups, several tests and various "logic sugar".

Quote from Miwarre

In the current implementation, all the above computation is reduced to just one single bitwise AND!

I know that it will be more computationally expensive to do the area checking but for us and I presume quite a few others the reach in issue is something we cannot accept in an area protection plugin as it defies its purpose, it does not protect our whole areas

We can at least try it get on a server (or a steam p2p game) create 1000 tiny areas everywhere and then start mining, we could gather 10-12 people for testing at a convenient (evening for europe lunch time for the US would probably work the best I think) time I think

Quote from Miwarre

I was expecting comments on this point, but none was made so far. The current solution allows to reduce the load on the server significantly, can you elaborate why it is such a big problem and why for creative servers in particular?

I understand the reducing load problem as with your Area Attribute solution you save a lot of computations from iterating over all areas as red51 told me a few days back. But is it so bad to iterate over 1000-5000 areas? Java is slow but it is not thaaat slow

I said for creative servers mostly as for PvP servers destroying other people's stuff is part of the game so even if they use some AP settings most of it should be fair game to destroy from inside or outside the area.

Now it is a big problem as when I give a player an area 200x200 blocks they expect it to not be able to be griefed in its whole not have a small 2-3 block perimeter where it can be dug or their builds destroyed Also when I want to protect roads or portals I want to be able to have small areas around them to allow for the rest of the space for player areas but such small areas with the reach-in issue would lead to all our roads and portals destroyed by a griefer

Edit PS: our server is quite big and we constantly only have about 2000 areas as we remove old areas after 30-40 days of inactivity

Quote from Miwarre

but there is no PlayerSpawnEvent

but a player spawn event is always triggered no matter if the player is flying or not at least on all my games so far and on our server. For the EnterAreaEvent I would have to test

perfect that is what I suspected but needed confirmation before I go on a rampage with huge attribute names

Quote from Miwarre

"reach-in issue"

people outside an area hitting inside it for a short range biiiiiig problem for pve/creative servers unfortunately

The pivot position is the position on the Element the coordinates will start from. e.g. pivot of the element on the bottom left with an absolute position at 2px/3px means that the bottom left corner of the element will be at the second pixel left from the bottom left and the third pixel up from the bottom left.

Quote from Trevor

I see here that the anchor point is relative to the bottom-left of the GuiPanel and that positive coords send the image up/right in all cases. From having dug through the threads here, I expect this is "working as intended" as that's the way that OpenGL does it.

It is not so the anchor point but more the 0,0 origin of X/Y coordinates.

Quote from Trevor

I want to put (for example) the close button at the top right of the GuiPanel.

For this I would recommend doing pivot top right and relative coordinates 1,1. This way you get your element at the top right but since the pivot is to the right of the element, the actual element remains inside the panel.

Quote from Trevor

I don't want to use relative coords as they're imprecise.

Why? relative coordinates are the most precise when it comes to people playing on different monitor sizes. If I open your a 100x100px GuiLabel on a 1920x1080 screen I can see it ok, but if I open the same in a 4K monitor I can't see it at all as it is tiny, thus the need for relative sizes and coordinates, it takes a bit more time to get it right (I would recommend working down to 3 significant figures i.e. 0.001) but when done everyone sees it exactly the same no matter their screen resolution

Quote from angriff

Since the player has the attribute you say we can get the definition it from him. I was initially looking for it to be defined in the event or something like comparing the text but get text is not available in PlayerGuiElementClickEvent just element. I am not sure I would have looked at the player having it.

The event can only give you the internal ID of the GuiElement, that ID is unique to that element but it can change every time the server restarts so I don't think of it as a reasonable number to use for defining my GuiElements.

Quote from angriff

Still having trouble grasping why the player has to have it and I cant get it from the text or ID from the event but then only the single player has to see it. So thanks.

If you want every player to have their own Gui and be able to interact with it independently of what other players do with the same Gui then the Gui must be saved as attributes on the Player object. If you just need a generic box that every player can click and something happens only for the player who clicked it but the Gui doesn't change by that click then you could have your Gui instanced only once and registering all the clicks from all players without it being player specific.

For example if you wanted to implement a generic heal button them you could just put a GuiLabel always visible on all of the players' screens and when any one of them clicked it then that player got healed, in this scenario there is no point in having a separate GuiLabel saved to the player as the label is not altered by what the player does with it (i.e. click it).

since you are saving the GuiElement as an attribute for each player you don't really need the internal id of the element. Not to mention that the internal ID can be different after every restart.

So you could simply use something like this:

@EventMethod
public void onGuiElementClick(PlayerGuiElementClickEvent event){
    Player player = event.getPlayer();
    GuiElement element = event.getGuiElement();


    if (element == (GuiLabel) player.getAttribute("myLabel")){
        //Do something
    }
}

PS: if (box.equals(player.addGuiElement((GuiLabel) player.getAttribute ("closeme")))) this line is absolutely wrong, you are re-adding the element to the player while checking if the element has been clicked. Makes no sense at all

I was wondering is there a limit imposed by the game on the number of characters attribute names can have? I know that in general Java allows for arbitrarily long method and variable names but wanted to ask just in case

Quote from angriff

The cursor being on will not allow you access to to the command line or RCON. Basically until you have the return to turn off the cursor it will lock you in cursor mode forever with no recourse but to log off.

sorry for not replying earlier to help. I was away for a week

I see @Trevor posted and implemented my example to help @angriff out very well done thank you for stepping in to help

I would recommend opening the GUI and showing the cursor (player.setCursorVisible(true);) via command (PlayerCommandEvent) or by pressing a key (PlayerKeyEvent). Then on the GUI you can have a "close" button (i.e. GuiLabel with .setClickable(true);) which when clicked (PlayerGuiClickEvent) would close the GUI and hide the cursor for the player (player.setCursorVisible(false);)

Yes i think it was done but can't remember what name it wa uploaded under. But if you own the servee you can just open the world database to see all players

Edit: found it, [Plugin] List all Players

hmmm no there isn't really a tutorial but I can post some code snippets of how I do GUIs in the game, I like simple so my approach is very simple to follow

So first you need to create your panel and a label e.g.

public static GuiPanel createMainPanel(){
        GuiPanel mainPanel = new GuiPanel(0.5f, 0.5f, true, 0.65f, 0.9f, true);
        mainPanel.setColor(0.0f, 0.0f, 0.0f, 1.0f);
        mainPanel.setPivot(PivotPosition.Center);
        mainPanel.setBorderColor(0.0f, 0.6f, 0.933f, 1.0f);
        mainPanel.setBorderThickness(2, false);
        mainPanel.setVisible(false); //I use this as false so that the elements don't appear one I add them to the player but only when I call my show/hide function


        return mainPanel;
}






public static GuiLabel createHeaderLabel(){
        GuiLabel headerLabel = new GuiLabel("SomeLabel", 0.0f, 1.0f, true);
        headerLabel.setPivot(PivotPosition.TopLeft);
        headerLabel.setFontSize(20);
        headerLabel.setFontColor(1.0f, 0.533f, 0.0f, 1.0f);
        headerLabel.setColor(0.0f, 0.0f, 0.0f, 0.0f);
        headerLabel.setVisible(false);


        return headerLabel;
}

Then you need to instance your panel, add to the player as an attribute and add it to their Gui

//This method should be called in the PlayerSpawnEvent


public static void setMainPanelAttributes(Player player){
    GuiPanel personalMainPanel = createMainPanel();
    GuiLabel personalHeaderLabel = createHeaderLabel();
    //if your element is a label or child to the panel you also need to call the .addChild Method here e.g. 
    personalMainPanel.addChild(personalHeaderLabel);
    player.setAttribute("MainPanel", personalMainPanel);
    player.setAttribute("HeaderLabel", personalHeaderLabel);
    player.addGuiElement((GuiPanel) player.getAttribute("MainPanel"));
    player.addGuiElement((GuiLabel) player.getAttribute("HeaderLabel"));


}

Then I create my show/hide method to display the panel and label

//This method can be called by e.g. a PlayerCommandEvent, or a PlayerKeyEvent to show the GUI, then you can call it with showhide-false to hide the GUI after the player has clicked something on it via the PlayerGuiClickEvent


public static void showHideMainGui(Player player, boolean showHide){
        GuiPanel personalMainPanel = (GuiPanel) player.getAttribute("MainPanel");
        GuiLabel personalHeaderLabel = (GuiLabel) player.getAttribute("HeaderLabel");


        personalMainPanel.setVisible(showHide);
        personalHeaderLabel.setVisible(showHide);
}

Quote from angriff

Hmm.. will it trigger everytime they spawn? Even after they die or sleep?

After you sleep you don't spawn you just exit sleeping mode see PlayerSleepEvent

After you die you don't spawn but you RE-spawn see PlayerRespawnEvent

no you cannot change the time it is visible. The time depends on the length of the message and is handled by the game itself.

But why do you want to use a yell message? Personally I find them extremely annoying and wish there was a way to say in the settings that I don't want them appearing at all

yell messages do not support colour, they are only white.

and no you cannot change the fonts size but the default should be big enough for anyone to read