XmlSockets

[sUpplier1]

What do you think about perfomance of such systems? I'm a bit cautious about XMLsockets and other mass xmlattach-items systems. I wasn't attentive when I looked at the code but I think that when there're will be many attaches it will lead to the great memory "leaks". XML-tables are very fat and loading/checking/unloading them on every hit in the world may lead to server lags.
Am I right? Or there's something that I didn't know?

Don't get me wrong, XMLspawner and it's attaches/triggers are really great, I like them and I use them.

 

[ArteGordon]

I believe that there is a little bit of confusion over the name. The Xml in XmlSockets, or any of the other XmlSpawner2 addons is just intended to reflect the fact that it requires the "Xml"Spawner2 system. It doesnt actually use XML for anything at all. That also applies to the entire attachment system which is serialized/deserialized in binary form and doesnt use XML for anything. In fact, the only thing that even the XmlSpawners themselves use XML for is saving and loading spawn configurations into external files, not everyday performance.

As for the sockets, and the other addons, I've done quite of bit of stress testing and performance profiling on all of them and the performance impact is barely detectable even under heavy use conditions. This is because the attachments work on a hash table lookup system that is keyed to the target object. So the only additional overhead that you would suffer using these systems as compared to actually putting all of this stuff directly into the target object classes, is the hashtable lookup use to get the attachment, and that is virtually nothing. After that, accessing any of the attachment data is just as efficient as if you were doing it all on the target class itself.

The memory load is basically the memory for the attachment data, which you would have to handle anyway if you were to put everything into the target class. The only additional memory overhead related to the system is the hashtable itself, and that is really negligible.

This is true of all of the attachment addons, but the sockets in particular are really minimal in cpu load since they dont really have ongoing functions tied to them. They are only engaged when you are adding sockets to a target, or adding augments to a socket.

 

[jaynigs]

They use a system of attachments that was developed as part of the xmlspawner package. Attachments are a way of associating an object such as an instance of the XmlSockets class to a target object such as an instance of a basecreature or baseweapon, without actually requiring modification of the target object.
In this way they alleviate the need to serialize/deserialize information directly by the target object class, or to make derivative classes that would perform this function, or in fact, to modify the target class in any way.

Attachments are a specific class that are defined in the xmlspawner system, so they arent actually "attached" to xmlspawners in any way, they simply use the attachment functionality that has been integrated into the xmlspawner system.

Arte, i wouldnt even waste your breath mate, as soon as these people remove their head from their arse they wont reply with pointless comments..

All these people can offer is criticism, if they dont want to use it, then they can save their comments for someone who cares. As runuo is still in beta / release candidate , it is very wise to use xml file stream to save information to avoid any messing up of serialization until we have a final runuo product.

If they dont like my opinion they can blow me, sick of reading this crap..

Phantom, if you have nothing nice to say, do us a favour, just stay out of the threads.

 

[sUpplier1]

Thanks Arte for the explanation, that's sounds very promising.
After reviewing and some balancing I'll install this system and will give you some feedback

Jaynigs, you got me wrong, please re-read my previous posting. There were no criticism in it, there were only questions that Arte successfully answered.

 

[jaynigs]

Thanks Arte for the explanation, that's sounds very promising.
After reviewing and some balancing I'll install this system and will give you some feedback

Jaynigs, you got me wrong, please re-read my previous posting. There were no criticism in it, there were only questions that Arte successfully answered.

Didnt mean u mate...

 

[ArteGordon]

Thanks Arte for the explanation, that's sounds very promising.
After reviewing and some balancing I'll install this system and will give you some feedback

Jaynigs, you got me wrong, please re-read my previous posting. There were no criticism in it, there were only questions that Arte successfully answered.

suggestions are always appreciated, particularly balance related issues since those are a little harder for me to test without a larger user base.

 

[Vertigo]

Arte hello

If i make random with this way:

private double m_MinSkillLevel = XmlSockets.DefaultSocketDifficulty + Utility.RandomMinMax( 0, 20 );
.....
private int m_ResourceQuantity = XmlSockets.DefaultSocketResourceQuantity + Utility.RandomMinMax( 0, 30 );

