Question about quest::saylink()

[kameko]

Hey,

I have been playing around with using saylink() in my NPC conversations
and noticed that there would be about 4 or so zeros before the text in my
saylink.

If I do #reloadqst in game most times it will fix this.

Has anyone else had a similar problem?

Here is a sample of what I am talking about:

my $others = quest::saylink("others", 0, "others");

quest::say("I'm glad you managed to escape the slave warrens in one piece.
 There are many $others who were not as lucky. Here, take this burlap 
armor. It's not much, but it should keep you safe");

Produces this in game...

I'm glad you managed to escape the slave warrens in one piece. There are
 many 0000others who were not as lucky. Here,
 take this burlap armor. It's not much, but it should keep you safe

Any ideas? I think I am declaring my variable correct. and like I said,
when I reload the quests it shows the link without the 0000 in front.

Thanks,

Michael

[ChaosSlayerZ]

this look very similar to extra chars/digits produced when a T client user is looking at item link posted by a SoF client user in game.
But I never seen this happening with quest links.

[realityincarnate]

It most likely has to do with where you are creating the saylink. Titanium and SoF/SoD use slightly different formats for passing links. If you create the link inside an event that is initiated by a specific client, such as EVENT_SAY, it will generate the link for that client version and it will appear correctly.

If you create the link outside of an event, however, there is no way of knowing what client will trigger it. It currently assumes the SoF style of link, so those extra characters appear when viewing it with a Titanium client. You can work around this by creating links only inside events that pass a client variable.

[trevius]

Yeah, I have it set to use the SoF format by default if it wasn't initiated by a client. This is because Titanium saylinks mess up MUCH more for SoF clients than SoF saylinks do for Titanium clients. So, where you see 00000, then the saylink, if it was the other way around, a SoF client might see any number of possible stuff that messes it all up.

Hopefully at some point, we will be able to parse the messages on their way out to correct item links and say links on a per client basis so they show up right on any client.

[kameko]

Ok, so if I moved my variable declaration from the global scope to the EVENT_SAY scope it should work? I'll give it a try.

I'll have to work this into my program I've been working on.

Thanks for the info guys,

Michael