Posts by Miwarre

Quote from sharkbitefischer

ok so the permissions of the second person in the smaller claim is dependent on the first player's permissions for the larger area and the first person's permissions are restricted by the second player's permissions in the smaller area when in the smaller area?

Well, not exactly: each player is separate; 1st person permissions for the larger area and 1st person permissions for the smaller area intersect each other; while 2nd person permissions for the larger area and 2nd person permissions for the smaller area intersect each other. But permissions of 1st person and permissions of 2nd person are completely independent.

(Of course, this assumes each player is given specific permissions for area A and/or B; by default each area has its own "generic" permissions which apply to any player without specific permissions, but any player can be given specific and independent permissions for each area).

Quote from sharkbitefischer

after setting an area manager, is the manager position transferred to all areas thus allowing them to assist with the setting of areas/claims? or are they restricted to making changes to the existing areas only?

An area manager has authority on all areas, past, present and future!

Quote from sharkbitefischer

When altering area dimensions, will there be an easy way to move the center point or will we have to guess and enter numbers? I would think a select center point button on the area dimension edit screen would be advised. click on the button, then maybe the window closes and you click on where you want the center point to be and the area edit window reappears?

This would be very nice, but for sure it will not be there in the first implementation, and I am not sure the API would allow it (but I'll see if something of the kind is possible).

Quote from sharkbitefischer

this will be fun checking on the already set areas that are overlapping or just plain inside other areas.

This is not a problem for the plug-in: areas can intersect or be one completely inside another freely, each with its own permissions, player list and group list.

Quote from sharkbitefischer

how would I set up a main claim, with a sub area that I wanted another player to be able to work in, without allowing them access to the rest of the claim? and could I remove access to the smaller area for the owner of the larger area without looseing access to the smaller area by the second person?

Well, this IS a problem: areas can intersect freely, but what each player can do within the intersection is the (logic) intersection of the permission he has for each area; in other words, if in area 1 he can do action A but not action B and in area 2 he can do action B but not action A, in the intersection of the two areas (if any) he cannot do either action, action B because he is within area 1 and action A because he is within area 2.

In other words yet, areas cannot have "holes", portions inside them where the area restriction do not hold, as this would make things very complex to manage for admins (and managers) and for the plug-in to compute.

Quote from sharkbitefischer

could we have a "goto area name list" button, from the edit window, when we are standing in an area?

Possibly I do not understand. By "go to" you mean:

1) Being physically moved from the current area to another area you select on the list? This does not seem to me very useful, as while working in a dialogue box you cannot look around or move around and then being in a point or in another makes little difference.

2) Leave the editing of the current area and open the editing of another area you select in the list? In case, do you want changes to the current area saved automatically before switching?

Quote from sharkbitefischer

to be able to adjust permissions or add a player to the sub claim "only"

Currently, the plug-in has no concept of "sub-claim" or "sub-area"; there are areas which simply overlap. And I am reluctant to add it, as it would quickly make a mess of hierarchical relationships difficult to manage for the players and slower to compute for the plug-in.

Quote from noci

I noticed that already, I thought that it should be like that, saving memorey. But it could also be that then only the event is collected

Sorry, I do not understand your point: this is not a memory saving, it is an inconsistency between what is shown to the player and the internal data. Then, it should NOT be like that.

Quote from sharkbitefischer

I am not shure of what I am looking at but the 3rd choice looks like the better one I think.On the x, y cords is that the cords of the center point and the width is set in both directions from that as well as the depth? then you set the bottom and the top elevation? so for a 120x120x120 claim it would be width 60, depth 60, bottom height 60 and top height 60 measured from the center point in all directions? Or are they set from the center point as 120 and the game divides the area on both sides of the center point?

example

we will work from spawn with cords of 0 0 0 for ease of talking.

with the x width being 60 does the width get placed in both directions from the point or is it split between both directions to be 30 blocks on both sides of the point?

Display More

In my idea, width is width, from one edge to the other! Not half-width. This is what interests players (and admins), I think, how wide along the x (or deep along the y) is the area; to arrange that width (and depth) around the centre is the job of the code!

