MUDlib
 

Can someone post a tutorial link or care to get me started on how to make a
mudlib system?

Same here, can someone explain it in detail aswell or point us to thread that will.

http://forums.graalonline.com/forums...=1#post1262165

Look at the mud system Thamhic used.

It still don't teach me the exact thing about mudlibs and how to make them.

Sort of helps, thanks

yeah an articles covering:
would be nice =/

Outputs:

str,2
int,-1
dex,1
luck,0

huh?

Was just an example, array can be good, if you know a good way to get info from it. Else normal variables should be fine.

I prefer to use some other character to divide the values.
So bonus would be: "str:3:luk:3"
Then we use itemarray[index].tokenize(":");

The way I did it was something like:

temp.stats = { "str=10", "dex=6", .. };
temp.player_stats.loadvarsfromarray(temp.stats);
echo("Str: " @ temp.player_stats.str);

Not sure of the exact function name, but it was something like that. It can all be found in the link Twinny posted, in the 'mudclient' and 'mudfunctions' classes.

The way it is done on Kingdoms is to separate each part of the mudlib and use the best way to implement it:

- The items are some kind of TStaticVar, real objects, using normal variable names
- When saving or loading you can write your own function to make the file look good (separate file for each player)
- For displaying the items on clientside you write a function which takes the visible items and useful item attributes (e.g. name, icon) and set some client. strings; this function is called each time an item is changed or modiified
- For being able to communicate between server and client you assign each object you create an unique id which only works as long as the server is up (should not be saved) (client.mud_item123 on clientside, player.items[0].id==123 on serverside)
- The available item types are stored in archetypes; when saving an item of the player then you only save the differences between the current item and the original archetype to minimize the file size and to make it possible to change the archetype without changing each player item file (changing the icon of the archetype will change the icon for all item instances in players inventories except for items that got an unique icon (icon has been changed))

It would probably be good if there would be some item system which can be used on each server, I have not checked yet the zip that has been attached though.

Are this TStaticVar objects clientside or serverside?

I don't think i'm satisfied with the mudlib I made, i'm thinking of a way to make a general data-handling system that could be applied to items and many other things.

This could a very newbish question but where are the actual vars for the MUDitem itself stored, is it stored in a folder in the file browser maybe or some class?

In folder in filebrowser.

Thanks Invern

In my mudlib, all items are simply arrays: clientr.mud.item<uniqueid>
Anytime you make an item it gets a unique ID from the
serverr.mud.item.counter, this is so items dont overwrite eachother if you trade or anything like that since you're going to move the whole array.
The most important part of item data is the type which is the first var in array, the type is how you're going to know what stuff is where in the item array. All types are defined in serverr strings so they're easily available.
When you want a variable from an item, such as them name, you use:
mud_getitemvar(itemid, varname);
Or for example, mud_getitemvar("2006","name");

What this does is looks for the item in the clientr strings. When it finds the item, it looks at the item type (index 0) and loads the list of vars from that, and returns the index of the item array that matches the varname's index in the varlist. If you already know the index you simply use:
mud_getitem(id, index);
Any index less than zero returns the whole item array.

For updating the player, when you log in the mudlib compares your items with the archetypes that are loaded into the server, if there is a difference the mudlib updates all the variables except the 'noupdvars' such as the quantity, type, and archetype. Custom items lack an archetype so they're not updated.

so how do we add items to players? Like when they beat a boss or opens a NPC Chest?

Make a function for it.

I use mud_createitem(archetype, quantity);
Its a public function in the MudItems weapon that can be called clientside or serverside. If you want to call a function from a remote object you have to use:
Object.function(params); = MudItems.mud_createitem(params);

And for that, what I did was make an interface class. Which contains functions that call the function in the weapon object. So if I join the interface class I only have to use mud_createitem() in script and it executes fine.

My mudlib is different, almost same item setup as yours Inver :]

clientr.mud.item<ID> = { type, quantity, vars};

Type is what to trigger, like weapon, armor, food etc..
quantity is ammount ( obvious) and vars are the variables needed for the type :o

The mud library vars on Theed can get pretty hectic. Especially for armor. Short format example:

clientr.muditem_16=itemname=Twinny's Test Sword, equiptype= WEAPON_SWORD,weight=2

and so on.

