[Guide] How to change fonts and code pages in PT client.

How to Change Fonts and Code Pages in PT Client

This is a commonly asked question, and the answers are usually pretty vague, because there are many influencing factors.

The primary one, is the default local for non Unicode programs in your OS, and that is set differently in Win 9x to 2K/XP to Vista... and I haven't tried it in Windows 7 yet.

But there are ways to avoid the conflict with the OS altogether. They just take a little Olly. :wink:

Basic PT Client Translation
First of all, lets take a look at the translations that have gone before, and see how they where done.

I'm going to look at the 1873 client by Quantumfusion, because it's a good clean Korean client translation and the translation is pretty good, but not quite complete. It's a common base for many private servers, and some of the points it misses can be seen to have slipped passed others too.:blush:

The other point of possible contention is that I tend to use the beta release of Olly Debug version 2... It's not as complete, but it's fast and stable. I'm fairly certain that the Olly v.1 debuggers are just as capable of performing all the tasks in this guide, but if the UI looks a little odd, that's the reason.

So... open the client in Olly, and lets have a look at the memory map. http://a.imagehost.org/0178/MMapIcon.png
http://a.imagehost.org/0513/QFMap.png
You know that all these memory sections are from your main executable because of the name... 1873_quantumfusionNoXT.exe in my case.

So what about the section names? Windows has some standard accepted section names within PE files, which it will make some assumptions about.

