FAQ Tutorial: Adding more AccessLevels

[Khaz]

This tutorial is no longer applicable to the supported version of RunUO (2.0 RC1 at the time of this writing). It will continue to be supported for RunUO 1.0.0, but at this time, I will not be making an updated version for 2.0 or any future versions of the RunUO package.

Note: This requires core modification. If you are uncomfortable with this, turn back now. This is written using the most recent build of SharpDevelop, and does not address anything in Visual Studio .NET or any other compiler/project manager.

Forewarning: this tutorial is written using the RunUO 1.0.0 release and SharpDevelop 1.1 on the .NET Framework 1.1. Since RunUO 2.0 and the .NET Framework 2.0 have since been released, this tutorial is outdated. If you want to try to adapt some of the information provided, read on. Note that the screenshots may not apply to your version of SharpDevelop.

Applications you need:

• SharpDevelop, here
• Eggman's Project Creator, here
• RunUO Core Source (at the time of this writing, v1.0.0), here
• AccessLevel conversion script, see end of post for attachment

Now for the steps.

1) Extract the core source to a directory you will remember. Move the project creator to the base directory, and run it for SharpDevelop.



2) Now open the new RunUO_Core.prjx file (or the Server.prjx file, depending on the project creator you used). Once it's loaded into SharpDevelop, the first step is to make sure that you have the Projects tab open. You can do this by pressing Ctrl + Alt + L or by going to the menu bar, clicking View, and then Projects.

3) Next, we'll set the output type to Release, instead of Debug. On the second toolbar, the last tool is a combo box. By default it is set to Debug, but you'll want it as a Release.



5) Before we begin coding, you have to set some project options. Right click the project name, which is the second category and is in bold, and go to Project options. Please note that the Project name may be different on your current set up.



5a) Under the General tab, make sure the side arrow is at Project options. Change the 'Name' value to Server, and the 'Standard Namespace' to Server as well.

5b) Click on the Configurations tab folder. Select the Release folder. Double-check to make sure the first value in the window, "Allow 'unsafe' code", is set to true.

5c) Click on Output. Change the 'Compile target' value to 'Exe'. The Assembly name should be Server. I recommend setting the output path to ..\-core source-\bin\Release. Here's an example of my own setup:



6) Now for the coding. In the project files list on the left hand side, double-click Mobile.cs. Locate the following around line 417:

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

Code in your own accesslevels and increase the enumerator number as appropriate. Here are two examples, one adding an extra top-level accesslevel and the other adding one between Seer and Administrator.
One top-level accesslevel

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

Two new accesslevels

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

7) The next thing to do is to locate the name strings. This is around line 5417. Find the following code snippet, and plug in your accesslevel names as shown in the example below.

private static string[] m_AccessLevelNames = new string[]
	{
		"a player",
		"a counselor",
		"a game master",
		"a seer",
		"the protectorate",
		"an administrator",
		"the patriarch"
	};

Notice that these are in the same order as the enumerator values in Step 6. Don't forget the quotes or the commas!

8) Save and close Mobile.cs. Now you're done editing. This step is to build the project and make the executable. There are several ways to do this.

1. Press F9 on your keyboard.
2. On the primary toolbar, bring down the Build menu and select 'Build -your project name-'.
3. Right-click your project name in the file tree on the left hand side, and select 'Build -your project name'.

8a) About 118 warning messages will be given, but you needn't worry about these. They are reporting multiple definitions of the same object, and return to use the base definition from the .NET Framework, which is fine.

9) All that done, move your new Server.exe to your normal RunUO directory, overwriting the previous Server executable.

10) Download the attached file, AccessLevelConversion.cs, and move it to your RunUO\Scripts directory. Open the file in your usual editor, and go to line 17.