(this raise the point of what to do with odd widths, like 75, as there cannot be half blocks; but I'll see).

The difference between 2) and 3) is in the height:
in 2) height is treated like the other two dimensions: a span around a centre
in 3) height is expressed in absolute coordinate (as in 1), as in "Bottom: -600 | Top: 400"

I think 3) makes more sense than 2): "Bottom: -600 | Top: 400" is more clearly understood than "Centre H: -47 Height: 1000" (assuming the surface is at height 53 in the centre point).

Quote from sharkbitefischer

will regular players be able to delete there own claims?

No, only admins (and managers)

Quote from sharkbitefischer

or just the sub claims they set within there claim?

are regular players allowed to set sub claims?

No, at the moment. And, while possibly useful in special cases (which the admins/managers can always set up if needed), area splitting into sub-areas seems to me rather Baroque as a general concept available to everyone.

Quote from Jon_miner

Sorry for the delayed response... Your query resulted in: "Error Code: 1273: Unknown collation 'NOCASE'
The following query worked with 3821 rows returned with valid ID & Names.

SELECT `ID`,`Name` FROM `Player` ORDER BY `Name`;

I did notice that I have some players in the DB with spaces in their names with some of them even having a leading space...

I was starting to suspect something like this: collations are different from MySQL and SQLite. Which collations are implemented /installed / configured also changes from one version of MySQL to another and from one installation to another.

I could do something like:

WorldDatabase worldDb = Protection.plugin.getWorldDatabase();
String query = "SELECT `ID`,`Name` FROM `Player` ORDER BY `Name` COLLATE "
    + worldDb.getType() == DatabaseType.MySQL ? "latin1_general_ci" : "NOCASE";
try(ResultSet result = worldDb.executeQuery(query))
{
   // process result
}

if I can safely assume the latin1_general_ci collation be present on all versions and installations of MySQL.

Otherwise "SELECT `ID`,`Name` FROM `Player` ORDER BY LOWER(`Name`)" should be correct in any SQL context, but I have no idea how it would work with accented characters.

In SQL, I am more a "final user" than else; has anyone with a stronger knowledge something to suggest?

Scenario:

1) a player attempts to remove a vegetation specimen (say, a group of flowers, but I suspect the actual type is irrelevant)

2) a PlayerRemoveVegetationEvent is generated

3) let's assume a plug-in cancels the event

4) result: the group of flowers is not collected and remains visible in place and the cursor on it turns into a hand

So far so good. However, if the player attempts to remove it again, no event is generated, as if the vegetation be no longer there.

It remains so, until the player moves away enough for the chunk to be unloaded. When the player comes back there and attempts to collect the flowers again, the cycle resumes as above.

Summary: it seems as when this event is cancelled, the target object is not completely removed and remains visible, but it is anyway removed from some internal data structure.

Perhaps this applies to other world modifying events too?

Quote from sharkbitefischer

this sounds worth waiting for. This bug is the only 1 I can realy find so far, left. we can waite for editing the area dimensions after creation for a fix. please continue and we can come back to this later and the surch box will be a great addition too I think.

Ok. Area extent editing is more complex than it may seems, as RW does not allow to change the extent of an existing area; so, I need to destroy the area with everything is attached to it (the visible box, the permissions, etc...), recreate it with the new extent, recompute all cumulative permissions of players (who may pass from inside to outside the area or vice versa) and reattach a new visible box... But it is definitely worth the effort.

Question: the dialogue box where the values of the area extent is edited can be organised in various ways:

1) By min/max boundaries:

N: ____


   W: ____        E: ____


           S: ____


Bottom: ____   Top: ____

2) By centre point and extents:

Centre point X: ____     Width: ____
             H: ____    Height: ____
             Y: ____     Depth: ____

3) A mix of the two:

Centre point X: ____     Width: ____
             Y: ____     Depth: ____


 Bottom height: ____       Top: ____

Which do you think it would be more useful?

Quote from sharkbitefischer

I was asked to ask this question.
Is there a way that the ability to create claim areas could be given to a non admin person or group? or is this an admin only function?

...(read the manual)...
"Area managers" are exactly that: regular, non-admin players who have full area managing abilities. Only admins can make a player an area manager, but once appointed, that player can work on areas exactly like admins.

