Buy/Sell with v5 client (entire original thread now quoted)

OldnGrey · Post by **OldnGrey** » Thu Feb 09, 2006 11:58 pm

This was a topic in the old forum, but as far as I know these two probems weren't resolved. (discussed back in August 05)

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

Ok 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

MaudDib

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:

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

MaudDib

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

Post by **MuadDib** » Sun Feb 12, 2006 10:18 pm

v5...........

Can't test yet, nbut hopefully someone can!......

Try forcing it to send the name (tooltips also if used) again after sell/buy window is opened, to the client. Can try just renaming it quickly to test that.

Xandros · Post by **Xandros** » Sun Feb 19, 2006 3:12 am

There is no easy solution to this problem. No matter what you do, the
client will always use the stupid cliloc descriptions instead of the real item
names.

In the end we had to script our own buy and sell gumps so that we
could switch to the newer clients. Of course they're not as user
friendly as the hardcoded vendor gumps, but it was the only solution.
Luckily the newer clients support the TILEPICHUE tag in gumps,
so that you can at least script a gump that shows the items with their
correct color.

Xandros

Post by **MuadDib** » Sun Feb 19, 2006 4:28 am

Have you tried using tooltips, and resending the tooltip info after the sell and buy gumps? (OSI Does that iirc)? Same for sending the name info normal if you don't after the window is sent?

Xandros · Post by **Xandros** » Sun Feb 19, 2006 6:15 am

I'm not sure if that makes any sense. Once the client got the buy/sell
window packet, it opens that window. Whats the point in sending
item data afterwards? I don't think we tried anything like that.

Xandros

Post by **MuadDib** » Sun Feb 19, 2006 9:47 pm

The Buy/Sell window is treated as a Container so-to-speak in the client is why. All the items within can be changed while the window is open (by the server).

Post by **MuadDib** » Sun Feb 19, 2006 10:19 pm

Side Note: I have been debating a core command such as ObjectUpdate(item, mobile). That would force resending info to client for the selected item under normal UO, and force an item version # increase if AOS Tooltips are enabled, and sending the tooltip again.

Back to main subject: But once i get my pc here, i can see if the core has the support it SHOULD have for buy/sell under tooltips (that is where I will start on the problem). cuz it will be the same for nontooltip servers also, just handled different I believe.

In newer client especially, when a B/S window is sent, the client opens a container gump type object with the items inside. If you resend the info, or change those items then update the client, it will change what is seen in the B/S window. That is where the problem is I believe.

Marilla · Post by **Marilla** » Mon Feb 20, 2006 3:45 pm

I'm glad to see this problem wasn't just with me doing something stupid

Post by **MuadDib** » Mon Mar 06, 2006 12:31 am

After extreme testing with OldnGrey, I think we have a resolution (for now) with this oversized problem. Please read the post in the Bug Reports forum for 096 for this fix. Client side issues suck.

Post by **Yukiko** » Sun Apr 30, 2006 1:29 pm

*claps hands*

Yay!!!

Thanks Maud Dib for all your hard work.

I haven't encountered this problem yet but I am glad you are here to resolve these things.

Note: Here follows a deliberate attempt to encourage those who work so hard for nothing more than the furthering of other's enjoyment.

It isn't said enough, and yes I know this is somewhat off topic but I want to thank all of the developers: Shinigami, Melanius, Austin, Birdy, Syzygy (not sure I spelled that right. I believe he was/is a dev), Maud Dib ofcourse and anyone else I forgot or don't know about.

You guys are THE best!!!

Post by **Shinigami** » Mon May 01, 2006 5:26 am

MuadDib wrote:After extreme testing with OldnGrey, I think we have a resolution (for now) with this oversized problem. Please read the post in the Bug Reports forum for 096 for this fix. Client side issues suck.

...just send mega cliloc in front of opening then gumps. this will become a core-inside feature ASAP (a working test-release still exists)

Shinigami

Post by **Shinigami** » Tue May 09, 2006 4:50 am