is this correct?

 

[ArteGordon]

that will recalculate a new random value each time the variable is checked which is probably a bit more random than you are thinking. If you just want to assign a random value once when it is constructed, then I would put it in the constructor like this

[Attachable]
        public XmlSocketable(int maxsockets)
        {
            MaxSockets = maxsockets;
            MinSkillLevel = XmlSockets.DefaultSocketDifficulty + Utility.RandomMinMax( 0, 20 );
            ResourceQuantity = XmlSockets.DefaultSocketResourceQuantity + Utility.RandomMinMax( 0, 30 );
        }

 

[ssalter]

ArteGordon,

Thank you for this. It is people like you and Arya and a few others who really make this a community. You don't strive for self importance, don't belittle others, don't do anything but accomplish quality work and supply support selflessly. Thank you again.

 

[ArteGordon]

thanks. This is all for fun after all so if if makes it a little more enjoyable, then its all good. Just another way of expressing appreciation for RunUO and all of the devs efforts.

 

[sUpplier1]

For example, I have katana with 3 sockets and 3 avalable Unsocketed (no any crystals/runes in it), How to add Crystals/Rune to it?
As I understand the only way to add Crystals/Runes to the item is when I'm adding sockets to it using Socket Hammer.
After the socketgump is closed there's no way to add Crystals/Runes to the socket even if you didn't put Crystals to it.

Just take a look at TestSocketedWeapon with "case 2" how to add Crystals/Runes to this one?

Also I'm pretty sure that Hammer should be deleted when it's out of charges

I'll post additional feedback soon.

 

[ArteGordon]

For example, I have katana with 3 sockets and 3 avalable Unsocketed (no any crystals/runes in it), How to add Crystals/Rune to it?
As I understand the only way to add Crystals/Runes to the item is when I'm adding sockets to it using Socket Hammer.
After the socketgump is closed there's no way to add Crystals/Runes to the socket even if you didn't put Crystals to it.

Just take a look at TestSocketedWeapon with "case 2" how to add Crystals/Runes to this one?

Also I'm pretty sure that Hammer should be deleted when it's out of charges

I'll post additional feedback soon.

To add augments (crystals/runes) to something that already has available sockets you just need to open the sockets gump by identifying the item and then clicking on an available socket. That will bring up a targeting cursor that you use to select the augment to put into that socket.

The socket hammer is used to add sockets to a socketable target. It isnt used to put things into the sockets themselves.

After the socket gump is closed, you need to use the item identification skill on the object to open it up again.

The testsocketedweapon just adds sockets to the katana, it doesnt put anything into them.

I didnt have the hammer delete itself when it ran out of charges, although its easy enough to put into the OnDoubleClick method.
Just change

if(UsesRemaining > 0)
                    UsesRemaining--;

to something like

if(UsesRemaining > 0)
                    UsesRemaining--;
if(UsesRemaining == 0)
{
     from.SendMessage("This hammer is now useless");
     Delete();
}

 

[ArteGordon]

Just take a look at TestSocketedWeapon with "case 2" how to add Crystals/Runes to this one?

In the current version you cannot add augments to sockets within a script, it has to be done by a player via targeting.

I will change that for the next update and add a new case in the TestSocketedWeapon to illustrate this feature. Thanks for pointing that out.

 

[sUpplier1]

Those goofy questions were beacause I didn't know about ItemIdentification, now everything is clear. I like the whole system.

I found that using ConfigureRandom it's possible to recieve Item with XmlAttach.AttachTo(target, new XmlSocketable(0));
I think this is Pretty useless one.

Some things that I made on my server:
I moved:
msg += String.Format("\nRequires {0} skill in {1} to socket.", MinSkillLevel, RequiredSkill);
msg += String.Format("\nSocketing consumes {0} {1}.", ResourceQuantity, RequiredResource.Name);
messages to Ident Gump ( if(from != null) ), beacause I don't like them in properties list.
I didn't understand one thing, where does last " in properties gump come from (take a look at screenshot)? Can you see it too?

