Say Links

**trevius** · #1 04-22-2009, 05:55 AM

Hmm, this is interesting; I tried your itemlink2 code and it works for the most part. There is only 1 issue I have found with it. The issue is that it only works for item IDs that are less than 65536. It appears that it is only allotting and int16 worth of space for the item ID. Maybe it is cutting it off after that for some reason. This happens on both SoF and Titanium clients.

If I use this from within the script:

Code:

my $test3 = sprintf("%c%06X%s%s%c",0x12,71709,"000000000000000000000000000000000000000","Mask of Defiant Rage",0x12);

That works perfectly fine to show the correct item link.

But, if I try to use this:

Code:

my $mask = quest::varlink(71709);

The link returns item ID 6173 (Acrylia Reinforced Sleeves). And if I convert 6173 to hex, I get 181D. And if I convert 71709 to hex, I get 1181D. So, it makes sense that it is cutting off the first 1 in 1181D. I don't know why it would do this. The only thing I can think of is that maybe it is an issue with the MakeItemLink() function.

For any item ID less than 65536 it works great though. So, once this issue is resolved, I think this command should be ready to go.

**trevius** · #2 04-22-2009, 07:31 AM

Just figured out a pretty cool bonus to this new varlink quest command. Since it only requires the item ID, it makes it very easy to create arrays of items to use for a script that can be called on for creating itemlinks in say messages, or for item turn ins. So, you could have a single array that handles both, which would make things more simple and less likely to have mistakes.

Here is an example:

Code:

%epic = ("Warrior" => 60321, "Rogue" => 52347, "Monk" => 61025, "Berserker" => 18398, "Shadowknight" => 50003, "Paladin" => 64031, "Ranger" => 62627, "Bard" => 77631, "Beastlord" => 52911, "Cleric" => 9955, "Druid" => 62863, "Shaman" => 57400, "Wizard" => 12665, "Magician" => 19092, "Enchanter" => 52952, "Necromancer" => 62581);

sub EVENT_SAY {

  my $class_itemlink = quest::varlink($epic{$class});

  if($text=~/hail/i) {
      quest::say("The $class epic 1.5 is $class_itemlink.  Turn in a Cloth Cap to get yours!"); }

}

sub EVENT_ITEM {

  my $class_epic = $epic{$class};

  #Extremely simple Epic 1.5 quest (turn in a cloth cap!)
  if (plugin::check_handin(\%itemcount, 1001 => 1)) {
    quest::summonitem($class_epic);
    quest::exp(45000);
    quest::say ("It doesn't get much easier than that!");
  }
}

That is just a basic example and I am sure it could be written much better. But the main point is that it works and could really make handling a large number of items for turn ins and item links in say messages fairly quick to do.

**realityincarnate** · #3 04-22-2009, 11:17 AM

Oh yeah, it looks like I used an int16 in the perl XS part. I have no idea why I did that... I'm not sure this whole early morning/late night coding thing is such a great idea.

In perlparser.cpp change

Code:

uint16 itemID;

to

Code:

uint32 itemID;

And for the sake of consistency and to avoid any problems with much later item ids, you should probably change "int item_id" to "uint32 item_id" in the function headers in questmgr.h and .cpp too.

**trevius** · #4 04-22-2009, 05:42 PM

LOL, thanks! I was looking through for where that int16 was getting set, but I didn't think to look in the perl part!

I will get those changes done and run 1 final test on it, but I am sure that will fix it. That should pretty much finish up the new way to put item links into a variable. I guess this thread can get back to the original SayLink topic :P

**trevius** · #5 04-23-2009, 10:56 PM

I got the quest::varlink() command added to the SVN and also updated the wiki (here and the one I am working on to convert to MediaWiki) with the new quest command. Many thanks, realityincarnate! It works great, and that fix did correct the issue from before.

Not to figure out how to do those conversions into the aug fields and back into a string for the quest::saylink() command

**realityincarnate** · #6 04-25-2009, 04:39 PM

I finally got another chance to look at forcing another string into the link, and it's a lot more messed up than I thought.

For some reason, the client likes to receive a text representation of the hex values for augments, etc. I probably should have realized it from looking at how the item id is handled in the original sprintf statement used to generate the links, but it just didn't sink in. So just trying to put a string in there directly causes crashes because it doesn't know what to do with, for example, a hex number represented by "ST".

I was able to trick it into holding some information, but it's much less efficient than I had hoped. I used the string "test", which has a hex representation of 74 65 73 74. The link string allocates five characters for each augment, so we can put two letters in each.

Code:

sprintf(out_text, "%c%06X""%4X%1X%4X%1X""%s%s%c",0x12,999999,'te',0,'st',0,"00000000000000000000000000000","test link",0x12);

will produce an item link that will have "te" in aug0 and "st" in aug1.

Putting them back together is more fun. Each aug slot has two letters, now represented by hex bytes, and in the wrong order. I got them back out using a struct.

Code:

struct AugIn {
	char let2;
	char let1;
};

and running this to build the string.

Code:

AugIn* test;
	char response2[250];
	sprintf(response,"%c",0x00);
	for (int i = 0 ; i < 5; i++) {
		test = (AugIn*) &augments[i];
		sprintf(response,"%s%c%c", response, test->let1, test->let2);
	}

A similar struct method could be used to make it easier to get the string into the augments in the first place. It works, but leaves us with a limit of 10 characters for the response string. This could be increased by using the other variables (evolving item info, etc), but those variables aren't even being decoded by the emulator at the moment.

In other words, I'm beginning to doubt how much advantage this has over your the original suggestion of just using the database. I'll probably continue playing with it, out of stubbornness more than anything else, but I don't think the results will be anything spectacular.

**trevius** · #7 04-25-2009, 05:32 PM

Interesting stuff. I am not sure I understand why it is that only 2 letters can be used per aug slot. If it has 5 bytes per aug, couldn't we set 5 chars per aug? Then break the string into sections of 5 and maybe run some conversions on it like do atohex, then hextoi. I don't think all of the needed functions exist yet, but hextoi does in MiscFunctions.h. Then, after that, we would just do the reverse when the link was clicked. I dunno what it would take to do all of that though, but it sounds at least possible. Unless there is another reason for them only allowing 2 letters. If that is the case, then the database is probably the best way to go and should be pretty simple to do.

**realityincarnate** · #8 04-25-2009, 06:52 PM

The limitation is that the client wants the link sent as text. So, to send the letter "t", which is 74 in hex, you need to send the client the characters "7" and "4". So each character we want actually needs two bytes sent to the client. Since they're in groups of five, it ends up wasting the last byte. We could probably come up with a way to combine and use those too, but it seemed like a lot of work at the time.