Mapping of words in ingame languages

[Dragonkin]

I am making a tool that generates approximate translations for ingame languages (specificaly Darnassian), but i cant find the hashing function in the client that maps actual words to the Darnassian words in dbc (languagewords.dbc). I know that each word is mapped to a specific word of the same length from dbc (its not random) and I tried to generate a table of translations of each letter in the alphabet and tried to solve it as a system of modular equations, but that didnt work.

If someone could find the specific mapping function, I would greatly appreciate it :-)

[Jadd]

void CGChat::TranslateMessage( int nLanguageId, BYTE a2, const char *pszText, char *pszResult, DWORD a5, BYTE a6, BYTE a7 )

	/// <summary>
	/// Converts plain text to a specific language.
	/// </summary>
	std::string TranslateText( const std::string &sText, WoWLanguageType nLanguageId )
	{
		char *pszResult = new char[sText.length() * 2];
		Delegates::CGChat__TranslateMessage( nLanguageId, 0, sText.c_str(), pszResult, 0x00000800, 0x00, 0x01 );
		return pszResult;
	}

[Dragonkin]

Wow that was quick, thank you. I guess it would be a bit too much to ask for the body of TranslateMessage huh? :-)

[Threk]

Wow that was quick, thank you. I guess it would be a bit too much to ask for the body of TranslateMessage huh? :-)

Turn on IDA Pro or your debugger and look for yourself.
It's pretty obvious that it's a internal function of Wow, isn't it ?

[Master674]

void CGChat::TranslateMessage( int nLanguageId, BYTE a2, const char *pszText, char *pszResult, DWORD a5, BYTE a6, BYTE a7 )

	/// <summary>
	/// Converts plain text to a specific language.
	/// </summary>
	std::string TranslateText( const std::string &sText, WoWLanguageType nLanguageId )
	{
		char *pszResult = new char[sText.length() * 2];
		Delegates::CGChat__TranslateMessage( nLanguageId, 0, sText.c_str(), pszResult, 0x00000800, 0x00, 0x01 );
		return pszResult;
	}

I'm disappointed. Take a look at the function again and search for something that starts with 'm' and ends with 'emoryleak'

[ccKep]

I'm disappointed. Take a look at the function again and search for something that starts with 'm' and ends with 'emoryleak'

Not my code, though I'm curious... care to elaborate?

Does CGChat__TranslateMessage allocate the memory required? Otherwise I don't see what's wrong, std::string.c_str() gets reused / free'd automatically and the function itself seems to be expected to return a newly allocated string. I'm probably missing something?

[Jadd]

Not my code, though I'm curious... care to elaborate?

Does CGChat__TranslateMessage allocate the memory required? Otherwise I don't see what's wrong, std::string.c_str() gets reused / free'd automatically and the function itself seems to be expected to return a newly allocated string. I'm probably missing something?

I'm allocating memory and not deleting it, but w/e it was just to show which parameters you should use.

The function is at 0x00CD8D20 (not rebased).

[Dragonkin]

Oh, so that TranslateText function is yours :-)
There I was, thinking "how the heck did he get such a nice code from it, mine is all int v1 = v2 = v3 = v4 = v5" :-) Thats why I asked if you could post the body of TranslateMessage, I thought yours would be easier to read than the standard pseudocode :-)

[Cypher]

I'm allocating memory and not deleting it, but w/e it was just to show which parameters you should use.

The function is at 0x00CD8D20 (not rebased).

vector<char> is your friend.

[Jadd]

Oh, so that TranslateText function is yours :-)
There I was, thinking "how the heck did he get such a nice code from it, mine is all int v1 = v2 = v3 = v4 = v5" :-) Thats why I asked if you could post the body of TranslateMessage, I thought yours would be easier to read than the standard pseudocode :-)

The function contains calls to a lot of other functions, you're better off using code that's already there rather than writing it again.

vector<char> is your friend.

Any particular reason I'd use this over string? <-- C++ noob here

[Cypher]

Any particular reason I'd use this over string? <-- C++ noob here

That's a good question. The main reason not to use a std::string as a writeable buffer was due to the C++ standard allowing copy-on-write implementations in C++03, and the wording not being clear on whether or not strings were guaranteed to be stored contiguously in memory (you were of course guaranteed to get a contiguous buffer if you called c_str, so in practice you could rely on the same behavior when getting the address of the internal buffer in any sane implementation, but it was still technically not guaranteed). In C++11 CoW is banned and the string is guaranteed to store the data contiguously 'under the hood' so there's nothing stopping you from using a std::string as an output buffer (assuming that you manually 'trim' any extra null padding after the function call -- if appliciable). However a lot of people will still use a vector<char> for to-the-letter compatibility with C++03 and/or just habit. Using a vector<char> does cause an extra copy if you then pass it straight into a std::string, so if you're using C++11 it may be worth using a std::string as your buffer.

