Beta Technical Demonstration - Translation without Hexing the EXE

Okay... I'll go back to features in the prototype and cease working on the stable C++ thing for a bit.

Make some variations to see what you guys like, or find works nicest. Get some font and codepage choice in there and some TextOut() repositioning, stuff like that. And maybe implement some memcpy() patching, to see what it picks up. Big worry with doing it globally is that memcpy() isn't designed for strings of text... it's designed for any and all arbitrary data. I know it's used for moving textures and stuff around in memory in PT for example... so you could get some *VERY* strange entries in the log from that.

Working without a design, you never quite know when the breakthrough is going to happen, so putting a time scale on it would be hard, but I'll get working and we'll see how long it takes. I'll let you know how it's going too... but please don't be afraid to keep trying to add patches to your .lng file and letting me know which work and which don't.

If you could just share the version that you said you have fixed that Tribe and Class stuff, I could start to patch again and say to you what is working and what is not.

I don't have such an implementation yet. I said I know what it needs, but don't know the best way to implement. Fix the Exe, or add another patch to the DLL.

To make it work, I replaced the memcpy() call with a strcpy() call... but that has to be done right throughout the game exe in any place where strings are treated as just binary data. A global patch to memcpy() will produce logs of all pictures and figures and vectors and anything else that gets memcpy()d.

I also said I will make a couple of implementations and let you guys decide which you prefer. Either option is not very nice. Patch the exe makes it hard for people to use the DLLs with other game.exe, patch the DLL and you are looking at *MAJOR* intrusion into basic functionality of file and memory management in the game, and likely a massive slow down.

Maybe that could be minimised by setting ranges to not be compared to the array, IDK.

Fix in the dll, its easier.

Aha... new info on Tribe and Class.

It's not MemCpy, it's a const chr * "%s" used in wsprintf("%s",lpszTemp) or wsprintf("%s",lpszMori)... so it is possible to implement in the existing function patches.

Why they don't just wsprintf(lpszTemp) or wsprintf(lpszMori) IDK... I can't think of any instance where that would be a "good programming technique"... but when did that ever stop Triglow? :wink:

