Printable View
@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.
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. ^_^