Posts by Miwarre

It is a while I wanted to post this, but I always forgot!

When opening the console ('\'), I consistently get an extra '\' already showing in the command line, except the first time of each session.

I mean:

• First time: 'clean' command line
• Second time and following: extra '\' at the beginning of the line, which has to be deleted manually

If I do not delete it and close and reopen the console, I get two, then three and so on, one for each time I open the console and do not delete the extra '\'.

System: Linux Mint 19.3, nVidia 1060.

red51 : thanks for the detailed reply.

And thanks to Avanar , Deirdre and insG_Drifter for the replies and the welcome!

(Incidentally, I now have the health and the time to play RW again; not too much yet, but thanks to Sammwise, SquishCorg and the Planet X folk for luring me in again!)

Not sure if this fit here or in the "New Version" section, but I assume from other threads that:

1. The PlanksAndBeams (a.k.a. PnB) plug-in (or equivalent) will be useless in the new version. given the new construction system.
2. Will the new version include an Area Protection feature already or will a plug-in like AP still be useful?
3. Same for the GPS plug-in.

Correct? Thanks!

(Of course, I think about my own plug-ins first, but the topic may be expanded)

1) Explosions:

Quote from sharkbitefischer

[about explosions] it seems that area base permissions over ruel the player permissions and admin priv

This is precisely what I have said above:

Quote from Miwarre

in some circumstances, the API does not tell the plug-in who the player is who planted the TNT and the plug-in has to rely on the generic area permissions.

as there is no player for whom to check permissions or level.

2) Immediate permission update:

Quote from Jon_miner

Ok... something interesting. I had done a restart on my test server for a change that I made and now the permissions DO take a affect right away. Don't understand??

Do you mean that so far you replaced the plug-in with another version without restarting the server? It does not surprises me it was not working: chances are that, as far as the plug-in was concerned, the players did not result logged in at all and therefore their permissions were not updated.

Can we consider this issue solved?

3) Go to area:

Perhaps I do not understand the point: why the current "Go to Area" command is not suitable? Do you require a special "Go to Area" command? Under which circumstances?

Quote from sharkbitefischer

when a regular player is set to manager he can not edit player permissions properly unless he adds himself to the area as owner or admin.

This only happens if "Admin priv." are turned OFF and it is more or less by design (as in this case, non-explicitly granted permissions ARE turned off); if admin priv. are turned ON, managers can edit all permissions of other players.

"Admin priv. OFF" is a kind of debug setting; these privileges are assumed to be normally ON.

Quote from sharkbitefischer

also, when having owners rights or admin rights on an area, I placed a stick of tnt and lit it and it would not blow up. It doesn't blow if you have explosions on or off now.

By "you have" you mean "you, as personal player permissions" or "generic area permissions"?

The first case is in some circumstances expected: in some circumstances, the API does not tell the plug-in who the player is who planted the TNT and the plug-in has to rely on the generic area permissions (this is described in the manual). The latter is NOT expected.

Quote from sharkbitefischer

The fuse burns but no boom and you can't remove the tnt after it is lit. F7 removal tools will not remove the tnt either.

I assume this has nothing to do with the plug-in, but with what happens as RW level when the explosion is cancelled.

Quote from sharkbitefischer

we still need a way to edit secondary areas while within them. A go to area list button would be very handy.

The general "Go to Area" button is only two mouse clicks away (only one more than having the button in the Area Properties dlg box itself): press "UPDATE" and then press "Go to Area" in the main menu.

After having thought about it, I prefer to have to press the "UPDATE" button explicitly.

Quote from sharkbitefischer

When adding a player or editing a player's permissions, they have to log out and back in before the permissions take effect.

Well, I cannot replicate this in a debug session: to me, edited player permissions are immediately available to the player. Can you give me a precise list of steps?

Quote from Jon_miner

I noticed that newly created areas are always at the top of the list (not sorted alphabetically) until the server is restarted. Not a big deal, but can they be sorted right away?

They should be sorted right away (in fact, they are in my test server)

Quote from Jon_miner

It appears that you can't quite put a BP right to the edge of an area that you have BP permission (can put one block in). This may be by design and should be fine.

Very probably this is due to the same API bug about 1 block off coordinate conversions.

Quote from Jon_miner