Could do with a routine to "count C formaters" (ie, any % that isn't followed by a %) and I remember (and still have a copy of) an attempt at doing this. Picking out which ones are strings and what is not is... err, not hard, but complex enough to be a considerable slow down.

Then run the string replacement check on each of the follow-up parameters... at least, if they are filling a %s formatter.

If I write a routine to just give the number of extended parameters, and another to say if Parameter(x) is a string or not, that should simplify the design sufficiently enough to reduce the slow down when ever possible. I'll work on that now.

OK bob, ultil you dont release, I'll patch what I can. Any news, I'll post here.

---------- Post added at 11:48 PM ---------- Previous post was at 10:29 PM ----------

Another feedback.
In KPT 1986, when I got DC'd because of the checksum, this string appears:

Quote:

---

서버와의 연결이 끊어 졌습니다

---

It appears in somekind of MessageBox and in the chat.

In the debug txt I found:

String @1239352 = '서버와의 연결이 끊어 졌습니다' not replaced.

But bob said we should patch those kind of "numbers". So, I looked a lil' bit and found this:
String @54439880 = '서버와의 연결이 끊어 졌습니다' not replaced.

And then, patched.

54439880 = "Desconectado do Servidor"

But, this string is only beeing patched in the CHAT. Where it should be patched both in chat and in that kind of messagebox.

If a screen shot helps:
http://img189.imageshack.us/img189/2347/patchld.jpg
The good one
The bad one

---------- Post added at 11:53 PM ---------- Previous post was at 11:48 PM ----------

And bob, that tribe and class thing, will probably happen with the Mechanician Spec showed in the item.

That would suggest that the string is either copied in the opposite direction (so patch 1239352 instead) or they are using two constants that have the same content... f.e. See how many times you can find a sequence "/0%s/0" Those are all string constants, and they all have the same value. Also see how many "/0템스크론/0" (Tempeskron) there are... I found 5 in RData. That's shame on the Compiler optimisation routines, it should merge identical string constants, and clearly isn't. They may have it configured wrong in the project / make file, so I can't completely blame MSVC 7. I have to admit that I tend to manually "merge" such constants in a .h file, so I can change them globally in the file without a whole heap of Search and Replace work. But constants which are stored in "scoped" variables can't be merged automatically, so where I can force the merging by specifying it my self, they can also by-pass it's ability to optimise by writing the code badly. (There are some reasons why this might be advantageous, and therefore not bad, but not many.)

I've implemented code to do the job on the missing %s parameters, but my implementation is (through my miscalculation) corrupting the stack frame. Implementing full frame isolation seems excessive to me so I need to think up a way to create a small, lightweight temporary stack. I'll probably just declare some static memory and use that, but I need to "step away from the tree and see the forest" again, for a bit. :wink:

It would be nice, an option like this:

111 = "My Text"
Color(111,(255,255,255))

hehehehehehe.

I'm doing some progress, so far I have this:

Quote:

---

;Frases da tela inicial.

6209776 = "Ver: 1.98.7"
6215984 = "Conectando ao EvoPT..."
6215956 = "Falha na conexão!"
6215928 = "Preencha com seus dados!"
6215900 = "Usuário ou senha incorretos!"
6214708 = "Deseja continuar?"
6215808 = "Conta já está logada!"
6215720 = "Tempo de jogar expirou."

; Descrição dos itens

6136612 = "Talento: /n"
6136956 = "Defesa: /n"
6136932 = "Absorção: /n"
6136896 = "Integridade:/n"
6136844 = "Terra: /n"
6136820 = "Fogo: /n"
6136808 = "Gelo: /n"
6136796 = "Raio: /n"
6136784 = "Veneno: /n"
6136652 = "Nível: /n"
6136640 = "Força: /n"
6136612 = "Talento: /n"


6137004 = "Pod. de Ataque:/n"
6136992 = "Vel. da Arma:/n"
6136968 = "Crítico: /n"
6136944 = "Taxa de Atq: /n"
6136920 = "Bloqueio: /n"

---

In KPT 1986.
I'm just waiting bob to release an updated version.

Changing text colour is kinda beyond the scope. TextOut() and DrawText() APIs do not take colour as a parameter, but simply use the present GDI Pen. So there is no connection between the contents of a string and changing of default colour for subsequent GDI operations. That is by far better handled by modifying the game.exe I think. (Though you could patch CreatePen to a DLL function, and change the parameters passed based upon the return address. I just don't think it's practical.)

Preserving an unknown quantity of stack space and still passing parameters on the stack to a new API is doing my head in. >.< I've tried a number of approaches and they are getting silly complex and I'm still hitting the high level code causing fatal exceptions because it's reading memory it has no right to, unless the low level code completely destroys the information on the stack we're trying to process.

Oh, I thought it was possible to do.. But, what about the SetTextColor?

I think you are correct. The API is SetTextColor() not CreatePen(). The rest applies however.

Thinking about it while trying not to have a brain explosion on stack frame corruption and infinite possible parameters, I also considered that we could include (as you say) SetTextColor to any TextOut() or DrawText() API call... especially if we are patching the string pointed to anyway.

So I'll add that to a To-Do list. :wink:

Just checked MSDN and both recieve the hDC that SetTextColor() would require... but you list 4 byte figure, and although SetTextColor() takes 32-bit DWord the first byte must always be 0. (0x00bbggrr)

I assume you where hoping for an alpha level, which is not supported by either of these APIs (TextOut() or DrawText()) and would require you create a new Device Context, and blit that hDC to the main display hDC with a separate Alpha level, and that tends to destroy anti-aliasing (if any is enabled in the system), unless that is used as a mask... this all becomes very complex and is going to cause a major slow down. I doubt anyone will think it's worth it just to have "ghosted" text. XD

Outlines, highlights and / or shadow may well be much easier to achieve by simply displaying the text with a different colour at 1x1 pixel offsets from the main text. That would make for a pleasant effect IMHO, but the game does this in some places already, and you'd have to be careful not to "double do it". XD

Please comment if you think otherwise.

If you are saying, coloring text would cause a slown down, who am I to disagree :)