I hadn't actually thought about it until then, I fall into the camp of people who simply still use it out of habit! Now that all the compiler I use are C++11 enabled, I should port my library code to use a std::string directly and avoid the extra copy.

+repped for catching me out (EDIT: FU rep tool, why the hell does it default to 1 rather than the maximum I can give. I always click the button without looking >_>)

EDIT:

Oh btw, for legacy reasons, std::basic_string::data is a const function returning a pointer-to-const-char (unlike std::vector::data which has both const and non-const overloads). Therefore, for getting a non-const pointer to the string's buffer you want to do this:
char* p = &my_string[0];
Or this:
char* p = &*my_string.begin();
Do NOT do this (The fact that you require a cast should be a big warning sign):
char* p = const_cast<char*>(my_string.c_str());

[Jadd]

That's a good question. The main reason not to use a std::string as a writeable buffer was due to the C++ standard allowing copy-on-write implementations in C++03, and the wording not being clear on whether or not strings were guaranteed to be stored contiguously in memory (you were of course guaranteed to get a contiguous buffer if you called c_str, so in practice you could rely on the same behavior when getting the address of the internal buffer in any sane implementation, but it was still technically not guaranteed). In C++11 CoW is banned and the string is guaranteed to store the data contiguously 'under the hood' so there's nothing stopping you from using a std::string as an output buffer (assuming that you manually 'trim' any extra null padding after the function call -- if appliciable). However a lot of people will still use a vector<char> for to-the-letter compatibility with C++03 and/or just habit. Using a vector<char> does cause an extra copy if you then pass it straight into a std::string, so if you're using C++11 it may be worth using a std::string as your buffer.

I hadn't actually thought about it until then, I fall into the camp of people who simply still use it out of habit! Now that all the compiler I use are C++11 enabled, I should port my library code to use a std::string directly and avoid the extra copy.

+repped for catching me out (EDIT: FU rep tool, why the hell does it default to 1 rather than the maximum I can give. I always click the button without looking >_>)

EDIT:

Oh btw, for legacy reasons, std::basic_string::data is a const function returning a pointer-to-const-char (unlike std::vector::data which has both const and non-const overloads). Therefore, for getting a non-const pointer to the string's buffer you want to do this:
char* p = &my_string[0];
Or this:
char* p = &*my_string.begin();
Do NOT do this (The fact that you require a cast should be a big warning sign):
char* p = const_cast<char*>(my_string.c_str());

Interesting read - I only got into C++ as C++11 was first becoming available so I'm still unfamilliar with the pre-C++11 rules (still unfamilliar or forgetful with a lot of current rules as well but that's just the learning experience I guess ). It's good to have some light shed on the subject.

Generally I'll use &my_string[0], why I didn't when writing my previous post I'll never know

[Cypher]

Interesting read - I only got into C++ as C++11 was first becoming available so I'm still unfamilliar with the pre-C++11 rules (still unfamilliar or forgetful with a lot of current rules as well but that's just the learning experience I guess ). It's good to have some light shed on the subject.

Generally I'll use &my_string[0], why I didn't when writing my previous post I'll never know

The only thing you have to keep in mind is that if you create a string of length N, then pass the buffer to some C API which may write K bytes (lets assume K < N and everything succeeds), the length of the string (as far of the string object is concerned) is still N! You need to manually remove the extra trailing nulls (if it matters to you... sometimes it doesn't).

[jjaa]

Interesting read - I only got into C++ as C++11 was first becoming available so I'm still unfamilliar with the pre-C++11 rules (still unfamilliar or forgetful with a lot of current rules as well but that's just the learning experience I guess ). It's good to have some light shed on the subject.

Generally I'll use &my_string[0], why I didn't when writing my previous post I'll never know

Elements of Modern C++ Style « Sutter

Some interesting stuff in that post about C++11.

[Dragonkin]

Hi again,
I know that this reply is somewhat late, but I looked into the disassembled code again and this time got quite far. My problem now is that the SStrHash function (used by the TranslateMessage function) accesses an array variable called "dword_FCFDE0". I need to get the contents of the variable, but have no idea of how to track it. I know that Ida Pro 6.2+ has proximity viewer that should be able to do just that, but latest version I can get my hands on is 6.1. Is there any other way to track the variable, or could someone who owns Ida 6.2 track it? I would really appreciate it.