Page 1 of 1

Tooltip Packethook [0xD6]

Posted: Fri May 26, 2006 8:34 am
by MontuZ
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.

Posted: Fri May 26, 2006 12:44 pm
by Aeros
Ah, awesome :)

Will test and provide feedback where I can.

Posted: Fri May 26, 2006 1:00 pm
by Aeros
Ok, one question:

Code: Select all

		var Html := "<BASEFONT COLOR=#FFFFFF><C>";
		var xDesc := "";
		// Examples :)
		if ( xObject.newbie )
			xDesc := xDesc + Html + "Newbified<br>";
		endif
		if (xObject.isa(POLCLASS_WEAPON) || xObject.isa(POLCLASS_ARMOR))
			xDesc := xDesc + Html + "HP: " + xObject.hp + "<br>";
			xDesc := xDesc + Html + "Max HP: " + xObject.maxhp + "<br>";
		endif

		xDesc := CAscZ(xDesc);
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 :)

Posted: Fri May 26, 2006 2:17 pm
by Aeros
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.

Code: Select all

		// I've noticed that this packet is only sent if this value has changed
		// from the last time it was checked. And using html to change the size doesn't work
		// for some reason. Maybe a core/client issue?
Related to that maybe? If so, any workaround?

Posted: Fri May 26, 2006 3:53 pm
by MontuZ
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.

Posted: Fri May 26, 2006 4:27 pm
by MontuZ
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?

Posted: Sat May 27, 2006 12:48 am
by Xadhoom
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 :D

Posted: Sat May 27, 2006 9:43 am
by Aeros
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?

Posted: Sat May 27, 2006 9:51 am
by Aeros
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.

Posted: Sat May 27, 2006 11:17 am
by Aeros
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:

Code: Select all

		if (Cint(xObject.graphic) in {3649,3648,3702,3701,3705}) //CONTAINER
			xDesc := xDesc + Html + "<br>";
			var itemcnt := xObject.item_count;
			itemcnt := itemcnt - 1;
			xDesc := xDesc + Html + "Contains: " + itemcnt + " items<br>";
		endif
and, in onInsert.src:

Code: Select all

program on_insert(who, container, movetype, inserttype, adding_item, existing_stack, amt_to_add )

	SetName(container,container.desc);
etc.
Doesn't work..

[/code]

Posted: Sat May 27, 2006 11:47 am
by qrak
I'm using SetName( xObject, xObject.name); in tooltips.src and i'm happy with that:). Equipping/Unequipping stuff is changing description in tooltip.

Posted: Sat May 27, 2006 11:58 am
by Aeros
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.

Posted: Sat May 27, 2006 3:08 pm
by Xadhoom
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

Posted: Sat May 27, 2006 3:28 pm
by MuadDib
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.

Posted: Sat May 27, 2006 4:19 pm
by Aeros
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..

Posted: Wed Aug 09, 2006 1:47 pm
by skymarshal
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

Posted: Thu Aug 10, 2006 9:59 am
by skymarshal
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. :<

Code: Select all

		if ( xDesc.Size( > 0 )
		

			// Cliloc ID if these two ID's match it'll only show one line.
			packet.SetInt32(packet.GetSize() - 1, 3010200); // old value 1070722
			
  			// Get the offset of where the next text size
			var Length_ID := packet.GetSize();
			
			packet.SetUnicodeString(packet.GetSize() + 1, xDesc, 1);	
			
			// SetUnicodeString adds 00 BYTE[1] at the start of the Unicode offset, 
			// which messes with the length offset.
			// Setting the length of the unicode text below will fix that issue. Same deal as above.
			packet.SetInt16(Length_ID, xDesc.Size() * 2);
			
		endif

Posted: Sat Apr 07, 2007 7:07 am
by OldnGrey
You going to put this into the Distro maybe?
Doesn't look like a core solution is going to happen soon.

Posted: Tue Apr 10, 2007 2:10 am
by zandor
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....

Posted: Tue Apr 10, 2007 2:59 am
by OldnGrey
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.

Posted: Sun Apr 22, 2007 2:48 am
by Naglfar
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?

Posted: Sun Apr 22, 2007 4:10 am
by OldnGrey
Yep. I am using 097RC3 and tooltips works well apart from the growing RAM memory leak.

To make it work you need something like
UOFeatureEnable=0x20
in servspecopt.cfg



Their account (accounts.txt) should also have:
UOExpansion AOS
I do this with something like:

Code: Select all

	var acctref :=  FindAccount(character.acctname);
	if ( character.clientversion[1, 1] == "4" )
		acctref.set_uo_expansion("AOS");
	elseif ( character.clientversion[1, 1] == "5" )
		acctref.set_uo_expansion("ML");
	else
		acctref.set_uo_expansion("T2A");
	endif
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

Posted: Tue Apr 24, 2007 6:23 am
by tartaros
OldnGrey wrote: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.
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...

Posted: Tue Apr 24, 2007 8:15 am
by MuadDib
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).