But, yes ofc, an option like:

111111 = "My Text",1,1 ; String,bold,underline

Would be nice ofc, JUST if it DOESNT slow down the game very much.

RGB colour, via SetTextColor() is not too hard. Bold, Italic, Underline is all set in the CreateFont() API and I believe that the program then uses SelectObject() to specify which font to use during each TextOut() function.

Again, that could be added, and I could set aside space in the DLL for say 16 different faces. Then specify a font face, and a color to associate with each address... but they will only be applied to the display of text at that address, so TextOut or DrawText captures, not any of the strings that are only caught in string manipulation. strcat, wsprintf etc. You may have noticed most strings are placed in a buffer at the same 5 or 6 addresses before being passed to these routines, so even 16 fonts / font variations would seem excessive.

It's the "Alpha" or "Transparency" that I think would really kill the frame rate.

Unless by

Quote:

---

111 = "My Text"
Color(111,(255,255,255))

---

the "111" in "Color" is supposed to refer to the string address, rather than the opacity (transparency, or alpha blend).

I wouldn't do it like that anyway. I would follow MS ini/inf standards and have:-

Code:

---

[Strings]
;Frases da tela inicial.

6209776 = "Ver: 1.98.7"
6215984 = "Conectando ao EvoPT..."
6215956 = "Falha na conexão!"
6215928 = "Preencha com seus dados!"
6215900 = "Usuário ou senha incorretos!"
6214708 = "Deseja continuar?"
6215808 = "Conta já está logada!"
6215720 = "Tempo de jogar expirou."

[Font0]
Face = "Courier New"
Bold = 1
Italic = 0
Underline = 0
Strike = 0
CharSet = 0          ; System Default
Width = 11
Height = Default      ; Default, Cell or Character
Weight = 700          ; Bold
Quality = ClearType  ; None, AntiAlias, ClearType, Proof

[Font1]
Face = "MS Sans Serif"
Bold = 0
Italic = 0
Underline = 0
Strike = 0
CharSet = 0          ; System Default
Width = 14
Height = Default      ; Default, Cell or Character
Weight = 400          ; Regular / Normal
Quality = None        ; None, AntiAlias, ClearType, Proof

[Colors]
6209776 = 16777215 ; White
6215984 = 65535    ; Yellow
6215956 = 255      ; Red
6215928 = 16711935 ; Feucher

[Offsets]
6209776X = 164
6209776Y = 1
6209776A = Center

6215984X = -65
6215984Y = 1
6215984A = Left

[Faces]
6209776 = 0        ; Arial
6215984 = 1        ; Courier Bold
6215984 = 1        ; Courier Bold

---

etc.

Oh, if the number to colour conversion seems a little odd, I could implement "= #FFFFFF" being equal to "= 16777215" with only a little overhead in loading time... that's the delay before the splash screen arrives... and as more strings are added, I'm considering displaying a splash or loading bar during that routine anyway... it's currently quite tempting to click the icon again because you think "Nothing's happening." XD Actually, it is, this is the point where I'm looking up and reading all the settings in your .lng file into the memory arrays for rapid processing during game play.

B.T.W. what is the file name of your Brazilian Portuguese .lng file? I know English is "009" regardless of whether it's British or American (or Australian, Canadian, New Zealand, or International English)... so I'm hoping that Brazilian Portuguese will have the same number as Portuguese Portuguese and, most importantly, not the same "009" that we have for English.

Just awesome! This ini you showed me, is only ficticial or is it already working? I mean,adding just

Quote:

---

Originally Posted by bobsobol

[Colors]
6209776 = 16777215 ; White

---

Wouldnt be possible without slowing down the exe, right?
About the Font, I already have in my DLL written in pascal, a routine to adjust the Font Call, CreateWindow, ShowWindow and some others API, so to me it wouldn't make a big difference.

Just one thing, the TextOut API, gets the X,Y and Z(?) of the string to show. I mean, in my dll written in delphi, I could put the string a liltle bit more to left, right, up , down....

It could be useful in this txt so we can align the translated strings, or do you think it would slow down the game?