FOSS gamedev and creative worlds

Ok it seems there is some lag between the update and the readme. I know it is not config.lau but settings.lau. I need to increase the max area to protect.

it says the max is 1024m^2, trying to increase it to 5000 or more. When I do it crashes on boot.

freejack wrote:Ok it seems there is some lag between the update and the readme. I know it is not config.lau but settings.lau. I need to increase the max area to protect.

it says the max is 1024m^2, trying to increase it to 5000 or more. When I do it crashes on boot.

Areas has no maximum or minimum size by default. And self-protection is limited to 50*100*50m^3 by default.
Do you mean Sokomine's markers mod?
It implements a GUI for areas and has a 1024m^2 hardcoded limit (although it's in a variable).

That is it thank you now off to figure it out.....

I may be missing something, but I follow the steps (using the chat commands) to create an area, set myself as the owner, and then use the protect command to prevent others from digging/building on it.
Now here's the problem: the area is listed as my area, but people are still able to build and dig on the area even after I use the /protect command.

Any suggestions?

The areas mod usually works pretty well and protecs reliably. Try my markers mod. It has a book and a marker stone that allow you to visualize the area. That way you can check if you protected the right place.

[Edit] Of course it might be that all your other players have extensive privs and are thus allowed to build in any area. Check if they got the areas-priv.

Sokomine wrote:The areas mod usually works pretty well and protecs reliably. Try my markers mod. It has a book and a marker stone that allow you to visualize the area. That way you can check if you protected the right place.

[Edit] Of course it might be that all your other players have extensive privs and are thus allowed to build in any area. Check if they got the areas-priv.

Oh, so if they have the areas priv, then they are able to build on protected areas?

BRICK wrote:Oh, so if they have the areas priv, then they are able to build on protected areas?

Yes. Players with that priv are area maintainers and can build there regardless of ownership. Do not give the areas priv to normal players. Only give it to your moderators/trustworthy players.

Sokomine wrote:

BRICK wrote:Oh, so if they have the areas priv, then they are able to build on protected areas?

Yes. Players with that priv are area maintainers and can build there regardless of ownership. Do not give the areas priv to normal players. Only give it to your moderators/trustworthy players.

Okay, thanks! That clears up a lot of confusion...

This is a pretty cool mod. It protects from dig and place, but not from anything else. So, you get these usage scenarios:

1) Set up a public place where the area is protected by an admin, so anyone can store or use items, but they can't change what those items are or where they are placed.

2) Set up a private place where the area is owned by that particular owner, using locked doors and/or locked chests to protect places/items completely from other users.

It wasn't completely clear from the description that this was the case until I tried this out, myself. There's also a few caveats:

- Doesn't protect your area from TNT or mesecon pistons (might have to adjust those mods if you use them).
- Doesn't protect your area from flowing water or lava placed on some kind of ledge a griefer might decide to build at the border.

gsmanners wrote:There's also a few caveats:

- Doesn't protect your area from TNT or mesecon pistons (might have to adjust those mods if you use them).
- Doesn't protect your area from flowing water or lava placed on some kind of ledge a griefer might decide to build at the border.