11) Now, looking at the AccessLevel enumeration that you changed in the core Mobile.cs (around line 417 if you need to reopen the file), adjust the m_Offsets array to reflect your changes to the default accesslevels. You will need to add your new accesslevels to this list.
For example, if you added one accesslevel above Player, then Counselor, GameMaster, Seer, and Administrator are going to be 2, 3, 4, and 5 respectively (instead of the default 1, 2, 3, and 4). Your new level will be 1. Therefore, inside the AccessLevelConversion file, you would change the m_Offsets to be 0 (player), 1 (new level), 2 (counselor), 3 (gamemaster), 4 (seer), 5 (administrator).

12) When you have figured that out, save and close the file.

13) Boot your server as usual. Use the command FixAccessLevels to restore everyone's AccessLevels. If you are not an Administrator (because you added a new level under it, for example), create a new (temporary) character on your Administrator account and run the command with that character instead.



End Notes:

• Editing the core of RunUO can have extremely upsetting side-effects if done incorrectly. Always, always, make sure you backups of everything you are going to change.
• If there are any problems or inconsistencies, please contact me as soon as possible and I will remedy them.
• If you add an AccessLevel above Administrator, it is recommended that you also adjust the Mobile.AccessLevel property around line 5670 in the core Mobile.cs (you will need to recompile the core for this change).
  For example, if you have a new level Owner above Administrator, the property could now be:
  [CommandProperty( AccessLevel.Counselor, AccessLevel.Owner )]
• There are a few files that you will need to modify for this to work flawlessly. These files include, but are not limited to:
  • Gumps\AdminGump.cs
  • Gumps\WhoGump.cs
  • Misc\Notoriety.cs
• Note that if you delete or rename any existing access levels, you will have to substitute all of these edited access levels with your own new ones (i.e. if the accesslevel for the set command is currently set to Counselor, and you remove the Counselor accesslevel, you will have to change the command's accesslevel) [See Atomic's post below this one].

[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]

*nods* That's true. I don't know exactly how to do that, so I just dealt with it (and forgot) on my end. Please accept my apology, but I am rather timid around serializations.

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.

[XxSP1DERxX]

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

[XxSP1DERxX]

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

[XxSP1DERxX]

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

[Khaz]

Trying, I don't think what you suggest would be gods-awfully hard to do, but if I understand your goal correctly, you want to tag the PlayerMobile, no? I'd say go for it, and I'll see if I can pull up anything my end but please don't hold me to it (lots of stuff on the ToDo list).

I didn't know about the project creator from the Third Party Program forum either. I think it was one of the Announcement topics that I found out about it in. =/ Anyway, that and Project Generation are very promising.

Hopefully I can get that guide updated with some more promising ways of updating the access levels.

[Phantom]

A really nice trick you can do is the following:

Make all your Mobiles a Player since that value won't change.

You won't have to do any sort of lame conversion.

[Khaz]

Ha...ha...

Actually, I'm adapting Outkast's example code and will be testing that later tonight.

[Trying]

Heyyyyyyy now... LOL...! as I said earlier I would`nt have a clue where to start, Sure I can throw in some suggestions, but thats about my limit, though today I must confess I have bent over backwards to help many out on the forums with connection issues etc.. but scripting is something which seems to me takes a life time to learn and one is never able to master... :P

Curiousity and all of that led me to watch this topic with intrest to see where it was going... but as far as scripting anything.. still out of my depth at the moment im afraid...

But to try perhaps cut a corner or two, the idea of having "Tags" rather than altering everything was one of them flash bangs that just pops into our heads from time to time... not sure if it was even do`able and to be honest I expected to be laughed at... :P

Just an idea that may or may not be of any use to anyone that was thinking about perhaps looking at adding levels....

[Jarrod]

I followed the steps to a tee, only modified a skillname and added Developer over Administrator as an access level.

it builds fine, however when i try to start the .exe, it runs through most of the way, but then exits with a windows error.

I assume that its because when i installed the Sharp application, it dropped a 1.0.3705 version of .NET over my 1.1 installation.

Did anyone else have this happen, and should i be able to just remove the 1.0.3705, then reinstall 1.1 without any negative side effects?