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 with an offset of 0x4000? Is it posible for it to be much greater? I was hoping it could be something like an offset of 0x7000000 instead. But I don't know if the graphic ID is 4 bytes or 2, nor do I know if POL hard codes some sort of relationship between Graphic & MultiID, although given both are being defined in itemdesc.cfg, I am for the moment hoping it isn't a fixed relationship hard coded.

Even being able to shift the offset to 0xF000 would possibly/probably be good.

You are probably at this point asking "Why do you want to do this?"

Well, in a prior message on the bug board I discussed a new client which opens up the possibility of gaining the ability of using more layer IDs than is currently available with the OSI client. That is a future thing that may or may not be added(I am hoping it will be). But one thing it does already support is having graphic ID's >= 0x4000 in tiledata and art mul files and accessible via the client. This means you can have a tremendous amount more of art supported by the client, if, POL supports it.

I realize at this point we are restricted to <0x4000, but believe that most of that is probably fixable to allow art above that ID. The biggest issue I would see as far as conflicts is how Multis are given graphic ID's in that range. Of course, there are also alot of other custom items that are > 0x4000 which would have to be watched, but this is something that is managable if POL loosens up that restriction. So an easy place to add a lot of new art would be just above the current art, in the 0x4### range. But my multis all have their graphic ID there, so I would like to move them higher if possible to get them out of the way.

As a design issue, I realize there gets to be the problem of "How can you tell if the item is in the traditional range of OSI art, a custom item, or specifically a piece of art that has a graphic and tiledata entry way outside the traditional range of OSI art?

My suggestion for this would be that if an item is >=0x4000 and has as it's graphic an ID >=0x4000, and isn't a house/boat entry, then you know it is an item in art >=0x4000 and to look there for entries. UOConvert would have to be modified to handle entries > 0x4000 too of course to create proper tiles.cfg entries, but I think this could all be managed, and would be of great benefit to the currently art-tight restrictiveness of OSI clients, allowing us to put in more art and use a custom client more effectively.

So, the two questions I guess are :

1) Is the 0x4000 offset to multiID's something that is hard coded or can I pick whatever offset I want, and if I can pick what I want, what is the highest offset POL will allow?

2) Is it feasible to modify POL in the future to allow for art with IDs >=0x4000 to take advantage of custom clients which allow for the display of such art?

I realize that neither will be forthcoming in 097 specifically likely, and that this is a longer term project where you will have to go through POL code and find where the checks for out of range IDs are, and raise these checks and deal with design issues involving such raising, but is it possible?

I probably won't be back before new years to read any replies or make any myself, so Merry Christmas/Happy Holidays/etc to everyone and have a Happy New Year!

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 then, why waste time and effort?

Custom clients should be designed around the server; not the other way around. That's why they're called "custom clients." As for the rest of your question; I'm sorry, but I really couldn't tell ya

Marilla wrote: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 then, why waste time and effort?

SMJ wrote:Custom clients should be designed around the server; not the other way around. That's why they're called "custom clients." As for the rest of your question; I'm sorry, but I really couldn't tell ya

Well, I can only hope that the developers don't share these beliefs I guess.

Marilla, why 'waste the time and effort'? Well, a few reasons come to mind off the top of my head. For one, most of your assertions are just wrong. The client does exist, and it is being used by players. For another, being 'finished' is a silly standard to hold any piece of software to. The only 'finished' software is software that has ceased to be supported, POL included in this. In fact the POL faq from years ago used to state that POL isn't finished and probably never would be. And finally, when I went to the developer of the client and asked him to make changes to his client to support some of POLs specific issues(like server ID's being offset in a way different from Sphere & RunUO, and at least two other issues), he didn't give me as a list the following reasons he wouldn't support POL..

a) POL doesn't really exist.

b) POL isn't used by any actual players.

c) POL isn't finished.

He could have argued all three effectively as you can argue his client in those statements in place of POL, but he didn't. He was nice, he looked at the issues, saw they weren't too difficult to make work, and did so. If for no other reason than the fact that he didn't sound off with an attitude of "Eh, RunUO rules the world, why bother with a stupid little server like POL?" and instead was happy to help support POL. If for no other reason at all, I think that is reason enough to at least 'waste a little time and effort' on supporting his client.

neizarr wrote:The client does exist, and it is being used by players.

Krioss and Iris exist, and were being used by players, too. But I think we all know what I meant.

You can hope, I can hope... let's all hope. It's the season of hope. Tell you what - hold your breath for this feature not supported by 99.99999...% of the clients that connect to POL. I'll come check on ya in a few years or so.

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#.

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?

MuadDib wrote: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 intentionally shuts down the shard if the death robe isn't at the layer it wants it at, 095 and most of 096 test cores didn't, so this is intentional design for reasons I still haven't heard explained. I still think it's the ESRB. I blame it all on the reactionaries who witnessed Janet Jackson on that infamous superbowl flashing incident.

Yes, Mulpatcher allows you to extend out the various files to have art and tiledata ID's greater than 0x4000. It is written by the same guy as who wrote the client, look for the button under the list of ID's & Art that says "Fill slots to 0x7FFF"