eqstr_us.txt

[neiv2]

I am trying to understand the logic behind eqstr_us.txt. Here are the first few lines of the file:

EQST0002
0 5901
1 %1 %2 %3 %4 %5 %6 %7 %8 %9
100 Your target is out of range, get closer!
101 Target player not found.
102 Duplicate Lore Item deleted.
103 Duplicate Lore Item deleted.  There was one already in your bank.

Can someone explain the significance of line 2? What does "0 5901" refer to (it's NOT the number of lines in the file).

Also, what other code/files are the lines referencing? If a line is changed, it produces an error "cannot find string" message once you get to the character select screen. Thanks for any help.

[neiv2]

Okay, I've answered one of my own questions. It appears 5901 does refer to the number of paragraphs below the first two lines there are significant gaps in the numeric titles for the lines, but the paragraph count is 5903 for the file). But I stll cannot figure out what other code or files this txt file is referencing. Any help on that will be greatly appreciated.

[joligario]

The eqgame.exe uses the text file to "push" messages to the client. If you use a program like IDA or Ollydbg, you could search for the push 100 and it would be (most likely) at the end of the function for target range check.

[neiv2]

Thanks Joligario; I downloaded Ollydbg and about half a dozen similar exe analyzers, and still cannot find the references. I assume at this point eqstr_us.txt cannot be changed without hacking into the exe. That's too bad.

[AndMetal]

The "IDs" (the number at the beginning of the line) are considered String IDs and are used by the Message_StringID functions in the source. The most common one we use is Client::Message_StringID().

Basically, instead of the server sending the string, it sends just the string ID (so, less data over the wire). If the string ID has any variables (%1, %2, etc), you can also send a smaller string as part of the function that will be inserted where the variable is.

The idea behind EQ using a file like this is you don't have to recompile the EXE if you want to change what the strings output, especially when translating to another language.

As for the "cannot find string" error, I would recommend changing it in eqstr_en.txt also, although I'm pretty sure it's been depreciated (although maybe not entirely). It looks like the line endings are Windows-style & there is a new line at the end of the file, so as long as you maintain that, it should be fine.

[neiv2]

So, what I'm hearing you say is that there is no validation of characters for each line, and in theory I should be able to change the 'Entering [zone]" text that appears while zoning simply by changing the string next to the numbered reference for that zone. That makes sense of the numbering system at the beginning of each line.

Yet I just attempted to change line 2303 (Felwithe) to another name, in both eqstr_us.txt and eqstr_en.txt, and upon reaching the character select screen I receive the following message: [5 ERROR: String not found. (1530)]. I'm concluding the first number in the brackets is simply the character level since that number changes when I select another character. The error number itself (1530) also changes, but I cannot map it to anything. Selecting some characters produces error 1530, others 1502, 1542, or 1558. The difference is not due to zone since some characters in the same zone have different numbers while others in different zones have the same number.

Any suggestions on what's going on here and how I might be able to change these zone references?

[ojamajoe]

I've not done a lot with eqstr_us.txt or eqstr_en.txt, but the only time I had trouble playing with these files was when I used notepad to edit them; which apparently adds carriage returns. I've not had them misbehave when I used something like notepad ++ to edit them, nor have I figured out where the lines you are trying to edit are referenced by the client.

[joligario]

Also, don't forget your hex -> dec conversions... When reading and searching that is.

[neiv2]

Okay, using Notepad++ resolved the "string not found" issue. However, after changing the zone name and logging in, I see no change in the zoning message when entering the zone whose name I changed. In fact, I do not see any effect at all after changing the zone name in both str files. Am I missing something here?

[AndMetal]

You may also want to take a look into dbstr_us.txt.

[ChaosSlayerZ]

it has been long figured out that zones names cannot be changed by editing them in that file.
Its believed that zone names are hard coded into the exe.

Shards of Delaya have changed zone names, but they have been known to hacked the exe file

[neiv2]

it has been long figured out that zones names cannot be changed by editing them in that file. Its believed that zone names are hard coded into the exe.

Damn.

Shards of Delaya have changed zone names, but they have been known to hacked the exe file

SoD was the inspiration for my inquiry. Was hoping for an easy solution to creating a truly custom game, but I guess I'll have to settle for a partial one.

[Xardon]

Originally Posted by ChaosSlayerZ

it has been long figured out that zones names cannot be changed by editing them in that file.
Its believed that zone names are hard coded into the exe.

Shards of Delaya have changed zone names, but they have been known to hacked the exe file

Not true ... the eqstr_us.txt file for the zones is only the text that gets displayed when zoning ... like Entering My Happy Zone.

If in game you want it to ... when you do a /who all happyzone say There are 10 people in My Happy Zone. You need to make sure the shortname (happyzone) and longname (My Happy Zone) in your zone table reflect that. All the client cares about is the zoneidnumber ... that's it.

[ChaosSlayerZ]

The reason your strings get corrupted is because you screwed up the string file format when edited it with soemthing like regular windows notepad. You need to use an editor which shows and preserves special lien characters which used in that file. Like shell edit or Notepad++.

But in either case- I have tried altering both: the long name in DB and a name in string file (both of them) at SAME time- and it produced no effect, other one the one in chat box.

Also, I have no idea why Xardon keeps referring to short name file - it can never be changed unless you want to perma screw up the zoning =)
And it does not in any way impact the zone name you see on screen or in chatbox

[neiv2]

The reason your strings get corrupted is because you screwed up the string file format when edited it with soemthing like regular windows notepad. You need to use an editor which shows and preserves special lien characters which used in that file. Like shell edit or Notepad++.

Yeah, I was going to came back and note that, but was too lazy. Using Notepad++ prevents those string errors.

But in either case- I have tried altering both: the long name in DB and a name in string file (both of them) at SAME time- and it produced no effect, other one the one in chat box.

Right; that's the same result I get. However, (per Xardon's prompting) I've been experimenting with the SoD version of the eqstr_us.txt file in the SoD environment, and in fact you CAN change the zone names in that file and have it reflected in both the "Entering . . ." text and the "/w" text. It appears they are using an earlier version of eqgame.exe (their version is half the size of the Titanium version). In any case, Xardon is correct insofar as at least SoD's version of eqgame.exe allows the eqstr_us.txt file to drive the in-game zone names. It just doesn't appear Titanium does.

Incidentally, I also tried replacing the Titanium eqgame.exe with SoD's version just to see if it would work, and it will not load with the EQEmu server code. So, it appears (for whatever reason) Titanium doesn't use the zonename entries in the eqstr_us.txt file.