Beta Technical Demonstration - Translation without Hexing the EXE

Line like that for example

Code:

---

TextOutA(), 54394804, "From> a: Admin Level 3 - Activated.  ", "/* Not Replaced */"
TextOutA(), 54394804, "From> a: Admin Level 3 - Activated.  ", "/* Not Replaced */"

---

might be taken from memory than again whey its formated on chat out.

But yeah its showing up in memory too many times. Some kind of check or refresh?


PS. Your client crashed when I tried to accept T4 quest (with mech), I need to w8 70 minutes now because on my .exe it was OK and I will check that again with debugger.

And something is wrong here:

http://oi55.tinypic.com/izmg5e.jpg

Time is not going down too :/ "70minute" all the time. Are you missing some %d?

--UPDATE--
In KPT is Time Limit: 70Minutes, thats static and not decrease too
and under is Avelin: ??/?? killed.

Yea... that's the kind of play-testing I need. I've never figured out how to do tier quests... which is why my highest character is level 9x and still only has 4 skills. :lol: I have no idea what the quest is asking me to do.

You do all know I'm no good at actually "playing" this game right? :ott1:

Things I've never done:-

• Survived round 1 of SoD or even entered SoD2
• Been to "Bless Castle" when the event was on (except as a "hidden GM")
• Got past the the second rank-up quest
• Legitimately leveled up to 40
• Aged an item
• Killed, or been in a party that killed a "boss" spawn (unless I spawned it my self as GM)

None of that is exaggeration. I have literally never been that good a player. I'm a complete *noob* at video gaming, and always found PT too hard to be fun to play after the mid lvl30s.:*:

There is a problem when I start with debugger:
763028C7: The instruction at 0x763028C7 referenced memory at 0x0. The memory could not be read -> 00000000 (exc.code c0000005, tid 5592)

Code:

---

kernel32.dll:763028C7 mov    al, [ecx]

---

But i can pass that.


When I click OK to take T4 quest:
769A9D60: The instruction at 0x769A9D60 referenced memory at 0x1E. The memory could not be read -> 0000001E (exc.code c0000005, tid 5592)

Code:

---

user32.dll:769A9D60 mov    dl, [eax]

---

and game crash/quit.

When I just quit, debugger giving me error:
0: The instruction at 0x0 referenced memory at 0x0. The memory could not be read -> 00000000 (exc.code c0000005, tid 10580)

And no more information to all those errors :/

With or without 009.lng file make no difference.
Same thing happen with your older IntStr.dll

Even restart did not help, do you have same problems?

How would I acquire this quest to try to replicate it?

I'd like to try on some of the earlier edits of Butchered and 1977 to see if it's some edit I made way back when. I keep all the key stages, even if I don't remember every edit that I made, I can compare blocks of code around an area and what information they are given.

Copy
DataServer > userdata > 65 > a.dat
DataServer > userdata_backup > 65 > a.dat
DataServer > userinfo > 65 > a.dat

files in attachments, to your server.
Create account with "a" login "a" password.
Login as a mech and try to take T4 quest from skill master, game will crash.

Also when you start game with olly and press quit; it can be done even on login screen; game will crash with error (additional errors that only IDA shows me are in previous post):

http://oi53.tinypic.com/2mgrqly.jpg


If you planing to do quest by yourself than use this:
Priston Tale: Tempskron job quest
Priston Tale: Morion job quest

Seasons Greetings to all.

I've spent the last couple of days boxing with my server... seems something has broken my registration page (probably switching to IIS) so I've not managed to use this account.

The guides look good, and I implemented a warning on mismatched parameters in the logging version of IntStr.dll and a compiled (executable) SetLogging program with a simple Windows Dialog UI which is prettier and faster than the batch file.

So before I head off to be with family this holiday season, I'll leave you this latest release archive containing all DLLs, and both the game executable (ButcheredInternational, which I don't think has changed since the last upload) and the SetLogging executable to quickly switch between logging and release DLLs.

Wishing you all the very best of the holiday season. :wink: "God bless us, every one." Be safe, be merry and stay warm, within and without.

@off

Merry christmas.

@on

What is the issue with the dll? I've been away for a few days, whats going on?I saw the pictures but cant understand the error.

I think it's my game.exe rather than the DLLs, but there seems to be a bug with (at least) one of the rank-up quests.

I suspect there is also a problem with Server DC... If I shut the server the client doesn't quit, it locks up.

Sorry, by mistake i wrote "take skill from skill master" I meant "T4 quest", and I fixed that =P

@lelejau you can try if you have same bug as me, game crash when you try to take T4 quest with bobsobol game.exe and dll's ON.

Re Post 125 above.

I've looked into it, and it feels like a corrupt save game file... but what I don't understand is why some clients will ignore the corruption.

Specifically, I have a 1977 client which only has the simple "ignore XTrap if it's not in the folder" patch... and it will work on that.

