Altering the Add command to dynamically read accesslevel requirements per object

[Waverian]

Just something that came to mind when reading this post:

Lag spike when users enter dungeons

Basically what I mean is for the current primary base classes ( namely Mobile and Item class ), have something such as this..

public virtual AccessLevel AccessToAdd{ get{ return AccessLevel.Administrator } }

and then in the Add command have it read the AccessToAdd prop of the object it's trying to create. This way there can be a dynamic way of changing requirement to add things, and gives administrators more freedom to let their lower-access staff still be of sufficient use, while preventing abuse.

[XxSP1DERxX]

Even better... make another attribute (since the Constructable attribute is in the core).. and have the accesslevel be a parameter of it. Then read it like you do for properties.

If its implimented in a release.. then they can make it a parameter of the constructable attribute obviously.

[TheOutkastDev]

you can do this without requiring changes to the core.

[Waverian]

I'm not really familiar with attributes yet, but --

Outkast, which 'version' of the solution? I know that the way I suggested can be added to, say, BaseCreature ( because if memory serves any mobile you'll be creating in-game is a derived class of BC ), but this wouldn't really be possible for Items.

Many items stem as direct derivatives from the Item class, rather than with some mediator outside of the core.

[TheOutkastDev]

Originally Posted by Waverian

I'm not really familiar with attributes yet, but --

Outkast, which 'version' of the solution? I know that the way I suggested can be added to, say, BaseCreature ( because if memory serves any mobile you'll be creating in-game is a derived class of BC ), but this wouldn't really be possible for Items.

Many items stem as direct derivatives from the Item class, rather than with some mediator outside of the core.

Not all mobiles created in game are derived from BaseCreature.

You just add the attributes on the items you want to restrict. Your original suggestion has the same problem that I think you are eluding to. In order to change restrictions, you'd need to override it for a base class for every item. With attributes you'd have to do the same thing, but can be implemented without Core changes.

[Waverian]

Firstly, I should have been a little more clear when saying:

because if memory serves any mobile you'll be creating in-game is a derived class of BC

I understand that not all are, but a vast majority of them go through inheritance of BaseCreature. And type of creatures from things you'll be fighting to simple dogs and such, and even BaseVendor has roots in BaseCreature. The only exception that comes to mind is playermobile, but I'm talking about things we'll be adding to the world via the [add command.

Anyway, I'm drifting:

I pretty much see your point. Realistically someone isn't going to restrict that many items, and even if they do they'll have to include a seperate override for each. *Shrugs*

I still think it's a viable idea, though.

[XxSP1DERxX]

It would be great if you implimented it into BaseCreature, and had a BaseItem class to impliment there... then you could override for specific items. Then again... you could just set the base accesslevel needed to add npcs/items in the add command, then have the attributes specific for the items/mobiles you want to restrict. Would be alot easier that way.