Also I added ArtifactRarity check to disable arties with Sockets.
And added random SocketResource.

 

[ArteGordon]

you're right, the 0 socketable random config isnt really useful. I'll modify that and just make the 1-socketable case the default instead of the 0-socketable.

The quotes are just because of the cliloc that i used for displaying the attachment props.
The extra '\n' that puts the " on the last line is because of the way the OnIdentify strings get added to the props list in AddAttachmentProperties in xmlAttach.cs in xmlspawner2. It tacks on a cr between attachmentment OnIdentify fields but also leaves one at the end. That can be changed by modifying AddAttachmentProperties like this

public static void AddAttachmentProperties(object parent, ObjectPropertyList list)
        {
            if(parent == null) return;

            string propstr = null;

            ArrayList plist = XmlAttach.FindAttachments(parent);
            if(plist != null && plist.Count > 0)
            {
                for(int i = 0;i<plist.Count;i++)
                {
                    XmlAttachment a = plist[i] as XmlAttachment;
                    if(a != null && !a.Deleted)
                    {
                        propstr += a.OnIdentify(null);
                        if(i < plist.Count-1) propstr += "\n";
                    }
                }
            }

            if(propstr != null)
                list.Add( 1062613, propstr);
        }

Arti check is a good idea. I think I'll drop that in as a configuration flag.

Suppressing the extra socketing requirement info in the mouseover properties display also seems reasonable. I'll try that out.

Thanks for the suggestions.

 

[ArteGordon]

updated to version 1.04

from the changelog

New to v1.04
updated 12/26/04

- added support for adding augments via scripts instead of just via player targeting (thanks to sUpplier1 for the suggestion).

- added a new example of this feature in testsocketedweapon.cs (case 3)

- minor change in reporting of objects that have already reached their maximum number of allowed sockets. It no longer describes the requirements and socketing chance for such objects.

- minor change in property list display of socketable objects. The resource and skill requirements will no longer be displayed on mouseover. That info can still be obtained by using the Item Identification skill on the object.

- the random socket/socketable configuration method "ConfigureRandom" will no longer create 0-socketable configurations (thanks to sUpplier1 for pointing this out).

- added jewelry support to the crystal and radiant crystal augments.

- modified installation step 3 to support randomly socketed jewelry drops and to allow you to exclude the possibility of socketed artifacts if you like.

 

[sUpplier1]

Continuing to test the system, I found one more thing that I didn't like:
It's possible to make(to craft) Socketable items. Players can just craft items at home and receive them woth sockets.
I tried to disable this in several ways, In first just checking Crafter != null value in ConfigureRandom function.
But It didn't work, because Crafting properties are applied after the items generation.
I found nothing best than modifying CraftItem.cs and placing the code with removing sockets like:

		            ArrayList plist = XmlAttach.FindAttachments(item,typeof(XmlSockets));
                  if(plist != null && plist.Count > 0)
                    {
                        foreach(XmlAttachment x in plist)
                        {
                            x.Delete();
                        }
                    }

		            ArrayList ulist = XmlAttach.FindAttachments(item,typeof(XmlSocketable));
                  if(ulist != null && ulist.Count > 0)
                    {
                        foreach(XmlAttachment x in ulist)
                        {
                            x.Delete();
                        }
                    }

It works, but I didn't like this one. Maybe you know some other solvation of the problem?

 

[ArteGordon]

sorry I couldnt get right back to you, I have a lot of travelling this month.
Yes, by adding the attachments in the weapon/armor/jewel constructors it makes it possible for any such item to be socketed regardless of how it was created. So dropped or crafted weaps/armors/jewels can all end up socketed.

If you would like to have only dropped items get socketed, just move the ConfigureRandom calls out of the constructors and put them in LootPack.cs

For weapons/armor/jewels a good spot is in in the Mutate method around line 515

change

if ( item is BaseWeapon || item is BaseArmor || item is BaseJewel )
	{

to

if ( item is BaseWeapon || item is BaseArmor || item is BaseJewel )
	{
		XmlSockets.ConfigureRandom(item, 2.0, 0.1, 0.5, 3.0, 15.0, 50.0);