FOSS gamedev and creative worlds

Ferk: I understand what you are suggesting now, will look into that.

Updated to 1.3: Code has been tidied and tweaked so that on_place is now inside node definition, also protected zone display appears for 5 seconds now instead of 10.

Fixed protector overlap bug thanks to Xanthin, could any server owner using this mod please update.

I'm always unhappy when a server uses a protector-based mod instead of an areas based one. It is very tricky to protect even a relatively small building due to all those overlapping problems. Most of the time the griefers win, and the time used to build a house is wasted more than ever :-( There are other players who seem to get along with the way protectors work, but I don't.

Would it be possible to add at least a command that allows owners of an area to add people who can build there to more than one protector in one go? It's sometimes tricky to find all conflicting protectors. Or, perhaps easier, add a command so that a player can allow other players to build everywhere where he (the player granting the right) has a protector. And if there's overlapping, some information like "Protector at x,y,z owned by whoever causes a conflict" might be more informative. A "fill this area with protectors owned by me" command might also help. In general, er, I want something like areas :-)

i guess that would mean that you have to use areas instead of protectors, but another idea would be to add different types of protectors with different sizes.

the protector/logo uses stone and iron/copper.
other protectors could be made from sandstone/obsidian and use bronze/mese shards.
the types could be:
- road sign (a protector with a small area to be paced under roads)
- tower protector (a protector with a slightly smaller area that is much higher than the others)
- landmark (a protector with a wider area than the others)

the road sign would not only be for roads but also to cover small holes in the protection or to operate in high populated areas.
the tower protector can also be used for trees.
the landmark would be good for farms or very large buildings.

Sokomine: I see many MANY builds on server which are easily protected with node protection instead of areas, and in the later versions the protection radius can be increased. imho this is still the easiest and quickest way to protect buildings.

She's got a point that it would probably make sense to show if any protectors from other players conflict when you are placing the protector. Specially if they actually prevent any player from building there, even if they are owners.
Perhaps you could search for conflicting ones just like this?

And then exclude from the array anything owned by the player scanning.

Ferk: Protector Redo already does that when placing protection, it checks 2x area around itself to see if anyone else's protection is present, also when used as a tool it will show you the location of nearby protectors.

Ok, then maybe those servers are using the old protector. They should update to protector redo then.

It might also be possible to allow to place a protector if there's a conflicting protector owned by someone else but where the placer is amongst those who have been added to the protector. The owner of the conflicting protector could be added to the new protector automaticly.

If a player is added to an already existing protection node and tries to place their own protector inside that area it wont work, it's up to the main player who owns that area to place another node and add the player themselves.

TenPlus1 wrote:If a player is added to an already existing protection node and tries to place their own protector inside that area it wont work, it's up to the main player who owns that area to place another node and add the player themselves.

...who can't place that protector either because the next best protector from player2 will interfere. In the area between player1 and player2, neither can place a protector even though they share all the protectors they can find. I know why that is the case (=undefined situation in case build privs at one end are removed), but still...it is extremly annoying. It's also something based on the core of how protectors work.

Maybe there could be some priority value.

Something like allow the protector to be placed in an unprotected node even if other protectors conflict in the area, but after doing so make the placed protector have a lower priority than any of the conflicting protectors that were placed before it. In such a way that you can still own the piece of land in between conflicting areas without affecting the areas around that were previously owned.

You'll have a smaller area but you'll still be able to protect it and fill the gap in case you ever want to get closer to the neighbor without doing a complete merge.

Ferk wrote:Something like allow the protector to be placed in an unprotected node even if other protectors conflict in the area, but after doing so make the placed protector have a lower priority than any of the conflicting protectors that were placed before it. In such a way that you can still own the piece of land in between conflicting areas without affecting the areas around that were previously owned.

That's a good idea! All it'd take is storing the date when a protector was placed (first comes..) and some more logic when there's more than one of them lurking around. That way, griefers won't be able to exploit those holes by griefing anymore.

Which leads to an overcomplicated and laggy mod checking protectors around an area instead of simple placing them properly in the first place.

Don't you already check for protectors around the area? I just checked the code and it looks like it does.

The expensive call is already done. And you are even already iterating over the result. The only thing this would add is maybe having to do 1 or 2 more iterations (I don't expect more than 3 protectors in the same area which means only 1 or 2 more get_meta(), the only expensive call in the loop). And this is in the worst case scenario, most of the time you could even return already as soon as you find a node with no priority assigned (and assume no priority is highest priority) and when placing it, if there were no conflicting areas not owned by you (which you are checking for already as well) you don't have to save any priority/timestamp since a protector placed without conflicts would always be highest priority.

The thing is that there are cases where "placing it properly in the first place" is not possible. See this case



R is your protector, P is other people (with one dot in each direction of radius in a square), the x is what you want to protect. Trying to protect it will always get you in conflict with the other protectors, who are maybe by people that don't want to give you permissions to access their house area, even if they would be ok with you expanding one dot to the side as long as you don't disturb their areas.

Adding this would cause players to become lazy and develop no planning skills as a result... I would gladly add the new checks if I felt they were needed, but in my opinion it overcomplicates a mod that works well on a standalone and sever environment without causing much lag or jittery movement.

so a simple solution to this would be to add mini protectors with a small radius to fill those gaps between areas.

Then I would have to rewrite the mod to check for different sizes of protector which could slow things down. It's still a better idea to plan things out beforehand.

You only need to check once using the bigger size radius like you already do now, when a protector is found just see if it's a small radius type (could be determined by metadata) and ignore it if it's too far. Doesn't add anything expensive to compute (the find_nodes_in_area and get_metadata has to be done anyway), other than some math you can do with vector.distance which only needs to run when there's an actual small protector and that I'd guess is already faster than the get_meta (it's just arithmetic, no database query or I/O needed for that).

But I think adding a smaller version is not really a solution to the problem, would be best the prioritization (which I believe it's not much difference in speed as well). However, it's entirely your call, it's your mod and it's fine if you decide you want to leave it like it is.

Updated to version 1.4:

• Changed protector recipe's to give 1 instead of 4
• Added [+] button to interface when adding names
• Added /delprot command for server admin to remove protectors in bulk
• Tweaked and tidied code

Changed protector recipe's to give 1 instead of 4

reason?

maybe because some players spam their protectors all over the landscape, taking the rare crystal biomes all for themselves and then never log in again ....

Exactly that firefox, on Xanadu I'm fed up removing landscapes full of protectors and making the recipe a little more expensive should help in the long run.

Note: Players who have been banned or not on server for over 4 months will soon have protectors removed so that other players can build.

TenPlus1 wrote:Note: Players who have been banned or not on server for over 4 months will soon have protectors removed so that other players can build.

Happy to see you speaking about this improvement, it will be possible to tweak this "counter" in the "minetest.conf" ?

Updated to version 1.5:

- Added protected trapdoor (craft trapdoor + copper ingot)

Can anybody write settings for minetest.conf that increase the speed of protected block return to the place if not owner dig it?

Do you can add support for chicken and bunny to protector? Because other players can kill my animals even in protected fence wood cage.

amadin wrote:Do you can add support for chicken and bunny to protector? Because other players can kill my animals even in protected fence wood cage.

maybe tamed animals should have the same PvP protection that players get in protected areas, so that only the owner can kill them.

for Xanadu i recommend you to use invisible glass slabs. (the slabs are harder than the full blocks and can't be broken by hand.)

Updated to version 1.6:

- Added protector_drop and protector_hurt settings to minetest.conf

...these settings were added to stop players using lag to grief through protected areas and inside buildings by dropping their tools and hurting them.