just check out latest build:

Code: Select all

05-07 Shinigami
        Added : flag VENDOR_SEND_AOS_TOOLTIP in
                  uo::SendBuyWindow( character, container, vendor, items, flags := 0 )
                  uo::SendSellWindow( character, vendor, i1, i2, i3, flags := 0 )
                to send Item Description using AoS Tooltips in any case (this will correct problems
                with Item Descriptions in newer Clients, but maybe freeze ancient Clients...).

feel free to test...

Shinigami

Post by **Shinigami** » Wed May 24, 2006 11:59 am

no comments? hmm

Shinigami

CWO · Post by **CWO** » Wed May 24, 2006 4:39 pm

Oh thought you knew... I am using it currently and it works perfectly even without AOS stuff. And like you note, it either freezes or crashes any client thats not 4.x or 5.x. "Deed" turns into "a deed for a large tower" as it should

Datus · Post by **Datus** » Thu Oct 12, 2006 7:17 pm

I'm just wondering if this flag is supposed to fix the stack amount from showing up as the item description. My item descriptions work properly but the item amount still shows up in the name. A stack of Nightsight potions for instance show as "10 Nightsight potions at 18gp". If I enter one into the bill of sale it will say , "1 10 Nightsight potions at 18gp". Same problem Marilla described originaly.

I've entered flag := 0x01 in sendbuywindow and sendsellwindow functions within uo.em. I've also tried simply entering the constant, VENDOR_SEND_AOS_TOOLTIP within the same functions of merchant.src itself. Just wondering if I'm doing something wrong?

Core version 96.3

Thanks!

CWO · Post by **CWO** » Thu Oct 12, 2006 8:13 pm

this doesnt affect what names the server handles. It only fixes what names the client sees inside the buy/sell window. It was never intended to have any affect especially after you already bought it.

Marilla · Post by **Marilla** » Thu Oct 12, 2006 10:49 pm

Datus wrote:If I enter one into the bill of sale it will say , "1 10 Nightsight potions at 18gp". Same problem Marilla described originaly.

Actually, that's not the problem I was reporting; I think someone else had that. I was reporting that the buy/sell windows always showed the cliloc names for items, and not the server names.

Datus · Post by **Datus** » Fri Oct 13, 2006 4:53 am

CWO wrote:this doesnt affect what names the server handles. It only fixes what names the client sees inside the buy/sell window. It was never intended to have any affect especially after you already bought it.

Yes I understand that. I have no problem with the item name once I buy it. As stated I'm refering to how it appears in the "Bill of Sale" portion of the Buy/Sell window, aka the "Confirm Window".

The Item takes on whatever name I enter in the "desc" parameter. So that works fine.

I'll illustrate the problem.

Alchemist has 10 Nightsight Potions for sale. In the B/S window they show as "10 Nightsight Potions at 18gp". This is OK. When I double click them to enter them into the Bill of Sale(aka confirm window) it now says, "1 10 Nightsight Potions at 18gp". See how it's wacked?

So before I try to chase this down, I'm just wondering if others have this problem, if it's related to the aforementioned bug, or if my gumps/configs need fixing.

Marilla,

Sorry I must have mis-read your post.

Thanks!

Datus · Post by **Datus** » Fri Oct 13, 2006 9:07 am

OK, nevermind I fixed it. I had the megacliloc tooltip package enabled even though I haven't made any changes to allow tooltips to actually work properly.... so disabling the package fixed the problem for now.

Now I wonder if I even need the VENDOR_SEND_AOS_TOOLTIP flag if I'm not using tooltips...

Sorry if I sound really confused cause I am

... but I'm learning...

Thanks.

CWO · Post by **CWO** » Fri Oct 13, 2006 11:30 am

yes you can use it even though you're not using tooltips. My shard does. You have to in order to ever support 5.x clients on your shard with the usual buy/sell window. Its the difference between it saying "a deed to a small forge" or just "deed" in the buy/sell window.