MUDLibs

[projectigi]

Hi,

yeah.. i kinda hate them :P

So can someone tell me how _exactly_ it works?

my current idea about it is like:

a .arc file for the items, like deserteagle.arc, ak47.arc etc
or named by ids 1.arc, 2.arc ... 6879457.arc

like the gun arcs can hold the damage of the gun, its max ammo clip size, reload time, ganis, etc

now the player has a arc file too, that holds the itemnames or id's of the arc files, now everytime the player comes on these id's are taken, the arc files are loaded and saved to clientr.strings

and the inventory and other stuff reads that strings to know the item's attributes and stuff :/

But now I'm missing the point of having items that are objects and have some class joined to them x.x

[Rapidwolve]

What the HELL are you talking about..

Edit (After carefully re-reading I understand): Well for OC I have it so each item file is saved in an ARC file relative to its ID (Item_id.arc). Whenever the Q Button is pressed it triggers the itemlib NPC with a function loadItemInfo(). And then that function triggers the client with the information

[projectigi]

mudlibs Oo

edit after edit above:

what id? for every item thats created?
or for the base items?

so like the base item ak47
item_ak47?
x.x

uhm and ofc
wouldnt it be better to save the information of the item sin clientr. strings to avoid unneeded loading time when opening the inv?

[Skyld]

Huh. What's the obsession with people scripting their own mudlibs all the time? It's not really necessary. :|

[projectigi]

Originally Posted by Skyld

Huh. What's the obsession with people scripting their own mudlibs all the time? It's not really necessary. :|

yeah, sure, what else to use that doesnt need 1000 wnpcs x.x

[Kristi]

Originally Posted by Skyld

Huh. What's the obsession with people scripting their own mudlibs all the time? It's not really necessary. :|

Read my mind

[Rapidwolve]

Originally Posted by projectigi

mudlibs Oo

edit after edit above:

what id? for every item thats created?
or for the base items?

so like the base item ak47
item_ak47?
x.x

uhm and ofc
wouldnt it be better to save the information of the item sin clientr. strings to avoid unneeded loading time when opening the inv?

my "base item" is the wnpc

like item_100 is an Apple and the itemWeapon var is +Food

[Chompy]

>_>

It depends on how you want it to work, and hot it should affect the player, in-game and by systems I think

Originally Posted by projectigi

mudlibs Oo

edit after edit above:

what id? for every item thats created?
or for the base items?

so like the base item ak47
item_ak47?
x.x

uhm and ofc
wouldnt it be better to save the information of the item sin clientr. strings to avoid unneeded loading time when opening the inv?

bah,

ak47.arc = base item

then:

clientr.mud.item_1 = { ak47, weapon, dmg, spd, tps, description, icon}; etc...

ak47 is to load the file for info like equipping or whatever..

then do like getstringkeys( "clientr.mud.item_"); which would return an array of all the id (clientr.mud.item_*)

lalalalalalala (Tired and bored)

And an inventory doesn't need a timeout, only update it when needed

[Twinny]

Originally Posted by Chompy

clientr.mud.item_1 = { ak47, weapon, dmg, spd, tps, description, icon}; etc...

Or you could set it up so
clientr.mud.item_1={"deagle",quantity,personal modifications};

It's annoying having 500 lines of unneeded information ^-^

[Rapidwolve]

Hmm thats funny, I have mine setup as clientr.item_#=quantity...

[Inverness]

Bah, don't use clientr flags for storing item data in anything but an extremely simple system, those should only reflect item data for large systems.

In my system I load all item data into TStaticVar's on the serverside. They're designed to only work in a mudcontainer object, if you want the variables for opening the inventory you use:
MudContainerObject.reflectInvObjects(str location, boo delete?);

Location is relative to the container so for me, the default is "this.player.clientr.mud.item" because in the container object this.player is a reference to the TServerPlayer object. This would write all items to that location ending up with clientr.mud.item<ItemID#>=<important data array>.
The reflected data only contains important things used when displaying the inventory, like the item's fullname which is calculated from the prefix, suffix, singular, and plural names.

The way I have mine set up I could rather easily open the objects in other containers (player's inventories or other world objects) by doing something like: findcontainer("player","RandomAccount").reflectInv Objects("MudPlayer_Inverness.player.clientr.mud.it emsof_RandomAccount", false);
And yes it may be long-winded but its a base level function and can be shortened for specific things with several higher-level functions.

And yes, I am bragging about my leet system :P
But my thanks go to Stefan for the idea.

[Twinny]

I'd use that method if i constantly was moving information around (that system reminds me of encapsulation ) but it seems unneccessary for most basic to midrange mud systems.

[Inverness]

Yea well, for basic mudlibs its fine to store data in clientr.flags as long as its small and use a function to access the right index depending on a variable name.

But for Aeon, the system is alot more extensive and I'm planning the revamp it anyhow. First we would have the base MudObject and it would have certain joinable Qualities which would be comparable to Interfaces in Java.

Qualities List:

• Breakable - This quality is for objects that have a health and stop working properly when the health gets to 0 or so. This includes players, npcs, and certain world objects like gates that can be broken, and even weapons that degrade over time.
• Class - This quality is for objects that have a player class. It controls attributes and skills for players and npcs.
• Container - These are things that can hold inventory objects and has the functions to manage them like AddItem() and RemoveItem(). This would include players, npcs, and world objects like barrels and chests.
• Drawable - This property is for objects that can appear in a level and would dictate how they appear in the level.
• Enchantable - This is for objects that can be enchanted and would reference a magic effect list and determine how those effects apply to this object.
• Equippable - This would obviously be for objects that can be equipped by the player or other npcs and would have have functions for finding slots and triggering events when an object is equipped.
• Inventory - These are objects that can be stored in an inventory and would have certain values like GoldValue, Weight, Type, StaffItem.
• Magic - This is for objects that have a group of magical effects like spells and potions.
• Named - This is for objects have a name in the Mud System, players, npcs, world objects, items, spells.
• Player - This is the player quality and controls things unique to players in the system.

[godofwarares]

Woo, Thanks Inverness; You gave me an idea for MY MUD system o.o
-Coding-

[Inverness]

*Ego++*

Eh? Do tell...

I plan to release my MudLib to the public once I can get a stable and flexible system going that I'm satisfied with.
Though all my inspiration surely goes to Oblivion, its such a kickass game and I'm currently working on my first Mod for it. Its mostly scripting but its a spell that will allow you to Remove Enchantments or Switch Enchantments between items, which isn't normally possible obviously or I wouldn't be doing it.