Really good release
How about we creating like a RageZone team to translate a modern game.exe to english?
I would be happy to help with what I can
This is a discussion on KPT1977 NoXTrap --- Butchered! within the Priston Tale Releases forums, part of the Priston Tale category; NoXTrap KPT 1977 Game.exe Butchered Beta 2b The first version I attached in JayMokos' 1976 Server thread as people where ...
NoXTrap KPT 1977 Game.exe
Butchered Beta 2b
The first version I attached in JayMokos' 1976 Server thread as people where asking for a 1976 client which was already no longer distributed, the current version (at the time of writing) is 1977, so this is the closest to what he is basing his server against.
The first version removed the initial XTrap check, but a new thread is created with checks again periodically, so it wasn't really "NoXTrap". This version removes considerable amounts of code and data related to XTrap and other functions which are never used in the modern client... they are dead code left over from older experimentation... that's why I call it Butchered.
I'm happy to keep improving this version... one need is for an English translation of a modern KPT client, which has been murmured about for some time, so that needs to be done... there are UAC violations which require game.exe to be installed outside the normal "Program Files" / "Program Files (x86)" or disable UAC. It creates and deletes files in it's own folder, not the users profile, and reads settings stored in HKLM which needs to be corrected, again to the users profile.
An internal IP address, preferably with an encryption algorithm attached to prevent custom clients being used on servers they are not designed for use with is also on the list of To-Dos', and I would like to attach to this thread, a tool to allow you to modify the internal version number. I'd also like add some form of the "Client Area" fix(s) for Window mode, and combination of settings (Registry, ptreg.rgx & hotuk.ini).
For now, this is a very fast and effective, modern client. Please enjoy it, and feed back to me your greatest problems with it... especially if they are not already listed above.
!!! Update !!!
New client configuration program to allow graphical setting of internal Version Number. (more features to come I suspect)
KPTVerSet.exe v184.108.40.206 MediaFire Rar Archive.
Source Code Rar archive with complete source code and project for Borland C++ 6 (should work with newer). Requires JCL components. (Only for the JCL FileEdit component at the top of the form, you can replace it with a standard VCL TextEdit component and a button and a FileOpenDialog VCL component and only loose Drag and Drop support without typing anything except to link the button to the "file open" dialog outside the form editor.)
Mini - Readme
Okay... most controls are absent when you start the program, this is normal, you can't set the game version on nothing. Drop a 1977 game.exe on it and it will read the version and checksum, if they match you get an okay dialogue and can switch between Beta and Release versions, use the drop downs to input only valid version numbers click "Save" and it should update your exe to report that version number both to the user and to the server!!! (Feel free to hex the string to report something different "on screen" before release)
It has been tested on Windows NT 4, 2000 and Vista x64, which I think covers enough bases to say it should work on just about anything. It contains a valid manifest for XP (UI theme integration) and UAC security (Vista & 7).
If you want to edit a client in your "C:\Program Files" or "C:\Program Files (x86)" folders on Vista or Se7en, please right click and "Run as Administrator" or move the file to the desktop or WHY and edit there before moving it back.
The reason it checks the version and checksum before it lets you edit the file is that if they don't match, the file is either already corrupted or it is not a real KPT 1.97.7 based client it knows how to edit. In which case it's safer for it to just not work.
Remember, don't let beta versions out into the wild, and if your Admins, GMs or Debug staff use them, don't let anyone outside the staff know what beta version they use. You have to allow a beta or debug version in hotuk.ini with a different command, but beta versions do not create a funcbox file! See this thread for why the version number and funcbox files are important for your servers security.
For your servers safety you are best to use a unique vendor version for your server (vV.VM.m where v is optional digit, V is vendor digit, M is major version and m is minor version). Each time you get significant attacks, or make changes to game.exe, code, item lists, mixes, ages etc. etc. you should change the version number.
Vendor codes I know are taken:-
- 1.8x.x, 1.9x.x, 2.3x.x are all KPT (Korean)
- 1.0x.x is PTCn (Chinese)
- 2.0x.x, 3.0x.x and 3.1x.x EPT (English)
- 2.3x.x and 2.4x.x is jPT (Japanese)
- 10.5x.x is PTV (Vietnamese)
- 4.1x.x is PTBr (Brazilian)
If anyone knows of others that private servers should avoid, please share.
- KPT1977 NoXTrap Butchered v2b Beta
- English PPF patch
- KPT VerSet tool
- BCB 6 project and C++ Source Code for above tool.
I have to thank Osirus who kindly donated an English translation.
I've included it as a PPF patch file En.ppf to keep size to a minimum.
This can easily be applied with PPF v3.0 and it's PPF-O-Matic GUI.You can tick the "Apply undo patch" option to return to the original file.
Don't forget that PPF files are primarily designed for ISO images (though they work on any binary file) and so you have to switch to "*.* All files" when browsing for the source.
Code:VirSCAN.org Scanned Report : Scanned time : 2011/02/05 17:03:05 (GMT) Scanner results: Scanners did not find malware! File Name : Butchered_Betav2b.zip File Size : 2183109 byte File Type : Zip archive data, at least v2.0 to extract MD5 : 3f504d1b362d9a1b21105ac69b1a4974 SHA1 : 880cbdb376325fda569b052f2ca10cb39d31a532 Online report : Butchered_Betav2b.zip MD5:3f504d1b362d9a1b21105ac69b1a4974 - VirSCAN.org Scanners did not find malware! Butchered_Betav2b.zip MD5:3f504d1b362d9a1b21105ac69b1a4974 - VirSCAN.org Scanners did not find malware![/url]Spoiler:
Really good release
How about we creating like a RageZone team to translate a modern game.exe to english?
I would be happy to help with what I can
Learning about PT server
Aye. V3 is bummed down some more and has DWM Window Mode fixed. I also enabled the desktop cursor, and wonder if I can't disable regular cursor rendering, and use the normal APIs to use cursors. And there must be a way to improve the font rendering and performance (glyph caching or Bitmap Blit or something) as framerate improves a lot if you disable all text rendering. XD
I have a working Beta of the Version setting program... I'm getting pointer corruption when I build for release (or remove a breakpoint) so I need to ensure that there is a buffer set aside for it... It's just a string conversion, but it's annoying that the debug build automatically sets space for it, and the release build doesn't. (shrugs) I'm stunned how easy it is to do when you just make a UI for it, it would be nice (I think) to add IP, Port and packet encoding keys to it.
If you want to start work on those easy strings in the .data section, (아이템 수납 공간이 부족합니다 = Not enough space in inventory etc) where there is plenty of space, I can just merge those back in without difficulty.
Hate to bump, but
a) nobody has commented on the last update
b) I'd like to inform you of some of the improvements coming to version 3.
So without further ado...COMING SOON TO A PT CLIENT NEAR YOU!Priston Tale in Wide Screen with no black borders in either 4:3 (classic) or 16:9 (contemporary), or any other aspect ratio for that matter.
! ! BIGGER ! !
!!! W I D E R !!!
Fully HD Ready!
Interesting glitch can be seen in the screenshots where the wider your aspect ratio the more the mini-avatar of the NPC your mouse is over expands over the top of their border. I'll look into it, but aside from going above 1080p I don't think it's a major problem.
I've bummed down considerably more code, got it loading faster, have allowed the Windows cursor to show over the display, and coded in such a way as this is optional. My hope there is that I can use Windows cursor (.CUR files) to replace the blitting to the game display for smoother cursor movement, eventually.
I've reduced some pointless delays which normally give back way too much CPU time if the window isn't active, and if I can refine it then I may be able to reduce the timeouts in Window Mode.
I've started work on fixing the Window size, it's now static so you can't maximize or resize but should open at the resolution requested plus the border but I'm hoping to be able to achieve this without adding any extra API imports to the PE file as my earlier solution did, and Gregoos guide currently does. I believe it can be done.
I have fixed DWM (Transparent Window Borders) being disabled, even though this incurs the penalty of not seeing a flashing "Loading" bar... I will look into replacing that with something that doesn't upset DWM, but probably no till v4.
I still have 1 XTrap call which is called dynamically in such a way as I can't remove it more than replacing the entire routine with a "RET" instruction. I know why and what needs to be booted, but it's knotted into the rest of the code and data tables so much that I get brain ache each time I try and mess up something simple, so I need to go at it in smaller chunks and save more frequently. XD
V3 will mark the first forey into adding new code as well as optimizing existing code and cleaning out junk.
I'd like some feedback on how people feel. Right now, the "ptreg.rgx" "ScreenSize" setting is taking a back seat to Hotuk.iniBut both files are parsed in a similar way, and affect the same memory locations.Code:// Screen Resolution *화면해상도 1280 720
I can read settings from Registry, Hotuk.ini, PTReg.rgx, lData.bmp or anything else in that form. Where would you most like this crucial setting stored? Would you like a launcher which looks and feels like the official PT one, but supports any resolution your GFX card + Monitor can handle? etc. etc.
I have to work out a way to decrease loading time (more than I already have) and to increase in-game frame rate, which I feel is "piss poor" right now. I expect an optional FPS overlay to be fourth coming, as the only way I can test the validity of what I feel with scientific results.
I've checked for useless threads and that doesn't help. There are a couple instigated mostly by the OS rather than the game, so I think it's about time I made the client as multi-core friendly as the server side and figure out a dedicated timed thread for updating the display... I think I can do that, but synchronising it with the main game engine may be tricky. Otherwise I'm not sure where all the CPU time is going, profiling reveals nothing astounding, it's just too much data moving from main RAM to VRAM, except that doesn't affect frame rate during the into... you may notice.
I've added many useful comments and labels. I wish I could share them with you, but right now they are very specific to my favourite version of Olly (2.00 Release is out, but like Beta 2.00k it doesn't recognise as many APIs by name as Beta 2.00j) and also by the exact location, and name of my exe file on my system, so until I can make a .UDD fixer for 2.00j UDD files they will be kind of useless to you.
They are speeding my understanding of various crucial bits of code however.
When I get to Translation (probably V5 if someone doesn't volunteer to help, I can merge your efforts with mine and will give credit.) I will probably externalise language files, so the client can work in Brazilian or Chinese if the user / Server Op desires.
Because I know that some server Ops don't like to have players using a UI in other languages I will ensure these can easily be custom encrypted. (Suggestions and protests are welcome.)
Anything else I've forgotten?
- Release V3 when I'm happy that Window functions and AR compensation is "satisfactory" (ie not necessarily perfect, but basically doesn't produce any major glitches.)
- Hotly follow with updated version of the Config tool to allow, at least, to turn off the Windows Cursor, preferably encryption Keys and Port settings as well.
- Fix as many style guide breakers as possibleNo HKLM reading and writing.
No writing user configuration, screenshots and Clan images in the programs folder or a sub-folders of that, but keeping everything user specific in the users profile
Add a security and compliance manifest and Version block to the resource section. Preferably check the Resource Version against the Version Checksum internally, and use it in the Window Title.
This may all require me to identify the OS the game is running on, to suit XPs default "%UserProfile%\My Documents\My Games" location vs. Vista / Se7ens defaul "%UserProfile%\Games" standard. But this is not a problem, as the OS version number is checked before WinMain, I just need to store useful bits of it and use them. I don't think there is an NT Namespace Oject which can be queried in order to find the DOS alias for these locations as there is for the Scheduled Tasks, Recycle Bin, My Documents, My Pictures, My Music and My Videos folders.
If you know better please tell me.
- Apply major consolidation of configurations "Hotuk.ini", "Shortcut.ini", "ptreg.rxg", "lData.bmp", System Registry etc. Anglicizing them and hopefully implementing either Registry only or compliant .ini / .xml format. (Possibly implementing both, and allowing you to configure which you would like via the config program.)
- Implement custom ADMIN string for whatever field replaces the ADMIN string in Hotuk.ini and obscure it in the client so even if you keep it in your client people are going to have to guess what the right command is.
- Implement disabling and removal of ADMIN settings and Window Mode options from the client in the Config too completely for before you release to players.This will involve actual removal of parsing "/:" and "~/:" commands as well as just not looking for the settings in the file, and removing the code they would call if they where parsed.
This will make your client more secure and should allow you to compress it better, even if I don't re-order the routines to allow them to just be removed from the end of the .text section.
- Optionally ensure that your game client is launched by your launcher, in a method that is difficult to replicate.uPT and RPT do this, but their method is (was, last time I looked) simple to replicate.
Yes, there should be an update to the config program to allow you to customise internal Clan etc. URLs and apply a fixed internal and encoded IP that doesn't rely on external files which client thieves can fiddle with.
Intermittently I'm also looking at supporting MP3 / OGG streaming for sound and using those zip functions on loading textures, maps, inx, sin etc. They are coded strangely however, and their method of operation is easier to patch with API overrides than to code directly in the client... that is not an acceptable solution IMHO.
Please feel free to comment, add suggestions or protest against any of these changes. I don't plan on taking down the V2 release, so you will always be free to compare the two and manually roll back various changes I make as I develop... if you have the skills to do that.
Some of them are quite a radical break from the norm, I accept that. I know Gregoo would rather keep the number of options for resolutions low, but I'm keen to be as inclusive as possible. IMHO, if you want to limit the users choice, you do that from the Launcher, not the client.
Okay... Pre-Release Candidate, just to prove that it can be done and give people and idea how it works.
KPT1977Butchered RC3a Beta
- User profile registry, not machine profile registry.
- Fixed window with correct size and no extra imports. (Method 1)
- Faster initial startup.
- Slightly more code bummed than the RC2 but still not complete.
- Code shifted.
- Enabled OS pointer in Window mode. (I'll make that optional if I can't replace the "soft pointer", but it proves correct Window size.)
- Any Aspect Ratio code (so you can steal that code for other clients... if you don't need me to make a tutorial in order to find my code.)Set the red values to any width and height you want your display to be. In a Window it really doesn't matter, (though any height less than 512 is a problem as the login button falls off the bottom of the screen) in full screen, your monitor will switch to the closest mode it has which can contain that resolution. Or (as far as I can tell) the largest display it can support, if the resolution you set is beyond the capabilities of your hardware.Code://*Observer Mode //*관찰자모드 // Screen Mode // 서버모드 = Server // 창모드 = Window // 전체화면 = Full *화면모드 창모드 // Screen Resolution *화면해상도 1024 768 //Admin mode (GMs and Debuggers) (왕초보가이드) 포장단체주문환영 /0
Please test this client out, and report any issues. I keep asking for feedback, but only get thanks. XD
I said "Method 1" in brackets for the correct window size "feature" because although I'm pleased that it does indeed work, it is achieved via "bad coding practice". Gregoorys' method does indeed follow the "Text Book" example, but there are other ways... the method I used that I'm calling "Method 1" involves creating the window, comparing it's client area RECT with the desired one, and then re-creating the window with width and height increased by the difference between what we want and what we get.
I've seen this method used in other games, but to do it properly, one should really "delete" the original Window structure created... we never actually open or display it anyway. Now, when I was thinking about it, I was silly enough to assume that that API would already be there, as you are supposed to delete any window structures you created before you quit your application, but PT doesn't bother. (Quelle surprise)
I have another method in mind which uses the "System Metrics" functions which are used in PT, for absolutely no good reason at all. In fact, ware they where used in 1977, I have removed. What they did was check the full size of the desktop in FullScreen mode, and then either ignore it utterly, or open the display at that resolution, and then switch to what-ever is the correct resolution a moment later. Without this code, the screen doesn't go black moments before the YD-Online splash. You may even see that splash in the top left of your desktop for a moment before full screen kicks in.
Anyway... Tell me what you think of the client, and the way it's developing. Is it the sort of thing you would want your players to use (after you've tweaked it)? I'm hoping this can be used by people to replace their SGPT (QuantumFusion) based clients which are now way too old, so what else (aside from translation) do you have in those clients that this misses? Tell me about speed, (real or perceived), time out messages, DC4? (I know QF did a lot with that, but I've never encountered it whether I use DC4 fix or not) I only have 1 set of hardware to test it on (at the moment) so how does it fare on different CPUs or GPUs? (there is code which seems to treat certain nVidia chips as "special needs") Do you have missing resources? (AssaLoading Error) How does your Clan or SoD system work with it? (after you fix the URL strings) etc. etc. etc.
Okay... 3b Beta is ready.
KPT1977Butchered RC3b Beta
I gave some details on how I implemented the fixed, correct size window in the 3a beta, so I'll do the same here.
You need to know some constants for the GetSystemMetrics() API so:-
- SM_CXFIXEDFRAME = 7
- SM_CYCAPTION =4
- SM_CYFIXEDFRAME = 8
So GetSystemMetrics(SM_CXFIXEDFRAME)*2 = additional width required when opening the window, and (GetSystemMetrics(SM_CYFIXEDFRAME)*2)+GetSystemMetrics(SM_CYCAPTION) = the additional height required... I hope.
That only applies because I have changed the window from sizeable to fixed... although the border sizes are identical on my system anyway. You would need to use different constants if you want your Window to be able to be resizeable while running the game.
I have made done an awful lot of labelling around this area of code in Olly, but you can find the memory addresses, but I'll show you the code:-Remaining constants, 80CA0808h & 90000008h are binary ORed together ( || in C) the first is the "style" attributes for Window Mode (the bit I changed to stop the window being sizeable) and the second being the attributes for Full Screen. 80000000h just means "system default" for the X and Y locations. It's passed with PUSH 80000000 in the original code, but ECX isn't used, and is destroyed by the CALL to CreateWindowExA() and mov ECX,80000000 is the same size as push ECX,80000000 (5 bytes) where push ECX only takes 1 byte and is a register to memory operation rather than a memory operation which saves a pull from main memory, up through level 2 to level 1 caches and into the ALU before pushing it back out again. Cost 1 byte, saving 5, costing 1 cycle and saving an indeterminate number of CPU wait states from the DRAM. (Quite possibly none if your level 1 cache is in good working order, but WTH I saved you 5 bytes in that too. XD)Code:mov eax,[bWindowModeCpy] cmp eax,ebx je short .FullScreen push 7 ; Index = SM_CXDLGFRAME call [<&USER32.GetSystemMetrics>] ; USER32.GetSystemMetrics shl eax,1 add esi,eax push 8 ; Index = SM_CYDLGFRAME call [<&USER32.GetSystemMetrics>] ; USER32.GetSystemMetrics shl eax,1 mov ebx,eax push 4 ; Index = SM_CYCAPTION call [<&USER32.GetSystemMetrics>] ; USER32.GetSystemMetrics add eax,ebx add ebp,eax xor ebx,ebx mov eax,80CA0808h jmp short .CreateWindow .FullScreen mov eax,90000008h .CreateWindow mov ecx,80000000h push ebx ; lParam => NULL push edi ; hInst push ebx ; hMenu => NULL push ebx ; hParent => NULL push ebp ; Height push esi ; Width push ecx ; Y => CW_USEDEFAULT push ecx ; X => CW_USEDEFAULT push eax ; Style mov eax,[szpWindowTitle] ; ASCII "KPT v1.97.7 Butchered RC3." push eax ; WindowName => [5F9A30] = "KPT v1.97.7 Butchered RC3b. - Beta" push eax ; ClassName => [5F9A30] = "KPT v1.97.7 Butchered RC3b. - Beta" push ebx ; ExtStyle => 0 mov esi,[<&USER32.CreateWindowExA>] ; call esi ; USER32.CreateWindowExA mov [hWndMain],eax
I'll mention some other code which has become quite heavily "humanized" with my labels, but is still interesting. Just after the timers is stored and before the Window Class is built (given and icon and a default cursor shape and so on) you get this bit of code:-Now, that's kinda where the original registers get the values that they pass to the window. The reason they are loaded, from one memory location and uploaded back to another memory location (which I've referred to by adding "Cpy" to the end of the label) is because all the running game functions referre to the copy, and all the initializing code (Reading the Registry, ptreg.rgx, hotuk.ini and ldata.bmp) write to the non-Cpy versions. Interestingly, if you don't have any of those configurations, the default resolution is (indeed) 640 x 480 x 16, exactly as I remembered the PT Beta using when I started playing. (I promise I didn't fix that, you can check it with an official download if you like)Code:mov eax,[dwDisplayBPP] mov esi,[dwDisplayWidth] mov ebp,[dwDisplayHeight] mov [dwDisplayBPPcpy],eax mov eax,[bWindowMode] mov [dwDisplayWidthCpy],esi mov [dwDisplayHeightCpy],ebp mov [bWindowModeCpy],eax
Anyway. The dwDisplayWidthCpy and dwDisplayHeightCpy memory locations are the basis of function I called subRendFrame which updates ever frame in game.
I would surmise from that, that if you re-enable window resizing and read the size of the window before the internal workings of each subRendFrame, you could maintain correct resolution rendering (without the screen being stretched or squashed) even with the window being a fixed size... but you'd really want to store those SystemMetrics values, because you'd either want to use those to subtract from "GetWindowArea()" or use "GetClientArea()"... I have a feeling they are both already imported.
Here's what I can't do, and can't test. Does it work right on any OS... There is a new SystemMetric for the "BorderPadding" which was introduced with Vista, and is still used in Win7, but that call is documented to fail on XP.
I'm using Vista but my setup has BorderPadding set to 0 because I hate those "fat" borders, and the BorderSize that's been there since Windows 2 seems quite sufficient control to me. But that's possibly why sizeable and non-sizeable borders are the same size on my system.
I doubt it, they seemed to be on XP and 2K as well, but they where smaller on Windows 3.x (a non-sizeable window had a 1 pixel border and a sizeable one had 2 + WindowBorder pixels) and I think that continues on 9x and maybe even 2K for any Window that doesn't have 3D controls enabled... which is basically nothing, because that would put you back to the old Windows 3.1 look with a different top border. :s
So I need to know, if you run XP, or 7 or 9x/ME do the window border APIs still give you the correct size Window?
And now you have both betas, which method would you rather see for the final Butchered RC3? Or is fixed window size too annoying, and you'd like me to work the idea of changing the display rendering to render to the size of the client area instead of making sure the client area fits the defined screen size?
If people are having problems with getting the hotuk.ini to work, try this one instead; because the korean one doesn't work on western OSs....
Code://*MODE WINDOW *°üÂûÀÚ¸ðµå // Screen Mode // ¼¹ö¸ðµå = Server // Ã¢¸ðµå = Window // ÀüÃ¼È¸é = Full *È¸é¸ðµå Ã¢¸ðµå // Screen Resolution *È¸éÇØ»óµµ 1024 768 //Admin mode (GMs and Debuggers) (¿ÕÃÊº¸°¡ÀÌµå) Æ÷Àå´ÜÃ¼ÁÖ¹®È¯¿µ /0
We will miss you ♥
Gah!!!! Do not post Hotuk.ini in non-Korean! Why do you do that Filterheadz? Surely you know by now that it annoys the hell out of me. >.<
If you use the one I posted, in your Korean ANSI (EUC-KR or CP949) text editor, it will work. If you use the one Filter just posted in any ANSI text editor, and don't live in the same language zone as him, it will fail. In my notepad, it gets turned into UTF16LE which is worse than it being ANSI in the wrong code page.
If you are having difficulty with the one I posted, do not; under any circumstance try the one Filter posted, but instead, extract the attached RAR, which is the one I posted in the correct 8-bit ANSI code page, even if your text editor isn't intelligent enough to detect that.
It may (in a very few cases) look just like Filters if use the exact same language code page he does and you are dumb enough to open it in a crappy editor like Notepad. >.<
</rant> Happy again.
Thanks for pointing out that some people will need a binary file as a base to work from Filter.
i like it!
Cheers 124641469hh, but like "what" exactly?
I'm actually hoping for feedback to develop further rather than approval or praise TBH. Hope that's not too hard for people to cope with.
Any response is better than none however. At least I know some people are looking at this project.
I know it's difficult to find time with keeping hackers down and players happy... but I'm offering free developments here, if you tell me what your priorities, hopes and fears are you will be happier with the "quality" of the free development you get from me.
I'm sure the same is true of the server-side developments from Vormav and JayMoko. (Gratz and 'big-ups' to them... is that showing my age again? XD)
Just telling you this because that's what I've been experiencing.
Cheers & Thanks you "ʘﺎɗ ҨᶖԎ"! ^_^
Last edited by Filterheadz; 11-07-10 at 10:38 AM. Reason: ʝʮʂʈ ȿѻɱɞ ʘﺎɗ ҨᶖԎ
We will miss you ♥
My English is not very good
I can only say to you, you are great
No other meaning……
Okay... that's kind of a bug report for documentation, but I can't reproduce at my end. Doing exactly the same thing works fine.
I'll explain my method.
Open MadEdit (or other decent internationl ANSI Text Editor)... new empty file appears.
Change code page to CP 949 or EUC-KR or Windows-Korean (different editors list the CP under a different name)
Copy and paste Korean Hotuk.ini into text editor (only after correct CP has been choosen for it)
Save as "Hotuk.ini" in the Game installation folder.
There is also the possibility to past the Korean into a Unicode (UTF-8, UTF-16LE or UTF-16BE) document, and then "convert encoding type" to EUC-KR / CP 949 / Windows-Korean... MadEdit can do this, but there are other tools too.
I've tested your "KPT1977NoXTrap3b" with this "hotuk.ini" (and with KPT1977 Server file from JayMoko):
And :Code://*Observer Mode //*관찰자모드 // Screen Mode // 서버모드 = Server // 창모드 = Window // 전체화면 = Full *화면모드 전체화면 // Screen Resolution *화면해상도 1360 768 //Admin mode (GMs and Debuggers) (왕초보가이드) 포장단체주문환영 /0
+ Loading Bar gone (no DWM buggy)
+ Windows Cursor appeared with game cursor at the same time
+ Game resolution still 1024 x 768 (tried with Window Mode, same result)
+ After 10s when game UI shown, I got some Server Message then all NPC and Mobs gone with the wind :)
Green : Great, I like it!
Yellow : I don't like it
Red : Bug
Last edited by trungnt88; 12-07-10 at 08:00 PM.
Thanks for your feedback Wormy.
Another alternative you may like to try is to Hex patch @ file offset 000BE7D0h the byte A1 to C3, which will bypass the soft rendering of the game cursor and gain the intended performance increase.
Ultimately, that routine needs to be replaced with Windows APIs to set the Windows cursor to one defined in a .cur or .ani file (or resource in the game.exe) similar to the TGAs in "sinimage\cursors", but that is for a later release, and I'm still open to suggestions.
Personally, I find it more user friendly to have the mouse pointer respond instantly, rather than at the next game frame update... but it does need to "change shape" for Attack, Grab etc. and seeing both cursors (Windows pointer and "Soft" pointer) is TMI XD
My guess is that you have the linein ptreg.rgx... just remove it.Code:"ScreenSize" "1"
Also, please compare the results to the RC3a method, which should achieve the same thing in a completely different (and actually more code heavy) way. I don't mind using more complex code if it produces better results. If you (all of you) find less issues with RC3a, then the RC3a method will end up in Beta v3... for the moment I'm getting a happier vibe from RC3b, but 1 person is not a wide enough test bed.
Your Hotuk.ini looks good. Mine is currently set to "*화면해상도 1152 648" and works at exactly that.
My ptreg.rgx:-I've now tested with various "Vista" themes and border sizes with and without DWM and the fixed resolution is always "correct", I still can't test on XP though.Code:"FullMode" "Off" "Version" "3124Ä" "Graphic" "4" "Network" "1" "ColorBPP" "32" "MotionBlur" "false" "CameraSight" "ON" "RainMode" "2" "Sound" "Off" "CameraInvert" "true" "MicOption" "OFF" "ServerName" "Personal-PT" "Server1" "127.0.0.1" "Server2" "127.0.0.1" "Server3" "127.0.0.1" "Account" " "
Please let me know "what setting" is overriding hotuk.ini... I would appreciate that very much.
You may also like to change the version number, and / or check your 1977.dat in server side "funcbox" folder is a correct match for the game.I'm sure you are already aware that this happens if you have Admin mode enabled in the client hotuk.ini and log in to an account, or from an IP which is not allowed Admin / Debug mode in the server hotuk.ini... But other "client checksum" failures and such can also cause the client to disconnect soon after log in.Again, please let me know if any of these suggestions help, or if you find something different is causing the problem, as I have not experienced it.
I'm still running (usually) against basic ET 2.2, but I would hope that this client would be a "better match" for JayMokos server than most of the old (187x based) ones. (once translated and so on)
Once again; thank you very much for your feedback, and testing. It is much appreciated. Problems don't necessarily show up when used on only one server and one client machine.
--- EDIT ---
I presume you are using it with your ET 3F AIO pack which looks awesome. I've seen that my client is mentioned in your thread, and they would (again) seem a good match.
If you want to include Butchered clients in your packs updates, you are more than welcome to do so, and I'm happy to work with you with any issues that come up.
(I can feel a new RZ open development team brewing )