KPT1977 NoXTrap --- Butchered!

Printable View

Show 100 post(s) from this thread on one page

01-08-10
tangodown

Re: KPT1977 NoXTrap --- Butchered!

It has suddenly dawned on me that I was not looking at the complete picture when it comes to the translation exercise. I was only looking at the client side of things and then only at the .rdata section. It seems that I also need to look at all the sections in both the client and the server for things that need to be translated. I can see why ppl are so protective of their hard work, I would be also.

I lack in a lot of training using the tools to accomplish those tasks. I will just read and learn as I go. Maybe I just may get good at it...lol
02-08-10
bobsobol

Re: KPT1977 NoXTrap --- Butchered!

I'm still looking at exactly what causes this bug with the Wormy character in Butchered RC 3b, and also considering asset management (sounds, meshes, animations and 2D images), especially as we now have such a good source of data in the original maps. But there are a number of things I hope to make into assets, which are currently built in to the executable. All language specific information should be this way IMHO.

We should not have to "translate a client executable". Translate the data files, the .SIN files and the titles in the artwork, sure, but not the exe.

I suspect that some existing people will be resistant to that idea, exactly because of the work they presently go through in order to create and maintain a client. But I think we are moving to a time period where communities like this will be pushing development of Priston Tale, and not the original distributors.

I think some of the private servers have been ahead of the official ones (if only by a few months) in development and features for some time... if we can work together and pool our resources, I think we can surpass the big boys with ease.

But "open" is not the way PT has ever been. It's not how it's designed, and it's not how the established PT servers are used to working. Even the private ones.

There is too much "hacking" the executables which goes on, and that doesn't make for rapid development. It must stop.

The reason it is there, is because the way PT works is insecure in terms of cheating. And so the problem with PT Development is to improve the ability to develop quickly without increasing an already problematic situation with "cheats".

Things like Language files and User Interface design (if done with care) should be prime targets here. There is no reason why these things should be part of the executable (client or server) and pose any greater threat of attack.

But actually... as far as server translation goes, if you don't translate the executable, GMs (Admins and Debug users) will know if you haven't done it, but users really don't see. It's easier to manage a PT server if you have translated the executable, but since the one we use was originally for Japanese use, if you return to the original, you will see that there is as much Korean in it as Japanese. So something like Shagpubs server is probably more translated than the official distributors have to play with.