I decided not to use a group, as a player can belong to only one group and I doubt all the area managers would be equal under all other respect.

I'll look into that error. Thanks for the log.

@sharkbitefischer: thank for testing!

I'll check it of course, but for the moment being, I think I'll leave as it is in any case, waiting a few days for more testing of other features and cumulating updates; having to get out and back into an area might be annoying but it is not a "show stopper" (as the need to reload the plug-in or restarting the server would be).

I am also working on adding a search box and the ability to modify the area extent after the fact.

Quote from Smudger

is that a disease ?

It is an "in-ease" !

Version 1.0.2 released!

Version 1.0.2 is available from the thread top post.

1.0.2 Change log:

- fine tuned what the "Admin no Priv" flag turns off
- "Go to area" now lists all areas rather than owned areas only
- Adding/removing a player to/from an area is now immediately active, rather than after plug-in reload
- Areas a flying player is in at spawning are now detected immediately (by-passing a RW bug)
- Corrected a few bugs in group management

Enjoy!

Hmm, this sounds weird. It looks like the MySQL DB is defined differently than the SQLite DB. Would you mind executing this query on your local MySQL server and see if it works as one would expect:

"SELECT `ID`,`Name` FROM `Player` ORDER BY `Name` COLLATE NOCASE"

(this is one of the queries the plug-in is executing on the World DB)

@Jon_miner: I understand that you are working on a copy from a (rented?) on-line server with MySQL World DB into a local dedicated server also using MySQL World DB. Correct?

If this is correct, then how did you move the world DB? I might be wildly mistaken, but simply copying the <WorldName>.db file (if it exists) from the on-line server to the local server is not going to work, as both use MySQL DB, and MySQL servers usually store the DB in a specific directory, not easily accessible.

If, on your on-line server, you have access to either PhpMyAdmin or the mysql client programme, then you could generate a textual DB dump to download and import into your local MySQL server. I really believe that otherwise no player (except perhaps yourself) is defined in your local MySQL World DB.

About the group names, you are correct: there is a bug in the list display; it will be fixed in the next release in a few hours. Thanks for the report!

Maybe your mouse is aging? Clicks less reliable than they used to?

What happens at 2AM next day?

Second point: I assume this is a commercial rented server running on a shared host. Please never, NEVER EVER use a Windows machine as host! Windows is simply not made for this; if you at all can modify your lease, switch to a Linux host.

It is a shot in the total dark, but from the log it could be like the RW server trying to read from a file (or folder) which either does not exists or it has no permission to access, as if RW server set-up was not correct / complete.

But of course, this is really a wild guess.

P.S.: next time, please attach the log rather then pasting it into the main post, as lines are all scrambled...

Quote from mickeyjay88

I tried what you suggested and it seems that walking in and out doesn't work but relogging does seem to do the trick.

Yes, I reviewed the matter and an update will be posted this evening/night (Central Europe time).

Quote from Jon_miner

I am trying this plugin on a copy of my online multiplayer server (copy as a local dedicated server) which is using a MySql Database (not a SqLite DB). It appeared to "import" all of the areas from the old LUA script DB properly. I had copied all of the old .group files to the plugin presets folder and renamed as .preset (replacing the supplied ones).

Ok, this is correct for on-going AP running. But it is not correct for initial old data importing.

As the manual says, you have to move or copy the whole folder of the old AP LUA script as it is with all its sub-folders into the new plug-in folder (refer to the manual for an illustration of the resulting folder structure) before the first run of the plug-in.

During the import, the plug-in looks in the copied DB and in the copied Groups for data it needs. Once the data imported, you may remove/delete the copied old LUA folders, as they are no longer needed.

Quote from Jon_miner

However several things do not seem right.

- All of the Players listed in the imported areas are listed as "null (Admin), null (Friend), etc."
- No "Owners" are showing in the imported areas. They appear to be marked as "Admin" (hard to tell as all player names are "null")
- When I attempt to create a new area and add players, no players are listed at all.
- When I attempt to add a group to a created area with "Friend" preset, the group gets added as "null (Friend)"

