Plot / lair permissions

[Andrakhyn]

I do believe if you set plot to friends and structure to guild only you have to be BOTH to access. A guild mate not in the friends list cannot access nor can someone in the friends list but not a guild mate.

Its meet both or don't have access. Maybe I'm wrong but its the way seems to work for me.

I tested it very carefully before writing this post using alts and found the same.

Said so in the OP and tried explaining it to North but they have an odd idea about how it works. I'm very experienced with both programming and databases though so it looks incredibly obvious to me. I suppose if you're not used to thinking in those terms the plot permission logic could be confusing.

To make this real easy why not add a structure permit PUBLIC setting that overrides or ignores plot permission setting and allows any to use.

Wouldn't that be simplest solution?

That would be the simplest solution - but only to one part of the problem. It doesn't address others.

And yes it should be simple. Plot security is probably handled via some form of SQL and the above would just be a matter of adding a basic OR [structure setting = public] statement into the check.

But if that's simple and do-able then so is everything I suggested in the OP. The amount of code controlling plot permissions would be very small and basic.

Effectively most of what I suggested is just removing one AND statement, i.e. just check the structure permission setting rather than both the plot and structure. Simple. The majority of the work would be in reconfiguring the plot/structure permissions UI to add the extra options.

[Akrion]

Said so in the OP and tried explaining it to North but they have an odd idea about how it works. I'm very experienced with both programming and databases though so it looks incredibly obvious to me. I suppose if you're not used to thinking in those terms the plot permission logic could be confusing.

You seemed to have a confused idea of what Northwind was trying to say as well. There are numerous things that Northwind says that an experienced programmer should not have had any problem understanding.

According to Northwind's first post there would be absolutely no need to store timestamp data or other such nonsense. His entire post clearly reads to the effect of your plot setting being propagated to the structures at the moment of being set. Northwind is entirely correct in saying this would only require you to store permissions at the structure level, because the plot level permission settings are being used to globally set the structure settings. At its simplest it would look something like:

// 'permission' is set to 'DenyAll'
if (applyPermissionChanges) // 'Apply' is clicked
{
    // iterate through all plot structures, setting their permissions accordingly
    for (StructureList::iterator i = structures.begin(); i != structures.end(); i++)
    {
        i->SetPermission(permission);
    }
}

After that the individual structure permissions can be set to the user's desire. A solution like this would be one of the most basic implementation-wise but it brings about issues of having to reset every single structure permission if you change the plot permissions, so usability becomes a bit of a concern, but that's not the point of this post.

[Andrakhyn]

According to Northwind's first post there would be absolutely no need to store timestamp data or other such nonsense. His entire post clearly reads to the effect of your plot setting being propagated to the structures at the moment of being set.

You're quite patently just making stuff up. What he said was:

Or, even better, to have the last setting to take precedence over previous: setting Deny All at plot level will set "deny all" to all structures, then you go to those structures you want to open and set them to Friends/Allow All/etc individually.

He talks specifically of precedence - i.e. two stored settings and one taking precedence over the other based on the time it was set.

What you describe is functionally identical to what I did earlier in response to his suggestion - a mass-update feature, not a precedence system.

[Akrion]

He talks specifically of precedence - i.e. two stored settings and one taking precedence over the other based on the time it was set.

No. No he doesn't.

Northwind's statement of "Or, even better, to have the last setting to take precedence over previous" is a non-issue when you read what follows it. It could just be that Northwind didn't realize that there isn't really a "previous setting" to the concept he was proposing, but as a self-proclaimed very experienced programmer you should have realized that and seen what he was trying to say.

Either way, I'll leave off with this:

You came to the same conclusion at the end of post #3 but using a different phrasing

The argument regarding what Northwind was trying to say could have been over 18 posts ago. :P

[fashionever]

You can not have a silo open to a few friends and another silo open to everyone

[fashionever]

If you already know, so I'm sure that teammates did not hurt a generalization, it can provide some useful information plus episodes.