The problem was confirmed that for the latest clients (confirmed on v5.0.1h), a buy/sell vendor window still shows the description of the graphic of the item and not the objtype.desc as it should. There is also quantity naming issue with stacks. Here are all the posts:
MaudDib
MaudDibOk people. Done some investigating. First I'll list my POL setup:
Quote:
096 Beta Core (most recent)
096 Distro (most recent)
====POL.cfg====
ClientEncryptionVersion=uorice
====Servspecopt.cfg====
UOFeatureEnable=0x00
====Accounts.txt====
UOExpansion T2A
====Client version====
UOSE 4.0.11c
Vendor buy brings up the window as should (speech.mul still installed). The window, the text WORKS FINE. Only 1 issue. Items that are stackables, get listed differently than the others. Example:
Quote:
Backpack at 10gp
Arrows: 10 at 10gp
Will do some more testing. This is WITHOUT any sell window hook to convert to clilocs btw. Will post as i get more results and tests.
_________________
Project Board
Depository
Guides
Ok, new setup. Same result. Changed UOExpansion to AOS, Feature Enable to 0x20.
Showed npcs like it should, buy window now different.
backpack at 10gp
10 arrows at 10gp
Stackables changed. Desc stays that way in the confirm window too. Odd?!
_________________
Project Board
Depository
Guides
Marilla:
MaudDibMy problem has been that items in the buy window are already using client values, rather than the real names of the items.
If I rename a robe for sale to "blah blah", when the buy window comes up, client 4.0.4t shows it as a "Robe", and not "blah blah"; client 4.0.1b, however, shows it properly as "blah blah".
I have no trouble, either, with getting 'buy' to work, or any of the other stuff. The 4.0.4t client does show the amount of items in the buy list where it should not, as you note ("Blood Moss : 500 at 5 gp" instead of just "Bloodmoss 5gp")... but that's not a problem at all for me, compared with the problem of not showing the right name for the item in the window.
Ok, let's try this.
Take an item, new one, OUTSIDE the normal tiledata range (0x6329 for example, something past the max ID in the tiledata for the Artwork. Use INSIDEUO to get the max). Now, give it a custom name. See how that works.
So, the issue at hand now is, fixing the name. Told it uses clilocs, etc. I will investigate it to see how we can go about changing it. Especially since not all items on OSI match up Cliloc to Tiledata I think (special items, like Xbox of So and So, etc). They have clilocs for them, but the ID is different. And I doubt the code all custom items into the client. I'll try to do some checking on the new buy/sell packet structure and see what I can come up. Although I would rather the core support it, let's face it. The core doing too much, isn't a good thing. Should be easily fixable via a SIMPLE hook. AKA: If item.name != tiledatainfo name, fix it.
Shouldn't be TOO hard to come up with a fix in 096.
Marilla:
I tried putting an item with objtype 0x70ab that I have on my shard; It showed the tiledata name for the original graphic of the item.. so the client's going by graphic, only.
I also took an item and set it to a different graphic than originally; the name shown is that of the new graphic.
Perhaps there's something the client gets which lets it know not to use the client-side name?
MaudDib
To a degree.
The list of cliloc's for the items follows the same exact order (with an offset of course) as the tiledata. To an exact letter and all. However, on OSI, there ARE custom items with unique names. The catch is, logging a packet, to see how they determine which to use. I'll try to do that in a bit and post my results.
MaudDib
Ok, from OSI, it is the cliloc in it. Based on the packet structure of older clients, it gives the length of 8 for the description of the item. THe cliloc takes the first 7 places, then it is null terminated (so is description null terminated?).
And we all know, ALL items on OSI are in the clilocs. Now, let me give the results with the same client, and the packet sent from POL.
Using client 4.0.11c of course, newest out there.
Ok, POL sends the item's actual name. Interesting yet? Now, here is info on the older clients, which, still holds true on the new ones (to a degree).
This packet is always preceded by a describe contents packet (0x3c) with the container id as the (vendorID | 0x40000000) and then an open container packet (0x24?) with the vendorID only and a model number of 0x0030 (probably the model # for the buy screen)
Now, that being said. That is where it would get the idea of the numbers to place (since the "clilocs" would be invalid on POL sending them). Now, let's make a packet hook to "rename" arrows in the sendshop packet that pol sends, and test it with a provisioner. See if it changes the name on the gump.
Nothing, the conversion is 100 Client side (takes the graphic, and the count of it, and makes the conversion to cliloc with amount). Interesting.
Now, what i've discovered so far. It's a core issue, IN A SENSE. The AOS Tooltips sent after the SendShop and the AddMultipleItemsToContainer packets, are what is making the # prepended in the list. The "10 Arrows at 3gp", is caused by the core giving the stack info for the items in the vendor container! So, fix that with a packet hook, and you are good to go.
How to fix that? Easiest method is a hook that gets the id serial out of the Tooltip packet. Then, SFOBS the serial to get the Ref for it. Check the ref. If it is a mobile (or, the mobs inventory pack, hint hint) then restructure the tooltip without the "stack info".
Easier method? Ask the core devs for the fix. Since they know it is when the vendor's packet is sent for buy window, they should i hope, be able to add a check to send the info without processing stack properties. Only ones that can say if that is possible, is the core devs themselves. Hopefully they are reading this post to see the problem, and the fix.
Maybe a servspecopts.cfg entry for the style of buy window to send???
Also, is there issues with the SELL window also in the newer clients I need to check into?
MaudDib
Ok, also, do you have aos enabled, and the aos tooltips being shown? So far, that is where I am at, on the investigating of this issue.
MaudDib
Interesting.
Ok, newest clients (4.0.11c in testing), WILL show custom names. If I use the distro, and use "showinventory" with the merchant, and rename an item (using .iteminfo), it will give the new custom name in the sell window. However, if it is a stack, it still has the amt added to the beginning. So that is the only issue with Buy windows and the SE clients. The amt being prepended from a shop's inventory items.
Hrm. Now, with your client version, please try the above and see what the results is.
Marilla
Well; I guess EA just 'fixed' this with later clients, then. (later than the 4.0.4t)
I don't have any distros; but I renamed an item and put it on an NPC vendor; the item always shows with a name tied to the graphic of the item (not the object type, or the name/desc members).
I'm betting that any client new enough that it allows custom item names again probably also does not use verdata. hehe Oh well!
So I suppose I have to go back to a question I asked a bit ago: Does anyone know what the last client was that still read verdata.mul? I know it's at least 4.0.4t, since I know that one does. Maybe that info would be the perfect thing to know to 'fix' this; "Anything from client X to client Y will show cliloc names, rather than custom item names)
Alternatively, finding a nice tool to edit the gumpart files directly, instead of putting them in verdata, might help me (I only use Verdata for gumps).. but not anyone else who does use other things in Verdata, but wants to use a newer client to get the SE stuff.
Incidentally; yes, I have AoS stuff enabled, including tooltips. Incidentally, the TOOLTIPS show the cliloc names, and not the custom names, too.
MaudDib
Ok, it IS the client version.
Easiest way for you to test bout the verdata, is to patch each step with OSI, and use End Task to STOP the patch as it downloads the next one. Then fire the client, and see.
I know the first UOSE client did NOT use the verdata. How? Because they did away with needing it. They patch everything to UOSE cept the map.
4.04t is NOT an official client btw. Why? It is part of the UOSE beta series. When they was tweaking and screwing with it. Try 4.04a or 4.04b, and anything 4.0.5a and up (although, those are UOSE for sure, and won't use the verdata). Personally, never use a client that is "around" the beginning of a new expansion. Those are buggy as hell, and I know for sure get changed. AOS had that issue also. The first 3 or 4, maybe more, worked TOTALLY different for enabling the special features as the common ones do and current ones. Nice huh?
Now, on to the rest. Use a different client and see what you get (one of the ones recommended above!). That shop fix all your cliloc name issues I am betting. Test it, and let me know.
Far as editing the mul files directly, go to my website dude. There is a new guide I mirrored to do just that!! Using MUO Tool!
Now, for your file issue on our testing.............
Distro CVS (link below), the Mondain version is NOT compilable/useable YET, so just download the pol one. Compile it with the LATEST pol 096 beta core from the core-test group. Follow the UOConvert.txt instructions. And you are ready to test with a working Distro.
Now, let's see if we make some progress now
Marilla
Hey...
Had a minor disaster the other day, so I've been unable to do anything POL/UO related...
I see what you mean about the client; I did not know that about the 4.0.4t; It sounds very much like that could be the problem! I will do some client patching and see what works.
One thing I'm going to toss out, too; I'm assuming you are connecting in your tests to a server that is local or on a LAN? So the problem with inability to connect with low-latency is also not a problem with the clients you are using? (the 4.0.4t client does not have trouble, but all of the early SE clients I've tried had the trouble. There've been some threads here about it I'll have to find, if you want... but seems like it was a fairly limited problem with a certain range of clients)
As for the thing with a distro; I really can't use it. I haven't touched a distro since using the 095 distro as a reference in how to implement a couple of the new features it had (I moved our shard straight from 092 to 095 - Ack!)... I have right now a test 095 shard, and a test 096 shard, both running on my own system, not the distro. I just don't have the mental resources to keep my head around having something else! I've long since abandoned any idea at all of keeping my shard 'compatable' with anything else, which is why my help tends to be limited to certain things (I generally can't help anyone at all with understanding anything in the distro or some other popular shard setups like ZuluHotel)
Anywho, though... I was not aware there WAS an 096 distro, and I think I will dig into it anyway to check some stuff out, though not actually start it up or anything.
That was the end of the discussion. No idea if anything else was determined. Looks like 2 things rolled up into 1 thread:
* number of items displayed in a stack in a buy/sell window
* the description of the item for sale in the buy/sell window is taken from the graphic and not the objtype.
Both of these issues are problems for adopting v5 clients.
http://72.14.207.104/search?q=cache:XX_ ... clnk&cd=14