TNT mods should check for protection, as should mesecons pistons, using the protection API in the engine. File a issue with those mods. (Although there isn't area protection checking in the engine yet...)
Lava and water are virtually impossible to protect from as liquids need to be handled in the engine for speed. You can protect a few extra nodes to prevent liquids from getting to your things, and you can make tall areas so that greifers can't stack up over the top.

I was just thinking that you'd need something like a moat and a wall. It's classic protection all over again, but areas definitely helps even in that case.

Most servers at least disable lava buckets above ground. Water is easier to clean away, and in the rare occasions where lava above ground may do something good, asking a moderator to place it ought to be possible.

The area owners on the HUD do not seem to be working.
This happened just after I updated server to version 0.4.9.
Would anyone know what the problem could be? The hud.lua file is there.

CraigyDavi wrote:The area owners on the HUD do not seem to be working.
This happened just after I updated server to version 0.4.9.
Would anyone know what the problem could be? The hud.lua file is there.

0.4.9 has a bug in client initialization, the TOCLIENT_HUD_ADD command is sent, but it's sent before the client is ready to handle it. Update to a recent git build, wait for 0.4.10, or downgrade.

ShadowNinja wrote:

CraigyDavi wrote:The area owners on the HUD do not seem to be working.
This happened just after I updated server to version 0.4.9.
Would anyone know what the problem could be? The hud.lua file is there.

0.4.9 has a bug in client initialization, the TOCLIENT_HUD_ADD command is sent, but it's sent before the client is ready to handle it. Update to a recent git build, wait for 0.4.10, or downgrade.

At the moment it seems to sometimes show the area owners on the HUD but rarely.

So I need to update the minetest version. I use a dev build from January the 26th. Do I need a newer version?

CraigyDavi wrote:At the moment it seems to sometimes show the area owners on the HUD but rarely.

It's a race condition I believe, so your client might be ready in time, or might not.

CragyDavi wrote:So I need to update the minetest version. I use a dev build from January the 26th. Do I need a newer version?

It was fixed a few days after your build.

ShadowNinja wrote:

TenPlus1 wrote:It seems that cactus and tree blocks can be placed in a protected areas without any problems, any idea why ??

Yes. minetest.rotate_and_place ignored protection. I've fixed it here.

Works ok, am somehow still able to place doors though...

ShadowNinja wrote:

CraigyDavi wrote:So I need to update the minetest version. I use a dev build from January the 26th. Do I need a newer version?

It was fixed a few days after your build.

Ok thanks. I'll update it soon.

TenPlus1 wrote:

ShadowNinja wrote:

TenPlus1 wrote:It seems that cactus and tree blocks can be placed in a protected areas without any problems, any idea why ??

Yes. minetest.rotate_and_place ignored protection. I've fixed it here.

Works ok, am somehow still able to place doors though...

Same here. People can place doors in protected areas.

CraigyDavi wrote:Same here. People can place doors in protected areas.

That needs to be fixed in minetest_game in the doors mod.

TenPlus1 wrote:Works ok, am somehow still able to place doors though...

Fixed here.

What's the difference between /set_owner and /add_owner? For example, I (Admin) wish to grant another player (Moderator) access to the entire city (area ID = 1). It would be a sort of co-ownership. Do I use /set_owner, or /add_owner? What would each command do in this situation?

/set_owner is used for protecting areas for other people.
/add_owner is used for adding owners to an existing area.

So in your case if you wanted another player to access the entire city then using /add_owner would be best.

Unless you want them to only access a small area of the city in which case you would select a small area in the city and use /set_owner.

ak399g wrote:What's the difference between /set_owner and /add_owner? For example, I (Admin) wish to grant another player (Moderator) access to the entire city (area ID = 1). It would be a sort of co-ownership. Do I use /set_owner, or /add_owner? What would each command do in this situation?

/set_owner creates new areas that don't have parent areas.
/add_owner adds a new area and sets its parent the the area id provided. The new area must be fully contained within the parent area.

Administrators and moderators with the 'areas' privilege are able to use and manage all areas as if they owned them.
If the city is currently unprotected you probably want "/set_owner ModeratorName The city name". If it is already protected as you you should run "/select_area 1" followed by "/add_owner 1 ModeratorName The city name".

You should generally protect cities under whoever is the main developer of it.

CragyDavi wrote:Unless you want them to only access a small area of the city in which case you would select a small area in the city and use /set_owner.

Actually the /add_owner command is designed to be used for granting sub-areas. Just select the sub-area rather that the whole area before running it.

Could you consider changing the function 'areas:canPlayerAddArea' so that a player does not have to remove all sub-areas before being able to create an intersecting area ?

Something like:
- if area.owner ~= name then
+ if not area.parent and area.owner ~= name then

The following change would be useful as well, as a diagnosis tool:
- for _, area in pairs(self.areas) do
+ for id, area in pairs(self.areas) do
[...]
- return false, "The area intersects with an"
- .."area which you do not own."
+ return false, "The area intersects with area "
+ ..area.name.." ["..id.."]"
+ .." owned by "..area.owner.."."

Would it at all be possible to create a "negative area"? By this, I mean imagine a cube of space. That space is owned by me (ak399). Inside that cube, there's a smaller cube of space that I wish to relinquish ownership of. Currently, I must set six "walls" of ownership around that space to have the effect of an unowned space in the middle of an owned space.

Argos wrote:Could you consider changing the function 'areas:canPlayerAddArea' so that a player does not have to remove all sub-areas before being able to create an intersecting area ?

Something like:
- if area.owner ~= name then
+ if not area.parent and area.owner ~= name then

The following change would be useful as well, as a diagnosis tool:
- for _, area in pairs(self.areas) do
+ for id, area in pairs(self.areas) do
[...]
- return false, "The area intersects with an"
- .."area which you do not own."
+ return false, "The area intersects with area "
+ ..area.name.." ["..id.."]"
+ .." owned by "..area.owner.."."

I'll check the intersecting sub-area case. The debug info suggestion seems good.
Edit: I've implemented both of your suggestions here.

ak399g wrote:Would it at all be possible to create a "negative area"? By this, I mean imagine a cube of space. That space is owned by me (ak399). Inside that cube, there's a smaller cube of space that I wish to relinquish ownership of. Currently, I must set six "walls" of ownership around that space to have the effect of an unowned space in the middle of an owned space.

Yes, use the /area_open command on the sub-area. Re-run the comnand on the area to close it.

I have one large area "/set_owner"'ed by "SAFR". Inside that area I have a smaller area "/add-owner"'ed by "SAFR". To that sub-area, I have run the "/area_open" command. Playing in a second window as "ak399", I'm seeing the two areas [19 (SAFR), 20 (SAFR/open)]. I am however unable to do anything in the sub-area as "ak399".

ak399g wrote:I have one large area "/set_owner"'ed by "SAFR". Inside that area I have a smaller area "/add-owner"'ed by "SAFR". To that sub-area, I have run the "/area_open" command. Playing in a second window as "ak399", I'm seeing the two areas [19 (SAFR), 20 (SAFR/open)]. I am however unable to do anything in the sub-area as "ak399".

I made it work the way you want here. Update and try again.

Works! Thank you so much! :D

Can somebody make a video tutorial, i really cant understand. I have super tall building and i want to protect it from top to bottom but i can put only 2 nodes i want to cover the whole area of the building, sorry if i sound stupid but, its hard ...