FAQ Tutorial: Adding more AccessLevels

[Khaz]

FAQ Tutorial: Adding more AccessLevels

[highlight]This tutorial is no longer applicable to the supported version of RunUO (2.0 final at the time of this writing).[/highlight]

 

[Arya]

Nice tutorial, but you forgot an important point. If you wish to do this on an existing shard, with an existing world, you need to take care of this in the serialization of the Mobile class.

If an Administrator is saved (as a byte of value 4 by defaut), once you implement your mod the same mobile will no longer be loaded as an admin but as a Protectorare (in your second example), so you pretty much need to add a new version to Mobile that handles your change.

 

[Khaz]

I see the de/serialization of the access level in Mobile.cs. Would it be as simple as to just up the version on serialization and deserialization?

 

[Arya]

Well it's not difficult, but you need to introduce a new version in the Mobile class which will make it tricky to upgrade when a new core is released.

Another solution would be to write an ad-hoc script that performs a one time conversion... in other words, load the world and allow access levels to be wrong. Then run a script that looks at each accesslevel and adjusts it (so any Protectorate will be converted to Administrator).

Of course none of this applies if you add accesslevels with values < 0 or > 4.

 

[Kamron]

The easiest thing to do is to append serialization and go through all serializations of accesslevel (not just Mobiles... basesuit has it too), and use a conversion method to convert it from the old to the new. Basically would say, if its a (AccessLevel)4, its now AccessLevel.Administrator (whatever that is now).

You can do this by editing all serializations of accesslevel, or you can make a script to cycle through the world items/mobiles/multis and check every property... either way its pretty sticky.

 

[Khaz]

I see what you both mean. I think when someone goes looking for a walkthrough they want the easiest methods, so it might be best to make an external script to cycle through. Hrm...I'll put a note to clear up any confusion for the time being, until I or someone else can develop the serialization fix.

 

[Atomic]

You should also add info about deleting/renaming existing accesslevels, and tell people to substitute all old instances of the old name on all scripts if they want to do this. I'm just saying this because I see this questions coming soon, but otherwise it is a pretty well written tutorial.

 

[Khaz]

Added a couple notes there. I may have missed some of what you said, Atomic, so let me know if I understood it wrong.
I'll see about doing something for the serializations, but...I am no krrios.

 

[Atomic]

Yeah you got it right, but thats no biggie, as a file search for the modified accesslevel will turn out all the files you need to modify

 

[Kamron]

My world editor will allow users to do enumeration conversions, unfortunately it won't be out for at least a few months *sigh* lol.

 

[georox]

once someone posts a conversion script im happy..

 

[Arahil]

as a little side note - you wouldn't have to change the project settings if someone mailed me a correct sharpdevelop-header

 

[TheOutkastDev]

try a command that uses an int[] array to hold the new int values of the access levels. Ex:

RunUO Default:

public enum AccessLevel
{
	Player = 0,
	Counselor = 1,
	GameMaster = 2,
	Seer = 3,
	Administrator = 4,
}

New enum:

public enum AccessLevel
{
	Player = 0,
	Counselor = 1,
	GameMaster = 2,
	Seer = 3,
	Protectorate = 4,
	Administrator = 5,
	Patriarch = 6
}

private static int[] AccessOffsets = new int[]
        {
                   0, // AccessLevel.Player remains zero
                   1, // AccessLevel.Counselor remains 1
                   2, // AccessLevel.GameMaster remains 2
                   3, // AccessLevel.Seer remains 3
                   5, // AccessLevel.Administrator changed to 5
        };

public static void Initialize()
{
             Commands.Register( "FixAccess" .... );
}

private static void FixAcces_OnCommand( CommandEventArgs e )
{
             ArrayList mobiles = new ArrayList( World.Mobiles.Values );

             for( int i = 0; i < mobiles.Count; ++i )
             {
                     Mobile m = mobiles[i] as Mobile;

                     int newOffset = AccessOffsets[m.AccessLevel];

                     m.AccessLevel = (AccessLevel)newOffset;
             }
}

Just a rough idea, no guarentees that this code would compile as most of it is just off the top of my head.

 

[Trying]

I`m reading this topic with great intrest, but one thing is bugging me, on the official OSI servers, they brought in the companions, as you will well know... but when they brought this in, they had a great number of levels.. this being Companion, Senior companion, Regional senior companion, and Arch companion.. they had a simular structure with the counselors as well, what confuses me here, is that we have 0-4 for access levels, but everyone of the above had different access commands determined by there rank... so am I right in persuming that re-wrote the entire structure and "added" in the companion ranks... or was it a case of a "check" to see what rank they were at and then allowed/dis-allowed certain commands...

Im only curious, about how you would persume they went about this, as I cannot see OSI re-writing the entire structure to add all the above said ranks...

and now im going to ask about something I openly admit not knowing anything about, but is it possible for one rank to be "added" and then a check made to see what "tag" is attached to said mobile to allow/dis-allow certain commands...

To elaborate on this abit, my idea would be to have one custom "level" that has a max of "blah commands" then a check is made on said mobile to see what "Tag" is attached to mobile, if "Tag" is 1.. then give blah commands.. if "Tag" is 2.. give a few extra commands.. and so on untill the max commands have been reached.. only an idea, and I don`t know if its do`able or not, but it would certainly be easier then adding 4 or 5 new levels no..?

As I said before I have no idea how this advanced stuff works yet, so I may be as far of track as Mars... LOL
but as me name states, I am trying...

 

[Atomic]

Yeah you can do that, just add a new property to PlayerMobile, serialize it properly and on each command you check like this:

if ( mobile.AccessRank <= 2 )
{
mobile.SendMessage( "You can't use this command");
return;
}

This will not allow ranks smaller or equal 2 to use the command.

 

[Trying]

So logically then you would only need to "add" one new accesslevel lets say for arguement sake, same access as GM, or perhaps even use the accesslevel of GM and then write up a script to check for "tags" each of which has a "sub level" which has defined commands that are allowed to be used... then I guess it would be a case of Admin/GM to do say a [promote1..2...3...4....5 or something to place the "tag" on said mobile.... thus giving them access to that "sub level" commands...

Sounds easy does it not.... !! Yeah Right, I bet... hehehee

 

[Atomic]

Yeah, thats pretty much it

 

[Kamron]

If all you wanted to do was chop up the accesslevels that were already there... then it would make sense (for example)

Player
- Guest
- Normal
- Veteran
Counselor
- Trial
- Normal
- Senior
GameMaster
- Apprentice
- Normal
- Elder (Lead)
Seer
- Assistant
- Normal
- Dev (Lead)
Administrator
- Assistant
- Normal
- Owner (Lead?)

But other than that.. no matter what you do (since Accesslevel is serialized on items too) you wouldneed to do a conversion of some sort.

 

[Trying]

So the big question is... how hard is it to achive.... ? is it a simple script or is further modding into major scripts... ? (and yes spider I know you have the wolves at your door at the moment, so this question is general.... lol )

could be a nice script... if its not to hard to do...

 

[sirens song]

That project creator is a great application!, thanks for informing us of it. Im aware it was already in the forums, but I scarcely look at UO.sdk related things. Thanks