Now changes to permissions appear to be taking affect right away instead of having to re-log on my test server now. Yeah!

And then (in another message) they seems no longer work. As they consistently work (since several updates) on my local test server, I cannot reproduce this issue, which might be due to something other than the plug-in; see my answer above to sharkbitefischer: a precise list of steps could be useful.

Version 1.0.7 released!

Version 1.0.7 is available from the thread top post.

1.0.7 Change log:

- [new] Added a search box to area lists and to player lists: by entering at least 2 characters and pressing the Search icon, the list is
shortened to the entries contains that sequence of characters
- [new] Better explosion control (please read the relevant manual paragraph; feedback welcome)
- [new] With blueprint events ("Create Blueprint" and "Place Blueprint") spanning several areas, to determine if the blueprint can be created/placed, the permissions of the areas are ANDed again
- [fix] various bug fixes, including a nasty bug with permission ORing

Enjoy!

I am leaving for a week and I will be back on August 12th evening. In the meantime, I will not be able to read any post or message nor to do anything on the code. I hope there will be no serious problem with the last version of the plug-in...

See you next week!

@MasterLex: agreed, it is not a very high priority, but I still think it could be rather useful in a number of scenarios:

1) a player was granted an area on a server, did some work and then disappeared; the grant can be revoked, but the area is spoiled;

2) even in single player mode, I can realise I made a planning error or something equally structural

In all these cases -- and other similar -- it would be convenient to have a way to reset a "piece of the world" to pristine conditions, without resetting the whole world. How the extent of "piece" is defined can be discussed (just an X range and a Z range, extending vertically "from Paradise to Hell"; a 6-value 3D span; any other way).

What matters is that anything player-made (or played-removed!) within the "world piece" would disappear (or reappear!). Of course, it has to be a very privileged operation.

Quote from angriff

So basically the question is this. If I have a plugin that as a variable <player> and another plugin has a variable public <player> can my player be overwritten by the other plugin's player if both are event driven?

Not by itself. Particularly if the two plug-ins are in different packages, you have to code explicitly the first plug-in to be reachable (classes must be public, variables must be public and possibly static, and so on) and the other plug-in to look for it (using the first plug-in name with the Plugin.getPluginByName() API method) and write into the first plug-in variable explicitly.

Whether plug-ins are event-driven or not is largely irrelevant (in a sense, almost all plug-ins are event-driven); what matter are scopes and access levels; and Java does a rather good job in avoiding casual inter-package accesses.

Quote from angriff

Eventually a server becomes a hollow space .. if the owner does not tidy up and restock.. players dig to the dungeons then leave.. the next guy gets left overs.. would be nice to have routine to reset the dungeons without a server wipe.

Yes, I totally agree. In fact, I was thinking to ask for an API method the remove all customisation from a world part (either an X / Y / Z extent or one or more chunks or whatever, according what is more convenient to implement).

public void onObjectInteraction(PlayerObjectInteractionEvent tcevent)

and

public void onObjectInteraction(PlayerObjectInteractionEvent vent)

are totally equivalent.

playerreal = Player player = tcevent.getPlayer();

is non-syntactical: you would not even be able to compile it.

Quote from angriff

Problem is if someone does another event then the event tag in another plugin seems to change for event.player.

What you mean by "event tag"? In another plug-in? It seems hard to figure out what you are trying to do and then what might be wrong.

Some code excerpt would also help in understanding...

Quote from angriff

well I thought it was a local server event and if it had the same name..

Would mind defining "local server event"? On it surface, it seems a self-contradictory clause; or is it intended in a rather peculiar meaning...?

And what has the same name of what?

Glad eventually things fell into place.

Quote from angriff

PS dont put the add in the onplayerspawn or you get tons of them.

Of course! An area has to be added only once, not every time a player connects or spawns.

Quote from angriff

[..]The Lua script uses a database and theon PlayerChangePosition Event to track people so it can negate a movement into an area.

Listening to the PlayerChangePositionEvent to track players entering and leaving areas is a strange choice; the server already does that and triggers PlayerEnter/LeaveAreaEvent whenever this happens, so it is a duplication of work (possibly the LUA script listens to PlayerChangePositionEvent also for other reasons and/or the PlayerEnter/LeaveAreaEvent were not available yet when the LUA script has been written).

