Derived PlayerMobile

[David]

Another wish list item; a class derived from PlayerMobile for scriptors to use so we can all leave PlayerMobile untouched. OK, granted this is not just a couple of lines of code and if it's not already in it most likely will not be. But it sure would be a nice surprise to find it in 2.0.

[X-SirSly-X]

This is easy, but I do see your point into having a standard one, so people could swap scripts back and forth, and work without everyone having different "sub-player mobiles"

in charcreation do this:

		private static Mobile CreateMobile( Account a )
		{
			if ( a.Count >= a.Limit )
				return null;

			for ( int i = 0; i < a.Length; ++i )
			{
				if ( a[i] == null )
					return (a[i] = new SlyPlayerMobile());
			}

			return null;
		}

and then I've made the SlyPlayerMobile have all my custom additions, such as a race, class, religion, quest tracking, and leveling systems all in one file. It really does make it a lot easier than having to work with the PlayerMobile. Although my custom playermobile is already 769 lines long(and growing!) , so its getting harder to work with :\

[Phantom]

PlayerMobile is already a child class, of the Mobile class, which was done awhile ago. The problem with the above idea is the fact, there are several issues with a conversion script because of some issues within the PlayerMobile.

Plus the fact even if this is done, if there is an issue in the child class, it still will cause problems. So really in the end its easier to deal with PlayerMobile then it is to deal with yet another child class.

[David]

Yes I have been a proponent of derived PlayerMobiles since the early betas. Back when we had to update every couple of weeks it was a really big deal. Even now I simply feel that it is the "right" was to add custom scripts to your players.

[Phantom]

Originally Posted by David

Yes I have been a proponent of derived PlayerMobiles since the early betas. Back when we had to update every couple of weeks it was a really big deal. Even now I simply feel that it is the "right" was to add custom scripts to your players.

The problem is no matter what, if there is a problem with the code, its not going to allow the server to load and will want to delete the server's characters. As a programmer I would rather have one file, that I can look at and know the history, then look at a file that I know nothing about.

[David]

Originally Posted by Phantom

PlayerMobile is already a child class, of the Mobile class, which was done awhile ago. The problem with the above idea is the fact, there are several issues with a conversion script because of some issues within the PlayerMobile.

Plus the fact even if this is done, if there is an issue in the child class, it still will cause problems. So really in the end its easier to deal with PlayerMobile then it is to deal with yet another child class.

LoL - PlayerMobile is a child class... obviously.

A conversion script would need to be provided, but it would only have to account for the standard PlayerMobile. Anyone who has edited the PlayerMobile will have to do it again in 2.0, so they can just tweak the conversion script instead. Or they can continue to use the PlayerMobile script. I have used a derived PlayerMobile for years and have never had a problem with distro scripts referring to PlayerMobile while mine refer to BritanniaMobile.

Lets see, if there is an issue with a script it will cause problems... again obviously. The idea here is that scripts actually be tested before they are submitted or put on a production shard.

And finally how is working with a 2865 line distro script easier than working with a short script script that contains only what you have added to it? I have multiple custom features added to my Players but my PlayerMobile has been the default distro script since beta 26 or so.

It is called PolyMorphism and is used throughout RunUO. It is not hard at all.

[Phantom]

And finally how is working with a 2865 line distro script easier than working with a short script script that contains only what you have added to it? I have multiple custom features added to my Players but my PlayerMobile has been the default distro script since beta 26 or so.

Because I can tell people whats wrong with PlayerMobile, since I have followed the script since the introduction of it. So I can just by looking at the code, notice a problem, but with a new class it would make it tough.

Inregards to testing code, most people will never do this, which is evident by all the problems people have.

Its up to the coder to write a script, that is easy to use, and won't cause problems in the future.

[arul]

Originally Posted by Phantom

The problem is no matter what, if there is a problem with the code, its not going to allow the server to load and will want to delete the server's characters. As a programmer I would rather have one file, that I can look at and know the history, then look at a file that I know nothing about.

Programmers at the first place are trying to ease their work as much as possible.
Say one has a PlayerMobile class with bunch of modifications, when new official version of the file is released ( for example 2.0 comes out ) one has to do a lot of annoying merging a comparsions.
Another has "Player" class and all custom modifications are made to this class, then he has no problems when new version of file is available.

Good idea David.

[Anti-Basic]

David, I love you now. *hugs*

[Aenima]

Copying a file containing your own custom derived PlayerMobile class would be just as easy as copying it over one in the distribution, I would think. Well - except for modifying CharacterCreation.cs to create it. That's simple enough already really?

[Joeku]

Originally Posted by David

LoL - PlayerMobile is a child class... obviously.

A conversion script would need to be provided, but it would only have to account for the standard PlayerMobile. Anyone who has edited the PlayerMobile will have to do it again in 2.0, so they can just tweak the conversion script instead. Or they can continue to use the PlayerMobile script. I have used a derived PlayerMobile for years and have never had a problem with distro scripts referring to PlayerMobile while mine refer to BritanniaMobile.

Lets see, if there is an issue with a script it will cause problems... again obviously. The idea here is that scripts actually be tested before they are submitted or put on a production shard.

And finally how is working with a 2865 line distro script easier than working with a short script script that contains only what you have added to it? I have multiple custom features added to my Players but my PlayerMobile has been the default distro script since beta 26 or so.

It is called PolyMorphism and is used throughout RunUO. It is not hard at all.

I suggested the same exact thing, but for the Mobile and Item classes. It would be great for the PlayerMobile and perhaps even BaseCreature classes, too.

***EDIT***
Here's my old thread: Base classes...

[tobyjug]

This is a great idea, same with the Item and Mobile classes Joeku. The server I work for has a BaseItem which works great, and a new project of mine also has a BasePlayerMobile which works well.

[Anti-Basic]

David, would making mods intended for playermobile in the derived one instead prevent playermobile wipes if you made a booboo or just be easier....you seem to be mentioning how much easier it is...and not how great it would be w/o the wipes...I'm confused

[daat99]

Originally Posted by Anti-Basic

David, would making mods intended for playermobile in the derived one instead prevent playermobile wipes if you made a booboo or just be easier....you seem to be mentioning how much easier it is...and not how great it would be w/o the wipes...I'm confused

The wipes are due to ser\deser errors.
No amount of derived classes will save your shard if you don't know how to ser deser.
The only thing that it'll help is with upgrading from one RunUO version to another because you won't have to remodify the new PlayerMobile that is released.
Still if you mess up your ser\deser you will have a wipe.

[Zotos]

Love the idea..