Bukkit

@NoHoPeLess

Hello NoHoPeLess,

Couple of questions for you: Which version of AreaShop are you using? Is your server in offline mode or not?

@Dragon_12dk

By default only OPs can directly break a sign, the other players should get a message like 'You don't have permission to delete a sign.'. One way they could have broken the sign is by breaking the block below/behind the sign, which pops off the sign. So please check if players can break the blocks below/behind a sign, if you do have that then I recommend moving the sign or region boundaries.

Of course you can still do everything by the AreaShop commands (just point them to '/as', that will show all commands that player can use) but I understand that using the signs is easier. There is not much I can do about this problem, I can only detect it, preventing it would lead to floating signs and/or floating blocks, so that would not be so great.

@Xayges

I had this exact same problem when I switched my server to 1.8, this is a bug in WorldGuard, so if you update to the latest version of WorldGuard then this problem should be fixed. Let me know if that solves your problem.

@monstercat101

AreaShop is not integrated with LWC currently, but because I also had someone else ask about it a while ago I will add this to my TODO list and see what I can do. If/when I will work on that I will try to get a system going that supports adding other integrations easily, so that I can add support for more plugins if requested.

@AncientTom

This is how the system works for all settings that can be changed in default.yml, as example I take the price: At first AreaShop checks if the setting is in the region file itself, if it finds the price there then it uses that. If it does not find it then it checks if the region has any groups assigned and checks if those groups have the price setting, if one of them does then it takes that price (group with the highest priority that has the price setting will be used). If there is no group with the price setting then it takes the price from the default.yml file.

The above is the situation for an individual setting like the price, but what you are talking about is a profile setting. Basically the same thing happen, it tries to get the assigned profile name first from the region file, then from possible groups, and then from the default.yml file. If AreaShop found the profile name (for example the name of a signProfile) then it uses all settings from that profile as defined in the config file (without falling back to the default profile or something like that).

Now about your problem, if the groups assigned to the rent region do not have a setting that specifies the 'schematicProfile' setting, then it uses the profile as listed in the 'default.yml' file (so that normally is the 'default' schematicprofile). If it does not generate the schematic then check if schematic creation is enabled in the config, default.yml and that you do not have the 'enableRestore' setting set to false in one of the groups.

Let me know if that helps you with your problem.

@Androkai

You are right that it does not save the region file, I fixed that now. Changing something else about the region after it would at least mark it as 'to be saved' (for example using '/as setprice' twice or something like that).

@XgenDaNcEs

You can set the priority of the big region to -1 to fix it, set the priorities of the AreaShop regions to 1 or higher or set the big region as parent of all of the AreaShop regions as suggested by Androkai. I think the first option is the easiest one, that requires only 1 command instead of 1 per region.

@AncientTom

Yes: '/as rent [region]'

@AncientTom

Ah okey, you can do that with the 'eventCommandProfiles' section, first create 2 regions and add them to AreaShop, one for the upper part and one for the lower part. I recommend using a clever naming scheme, 'shop1' for the upper part 'shop1lower' for the lower part for example (the region of the upper part should be somewhere in the lower part regionname). Set the price of all lower regions to 0. And then you add all lower part regions to a group called 'notavailable', then you add a limitGroup to the config which has a group section that contains the 'notavailable' group and has all limits set to 0. Then you assign all players this limitgroup by using the correct permission, now nobody should be able to directly rent the lower regions, but the above ones should still be available. After that you add all upper part regions to a group and set them to the eventCommandProfile 'doubleregion', then you add this profile in the config.yml in the 'eventCommandProfiles' section:

  doubleregion:
    created:
      before:
      after:
    deleted:
      before:
      after:
    rented:
      before:
      after:
      - "as setowner %player% %region%lower"
    extended:
      before:
      after:
      - "as setowner %player% %region%lower"
    unrented:
      before:
      after:
      - "as unrent %region%lower"
    bought:
      before:
      after:
      - "as setowner %player% %region%lower"
    sold:
      before:
      after:
      - "as sell %region%lower"
    resell:
      before:
      after:

This would automatically assign the lower region to the player that bought/rented the upper region, and if they sell/unrent the upper region it also removes them from the lower region.

If you have any trouble with it just send me a message, if you have a teamspeak server then I could also join that (or we could use Skype).

@AncientTom

Technically a shop can only have 1 WorldGuard region, but you might be able to use the 'eventCommandProfiles' section in the config to assign the buyer of a region an extra region. Are you sure though that you actually need multiple regions? Because WorldGuard also has polygon regions (sel poly) and those are a bit more flexible.

If you can tell me what kind of shop thing you want to create then I might be able to come up with a better solution to your problem.