I think we are missing something in translation. Cfgelem.Weapon would return whether there was a Weapon property inside the Cfgelem. What I want is the Type for that Element, not an element named Weapon.

Ie :

Weapon 0x5352
{
...
Weapon 1
...
}

Armor 0x5352
{
...
Weapon 1
...
}

If you have ...

The Type I speak of is of the config file element Type...such as Weapon, Armor, Item, etc.

It is useful in that it allows you to know what sort of Type the config element is. Bear in mind, in this case I am not speaking of the "TypeOf" type, but rather the config elem Type.

As in :

Weapon 0xF020 ...

Not sure if these have been suggested already, and to be honest, I'm moving to another server platform anyway, but I had always found these lacking in POL before so thought I would suggest them for it's improvement.

A way to get all the properties in a given cfg element without necessarily knowing ...

It means you don't have to write a packet hook to handle the control-shift allnames stuff. POL will handle it automatically for you.

Varan's client (Palanthir) now fully supports up to 255 fully configurable layers.

It also fully supports the following :

Art with > 0x4000 ID's, this can be added to the MUL files with his nearly famous mulpatcher program, though POL does not support this yet.

Configurable stackable ID's (ie ...

Death robe fix ......... it's not a bug. So no need to fix anything there imo.

Far as the multis....... is there even a tool that extends past the maximum of the current OSI files? I know most all replace and add into, but not extend. Is there any?

True on the "fix" comment. 097 now ...

Second time I'm the .0000001% of the population that doesn't do it the way the rest of POL users do. Trust me, I won't hold my breath for this or the death robe fix. So I'm taking the hint and brushing up on my C#.

I think it would be a big mistake for the dev team to waste time working on a feature for yet-another-custom-client that's likely to go the same direction as Krioss/Iris - nowhere. Maybe when such a client really exists, and is really finished, and is really being used by actual players... until ...

How exactly are Multi IDs related to graphic IDs in POL? For instance, in the 097 distro I see :

House 0x4066
{
Name House0x4066
Graphic 0x4066
MultiID 0x66
}

The only one of those defined in MUL files is 0x66 of course. I am assuming you must assign a graphic ID to a multi? Does it HAVE to be ...

Sue me for having some fun.

I thought the ESRB comment was funny at least!

Well, layer 22 for death robe is not something that was the case before, this is new to 097 or more recent versions of 096 than what I was using(and still use primarily because of this issue alone now).

So I don't really see why this is a layer that POL would worry about, I don't see why POL even ...

The same guy that made the program MulPatcher, which I'm sure most are familiar with as one of the best MUL editting tools out there, has written a fairly decent client and has said he wants to add to the # of layers available and a system for shard operaters to specify draw priorities.

You can ...

I am not sure if there is another release that does better or if the current distro has something that compares, but this one include file has nearly revolutionized the way I handle player/staff interfacing, and I thought I would share it with others.

I also included a small sample script that I ...

I'm glad you saw the discrepency actually in the layers, or I'm not sure I would have ever thought back to when I changed all those layers! I would have just given up on it as some weird fluke probably. So no need to apologize, you helped, and I just needed to explain why I was doing what I was ...

Yes and no? :)

The Yes : If you get the script PID for the script running the gump then you have some degree of control over the gump. Here is the sequence you would have to follow. This assumes you are using a custom skill gump like I am. I think the default OSI skill gump automatically updates ...

I'm calm, I just didn't want anyone to think I was angry or something.

As for the client, no, it isn't. There is nothing actually in the client that forces robes to be at layer 22 at all, you can in fact shuffle the layers all over the place as you please and to your pleasure. All that layers do is ...

Oh, just to be clear, though I probably sounded shocked and perhaps even a bit demanding in that last post, it was more shock than demand, trust me. I do feel strongly about what I was saying, but understand that these issues may not be of utmost importance to the devs or that there may be some ...

Gosh, that was it. I didn't go so far on hopes that the tiledata.mul file didn't have to synch with the tiles.cfg file to do the test.

But for some reason I haven't figured out yet, POL is now making checks against layers? When did this happen and why? I would really prefer those checks be taken ...

Serious? About the layer needing to be 22 I mean? Can a dev confirm this? Because I specifically switched around the layers on my shard because I didn't like the way OSI did them and have been using a custom setup forever now that has worked fine with 096. I don't see why the core would suddenly ...

I went ahead and tried it anyway, no dice.

use uo;

program equiptest(who, item, startup)

return 1;

endprogram

That is my equiptest.ecl program located in scripts/misc.

Same error when I do the .resonly script.

I will try that tomorrow, for tonight I need to put this away. But I did a search and don't have an equiptest.src in my scripts/misc folder or anywhere at all for that matter.

Is that file required? My 096 test core shard seems to run fine without it, and the first mention of equiptest in core ...

I'm not entirely sure of the context of your question so I'll answer the two ways I can see.

1) Can I equip this item (0x1f03) via script?

Yes. I .create 0x1f03 and it puts a deathrobe at my feet. I type .equip target the robe, target myself, and it equips it to me. I can also equip it via ...

Tried it at the distro shard and it didn't crash.

I'm still at a loss though. I'm using the .res of old 094, which was a simple script that worked through 094, 095, 096. I guess something is not working with the item, yet I can equip the item if I just .create 0x1f03 and drag it onto the paperdoll ...

It would be nice if the method function isA would accept a new constant POLCLASS_PC, which would basically just do the check to see if it is a POLCLASS_MOBILE & not a POLCLASS_NPC.

Sure, it's easily scriptable, and you can do it in a include file, but if it existed in the core it would be a ...

I don't really see anything per say that raises any red flags. If I create the item and equip it via the paperdoll it equips just fine.

Armor 0x1F03
{
Name deathrobe
AR 2
Coverage Body
Coverage Legs
Coverage Arms
newbie 1
maxhp 1
dyeable 1
equipscript :combat:equip
unequipscript :combat ...