It's done this way so you can load make object with vars from it. Eg.
The system does have unique identifiers for each number but instead of being stored as a serverr flag, it is stored as a var in a DBNPC npc called 'mudlib'. The mudlib also has functions as well relating to speed/efficiency. Thanks to Kuji, this system is incredibly fast and versatile. But no secrets to give away ^^.

Mud commands can be done via a player class. Eg. player.Mud_CreateItem("sword3", 1); being mudname then quantity.

Is your mudlib based on the one I wrote for thamhic? Same var and function names, and methods of storing data, by the looks of it.

:O I haven't bothered making a mudlib using weight, never found a good algorithm for weight and speed ( movement)

Kinda similar. Thamhic was used as a reference for the original mudlib but than alot of changes were made in the second version ^^.

Kuji insisted on making all the systems on Theed. I can only touch them after he has finished. To his credit though, the new mudlib is awesome.

However, i find having each var for an item in an array quite ugly. What you could do is have a DBNPC which has items like this
mudlib.sword=itemname=Hax,somevar=hax!
or perhaps an address to a .arc which can be loaded.

Then for players, you could have muditem_2=sword, followed by any modifications/buffs. eg.
muditem_2=sword,+2fire,-50sharpness,+200rust
When accessed, mud function can return either an array of vars or an object containing the vars for use.

If anyone has any questions regarding mud systems, pm my RC on GX. Or forum pm but gx is faster.

If alot of people poke me, I'll write a guide on the wiki and my site. (though still waiting for mysql reset on my site)

Depends what you like though

I don't like the idea of having the variable names in the array, considering arrays get cut off after a certain point. If I did that I'd make all variable names only 4 characters to limit length.

For weight, I have the function mud_calculate() to parse all the items for values you need, when it gets the total weight it sets that in clientr strings, then the total weight is applied in the movement system somewhere.

I'm still kinda iffy about using Objects for the mud items or anything since I don't know exactly how they work with the server and don't want to spend time trying to find out, its just easier for me to use the function mud_getitemvar() or mud_getitem().

Also on Aeon, because the default Graal Q-Menu is not in use, I renamed all Weapons so simple letter-only names so they don't require quotes or makevar() to be referenced: MudItems, System, SystemGuiFactory, GuiInventory, GuiHud, etc. None of those slashes or anything else, and I love it that way :)

It's uglier when you load the player's attributes, but a lot more organised when you are coding with it :P The architypes in my mudlib were only used as a guide when creating the items. The original plan was to have each item have slightly different stats than others of the same type. Also, the overhead of having to load the archetype file, or access some DB NPC variables would be too much if players had a lot of items.

They only get cut off if you use the default RC client to open the player's attributes. Which is why scripted RC is for the win.

If you take the time to learn them while they are fresh, they will save you more time in the future.

I really don't see how making the items Objects will help me, I already have a simple way of getting the item data, so if anyone could point this out?

Well it's not a big advantage I guess, but such objects can join classes and could do dynamic things. On Graal Kingdoms that is mainly used for illnesses which sit in the inventory of the player and infect other players or npcs or reduce the hitpoints each few seconds or drop some item (e.g. teeth). If such functionality is not needed then you don't need to use TStaticVar.

okay I;m totally lost on this archetype thing, I'm trying to understand but I can't figure out how to add one of my custom to Okies Inventory weapon. :/ Any insight?

*bump*

I haven't looked into it but I believe you need to put the archetype file in the folder for it to be loaded.

I have, I also releazied that the .arc file can be read with wordpad so that helped a little I added a weapon from okies aswell but nothing. :[ I dont understand it...

If I make a TStaticVar on the player, will it save when the player logs off and reappear when the player logs in?

The object will not stay with the player when the player logs off. You would have to use the player log off event to call savelines(); on the object and loadlines(); on the file when the player logs on.

Yea I thought so.
Btw, why is "interface" a keyword (highlighted) in the scripting window?

It is a declaration (I have no idea what they do in GraalScript). They include the following:

• class
• extends
• implements
• import
• instanceof
• interface
• native
• package
• volatile
• throws

Hmm, when I make an object from an existing object, is it possible to make the new object inherit the class from the existing one?

Its probably because the highlighting template was taken from Java or something. Why re-invent the wheel right?

That is a cruel thing. I always thought it was in preparation for new additions to GS2.

The syntax file for GS2 for RC can actually be modified by the user (somewhere in the user files), it has been copied from some similar language, but added some stuff for multiline strings.