If you try looking at Korean on a Japanese computer (a computer who's default language is Japanese) is even harder to understand than it is on a European one. XD And yet, it seems, that is still what they where given.

I do pity those who have paid for the right to be the official provider for PT in countries outside Korea. It seems to me they get a pretty rough deal.
02-08-10
tangodown

Re: KPT1977 NoXTrap --- Butchered!

Makes good sense to me...If I could master the C++ language I would try and re-write the whole damn thing...but that's not gonna happen anytime soon. My only contribution to this project will be that of a tester/trouble shooter. I support the effort that you are pouring into this project, quite a task for one person, just wish I could do more..

I remeber in my IBM mainframe experiences, they used to insert code into the main executables that were nothing but red herrings, brnahes that would send potentail hackers into a forever loop. There must be a way of protecting a client against all attacks, just not sure what form that takes.

I'll have to read Wormy's problem description again, I didn't understand it the first time...lol Great scott Watson! the game is afoot!!
02-08-10
bobsobol

Re: KPT1977 NoXTrap --- Butchered!
The current client is checked and double checked for outside interference. But too much statistical calculation is done in the client.

Other MMO servers "tell the client" what state the player is in during battle, if it doesn't comply when the server says "you are dead" that makes no difference, the player can't wander far from where the server, and every other player sees his corps and still get feedback on mobs. He can't damage mobs he tries to attack because the server has already told him he's dead, and the server decides and tells every player who did how much damage to what mob.

In PT the client decides how much damage the player takes and how much he does. That is all wrong for security against cheating.

What ever checks and double checks you put in to it, a good cheat will just use a "custom built" client that tells the server it has passed the checks, and doesn't bother checking internally.

It's a fundamental flaw which I believe springs from the fact that it was designed to be played as a LAN network play game, like Doom, or Dungeon Siege, not an MMO. Other similarities with network play (not internet play) games include "Game Save" functions, Client and Server in the same executable (all be it somewhat mangled now) etc. etc.

In Butchered (or original KPT1977) notice the hotuk command strings:-
- *ODBC_TABLE_PLAY
- *ODBC_TABLE_PASSWORD
- *ODBC_TABLE_IDNAME
- *ODBC_TABLE
- *ODBC_PASSWORD
- *ODBC_ACCOUNT
- *ODBC_NAME
- *CLAN_SERVER
- *GAME_SERVER
They are only checked for if the game is launched with *MODE SERVER. XD

I won't be using C++. But I do hope to get a working Assembler source for the game client, and server some day. Others can then build a C / C++ framework and gradually port functions out of Assembler and into higher level languages if they wish. I don't honestly see much point to them, and I've never seen any advantage to C++ over C. Object Orientation is supposed to make development more rapid and easier to read. Well, I can read and understand code that isn't OOP, and I can read and guess code that is. But really, I have no idea what the compiler is going to spit out from OOP languages.

If I write pure C, I can compile to assembler in my head and know approximately what will be in the executable once it's been compiled. When I write with C++, I can't do that. I feel like I'm putting too much faith in the compiler to do my work for me... like, an old car, you hear something funny going on and from the sound and feel you know which component to look at to fix it... but once Engine Management Systems come in to play, you have to plug it in to a computer to get a diagnostic read out before you have a clue, then everything is burred and packaged up so you can't get at it anyway. XD EMS has clear performance and economy advantages though. OOP might help team-work, (by isolating class users from the workings of that code) but actually places a high reliance on team members creating good classes that provide solid error results when used incorrectly. If a function you didn't write doesn't work the way you think it should from the documentation, you can easily look at the code and find out how it actually does work.
02-08-10
UserNameHere2

Re: KPT1977 NoXTrap --- Butchered!

PT is written in CPP, you can't disassemble PT's classes if you would do it in C.

Writing in C if you can in CPP is just stupid, there is no performance gain, compiled C doesnt run on more CPU's than compiled CPP, blada blada.
03-08-10
bobsobol

Quote:

Originally Posted by UserNameHere2

PT is written in CPP, you can't disassemble PT's classes if you would do it in C.

Writing in C if you can in CPP is just stupid, there is no performance gain, compiled C doesnt run on more CPU's than compiled CPP, blada blada.

CPP compiles to a mess in machine code. C compiles to clean optimised code. Classes make a mess for the CPU... And, that doesn't need to be the case, I've seen Blitz Basic on the Amiga compile OOP code Classes and Structures to very clean and optimal Assembler. But Visual C produces clean assembler from C and a mess from CPP.

Most of PT is clearly written in C. Because it isn't a mess once Assembled. The places where it interacts with DirectX, OLE and COM are clearly CPP and are messy at assembler level.

But you can't write classes and instantiate objects in x86. You can run anything in x86 that you can run on an x86 PC... in fact, anything you run on an x86 PC comes down to x86 at some stage.

So saying "you can't write in C because it has no classes" is nonsense to me. x86 has no classes and no limitations. You can write in-line assembler in C, so there are no limitations on what you can do in C either. You may need some very messy wrapper functions to interface with the COM model, but it can be done.

Some assemblers come with Macros for COM interfacing which provide them with "clean" ways of describing class structures too.

The fact is that I don't like Object Orientation, and wouldn't choose to use it more than I have to to interface with other components I'm building against. That doesn't mean you shouldn't use Object Orientation or that what I'm doing will never work with C++ or any other OOP language if you choose to address it in that way. It just means that's a job for someone else. XD

I can take Butchered to an Assembly listing that will make offsets irrelevant. I can then "bind" that into a C project, and replace "non-speed critical" sections (loading files and parsing user options) with C source that is equivalent to the old Assembler subroutines. A VC (or any other C++ IDE) project can contain and compile a mixture of C, C++ and Assembler into a single executable... so if others want to add sections in C++, that will be fine too... but that won't be something *I* will do.

I'm confident I will get to the point where my Assembler listing compiles back to an executable. That I will share, and possibly host on an open repository. (GIT probably) With that done, I will look at making it build into distinct import .lib files which can be linked in Visual C, and maybe GCC (MinGW), and if I get that far that will get a repository for sure. What routines from the .lib files people choose to replace with what source code in C or C++ from there is entirely up to them.

The reason it will probably be GIT, is because GIT is designed for people to work on forks, and forks of forks... so if C guys want to work on C forks and C++ guys want to work on C++ forks and x86 guy want to work on x86 forks etc. that's all fine with GIT, and submits can all be pulled back from each fork to produce something that takes the best parts from each fork. No problem. :wink:

And if people want to write in Pascal or BASIC or whatever, so long as they can build those routines to a .lib and make the appropriate header / .tlb etc in their IDE, that can be linked in too.

I really don't care what programming language people use, or how they like to utilise the resources available to them, any more than I care what colour their hair is or if they choose to dye it. XD Just don't push it on to me. Don't tell me I'm too black, too white or too yellow. I am what I am, and you are what you are. I love you as you are, provided that accept me for who *I* am in equal measure. Only intolerance is unacceptable to me.

Back on track, labels are expanding and being refined... if you're developing with this client you may like to take some benefit from them. This list is CSV compatible so you can work from your favourite spreadsheet when entering them into Olly or some other debugger.

Code:

Address, Section, Type, Name, Comments 00407470, .text, Label, subRenderText1 00407FF0, .text, Label, sub2DRender1 00408800, .text, Label, subOpenMap 00408DE0, .text, Label, subToggleMap 004103D0, .text, Label, SubWndProc2 004116D0, .text, Label, SetUIWidth 004117B0, .text, Label, subShutdown 00413AA0, .text, Label, subCmdLineProcess 00414870, .text, Label, subWindProc1 00415D00, .text, Label, subRenderIntroFrame 004165A0, .text, Label, WinMain 00416BF0, .text, Label, subHashString 004310B0, .text, Label, subAllowanceNonFGWindow 00436AA0, .text, Label, subProcRegistry 00436D20, .text, Label, subHotukProcess 004375B0, .text, Label, subShortcutProcess 0044367D, .text, Label, DWMBreaker, Call [edx+44h] 00444720, .text, Label, subScanWMQue 0044BB70, .text, Label, subCreatePresentDAT 0044CD1A, .text, Label, DC4? 0044F960, .text, Label, subErrorLogWrite 0044FBA0, .text, Label, subDDrawEnum 00450510, .text, Label, subRenderPlayFrame 00463B00, .text, Label, subInit3DEnv 00465EA0, .text, Label, subWriteSMD 00467270, .text, Label, subGetResID 00467E30, .text, Label, subTGALoad 0046C2B0, .text, Label, subLoadArtShopWeapons 0046D3F0, .text, Label, subLoadArtParticlePt2 0046D690, .text, Label, subLoadArtShopPremium 00471230, .text, Label, subLoadArtChatInterface 00473E40, .text, Label, subLoadArtHelp 00476C00, .text, Label, subLoadArtPetPose 00479E40, .text, Label, subLoadArtUIPt2 0047D280, .text, Label, subLoadArtUIPt1 0048D820, .text, Label, subLoadArtInventParticles 00492010, .text, Label, subAeq1 00492020, .text, Label, subLoadArtItemInfoBox 00497190, .text, Label, subLoadArtMsgBoxPt2 004991A0, .text, Label, subLoadArtMsgBoxPt1 0049BFD0, .text, Label, subLoadArtPCBPet 004A2920, .text, Label, subLoadArtHelpUI 004A7510, .text, Label, subLoadArtPersonalShop 004BDB80, .text, Label, subLoadArtSkills 004BE6F0, .text, Label, subLoadCursors 004BE7D0, .text, Label, subSetCursor 004BEF30, .text, Label, subInitFonts 004C1D00, .text, Label, subLoadArtTradeShopPt2 004C89A0, .text, Label, subLoadArtTradeShopPt1 004CEF60, .text, Label, subXTBS1 004CF290, .text, Label, subLoadArtWarpGate 004D2AD0, .text, Label, subLoadArtParticlePt1 004D2CA0, .text, Label, subXTBS1.1 004D3E70, .text, Label, subLoadArtParticlePt1b 004D5600, .text, Label, subLoadArtParticlePt1a 004D6800, .text, Label, subLoadArtParticlePt1d 004D8B80, .text, Label, subLoadArtParticlePt1c 004DC560, .text, Label, subLoadArtParticlePt1e 004E4E60, .text, Label, subSetBGM 004E5090, .text, Label, subInitDSound 004E54B0, .text, Label, subStopBGM 004E5AF0, .text, Label, subChangeBGM 004E5EE0, .text, Label, subPlayWAV 004E6000, .text, Label, subFreeAudio 00510E90, .text, Label, subSaveBMP 00511CF0, .text, Label, subHanDesProc 0051A52A, .text, Label, CleanMe! 00523034, .text, Label, XTrap_Sometimes1 00529930, .text, Label, subRegister 0052B13E, .text, Label, DisplayVersionNumber 00537380, .text, Label, subLoadMeshLLPet 005374B0, .text, Label, subLoadLLPet 00538810, .text, Label, subLoadMeshPCBPet 00538980, .text, Label, subLoadPCBPet 0054F1A0, .text, Label, subAeqC 005552E0, .text, Label, subProcessPTRegRgx 00555520, .text, Label, subGetReg 00559550, .text, Label, subVersionCheck 0055CE70, .text, Label, subBackgroundTimingThread 005871D0, .text, Label, subCreateDDDtxt 005887A0, .text, Label, subLoadClanData 00588C6A, .text, Label, CleanMe!! 00588D10, .text, Label, subXTError 0058C490, .text, Label, subDDDtxtStuff 0058CFE0, .text, Label, subGetClans 005943F0, .text, Label, subSetLUAVar 005B3B30, .text, Label, subVCHeapAlloc 005B421E, .text, Label, VCfopen 005B4444, .text, Label, subAsc2Val 005B449C, .text, Label, jmp_subAsc2Val 005B4700, .text, Label, subGPUModelCheck 005B487C, .text, Label, subTimeUpdate 005B489F, .text, Label, subPointlessQMark 005B493B, .text, Label, XTBS1Fix 005B4AA4, .text, Label, FixMe! 005B5D0D, .text, Label, .WinNT, 9x rejoins NT 005B5DFC, .text, Label, subCalcZoom 005B6EC8, .text, Label, subVCHeapAlloc2 005B6F8C, .text, Label, subFreeMem 005B72A4, .text, Label, subAllocMem32K 005B9D28, .text, Label, subVCResetSEH1 005BD2FE, .text, Label, subMemProtect 005BF57D, .text, Label, VCErrorMsgBox 005C46DC, .rdata, Label, szFontName 005C4714, .rdata, Label, fOne 005C4D60, .rdata, Label, fDiv256 005C5D28, .rdata, Label, szWindowName 005C5ED0, .rdata, Label, fPi 005C5F60, .rdata, Label, szClassName 005C5F7C, .rdata, Label, fZoomFactor 005C6204, .rdata, Label, szShortcut.ini 005C6214, .rdata, Label, szHotuk.ini 005C9C88, .rdata, Label, szKWindowMode 005D00B0, .rdata, Label, fVFadeCull 005E759C, .rdata, Label, szRegisterPage 005E79D4, .rdata, Label, szHanRegisterPage 005EAA48, .rdata, Label, szPTReg.rgx 005F1C10, .rdata, Label, Struct.SEH1 005F9A30, .data, Label, lpszWindowTitle 005F9DC0, .data, Label, dwDisplayWidthCpy 005F9DC4, .data, Label, dwDisplayHeightCpy 005F9DC8, .data, Label, dwDisplayBPPcpy 005FCF28, .data, Label, expLevel0 005FCF30, .data, Label, expLevel1 005FCF38, .data, Label, expLevel2 005FD44C, .data, Label, bWindowModeCpy 005FD454, .data, Label, dwDisplayWidthDiv2 005FD458, .data, Label, dwHalfHeight 005FD45C, .data, Label, dwWidth 006FDCA0, .data, Label, lpszRegisterPage 006FF6E8, .data, Label, dwVerionNumber 00700318, .data, Label, dwLUAVar 00701478, .data, Label, memXTrapStart 0070147C, .data, Label, fTrueZoom 00701480, .data, Label, sRECT.left 00701484, .data, Label, sRECT.top 00701488, .data, Label, sRECT.right 0070148C, .data, Label, sRECT.bottom 007017D7, .data, Label, memXTrapEnd 00709140, .data, Label, dwTickStore 00709BE8, .data, Label, cso3 0073D568, .data, Label, cso2 0073D834, .data, Label, fDisplayHeightMul1.08 0073D95C, .data, Label, cso1 0073D980, .data, Label, szCmdLine 0073DA04, .data, Label, hWndEDIT 0073DA1C, .data, Label, hWndMain 0073EB40, .data, Label, fDisplayWidthMul0.00125 0073EDCC, .data, Label, dwLastTick 0073EDD4, .data, Label, tTimingVar1 008EBD78, .data, Label, bWindowMode 008EBD7C, .data, Label, dwDisplayWidth 008EBD80, .data, Label, dwDisplayHeight 008EBD84, .data, Label, dwDisplayBPP 0091C430, .data, Label, pCharRec 01C22114, .data, Label, hIDB_LoadingLamp 01C22118, .data, Label, hCDCLoadingLamp 01C2211C, .data, Label, hIDB_LoadImg 01C22124, .data, Label, hCDCLoadimg 01F38614, .data, Label, bSpecialNeedsGPU 01F38618, .data, Label, DDrawAPI_1 01F3861C, .data, Label, DDrawAPI_2 01F38620, .data, Label, DDrawAPI_3 01F38624, .data, Label, DDrawAPI_4 01F38628, .data, Label, DDrawAPI_5 01F3862C, .data, Label, DDrawAPI_6 01F38630, .data, Label, DDrawAPI_7 01F38634, .data, Label, DDrawAPI_8 01F38638, .data, Label, DDrawAPI_9 01F3863C, .data, Label, DDrawAPI_A 027DA21C, .data, Label, dwDisplayXCenter 02BDA24C, .data, Label, dwDisplayYCenter 02C9D7B8, .data, Label, dwDisplayHalfHeight 030FF368, .data, Label, pCharDAT 031408D0, .data, Label, dwCursorGrab0 031408D4, .data, Label, dwCursorTalk 031408D8, .data, Label, dwCursorRepare 031408DC, .data, Label, dwCursorBuy 031408E0, .data, Label, dwCursorAttack 031408E4, .data, Label, dwCursorGrab1 031408E8, .data, Label, dwCursorSell 031408EC, .data, Label, dwCursorDefault 03140CE0, .data, Label, dwAttackCursor 03140D28, .data, Label, dwGrab1Cursor 03140D2C, .data, Label, dwSellCursor 03140D34, .data, Label, dwDefaultCursor 032D6DC0, .data, Label, dwDSound2Error 032F16C8, .data, Label, dwDSound1Error 032F3168, .data, Label, ppDS1 032F3174, .data, Label, ppDS2 032F3188, .data, Label, varBGM 032F318C, .data, Label, hBGMPlaying 032F3190, .data, Label, uTimerID_BGM 032F3198, .data, Label, bBGMPlaying 033710A0, .data, Label, szAccName 0341F788, .data, Label, tTimingVar2 03423F54, .data, Label, szServerName 034A6874, .data, Label, bOpenBracketAmpasand1 034A688C, .data, Label, bOpenBracketAmpasand3 034A6894, .data, Label, bOpenBracketAmpasand2 034A6CFC, .data, Label, bDDDtxtActive 0444D5C0, .data, Label, dwPlatformID 0444D5C4, .data, Label, dwBuildNumber 0444D5C8, .data, Label, dwOSVer 0444D5CC, .data, Label, dwMajorVersion 0444D5D0, .data, Label, dwMinorVersion

Some of them don't make sense till you see the code around them. Not that lpsz is a pointer to a string, and sz is the null terminated string it's self. Structures like sRECT, use dotted notation (as per MS documentation) to label their individual components. There is no reason why these memories can't be used differently in different places, but I haven't "seen" much of that.

What the function of the DDraw_APIs is, I can't say because it's COM, and it's only documented in C++, so how the machine actually uses it is still something of a mystery. Of course, it does, and can be understood. (I've seen a hobby OS written in Assembler which uses COM as the basis for all it's APIs, so it's not impossible for sure.)