• .text is where the main program body lies.
• .rdata is where Windows looks up initial run-time linkage libraries (DLLs) that the program should use.
• .data is assumed to be essentially variable declaration section, (if you code Pascal or Cobol) but for the whole program, not just a particular function or object.
• .rsrc is where we store program resources in .res format. Early on in NT life (NT2 or NT3) .res files where kept separate from the main executable, but since it contains the icon for the program, in NT4 (and it's cut down Windows 95) the PE executable was introduced allowing for various sections within the file (based on ELF as used in linux with backwards computability for flat DOS style MZ executables)... LE and LX executables used in Windows 3.1 and early OS/2 didn't work like this, normally.

That resource section contains your program icon, windows dialogue definitions, and is recommended to contain strings for localisation, so that you only have to change the resource you link, rather than compile a whole new executable for a different language... PT doesn't use that API facility however. It does load it's inital loading splash screen from the resource section using legal APIs though... and you can include a version string with localisation information and copyrights.

Strictly speaking, it should always be the last section in the executable... but in this case it isn't. Which begs the question "Why?".:wink:

The final section is called "KPTTrans" which is quite meaningful in it's self. Which is good, because the "Contains" column is blank for it. That's because this is not a standard section that Windows has any understanding of. That doesn't mean it won't load it, or that you can't use it, but you will have to be very specific in your program as to how you access it.

Go ahead and double click on it, and you will see why it has been added.
Right at the start of this section you will find the ASCII text string "This section is taken from rPT Client for Translation Purpose. Thanks Sandurr---" which is a nice indecator of the start of this section if you are looking at the executable in a hex editor, and tells us exactly why it is there, and where it came from.

If you highlight all of that, and press <Ctrl>+"R" or right click and Find references to... -> Selected block, you will see that that data is never actually used in the program, and is only there for our benefit as RCEs. (Reverse Code Engineers)

If you move the scroll bar right down to the bottom of that memory section however, you will find two items which are not strictly speaking translations.

1. The string "COMIC SANS MS"
2. A string containing an IP (I hexed in my server address already) :oops:

So why are these here? Well the first is the beginnings of an alternate font for translation... but it hasn't worked out all that well, or wasn't finished off. The second, I think we all know, is the IP that this client will look for the login (game) server on. The IP is normally held in a text file called "ptreg.rgx" in the client folder, but this client has been modified to ignore what it reads there for Server 1 and uses this IP instead... now we could continue this tactic and add the IPs of Server 2, 3 and 4 there as well... and once they are in the executable, they will be locked by the client connect code. :cool:

But if you highlight the "COMIC SANS MS" and search for references to that... you should find 5 points in the code (.text) section where the address of that string is pushed onto the stack.
http://a.imagehost.org/0033/CSRef.png

If you go and look at any one of those references, you will see they are related to calling the GDI32.dlls CreateFontA() function.
http://a.imagehost.org/0841/Code1.png

MSDN says:

Code:

---

HFONT CreateFont(
  __in  int nHeight,
  __in  int nWidth,
  __in  int nEscapement,
  __in  int nOrientation,
  __in  int fnWeight,
  __in  DWORD fdwItalic,
  __in  DWORD fdwUnderline,
  __in  DWORD fdwStrikeOut,
  __in  DWORD fdwCharSet,
  __in  DWORD fdwOutputPrecision,
  __in  DWORD fdwClipPrecision,
  __in  DWORD fdwQuality,
  __in  DWORD fdwPitchAndFamily,
  __in  LPCTSTR lpszFace
);

---

These parameters are passed via the stack in reverse order in Assembler. But we can already see a glaring mistake if this is supposed to be an "English" translation!!!:blush:

Surely the character set should not be SHIFTJIS_CHARSET as this relates to the usual Windows Japanese code page?

For clarification, in C/C++ this call would be a single line like this:-

Code:

---

hFont = CreateFont(12,0,0,0,FW_NORMAL,FALSE,FALSE,FALSE,SHIFTJIS_CHARSET,OUT_OUTLINE_PRECIS,CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY, FIXED_PITCH|FF_MODERN,TEXT("COMIC SANS MS"));

---

But if the font face specified is "COMIC SANS MS" why does this client produce text (usually) in "MS Sans Serif"?

Well... the answer to that is quite simple... for a start off there is no SHIFTJIS_CHARSET glyph table in the font "Comic Sans MS" which should match to the mangled description "COMIC SANS MS" if only via font aliasing. There is no guarantee of this however.

All upper was the way to work on Windows 3.1 but gave NT 3.1 and 3.5 problems when the fonts where stored on NTFS file systems which could store mixed case file names. In NT4 / Win95 the correct call should be to a font name, as it's defined in the file, not the files name... so if you installed a font with a different file name, whose title in it's header is "COMIC SANS MS" regardless of what it looks like, it will take prescience over "Comic Sans MS" with this description.

Fixing It
So really we want the line that says SHIFTJIS_CHARSET to say something more western.

This is what WINGDI.h from Wine has to say about CHARSET defines.

Code:

---

#define ANSI_CHARSET          (BYTE)0  /* CP1252, ansi-0, iso8859-{1,15} */
#define DEFAULT_CHARSET      (BYTE)1
#define SYMBOL_CHARSET        (BYTE)2
#define SHIFTJIS_CHARSET      (BYTE)128 /* CP932 */
#define HANGEUL_CHARSET      (BYTE)129 /* CP949, ksc5601.1987-0 */
#define HANGUL_CHARSET        HANGEUL_CHARSET
#define GB2312_CHARSET        (BYTE)134 /* CP936, gb2312.1980-0 */
#define CHINESEBIG5_CHARSET  (BYTE)136 /* CP950, big5.et-0 */
#define GREEK_CHARSET        (BYTE)161 /* CP1253 */
#define TURKISH_CHARSET      (BYTE)162 /* CP1254, -iso8859-9 */
#define HEBREW_CHARSET        (BYTE)177 /* CP1255, -iso8859-8 */
#define ARABIC_CHARSET        (BYTE)178 /* CP1256, -iso8859-6 */
#define BALTIC_CHARSET        (BYTE)186 /* CP1257, -iso8859-13 */
#define VIETNAMESE_CHARSET    (BYTE)163 /* CP1258 */
#define RUSSIAN_CHARSET      (BYTE)204 /* CP1251, -iso8859-5 */
#define EE_CHARSET            (BYTE)238 /* CP1250, -iso8859-2 */
#define EASTEUROPE_CHARSET    EE_CHARSET
#define THAI_CHARSET          (BYTE)222 /* CP874, iso8859-11, tis620 */
#define JOHAB_CHARSET        (BYTE)130 /* korean (johab) CP1361 */
#define MAC_CHARSET          (BYTE)77
#define OEM_CHARSET          (BYTE)255
/* I don't know if the values of *_CHARSET macros are defined in Windows
 * or if we can choose them as we want. -- srtxg
 */
#define VISCII_CHARSET        (BYTE)240 /* viscii1.1-1 */
#define TCVN_CHARSET          (BYTE)241 /* tcvn-0 */
#define KOI8_CHARSET          (BYTE)242 /* koi8-{r,u,ru} */
#define ISO3_CHARSET          (BYTE)243 /* iso8859-3 */
#define ISO4_CHARSET          (BYTE)244 /* iso8859-4 */
#define ISO10_CHARSET        (BYTE)245 /* iso8859-10 */
#define CELTIC_CHARSET        (BYTE)246 /* iso8859-14 */

---

Unsurprisingly it is more descriptive than the one provided with the Win32 SDK by Microsoft.

So now you have a choice... if you want the game to use the default character set of the clients machine, you can PUSH 1 instead of PUSH 80. (80 in hex = 128 in decimal) but if you want to force the matter, you can PUSH 0 to make sure everything is printed using the ANSI codepage.

The thing I love about this, is it disables all the kana glyphs, but allows me to use the GBP sign. "£" :D

Doing it Properly
Okay... so that's what Quantum started, and it's a good start... it shows us what needs to be done, but doesn't quite finish the job. That's fine, he's not here to do our job for us, even though he frequently comes close.:wink:

Let's start again opening his client in Olly. This time, right click on the code disassembly and Search for -> All intermodular calls. This opens a new window with lots of funky stuff in it that we can look at... These are all the API calls made by our executable to outside DLL functions. Not just the ones in the OS, but any function the executable imports from any other code library on the system.

First, it's a mess, lets sort it by description, and then scroll down to the CreateFontA() function calls. This orders the list alphabetically by function name... sadly I don't know if there is a way to include the, greyed out, library name in that ordering, so you are looking for CreateFontA, not GDI32.
http://a.imagehost.org/0700/Intermodular.png

There they are. So we can see that the executable defines and creates 6 fonts in all. Which means that Quantumfusion either missed one, or deliberately left it alone.:blink: The last one points to the string "Tahoma". Double click it and see.
http://a.imagehost.org/0593/code2.png

Okay... lets highlight the line that pushes a pointer to that string in the code, and follow it to the location.

http://a.imagehost.org/0405/Referance.png

Note that if you cannot see the pane below the disassembly and above the memory hex, check for the size control indicated... it's very small and tricky to get hold of.

We can clearly see that this string is stored in 5BA6DC... which our memory map shows us is part of the .rdata section... mapped between 5BA000 and (5BA000 + 33000 =) 5ED000

Look it up if you like. :D:http://a.imagehost.org/0905/Tahoma.png There it is.:w00t:

So we can see how the string is mapped in the code... wouldn't it be nice if we had full control over the font faces of each of those fonts defined in the CreateFontA() function calls? Well, we can. There isn't a lot of space where "Tahoma" is, if we wanted to use "Palatino Linotype" or such we would be in trouble. So the first thing we'll want to do, is move all those pointers into a nice "cave" in the executable where we can just hex any ZString we want.

A "cave" BTW is a term RCEs use to describe an unused hole in the program file that you can insert some new information. Normally compilers don't just create large blocks of empty space in the final executable, but because this executable wasn't the product of a compiler, but another RCE, the great Quantumfusion, he has already made some space for us. The KPTTrans section isn't completely used, so we can find a blank space there for what we need. It'll probably be filled with 0s. Let's look.

http://a.imagehost.org/0738/MemoryCave1.png
Well that hole looks pretty blank... but disastrous things could happen if we are wrong... so lets <Ctrl>+"R" to look for references to it just to be sure.

:love:Nope... there is no code referencing that area of memory.:D: That's my hole.

8X-------------- EDIT ---------------
Actually, there could be table references and such, so you should still be wary. You can set a memory breakpoint (see Gregoorys' guide linked at the bottom of mine) and run through some complete game tests to convince yourself more... but I checked the last filled bytes above this, which when examined as code are clearly a routine which returns at the end. That makes me even more confident that no data would be using relative pointers or writing to this area when there is a machine code subroutine just above it.
8X------------- END ----------------

Now, I'm going to say, for the sake of argument, that 31 characters is enough for my font face name. So I can space each font name 32 bytes apart, see each one on a new line, with a line space between them in a hex view. They will need to be no more than 31 characters long, because I need 1 byte for the null / zero termination byte. :wink:

http://a.imagehost.org/0702/FontFaces.png
So here, I've gone to each of the addresses I want to store my Font strings and pressed <Ctrl>+"E" to binary edit, and pasted in some unique looking font names that most people will have on their system. The idea is that each font will be instantly recognisable, as we don't yet know which font is used where. They aren't supposed to look good, just different.

Now select all of that changed stuff, and copy it back to the executable, with a right click -> Edit -> Copy to executable. Minimise the proceeding window... that's the memory image of your changed exe file. :wink:

Then... keeping the addresses of those strings handy, go through each call to CreateFontA() in our intermodular call list window, and change the first PUSH address to a different one of these strings.

You can select the PUSH that points to the string and press space to re-assemble that line pointing to a different address... but if you want to change the code page, you will probably have to <Ctrl>+"E" again, to binary edit, as you need to PUSH a 32-bit figure on to the stack, and if you want 0 or 1 (default or ANSI) then the assembler will correctly deduce that these numbers comfortably fit in a single byte. :$: It will make a byte PUSH not a Word PUSH, and that will break our exe.:lol:
http://a.imagehost.org/0287/BinaryPush.png
Remember the reverse byte order of Intel x86 CPU. 01 00 00 00 is 00000001.:glare:

Again... copy these changes back to the executable, and when done, right click the executable dump and select Save file. I'd give it a new name, but that's your funeral. :wink:

If you used the same fonts as I did, you will see "Courier New" in the login, and chat box, "MS Sans Serif" in the character stats and item tool tips, with "Times New Roman" for the title of each item. "Comic Sans MS" is used for the character details on the character selection screen. "Courier New" is also used for the names over peoples heads and "MS Sans Serif" is used for NPC chat and quest text, while "Times New Roman" is also used for the titles over quest text.

But what happened to "Terminal" and "Tahoma"? Well... TBH, I'm not entirely sure about that.

BTW... you should really pick up that original point where the "Tahoma" string was in the .rdata section, and zero it out... this will make your exe less confusing for you when you come to re-edit it, and if you plan on using compression or encryption on your exe later, it will help a lot there too.

Further Considerations?
I can tell you, to help clean up your client even more, that each string is displayed on the screen by the TextOutA() function in the GDI32.dll which takes an X and a Y pixel co-ordinate and a ZString and renders it to a given Device Context provided as a handle... with that knowledge, and the information in this tutorial, you should be able to trace back each of the calls, and shift the strings display left or right until they line up better using your preferred fonts and / or translation. :D: (It will take some considerable work to find them all)

I will also mention that most of the actual calls are made by one pre-made internal function, which acts as a wrapper for the GDI32 function.

And that, (the length of this guide) is why this question very rarely gets a full and descriptive answer, despite the frequency it is asked.

Good luck, and happy hunting. bobsobol

Credits and Thanks
I hate to say it, but I don't really have anyone to credit in this guide. I know I'm not the first person to work it all out, but I've not seen a description I could work from so far, so what I figured out, is mostly what I figured out, looking at Quantums client, and the official clients and seeing how things worked.

I would like to thank a few people without whose efforts I would not have been able to figure this out, and share it with you.

Thanks then to:-
Quantumfusion et.el. for the 1873 client this guide is based on.
Gregoory for the Let's Learn Together series of threads, which got me up to speed with modern debugging methods and Olly Debug in particular. ]EDIT[-- Now transferred to Gregoorys' own site.
Unzubrau et.el. for asking questions which kicked me into going through all this in public.
DarkKnight for being able to share some of his insights into the creation of the ET, level 120 server patching, which lead to my enlightenment of PE sections uses.
SoyEdu for making me look long and hard at the sections in the server exe, which lead to my understanding PE sections better.
MentaL (last but not lest) for this fantastic community he has created and maintains.

Thank you all... and thank you for reading all this Voodoo. :wink:

Darkknight we need a tut section. this is pure gold! Well done mate this is awesome and will help n00bers.

Thanks Unzu. Not to cast any dispersions on your ability, :wink: one of the reasons I stepped up this post was your desire to work on moving Exp tables into a new "cave" for level 200. ^_^

(Clarification: No I don't think you're a "n00ber", but this tutorial would give us a base point of reference when talking about what to do how. There may be other approaches, but this is mine.)

I know this isn't the answer you are looking for, but it demonstrates some of the principals you will need to exercise. Specifically searching for and updating references to data points.

As I have said in your thread, I do plan to release a tutorial covering creation of sections within a PE executable and specifically an item list table section that can easily be synced with the server. My procedure seems to work fine, but I still have some stress testing I want to do before I am confident enough with my technique to put it into a guide / tutorial.

---- EDIT ----
Scratch that folks... stress testing = epic fail. Works server side only, and then probably only because Shagpub et. el. have done such a good job of relocating the table in the first place. :(
---- END ----

Because Quantum has kindly given us an excellent client which already has a neat section in it to put stuff, I can skirt over the section adding part and post this real quick to illustrate the basic process on something a bit easier.

If you can follow this guide successfully, I think you will be much more comfortable working with moving your Exp tables around... at least, that's the plan.

Quote:

---

Originally Posted by unzubaru

Darkknight we need a tut section. this is pure gold! Well done mate this is awesome and will help n00bers.

---

This isn't gold, it's platinum! Tutorials that go out of the way to produce as many screen shots as possible while providing a boat load of information are great :):


The PTZ font works surprisingly well in the client once registered properly btw.

That it does, in many areas... I have found that using stylised fonts for the character selection, and tool-tip titles / quest titles can add a level of Unique style to a client however.

One of the most useful things in this guide, may well be that our friends in the Middle East can select ARABIC_CHARSET, (or HEBREW_CHARSET if that is more appropriate) and in Eastern Europe they can choose EASTEUROPE_CHARSET or RUSSIAN_CHARSET or even KOI8_CHARSET.

I know there are many players from the UAE that already enjoy PT, and can be frustrated by the language barriers on English or Brazilian servers, and I have a great deal of respect for the RCE skills coming out of the Republic of Russia and surrounding nations.

Seriously, those guys (and / or gals) are to Code what the Japanese are to Art and Animation.

And I know that not everyone who uses this forum is primarily an English speaker, and "the more the merrier" I say.

A few more of these, and we may even get DarkKnight (another non-n00b) to tame the savage Olly. :wink:

EDIT----
P.S. you do know that there is a limit of 10 images to a post right DK? where there not, this guide could have been in less posts. :(

Quote:

---

Originally Posted by bobsobol

Thanks Unzu. Not to cast any dispersions on your ability, :wink: one of the reasons I stepped up this post was your desire to work on moving Exp tables into a new "cave" for level 200. ^_^

(Clarification: No I don't think you're a "n00ber", but this tutorial would give us a base point of reference when talking about what to do how. There may be other approaches, but this is mine.)

I know this isn't the answer you are looking for, but it demonstrates some of the principals you will need to exercise. Specifically searching for and updating references to data points.

As I have said in your thread, I do plan to release a tutorial covering creation of sections within a PE executable and specifically an item list table section that can easily be synced with the server. My procedure seems to work fine, but I still have some stress testing I want to do before I am confident enough with my technique to put it into a guide / tutorial.

Because Quantum has kindly given us an excellent client which already has a neat section in it to put stuff, I can skirt over the section adding part and post this real quick to illustrate the basic process on something a bit easier.

If you can follow this guide successfully, I think you will be much more comfortable working with moving your Exp tables around... at least, that's the plan.

---

Yeh sure i will give it a go :P,
What i meant by "n00b" was the fact that others now have a better soruce of informationfor changing font Lol.
Also yeh i do need to get handy with PE indeed it would help alot of i knew how to use it correctly. Though Tutoring would be even better *hint hint*

And yes... I also think we need a guide / tutorial section, or at least guides like Gregoory's pinned. ^_^

yeh, Dark bro you missed Gregoory's that was REALLY good, he had how to make your server hacker free and getting rid of that annoying Rvc.TimeOut message thing :D. Look back a few pages.


EDIT----
SHIT, Bobsobol i have to read thorugh this and do it T_T, too long, too tired.

-----

Quote:

---

Originally Posted by bobsobol

A few more of these, and we may even get DarkKnight (another non-n00b) to tame the savage Olly. :wink:

---

Never! :laugh

Quote:

---

Originally Posted by bobsobol

P.S. you do know that there is a limit of 10 images to a post right DK? where there not, this guide could have been in less posts. :(

---

Indeed I do. Unfortunately, a lot of forums are like that to prevent spamming of images within posts (which I know you know already, but I'm writing it anyway). To be honest though, I think it is MUCH easier to read when it's in a multi-post format, as it allows the guide to be in sections instead of one long post :cool:

Quote:

---

Originally Posted by unzubaru

yeh, Dark bro you missed Gregoory's that was REALLY good, he had how to make your server hacker free and getting rid of that annoying Rvc.TimeOut message thing :D. Look back a few pages.


EDIT----
SHIT, Bobsobol i have to read thorugh this and do it T_T, too long, too tired.

---

Nah, I totally saw that post. It was very nice as well! Definitely going into the hopefully near-future "Tutorials" section (if administration makes the section).

Yea... looking at it again, it counts smilies as images, so I could cut down on my smilies and get in more illustrations. ^_^

Private Message received on what I consider a public subject.

Quote:

---

Originally Posted by Skuld

Really thank you, bobsobol! I studied this at all night and now I'm using part of that to do other things that I probably need. If I get other applications for this, I'll post...

But I'm don't understand just one thing. In your guide, you change the font location on hexa to an another spacious place... How can I do exe "reads" the font in an another place? An the old location, you pot just the 00 00? And I can do with all of the game "parts"? Like, change the whole Item table for other place, and after add some new items? Maybe move the NPCs for other place and create other functions to them?

I know... I dream a little bit. But of course I'll try all of that at least. My idea is start to put some new funcions on the game. Mak from "ArcadePT" did that, but in an online way, all in their account manager. But I know just strictly basic things about HTML and a little bit of PHP. So my scape is try to do this right on game and server side. Other brazilian developer get the PH Egg, and soon as possible I'll try to research more about this.

Once Aagain, really thank you! This already help a lot and I'm sure that'll help a lot in future.

---

Well... I've not looked too deeply into the website stuff yet.

Yes, you can move all the data, and the code around... but at a certain point it becomes easier to disassemble the entire exe make the changes you want and assemble a whole new one.

Item lists and Exp tables are the data that causes the most devs the most grief. Creating a translation section to place strings for your language in a client of a different language is the most common place to use this method... that way it doesn't matter if there are more or less characters in your language than the one the original client was written in.

Making a new section to store information is the first step... but for this guide I used a specific (and now quite old) released client which has a new section already added to it, and doesn't use all of the space in that new section.

If you want to try this method on a different client, and I recommend you use the same client I did to follow my guide through the first time, there are guides here on adding a new section to your exe with Topo, (credits to Gregoory) one I wrote using CFF Explorer, and the beginning of strangefays guide on extending the Exp table tells how to do it with LordPE.

It doesn't matter how you do it, though the end result is a little more professional with LordPE or CFF Explorer, but Topo is a lot easier than either of them, and it's very easy to make disastrous mistakes with LordPE. It's one of those really powerful, really dangerous tools, like fdisk on Linux.

@bobsobol: Very nice Tutorial was easy to follow, my problem started with trying to find the "Cave". Kpt1871 has no reference to any font face in the client, so finding a cave was impossible for me, I wanted to add them to the client. The font size ingame is 6 very hard to read, especially for someone like me with vision issues. I hope you can help me fix these problems.:?:

KPT 1871 is one of QFs early releases. It does have code an data holes because he has striped (disabled reliance on) XTrap.

If you "finish the job", and NOP the XTrap code, and NULL (00) the XTrap data, you have lots of space for a couple of font details. :D:

If you are not an Assembler Guru, determining what is XTrap code and Data is not easy... and the job is actually made harder by the fact that it's already disabled, but not removed.

Easier, and probably safer in that case, is to add a section to the PE with LordPE, Topo or CFF Explorer. (or any other PE editing tool, but I think those are the best / most popular / nicest)

PC assembler is not my forte however i do have an extensive background with IBM mainframe assembler, not exactly alike but gives me something to compare to.

I was able to use the Lord-PE to extract a the KPTrans section from KPT1873 and put it into the KPT1871 client

At this point i am not sure what comes next, I did copy the addy offsets of the Font faces. what I see in the first font location is this
; /Face = "ü"

my issue is trying to match this
; /Face = "MS Sans Serif"
to me this looks like a label between quotes, not sure that I am coreect there.

I am all set with this, I was able to figure it out...now I will see if it worked

Oh yea... if you are still editing in Olly, you will have to re-do the "Analyse" on the image (.exe / PE file) before it's automatic commenting is accurate again.

Comments come from the analysis, and that was performed before your edits. Sounds like you are well on track though. ^_^

---Edit--- if you do not have comments and labels that you want to preserve deleting the .udd file Olly creates that is associated with that executable file, and re-loading it in Olly will force a completely fresh analysis... but if you do need to preserve manual notation, then you can just right click the CPU disassembly and select "Analysis" -> "Analyse Code".

I did run into something in your tutorial that mentions "aasembly" and then "copying" to the executable. Do I copy from the CPU window? or from someplace else? Do I only need to copy the assembled line of code?
I was able to do this task, took me a few iterations to finaly understand the process.

What else is in that KPTTrans section that I can hook into?

Yea... copying your edits from the image in memory, back to the file Image Olly keeps, and saving that off to a new Executable is covered quite eloquently in the guide by Gregoory that I link to.

What else is in KPTTrans? Hmm... well it contains every string (line of text) in the game client, and some from the server as well, and a few replacement or additional sub-routines.

The KPTTrans section it's self does not originate from quantumfusion (according to the credits) but is more a conglomeration of works by Shagpub, Sandurr and others. Not all the features it provides are (or even should be) utilised in the 1873 executable. Some probably should be. There are some translated strings for the in game guide and for GM notifications which still come up in gobbledy goop left over from the Korean text, though there are English versions in KPTTrans... they just haven't been linked in yet.

The in game guide is probably the most glaringly borked part of 1873. It pops up, but the "More >>>" link isn't translated, and doesn't work, presumably for the same reason that the guide from the system menu in game doesn't work. Personally, I find that guide more useful, interactive, and far less annoying than the beginner pet which was introduced later on to PT.

The KPTTrans section is used in many of the newer server packs executables too, and many of the extended subroutines are there for server use, and are not needed client side.

Please note, however, that I was not active on the scene when the KPTTrans section was developed, or even when QF built the 1873 executable... so I'm only filling in my understanding from what I've seen, and read here, on other forums and in the code it's self. Your interpretation of those information resources may differ, and the memories of others who frequent these forums less often than they once did (if at all) will surely be more accurate.

I am enjoying my new found ability to use Olly, I have done several edits and all were successful. I know that I have along way to go before I can call myself a bonifide RCE...lol You have been very instrumental in helping me develop what talents I now have...thanks for that assistance

Hey Bobsobol, thanks for this great thread. As always you help the RZ community to become more knowledgeable on how the client works everyday. There is a flaw to your guide however. The font size becomes dreadfully small. I have been unsuccessful on editing it myself. Is it possible to add to the guide or post info on how to make the font a larger size here?

There are many ways to make the font larger... especially if you are making a custom font specifically for your game. However the easiest method, I though was pretty obvious. If it slipped by you, I shall illustrate.

From the 6th figure in the tutorial, you can clearly see that the font name is only one of the parameters passed to GDI32.dlls' CreateFont() API.

http://a.imagehost.org/0405/Referance.png

You can find detailed information on this standard Win32 API on MSDN

The parameters Weight (how emboldened) Width (character width) and Height (character height) allow you to change the size of the text to your hearts desire. The sizes are supposed to be in points, which is something like 1/100th of an inch assuming that all monitors have a dot pitch of 96 points per pixel. This is what Microsoft assume for ALL monitors, and in practice the assumption is ALWAYS WRONG. Then again, the only OS which does this correctly by default is Mac OS.

As a game developer, what you would really like to know is the size in pixels... sadly, if a point is 100th of an inch, and a pixel is 96 points the math gives you a silly big decimal fraction to match to, and you have to resort to an "artistic" approximation. Trial and error, until it "looks right".

A zero width, means the default width for the font height, and then point sizes will work in the game, much the same as they do in Word, or any other word processor... except that letter spacing is performed manually in Word... so the games' rendering of text is more like Wordpad, in fact.

What "looks right" will be different for each font, and many proportional fonts work very badly at any size, especially with the far east Asian clients which expect indographs (glyphs / characters) which are all the same size. All of which will increase the amount of artistic trial and error you need to perform to find something really, really nice.

Good luck, and happy hunting. :):

I dont know

There are many ways to make the font larger... especially if you are making a custom font specifically for your game. However the easiest method, I though was pretty obvious. If it slipped by you, I shall illustrate.

From the 6th figure in the tutorial, you can clearly see that the font name is only one of the parameters passed to GDI32.dlls' CreateFont() API.

You can find detailed information on this standard Win32 API on MSDN

The parameters Weight (how emboldened) Width (character width) and Height (character height) allow you to change the size of the text to your hearts desire. The sizes are supposed to be in points, which is something like 1/100th of an inch assuming that all monitors have a dot pitch of 96 points per pixel. This is what Microsoft assume for ALL monitors, and in practice the assumption is ALWAYS WRONG. Then again, the only OS which does this correctly by default is Mac OS.

As a game developer, what you would really like to know is the size in pixels... sadly, if a point is 100th of an inch, and a pixel is 96 points the math gives you a silly big decimal fraction to match to, and you have to resort to an "artistic" approximation. Trial and error, until it "looks right".

A zero width, means the default width for the font height, and then point sizes will work in the game, much the same as they do in Word, or any other word processor... except that letter spacing is performed manually in Word... so the games' rendering of text is more like Wordpad, in fact.

What "looks right" will be different for each font, and many proportional fonts work very badly at any size, especially with the far east Asian clients which expect indographs (glyphs / characters) which are all the same size. All of which will increase the amount of artistic trial and error you need to perform to find something really, really nice.

Yes, I'm sorry the image host has gone down, and I don't have a backup. I need to find time to recreate similar illustrations. :( (there's also a couple of blinding spell-checker mis-corrections :s)

I'm glad you figured it out in the end. Olly doesn't recognise header enumerations when assembling, only when Analysing and, of course, the push for the font name is a pointer to a string of characters. ^_^