Check that the LUA script adds to the server the Areas it creates (right now I cannot do it myself); if it does, then simply use the PlayerEnter/LeaveAreaEvent to know when a player enters or leaves an area.

Quote from angriff

I just want to piggyback onto the area to do other things.
I could read the database but since it is always using it I wanted to avoid the conflict possibility. I will try your suggestions.

Reading from a DB should not raise any conflict, but:

1) if the DB is read at start-up and than kept in memory (which could be wise to minimise CPU load), data would become obsolete once a new area is added or an existing one deleted.

2) Again, you would have to check players crossing area boundaries, which is a task the server already does; as PlayerChangePositionEvent is a very frequent event, minimising the work done in it is quite important.

Area is an RW defined class; once a plug-in defines an Area object and adds it to the Server with the Server.addArea() method, whenever a player enters or leaves it, a PlayerEnterAreaEvent / PlayerLeaveAreaEvent will be generated and any plug-in listening for them will know about.

The important point is adding the defined Areas to the server.

I cannot be 100% sure about the old LUA script, but I imagine it does exactly that.

This is completely separate from having access the the areas themselves from other plug-ins. In my plug-in, I chose NOT to give this access, as adding / deleting / modifying an area requires collateral housekeeping jobs and therefore should only be done via the plug-in itself and not from other plug-ins.

As RW does not support, as far as I remember, any inter-LUA-script communication, I imagine this external access to the Area objects themselves to be impossible with the LUA script

As I asked in your other post of this question, which plug-in? PlayerEnterAreaEvent is an event any plug-in can listen to, if it needs.

Quote from angriff

I am not sure but I think if a player is owner he can remove it.

The principle I used in the coming Java area protection plug-in is: if you cannot re-create it, you also cannot delete it, which implies that the regular user (non-admin) is not able to delete an area he "owns".

Quote from angriff

The question I have is are areas declared in the Lua script useable in the plugin PlayerEnterAreaEvent?

I do not understand the question. PlayerEnterAreaEvent is not a plug-in but an event, which any plug-in can listen to, if it needs.

And eventually the point is? Are you asking something? Or complaining about something? And complaining with JIW or with your fellow players? Sorry, but I cannot make an overall sense out of you post.

Quote from red51

Do you just need it to allow certain characters only? In this case we could add a new method like "setAllowedCharacters()", preferably in combination with a regex. This way you can make sure the player can only enter numbers, for example

As far as I can tell, I believe this would be the kind of cases @Minotorious might be referring to. The usual use cases are: integer numbers, decimal numbers, arbitrary texts.

A selector INTEGER_ONLY (allowing just ,'+', '-', and [0-9]), FLOAT_ONLY (allowing ',' and/or '.' in addition), ANY (allowing any input) would already go ahead a long way.

A regex would allows more flexibility like deciding the number of decimal figures and so on. Possibly allowing to specify a regex would already be enough, as far as I can tell. Of course, this can entirely happen client-side, once the server has sent it the regex.

(Should RW go Unicode in the future, things would become much more murky, as in Unicode "digits", for instance, cover a lot of things more than simply [0-9], but we will cross that bridge when we'll get there, I suppose).

Yes, this is definitely a consequence of changing the AND into OR. I overlooked the fact that, while ANDing, you start with everything allowed (as when without any area) and each area you are within "carves" its prohibitions out.

But, when ORing, you start with everything if within no area, but if within one or more, you start with nothing allowed and each area "adds" its permissions. So, this case is more complex logically and it is not simply a replacement of one logic operator with another.

I'll fix it...

Version 1.0.5 released!

Version 1.0.5 is available from the thread top post.

1.0.5 Change log:

- [new] Added area extent editing while creating an area and after creation; all the 6 boundaries can be edited
- [new] When within multiple areas, total permissions are united (OR) rather than intersected (AND)
- [new] Added chat shortcuts for each main menu item (see manual for details)
- [new] Admin privilege ON/OFF status shown in area status text of admins/managers
- [new] Compensated for an oddity in event notification order from the plug-in API (see here for details)
- [fix] Fixed exception on editing area manager list
- [fix] Fixed exception on some combinations of list selection and scrolling

Note: the images in the manual have not been updated, but the manual text should be up-to-date with the current plug-in status.

List search box will be included in the next update.

Enjoy!