I have updated the OP to include lots of download locations of Beta 2 variant b... which has proved the most stable.

It also includes the Version patcher and a ppf patch file to translate the client to English. This is the primary reason for the update since Osirus provided me with an En translated version.

Thank you Osirus

I'm sure many of you are used to using PPF-O-Matic for one reason or another. Although it's designed for PlayStation ISO files (creating patches to make them work on Emulators) it's actually a very capable and very standard binary file patch format. I've used BinPatch and such in posts before, and though their format is smaller, having the ability to reverse the patch, and under the assumption that many of you will already know ppf files, I probably don't need to provide an executable patcher, which actually makes the patch bigger. (PPF-O-Matic_has become popular for many many large files... especially when modding game archives)
29-05-11
animetop

Re: KPT1977 NoXTrap --- Butchered!

Can anyone re-upload, KPT 197x server File out Malware-gen?

I got server KPT 1976 But in ET1 and ET2 is impossible put monsters on spow lol!

Anyone can fix it?

ET3 is perfect!

Fille exe for Download!
http://www.megaupload.com/?d=76B92AP1
30-05-11
bobsobol

Re: KPT1977 NoXTrap --- Butchered!

IDK what you are asking for. The server I linked to produces a "false positive" in many anti-virus programs. To fix it, complain bitterly to your Anti-Virus provider. (or just accept the high rate of "false positives" in pattern matching AV and medium rate in Heuristic AV and set an exception against the download) The download links are still very much alive and active.