The 1st point is because the player id's listed in the old LUA DB are not defined in your local world DB; so the importing process cannot attach a name to them.
The 2nd point is because there is no AreaProtection/Groups/owner.group in your ap plug-in folder where the old definition of owner can be looked for.
The 3rd point is because there are no other players defined in the local world DB?
The 4th point I do not understand; are those groups defined in your local server?

Quote from Jon_miner

Does this plugin only work with a SqLite database and not when using a MySql database?

I cannot see any reason why it should not work with either SQL flavour, as this only affects the world DB; the plug-in own DB is defined internally to be SQLite and the world DB is accessed through the defined API and should then be independent from the actual DB implementation.

Quote from Smudger

I had a similar experience trying to set a user as an owner of his area on my server, but his name had been written in German and he was using an Umlaut above the a in his name.

Well, this should not be a problem: either string manipulation within a plug-in and/or SQL data processing should not be affected by non-ASCII characters.

Quote from Smudger

ö Alt 0246 Option + u then o
ü Alt 0252 Option + u then u
Ä Alt 0196 Option + u then A
Ö Alt 0214 Option + u then O
Ü Alt 154 Option + u then U
ß Alt 0223 Option + S

or am I missing an even more simple way...?

Display More

Well, yes, under Linux it is simply: ComposeKey then a then " (or ComposeKey then " then a. Same for Ø, Đ, Ş, Ṫ and so on...

Come on guys, this is year 2018; Unicode is out since 27 years...

Quote from sharkbitefischer

also when logging in, even if you know you are in an area, it acts like there is no area until you move in any direction. example if I am on a claim that I have no permissions for and login, before I move I can dig holes in the ground at least and maybe do more then that until I move just a little bit then the area sign pops on and I am restricted from doing anything again.

Ok, I re-checked this and, in fact, the plug-in is not notified of the area the player pops into, if the player is flying. If the player is NOT flying, the plug-in is notified by RW and things work correctly since the beginning. I'll alert red51 and I'll try some work-around for the time being.

Assuming a player spawns into an area (already defined and added to the server with Server.addArea(Area)), according to my finding:

• if the player is flying, no PlayerEnterAreaEvent is triggered; PlayerSpawnEvent is triggered regularly;
• if the player is NOT flying, the correct PlayerEnterAreaEvent is triggered, but there is no PlayerSpawnEvent

Having the same events triggered regardless of the player flying status would simplify several things...

Quote from sharkbitefischer

ok tnt is not protected from. I managed to get the admin privileges turned off like you said. I tested just about everything and it all checks out except tnt. It will still blow holes in your buildings no matter what setting I used.

I tested dropping a light TNT tube and it is blocked. How did you test it?

Quote from sharkbitefischer

Also when adding or removing a player from an area, it is requiring a server restart before changes are registered and work.

Well, a server restart seems to me rather extreme; possibly, as I said in a previous post, it may be necessary for the player to get out of the area and back in, if he was within the area at the moment of the change. I am fixing this, though.

Quote from sharkbitefischer

also when logging in, even if you know you are in an area, it acts like there is no area until you move in any direction. example if I am on a claim that I have no permissions for and login, before I move I can dig holes in the ground at least and maybe do more then that until I move just a little bit then the area sign pops on and I am restricted from doing anything again.

Does this happen in SP or MP? In SP it might be kind of expected until the player connect event if fixed. In MP, this does not match my findings (I'll redo my tests to be sure, but I tested this point many times).

Quote from sharkbitefischer

Another little request. Could you make the lists able to be scrolled by hovering over it and using the mouse wheel? It would make paging through a list of 2000 names a lot quicker and not wear out our mouse buttons by clicking on the down triangle as well as not give us carpel tunnel ? or maybe even the ability to use pgup and pgdwn to scroll through the lists would be sufficient.

Neither hovering nor mouse wheel movements are sent to the plug-ins, as far as I know, so unfortunately this is not possible given the current API. [PgUp] and [PgDn] might be possible, if there is only one scroll list in the dialogue box; but if there are more than one scroll list -- as in the player + preset double list -- the dialogue box handler would not know to which of them to apply the [PgUp] and [PgDn] keys. I definitely plan to implement a search box, though; this should speed up things a lot.