Author: MontuZ(Aka Unreal) (MontuZ@Gmail.com) May 26, 2006.

Version: 1.0

Core: 096

Bugs: Tested it about a thousand times without any problems.

Ah, awesome

Will test and provide feedback where I can.

Ok, one question:



Works fine, except - when an item is newbified during the course of gameplay, the tooltip doesn't update to reflect the newbie status.

Secondly, I've set xDesc to contain the text "This is a nice item" (very original, i know) on an earlier session. After that, I changed the file, recompiled, and restarted the server. But, lo and behold, after the server restart, one of the items in my backpack still had the tooltip "This is a nice item.".

Don't know if these are bugs, or something I'm doing wrong

Question/observation #2:

If an item property changes during the course of gameplay (e.g., the item's HP changes), this does not seem to reflect on the tooltip until after a restart. This is the case with any property, not just HP.

EDIT: When putting prints() in the exported function, it seems to be calling it quite a few times for a heckload of random items on server startup, and then not again. So for instance, if I hover on a shield, it doesn't call the exported function again, and therefore does not update the item properties.



Related to that maybe? If so, any workaround?

See, we're just modifing what the server sent.

0xBF SubCMD 0x10 is sent by the client to requesting tooltip data. (Currently) Server checks to see if anything has changed(Only checks for a name change, doesn't check if they turned a murderer, criminal, etc) I think, I have no idea how the server does this check. Or if it's the client. I'm pretty sure it's the server.

We'd have to hook that packet and check the data from it's old data to see if anything's changed(Cprops, dmg_mod, hp_mod, all the stuff we want to check) And send the packet if it has changed. Only way I can think to check for changes is if a CProp/Datafile stores the data we've already sent out. But that could be a lot of data to hold in most cases. Which is why I only hooked 0xD6 when it's being sent out.

OR... We just send 0xD6 and not give a damn about bandwidth... ? But I don't like that idea. Then again storing all the items data in a datafile would take up a lot of space(In the end when you got about 100k items on your server(Or a million, whatever, lol.).). And may result in a performance issue. Either way we're screwed in the end.

I am however going to hook 0xBF SubCMD 0x10 right now and do some tests.


Sorry if that's not very detailed. I'm not much of a explainer... lol.

Alright. I think I'm very wrong.

I tried to see how many times Tooltip Request packet was sent to the server. And it was only sent once. The server replied with the tooltip data. Then I hovered my mouse over the items again and it wasn't sent. So I'm guessin' it 's clientside.

I really have no idea how we're supposed to update the data. Any ideas?

You just need to rename the item after you change something and you want to refresh the tooltip. Something like SetName( item, item.desc ); and the client will ask again for the tooltip

i will try your hook because that one i use sometimes crashes pol, after the test i'll say if it works

Well, instead of trying to find the millions of scripts where the item's name should be changed, cant we just change it in the tooltip script?

Well, that didnt work. Didn't think it would too. So, guess we'll have to identify where the item's properties could possibly change.

Well, changing the name works. One thing though:

Changing a bag's name in the onRemove and onInsert scripts doesnt update its tooltip at all. Check:

in tooltips.src:


and, in onInsert.src:


Doesn't work..

[/code]

I'm using SetName( xObject, xObject.name); in tooltips.src and i'm happy with that:). Equipping/Unequipping stuff is changing description in tooltip.

That doesn't work for me... Where in the script do you do that?

Secondly, that would only work for mobiles, wouldnt it? An item has .desc for names.

Items have .desc, but if you rename an item, then it has also .name, otherwise if i remember well .name is an empty string

About the OnInsert i don't know, but using rename works well on everything, maybe i haven't tried with containers.
You can try to rename the container in its CanInsert script, maye should work

Do me a favor peeps.

This needs to be reported (cuz will be looked into in 097 probably) that item info being changed is NOT updating "the revision number" that is required for tooltips to work correctly.

When stuff is changed, the server tries to resync with the client. THe client Caches the tooltip data now, so the server sends the new revision #, and the process starts over.

What needs to be done, is the core changed to know when stuff is done (like newbie, name, etc being changed) and the new info sent to the client.

Luckily for me, this already happens in a sense with the Reputation system thanks to the way i rewrote it. But items and such, unfortunately, are not updated the same way as reputation is.

Will do, Muad - it'd be nice if the core can monitor for changes

Ok guys, got the tooltips working fine, except still in the case of containers. If anyone can test and confirm this..

And i'm getting this in my tooltip, when creating a dagger and pointing it.

a Dagger
Error (MegaCliloc) : StringId Not Found : 1070722


Any ideas how i can correct this?
I have been away from UO and POL for several years and i can't do anything for this atm. before i learn this system again.


Thanks in advance

Pff... I don't have anything proper in my cliloc.* files what to use instead of your 1070722 cliloc id. Except ID 1042971, "~1_NOTHING~", which is already used for object name.

I chosen to write object "3010200 ~1_stuff~" info in cliloc.enu-file.

Now this is working fine but i don't like about this move, changing special client files. :<

You going to put this into the Distro maybe?
Doesn't look like a core solution is going to happen soon.

I need help.... What are you speaking on? What is "cliloc" and item description? Can't be use ".desc" ? What do this package? Sorry but i really know none of what you are speaking....

I've been using this package with mixed results now for a few days.
The big issue seems to be updates to quantities as you already found out.

The other problem is that even players with AoS seem to need some patching up with OSI to get this package to work with a v4.0.3d client otherwise mobiles give them a tooltip error namig megacliloc. Items seem to work okay.

Also LBR installs seem to have the same error even if patched up with OSI.

And if you want an example of memory leaks, use megaclilocs. Our RAM has started growing massively since it was introduced.

I use core 097 RC3, ML client 5.0.9.1, package starts correctly but i can't see any tooltips.

Does this package work with core 097, ML and latest clientes?

Yep. I am using 097RC3 and tooltips works well apart from the growing RAM memory leak.

To make it work you need something like

in servspecopt.cfg



Their account (accounts.txt) should also have:


I do this with something like:

One oddity, it can take a couple of seconds for .clientverion to register a value, so I run this after a sleep spawned off logon.src

Dunno how POl has this implemented, but the truth is that these tooltips only work since 3.0.6o (I think), by then they used the 0xbf 0x10 packet to resync the tooltip identity ("revision") number, now they use 0xDC (which can request more than one megacliloc packets at once), I haven't yet foud out when exactly was the 0xDC introduced (gonna need that soon tho ) because I'm now in the process of implementing this functionality into my emulator...

It should be also noted that it's always the server who initializes the tooltip syncing, by sending the tooltip identities that it believes could be new for the client. The client looks into it's cache, and if it doesn't have them there, it requests the data (megacliloc). The server also has to keep a parallel cache of the sent identities and their data, until they change or become unused for long etc. - that might look like a memory leak. Or it may be a real one
And whenever one of the displayed properties change, the server should send to clients around the new tooltip identity and be prepared to send the data on request...

Give me some time on those memory leaks. Between shini and me, we should be able to fix more in 098 which is coming soon I hope. I plan several optimizations in the core, one of which may fix memory leaks involving .ecl execution (god i hope so, lol).