Therefore, there is no problem, except that any talk of servers is "off-topic" for this thread.

Whether monsters spawn or not is not an issue with the linked server, or this client (especially when used in combination... I've done it, so I know they work well together) therefore you have done something wrong. (probably forgot to copy over Char and Field from client, or simply haven't got the basic server data files to go with that linked server executable)

Again, this is off-topic, as it's completely unrelated to KPT1977 Butchered.

--- EDIT ---

As it's falling away now, I'll not here that the last development release of this client is v4 Pre-release.

It updates a number of things, and specifically includes all those labels I keep sharing as exports. So the PE structure has changed a fair bit. I think that means the configuration program doesn't work right any more? Oh well... it's only a pre-release so people can see it is still moving along and have a play with what I've been developing.

Exported labels get disassembled by any disassembler, so I can improve on the source listings by dumping multiple disassembles, and cherry-picking. But it also means you have a much better understanding of how my client works, and where you should make changes to make it do what you want. ^_^
11-02-12
bobsobol

Re: KPT1977 NoXTrap --- Butchered!

Okay, I know I'm bumping an old old thread but. Since we have so many broken links I have re-attached this release. However, I didn't have the original archives, so checksums will have changed.

More importantly, I didn't keep the original PPF patch for the English translation by Osiris. I've created a new PPF, but didn't get the options the same, so the detail in PPF-O-Matic look different. Don't worry, it still works the same way. :thumbup:

Show 100 post(s) from this thread on one page