COMMITTED: More detailed merchant rejection code
 

The code (at least the version I have from eqemu) that tells a PC to go pound salt, isn't good enough to avoid situations where a half elf is told by a half elf that his race should go elsewhere.

This patch changes it so the merchant decides what to say based on the worst contributor vs primary faction be it class, race, deity or nasty deeds.

Use it if you like, seems to be working as intended on my server.

You should really change this to use the eqstr_us.txt versions.
Look around the code for how this is used. It'll be MUCH easier to pull a deity/race/class name that way.

Also, you used rand() instead of our random system. I'd change that too. (MakeRandomInt(0, 4) for example)

Not that it matters if you're going to use the eqstr_us.txt version here, but, If you're going to use a string, may as well use it all the way and build the string as you go along as opposed to using these temporary buffers. I would c_str() it when it comes time to use it in a function that uses it instead of what you have set up right now. I know the code doesn't have this practice but it was made at a time string had performance issues. But, moreso for code cleanliness and readability, and a slight performance boost from a compiler standpoint as there's less messing with registers.

Regardless I'll see if I can get this cleaned up and put in the main branch soon. Thanks a ton!

I'm still learning about the code base, so I tried to change as little as I could

When you say to use the eqstr_us.txt versions, is there a mechanism for that or are you just saying to go find those strings and put them into the code like the ones that were there (I didn't pick then strings, I used what was in the code already).

Do you want me to followup with guidance and resubmit, or am I stealing what you clean up? :)

Thank you.

Usually we set up a define in zone/stringid.h since defines are better than just the raw number. Pretty much everything the live server sends to the client used these because its a lot better packet size wise. The Client::Message_StringID functions are what you will want to use with them, you can find examples in the code.

If you could follow up yourself that'd probably do me a favor and you'd learn something in the process.

Take a look at zone/string_ids.h and the function Message_StringID. Each parameter is passed in the formatted message packet.

So when you have something like,

It references a file in the client, eqstr_us.txt - 1159 is the ID in the header, and the parameters that are in the function are directly taken from the packet.

So, instead of constructing a string, you can simply do something like this:

which is an example of a spell <name> wearing off of a mob object with <name>

SPELL_WORN_OFF_OF is ID 436 in the eqstr_us.txt file, and looks like this for the data: Your %1 spell has worn off of %2.

%1 is a variable length null terminated parameter, as is %2, and these are filled in by the server.

Hopefully that explains a bit more in detail of what exactly to do.

Also, there's tons of areas in the code like this that are missing. General rule of thumb is check if it exists in eqstr_us.txt in some form, if not, do it manually like you were doing.

Note you cannot add entries to this file - we're using the stock version of it that is included with the box set or steam download. So it must exist there, and if it's missing from one client, you should probably go ahead and do it manually.

The reason behind this file was so SOE could conserve bytes on the wire in 1999. Still, it's good practice even in 2014 to do something like this and that's why I recommend it.

I'll look at that tomorrow and get back to you. I'll definitely do the work. I want to learn.

I'm working on some faction rework today.

I'll post it. Not sure if you'll want it or not. The changes are based in something i found earlier and wanted to fix.

Working on this now. Do you have any idea which strings were used by vendors? I shouldn't have any problems with the changes, just not sure how many of them I should use. Some of the values 1172 and up look similar, but most smack more of combat than selling.

It is very obvious that you have an ability, eye and talent for issues of this nature.

When you finalize using proper strings please create a proper pull request to our Github repo and we can analyze the changes and review for submission.

Thank you.

I believe all of the ones I listed are used in merchants. The rest are used for combat.

The ones that appear similar, but have the parameter removed, in example:

are used when a non-standard player race is used. For example, if you are browsing a merchant that dislikes you in wolf form, 1160 is used. If you are human, 1159 is used with the added parameter.

The base race is never used for these messages.

If there is only one version of the line, it is used by itself.

The only exception is "Get out of here now!" - this one is sent following "Actions speak louder than beliefs, and I despise both your actions and all you believe in." in the same transaction.
Also i've never seen the one that says 'damned' on live. Probably had a player complain about the swearing in 1997 :P

Weird, I know, but I believe that's correct.

Ok, this is what I learned after coding it up as you said.

1) The changes work just fine for when my char is rejected for deeds or non-std race.

2) The other messages (those that take the B3(13) are CLASS or B3(12) are RACE hard codes on client already. Thus the parameter (not sure exactly what to send) has to be a race/class indicator of some sort. Right now, sending race or class codes, or race of class plural strings yields NOCLASSERS and NORACE.

The reason I decided to fix this to begin with was that on my server there is a bard that was clearly being rejected on the server due to his deity (Bristlebane) but the code ended up making a half elf vendor say he wanted nothing to do with half elves.

I don't see any messages that support the use of the deity's name.

This leaves me with a couple of options.

• Use some of the non-argument messages for deity rejection.
• Go back to not using the standard messages and have them say what I want.

I'm giving it some thought. I like that I learned the correct way, and I've learned that those messages on the cleint side are hard coded to race/class messages.

The only other messages with this "Bx(n)" argument format in the header file is:

#define AA_REUSE_MSG 413 //You can use the ability %B1(1) again in %2 hour(s) %3 minute(s) %4 seconds.
#define AA_REUSE_MSG2 414 //You can use the ability %B1(1) again in %2 minute(s) %3 seconds.

And I can't find those used anywhere on the server.

I tired uppercase, lowercase, 1st letter upper on class and race and still can't get the GUI to like it. Always NOCLASSERS and UNKNOWN RACE as the arguments displayed.

Also tried using race and class codes - also no go.

I think these messages should be passed through the Say_StringID functions, which use another StringID to embed another. (so passing one of these, the first arg because the 3rd, hence the 3)

Arg 1: mob name which is passed to GENERIC_STRINGID_SAY
Arg 2: embedded StringID
Arg 3: first arg to embedded StringID
etc

Changed it to this. Absolutely more correct.

I still can't find an argument I can send for %B3 that works.

With the stringIDs that have %B3 in them, none of these attempts work:

merchant->Say_StringID(messageid, merchant->GetCleanName(), "1"); * tried 1 - 100 in hopes that race/class id might work
merchant->Say_StringID(messageid, merchant->GetCleanName(), "ranger"); * tried 4 classes in lower, upper, 1st letter cap, and plural
merchant->Say_StringID(messageid, merchant->GetCleanName(), "erudite"); * tried 4 races in lower, upper, 1st letter cap and plural

They all result in:

The correct message, said by the merchant with the correct merchant name. If it was a %B3(13) is outputs NOCLASSERS and if it is a %B3(12) it outputs UNKNOWN RACE.

Obviously my last argument is wrong, and needs to supply race/class somehow.. Just don't know how.

I'll see if I can figure it out either through IDA or packet capture

Edit: also, Say_StringID handles the merchants name, should of clarified that, so you can remove the GetCleanName() (I was just trying to explain why it was a 3)

Doing Say_StringID(messageid, "12"); says Gnomes for me.

LOL. I saw that you're example differed from my code , but snagged an example from the code that passed GetCleanName() assuming it was correct, but that was for a different reason. I should have read your message more carefully.

Retesting and sorry,