Mudlib
 

chompy explained how to make 1, but should i??
all i can see it does it set a flag on the server, why not set a flag in the players strings?? what are the benefits??:confused::confused:

The benefits to creating a MUDlib is that you can create several weapons and items without having to create a separate GUI script for each one. These weapons and items are stored in files on the NPC-Server, usually in .arc format, and are parsed by the NPC-Server to turn that archetype into a virtual addable item.

If you are confident in your skill level and are sure you know what you are doing when it comes to File I/O on the NPC-Server, and know how to parse strings from those files, then go for it. Otherwise, study up on those topics and experiment with them. When you feel comfortable, make one.


Good luck!

it depends on how you script the main gui weapon to control your weapons and items. i am wondering if there is a point to making 1 or not

This is something I can't answer without knowing the details of your project's storyline or plan.

there isn't 1, but would u? from what i see a mud is just a bunch of functions interacting with each other. i see no point in it tbh, i could just make alot of player joined classes for that.

It depends on what you want to do with the server. A full blown RPG with a few hundred different items would benefit. If you just need to pick up stones and throw them in a pit, just add the stuff you need in Weapon scripts.

i will make 1 for the fun of it, i have nothing more to do

wouldn't it be laggy??

The point to it is to create a uniform, simple method of controlling player interactions, items, levels, etc. It is a way to keep your Class Scripts and GUI Scripts clean and provide a simple way to access player data. Archetypes are a way to create items that will be globally the same, but in their own way, unique.

For example,
Compare this with having thousands of GUI Scripts that you would have to sort through. Makes sense to have things organized!

Of course, it all depends on your needs and how you plan to implement them, but I would personally create a MUDlib over having hundreds or thousands of GUI scripts.

i see what u mean

when u store that data, do you store data in the players string list or do u keep it on the server where you cant read them??

In most MUDlibs, the player data is stored in a file in a similar format as the archetypes.

yes, but why not store them in the players string list, makes no sense to me

Think about account transfers, account resets, etc.

The string lists would be wiped. These files provide a 'safeguard'.

is that generally all...?

You don't need to name the files .arc, .txt is fine and those files are already set in windows to open with a text editor like they should be. I think people use .arc to feel cool or something :rolleyes:

Agreed.

I use .txt for mine ...

I'm not sure if it does it with .txt, but I know Notepad++ will make it so categories in .arc's can collapse and such(much like xml), making it much more organized and such.

.txt files are what we use on Symphonia. I've seen quite a few variations on the archetype format, including .xml, .arc, .txt, .arch, .mud, etc. .txt seems to be the most reliable.

There's tons of reasons but here are some:

1. Client. and Clientr. variables must be loaded on login when the player connects to the server which can be very stressful on the server if there is a ton of archetypes and variables to load.
2. When using the rc command, /open, When you apply the changes, variables are reduced down to 255 or so characters which can screw up player data. Having it stored on the player variable clientside (I usually create a TStaticVar linked from player.mud) removes the chance of data being accidentally trimmed.
3. As with #2, having the data not with a client. or clientr. prefix prevents people with simple /open rights to both read and modify archetype/player data that you might want to keep secret.
4. A cool thing about MUDs is you can script it so that a high staff member could load the account data of someone else instead of him self for the purpose of fixing problems and seeing the world from that player's eyes. Just a small feature that I always loved. Doing this would require data to be stored in files though.
5. As stated before, having the account reset would screw up the player data which you might not want reset.
6. MUD data stored in text files on the server can be read from and written to even while the said account is offline.

There's way more but that's just some of the reasons off the top of my head.

Couldn't you load from accounts/whatever?

To my knowledge, scripts can't access the accounts/ folder.

The accounts folder is available on servers using the newer system, the ones with an internal name like account_<owneraccount> which would be the ones named like "Dev <owneraccount>". I believe the accounts folder should be read only though even if you have RW rights to it.

Ah, can't say I've ever tried.

Only in extreme cases should the NPC-Server get any rights to the accounts folder and it is not something you should plan for.

You have to remember that rights, comments and everything else is stored in there which is not something you want to give anyone with access to a npc the ability to view/manipulate.