COMMITTED: More detailed merchant rejection code

[Secrets]

You should really change this to use the eqstr_us.txt versions.

1154 I don't like to speak to %B3(12) much less sell to them!
1155 It's %B3(13) like you that are ruining the continent...get OUT!
1156 Isn't there some kind of ordinance against %B3(13) crawling out from under their rocks?
1157 %B3(13) like you don't have any place in my shop..now make way for welcome customers.
1158 I thought scumbag %B3(13) like you just stole whatever they need.  Now GET OUT!
1159 I don't have anything to do with %B3(13)..move along.
1160 I don't have anything to do with your little gang..move along.
1161 It's not enough that you %B3(12) have ruined your own land. Now get lost!
1162 I have something here that %B3(12) use..let me see...it's the EXIT, now get LOST!
1163 Don't you %B3(12) have your own merchants?  Whatever, I'm not selling anything to you!
1164 Members of your little "club" have ruined things around here..get lost!
1165 I don't have anything to do with your damned club..move along.
1166 Creatures like you make me sick..the things you do..get out of here Pagan!
1167 After all the things you've done..the things you believe in..leave my shop!
1168 Actions speak louder than beliefs, and I despise both your actions and all you believe in.
1169 Get out of here now!
1170 I am tolerant by nature..but infidels like you push me past my limit..get out!
1171 I cannot abide you or your actions against all that is right..BE GONE!

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!

[noudess]

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.

[demonstar55]

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.

[Secrets]

Originally Posted by noudess

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.

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,

1159 I don't have anything to do with %B3(13)..move along.

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:

Message_StringID(MT_WornOff, SPELL_WORN_OFF_OF,
				spells[buffs[slot].spellid].name, GetCleanName());

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.

[noudess]

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.