It will work longer out of the debugger than in it, but there seems to be a lstrcpy() performed on a location pointed to by a DWord in the character file, which is 0 in this game state.

Run outside the debugger, it completes the lstrcpy() copying a 0 character string from what should be protected BIOS area. But then crashes when you accept the quest. Inside the debugger, of course Olly picks up the illegal memory operation as soon as the character is loaded into the game.

If the character is loaded into my older XTrap indifferent 1977 game.exe, then the pointer seems to be updated before it gets to the point where the lstrcpy() comes up.

It's rather odd, since it definitely seems to be the save game state, and either way it's only just been downloaded from the server.

At location 0049E456h lstrcpy is made to copy a string from address 0 to 03100480h

Before my edits, the address was not 0, but 005D457Ch.

This address is aquired by a routine at 0049DE90h:-

Code:

---

Mov EAX,[ESP+4]                                  ; game.0049DE90(guessed Arg1)
Mov EAX,[EAX*4+006AFFB0h]
Ret

---

This code is the same in both clients that work flawlessly and clients that crash.

If you NOP out the lstrcpy(arg1,arg2), (ie. the CALL and it's two PUSHes before hand) I don't personally see any detrimental effect, but even the International Client loads it okay. But that's clearly not the way it's meant to operate.

Strange error, one of the problems is here :
kernel32.dll:758A28CB inc ecx
ecx have wrong offset on stack, its pointing
debug024:04638BE0 aMetron db 'Metron',0
or
debug042:045E8828 aDarkSpecter db 'Dark Specter',0
I don't know why ist random :/

Code:

---

kernel32.dll:758A28B1 kernel32_lstrcpy:
kernel32.dll:758A28B1 push    8
kernel32.dll:758A28B3 push    offset unk_758A28E8
kernel32.dll:758A28B8 call    near ptr unk_75881928
kernel32.dll:758A28BD and    dword ptr [ebp-4], 0
kernel32.dll:758A28C1 mov    ecx, [ebp+0Ch]
kernel32.dll:758A28C4 mov    edx, [ebp+8]
kernel32.dll:758A28C7
kernel32.dll:758A28C7 loc_758A28C7:                          ; CODE XREF: kernel32.dll:758A28CFj
kernel32.dll:758A28C7 mov    al, [ecx]
kernel32.dll:758A28C9 mov    [edx], al
kernel32.dll:758A28CB inc    ecx
kernel32.dll:758A28CC inc    edx
kernel32.dll:758A28CD test    al, al
kernel32.dll:758A28CF jnz    short loc_758A28C7
kernel32.dll:758A28D1 mov    dword ptr [ebp-4], 0FFFFFFFEh
kernel32.dll:758A28D8 mov    eax, [ebp+8]
kernel32.dll:758A28DB call    near ptr unk_7588196D
kernel32.dll:758A28E0 retn    8

---

if I change ecx to 005D457C function go to call wsprintfA and crash there.

Quote:

---

Stack[000023A8]:0018F684 dd offset byte_3100480 <-- player name OK
Stack[000023A8]:0018F688 dd offset aMetron ; "Metron" <-- should be "©Ěă«Ŕđ"
Stack[000023A8]:0018F68C dd offset unk_2543E1F4

---

This is as far i checked.

I don't have clean 1977 so I can't tell for sure. Maybe your dlls messed stack somehow?

It's not the DLLs. I'll attach KPT1977 with optional XTrap, and with XTrap fully disabled, but no extra DLL usage.

The problem persists in the NoXTrap version, but not in the OptionalXTrap version... so it looks like I cleaned out something badly.

There are still a couple of calls to XTrap checking routines which I am simply returning from. It's quite a long time ago since I did those now, but I tried to check that the stack after modification was the same. It's possible one of them modified the frame under certain circumstances, but didn't normally.

(not)Fixed,
problem is (not) here:

Code:

---

0044367D  . EB 01          JMP SHORT Butchere.00443680
0044367F    90            NOP
00443680  > 83FD 02        CMP EBP,2

---

(not)change it back to:

Code:

---

0044367D  . FF52 44        CALL DWORD PTR DS:[EDX+44]
00443680  . 83FD 02        CMP EBP,2

---

At lest if you saying that KPT1977-NoXTrap.exe had this bug too.
I will check it on ButcheredInternational.exe when my quest time will break.

PS. JMP is better than NOP? Is it faster? Pointless nops are that slow?

--EDIT--

It must be something else you modified, there is no bug on KPT1977-NoXTrap.exe
:/

Quote:

---

Originally Posted by Vormav

...
if you saying that KPT1977-NoXTrap.exe had this bug too.
I will check it on ButcheredInternational.exe when my quest time will break.

---

I tried the saved character on ButcherdInternational, and it crashed. I restored the files, and restarted the server and tried on KPT1977NoXTrap and it crashed again. I restored the files, restarted the server and tried with KPT1977OptionalXTrap and it didn't crash.

This leads me to believe it's something I cleared out with XTrap.

Quote:

---

Originally Posted by Vormav

PS. JMP is better than NOP? Is it faster? Pointless nops are that slow?

---

In many circumstances yes. NOP is actually considered to be a "delay" instruction, like a primative Sleep() API call. NOP is usually a 1 byte instruction, but should take several cycles to complete. Different OS often treat it as a "privileged" instruction, and replace the cycles with a "sleep" type call to allow the CPU to do something else, some treat it as time to cool down the CPU, as an overheat prevention. Exactly what it does has changed over the years, but what it definitely is not is the JMP [EPC+1] which it appears to be when tracing.

Spoiler:

The EPA logo on many BIOS should mean they "virtualise" NOP (by making it privileged, catching the exception doing something else and then returning the Program Counter to it's original position) into an Interrupt 13h (IMS) which should send the CPU into a cool down. This is particularly useful on primitive OS like DOS on systems like laptops... but can increase energy efficiency during the bootloader process of many OS. (the BCD in NT6, Boot Manager for OS/2 - NT5, Grub / Lilo / SysLinux etc)

Back on DOS, up until the i486 we used to be able to execute a run of "something like" 50 NOPs and know that it would take a tenth of a second, regardless of whether the CPU was running at 25, 33 or 66 Mhz (the usual speeds at the time), and would use that to time vertical blanking and avoid tearing, since the VGA specification doesn't pass "fly back" or "refresh" data to anything the CPU can read.

CPU manufacturers like Evergreen and Cyrex broke those standards to appear to run "faster" or "cooler" than Intel processors; and exactly what NOP does has never been the same since.

Runs of more than a couple of NOPs should be avoided from being executed where possible, at least in a multi-threaded / multi-tasking environment. :wink:

Spoiler:

If you are very cleaver, and have thoroughly checked out the specification of NOP on every CPU you want to support, and have analysed exactly what make and model CPU your program is running on, you can use NOP to generate very very fine grained timing in your fabulous demo or 4K intro or something.

It's a massive show off, but I'm not sure the effort is worth the pay-off, and it dates your Demo very quickly, because you can't possibly know the specs of the processors that haven't yet been made, or that new OS aren't going to treat NOP in a different way. Some kernels take NOP as a queue to jump thread context, others treat it as a "give some time to the idle thread", others treat it as just "suspend me for a few microns", and others literally skip over it, with a possible context change and return... which is very wasteful.

Quote:

---

Originally Posted by Vormav

--EDIT--

It must be something else you modified, there is no bug on KPT1977-NoXTrap.exe
:/

---

That's odd... that doesn't tally with the results I got.

Seems I need to re-test again and ensure I didn't make a mistake somewhere along the way.

Nope on your KPT1977-NoXTrap.exe this bug simply don't exist.
I think problem is with your dll or with what you patched.

in you 009.lng file change:

Code:

---

6112628 = "Metron"
6112636 = "Dark Specter"

---

to

Code:

---

6112628 = "다크 스펙터"
6112636 = "다크 스펙터"

---

and your code will work till (it will crash sooner without this modification)

Code:

---

0049F2DF  |. FF15 D4425C00  CALL DWORD PTR DS:[<&USER32.wsprintfA>]  ; \wsprintfA

---

and after executing this call it will crash.

So your dll is patching something wrong again in:

Code:

---

user32.dll:76E39D60 mov    dl, [eax]

---

eax have wrong value (its 0x0000001E), eax should be 0310F558 (다크 스펙터) again.

This problem might be connected to picture I uploaded

http://oi55.tinypic.com/izmg5e.jpg

its showing wrong translations in wrong places (so it might patch wrong things in wrong places).



--EDIT--

confirmed just a moment ago:
if you leave only those two lines in 009.lng file:

Code:

---

6112628 = "다크 스펙터"
6112636 = "다크 스펙터"

---

you will be able to take T4 quest without any bug on ButcheredInternational.exe!

Conclusion, you are patching some wrong lines connected to quest.


--EDIT--2--

You can't translate this the way you done it:
server side file:
87_DarkSpecter.inf
have line:

Code:

---

*이름                        "다크 스펙터"

---

and client copy monster name from this line ignoring .zhoon translation and

Code:

---

*Name                        "Dark Specter"

---

in other words to see this translated you need to translate 87_DarkSpecter.inf to look like this

Code:

---

*이름                        "Dark Specter"

---

but thats a bit problematic when come to translation.

There is one more thing that can't be translated (I did not found it yet, maybe 6113028 = "<Quest> Hunt %d of %s "? I am sure its on quest icon), anyway I am not sure yet if line in .inf file is compared to what client have or you should translate monster name "after" player got quest (copy of quest is saved somewhere else and quest icon read from there so you need to translate that "somewhere else"... probably >=P).

I am sure you will be able to fix it now :)