Printable View
I was trying to make JPT Server (server4096.exe) usable but it have strange bug that I can not solve. Whey player see another player he will DC (서버와의 연결이 끊어 졌습니다) with error saved in game.log (client)
This error does not exist on -KPT-Endless-Tower-Update-V2.2.exeCode:1-5 (20:35:29) - Mesh Pattern Error [ playerName ] ( )
so maybe anyone know what was fixed?
Hmm, I've heard people say that about my PPT server. As you probably know, that was my own modification, directly from Operz release of jPT 4096... but I didn't experience it when I played it with my wife and friends during it's development.
Are you seeing 6x or 8x characters? They may not be supported in the old jPT release. It may not know about the tmABCD file information for 6x - 8x gear, and I know we didn't play beyond level 60, because as far as *I* was concerned, I had no intention of PPT supporting that.
(Deliberately)Spoiler:
Both characters are naked and lvl 1.
I am using same PC when I log both accounts.
Its "must" be a server bug because on same folder, same environment just different .exe's jPT server have this bug and -KPT-Endless-Tower-Update-V2.2.exe not.
But because there is so much mess in -KPT-Endless-Tower-Update-V2.2.exe I can't tell what was fixed.
Also error is a bit strange, it should look more like this:
1-5 (20:35:29) - Mesh Pattern Error [ playerName ] ( some.inf )
and I would know what to fix :/
@bobsobol
If you have some time can you try login on same PC to server4096.exe with two different accounts? Or/and upload me your server4096.exe?
PS. I am working on new server (thats why I need 'clean' server). Fields are working from dll now and I am moving whole function to C++ so adding new map will not 'waste space' and it will be quite easy. I hope that PT will understand it without 'extra assembling'.
Anyway I need to fix this stupid bug on server because I can't make my dev env without it :/
I understand your aim, and your choice of server. I've started similar myself, hoping to move all the networking to DLL, so the encoding / protocols can be switched out at will. Even from TCP to UDP or DirectPlay if desired, or even NamedPipes for LAN only play.
I'll not be back home on my own network for a day or two, but PPT contains the server I used... but as I say, some people have reported similar problems with it.
It must be something small that make that error in server.exe (maybe even not updated effects in server.exe) but for now my field code compile in MSVS8 and GCC (yay!). It still have long way to be usable. I see one weak point in this, because this is PT function that interact with other values in PT I have to use my game.exe memory addresses so porting it to other .exe will not be so fast. Well can't complain until I will make compiled code full working with PT ;)
PS. come one ppl don't be shy I am sure that someone knows how to fix this bug in server.exe =P
I'm glad you have your C source standard enough to compile on GCC and VC. That's usually half my battle. VS Solutions won't compile in GCC, and GCC make files are useless to VC. I managed to get my Socket handler to work by starting the project on VC6 (which can export a nmake file from the project) then adapting that to a regular make file... but I'm still in issues with differences between the GNU Win32 header files and the Microsoft ones. XD
Keep the addresses in a single header file as constants. (or enumerations) Refer to them everywhere else in the code by the Name, not the address. Then when you want to build it for a different Exe, you know what file to fix and only have to fix one line per address. You can also keep a catalogue of const lines separated by :-So that you only need to pass a different option via the command line, make file or project management to switch the target client. :wink:Code:#if_CLIENT == 1873{
const int* lpBlah = 0xB0B50B01;
const int* lpPoohBear = 0x9004BEA9;}
#elseif __CLIENT == 1987{
const int* lpBlah = 0xEGBDFEGB;
const int* lpPoohBear = 0x00000000;} // Fatal Exception !!! Oh noes!
#endif
As to who knows how to solve this bug, it was probably solved when the first KPT server was released, and since no Guide or Tutorial on how to convert jPT to KPT was ever written, the only person who knows is the one who made that conversion back in 2005 / 2006. Most of whom are utterly disinterested in PT servers these days.
I recommend you find the earliest KPT server conversion you can, check that it doesn't have this "bug" (which is actually an incomparability) and compare the GFantasy patches in it to the original. I did this against the ET2 server, with regard to protocols / encryptions, but haven't looked at the other things. (Aging and mixtures, maps etc.)
If you find an old jPT client, it works flawlessly on jPT4096. If you connect old EPT clients, they kind of work after you just change the ports and stuff. If you try to connect a modern client, it just doesn't work at all. You have to fix the protocols / encryptions, the item lists, the map lists and the ports.
Looking at the source we are building up, there could well be a change in the packet opcodes from the old server to modern clients. There should certainly be packets of larger sizes, because the packet sizes are fixed in all PT clients and servers, and the original sizes didn't support some of the massive levels of Experience and such like which current PT versions use. As we saw, the old preAOR EPT client only stored 32bit UINTs for the experience:level table... where our current clients and servers store a 64bit signed value. o.O
Still long way to go, now C++ is mixed with __asm, but I am not sure if
__asm MOV DWORD PTR DS:[0x007AF29C],512 is valid, usually its ok but sometimes compiler complain about it and I have some in between hex that debuggers see like "db 3Eh". Well PT complain a lot about small changes in functions.
For now mix with __asm should speed up working code creation but I not sure how to fix error like:
error C2440: '=' : cannot convert from 'sub_431B30::C *const ' to 'LPCSTR'
so instead of doing it correct way:
lpString2 = this; //LPCSTR lpString2
i do:
__asm mov esi, ecx
and I get same code
I hate __thiscall functions but they are only way to produce same code I see in debugger.
This game is getting older and peoples from "past" are not longer around so maybe you have some old KPT server somewhere on your HDD? =PQuote:
I recommend you find the earliest KPT server conversion you can, check that it doesn't have this "bug" (which is actually an incomparability) and compare the GFantasy patches in it to the original. I did this against the ET2 server, with regard to protocols / encryptions, but haven't looked at the other things. (Aging and mixtures, maps etc.)
Of course I do.
KPT Server Clean was uploaded to RZ long long ago... but I can't remember who posted. (sorry)
It would seem credit for this server should (at least in part) go to our good friends at FroggPT, though I'm sure it's far far removed from their current "state of play".
--- EDIT ---
Beware inline assembler if you are looking for cross compiler comparability.
Remember, VC compiles to MASM source, and CC / GCC compile to GAS source. MASM / GAS will then compile (possibly from an in-memory stream) to a .bin file, which "link" will turn into a PE or ELF. (or COFF, or NROFF or whatever)
Anything in standard C __asm is ignored by the compiler (except it is wrapped in basic stack frame isolation code) and passed directly to the assembler. But MASM and GAS syntax are not compatible.
Additionally, depending on your target platform, that stack frame isolation will mean that some registers are off bounds to you. Some you must not alter or must store in your local frame, and restore before returning to C code. Others you can use, but will be destroyed as part of the "un-framing" process.
Most importantly, you cannot rely on anything that your assembler expects to find in the stack frame, because it has been allocated it's very own, personal frame, isolated from the rest of the code.
Hi bobsobol and vormav's ^^. This didn't happen with the Server but the same scenario happened with a 1871 Game Client i was using.
Excuse if this is border line on one week but i had that same problem in a kpt client 1871 that i had hexed somehow wrong in the game client ip location. What i did was set all the values to 0 in the ip numbers then i added the ip numbers. Before i just wrote over the ip and the client did connect after some trial and error but i had that dc problem with another character coming into contact with me. Anyhow if someone came on to my server and came to where i was they would dc. So for me it was an editing hex problem in my ip that caused this. I don't think this is what happened to you vormav because you are an experienced dev and have helped me out alot and you are working on the server and this problem i had was in the game client but maybe this might help someone else out with this problem because they seem simalar with the outcome. But it did do the same things you discribed but the problem was in my Game CLient. Anyhow gentlemen nice chatting with you and cya later mates.
Wildman:)
Sounds like it's another jPT vs. KPT packet format difference then.
I suspect that Vormav is trying to connect old (Pre-AOR) EPT client? Though I though he was doing that with the EPT 64 server, so I could be wrong.
In my experience EPT sits somewhere between KPT & JPT test version in many respects. KPT Test and Release are pretty much the same in terms of packets, but the release client used to be better secured. Now it seems the test client is being secured more too.
It may be that the server is mis-reading client IP from the packets though... Thanks for the info Wildman. :wink:
In my case ports where a problem but your hint force me to check it so thank you for your hint.Quote:
Originally Posted by gkirby
Fixing ports fixed two things for me:
- players can see each others without DC
- server display correct number of users!
I believe that -KPT-Endless-Tower-Update-V2.2.exe added some fix to users number bug and that was unnecessary, all you have to do is change all 10006 ports to 10009 (for KPT)!
When I find time I will post (I need to check it first, because you should not change all 1627 hex) exactly what ports (there are only 15 values in server) need to be change, for now I changed all hex 1627 to 1927 and that leading me to correct players number on my server and no bug when players see each others.
With JPTServer. It will have error "Mesh".... I have fix it. I use disable function it.
Wut? woOt? wat?Quote:
Originally Posted by zaharavn
--UPDATE--
Do this with hex editor (server side):
1627 is port 10006 in JPT server so if you are connecting with KPT client change it to 1927 port 10009.Code:offset in value value
hex editor before after
change change
000012C2: 16 19
00035826: 16 19
00035871: 16 19
000358B4: 16 19
00035CE8: 16 19
0016B461: 16 19
00174732: 16 19
0017E9F4: 16 19
0017EA03: 16 19
00185E00: 16 19
This fix for me DC bug when player see other player and I have correct users count on server "Users :", users are not counted right away after login... it take around one minute not long but I think this is how it should work.
PS. From what I see JPT server is checking how many players it have online every ~1 minute?
So "not right away count" is correct. Maybe its connected somehow to "1Min." msg? =P
This fix my problem so thanks again everyone.
Not wrong, but inaccurate. Please let me clarify what I have seen.Quote:
Originally Posted by Vormav
From my attempt to make it run from a Console, rather than a GUI, I can tell you that it increments how many users are on-line the moment a user logs in, and decrements that value when a user thread is terminated. (which happens if you log out, DC, time out etc)
However, the textbox control which you see in the GUI is just that... it's like a little notepad document. Every minuet or so it's content is deleted, the value of the menu option which equates to what information should be displayed is checked, and a routine (which one depends on the last menu option selected) produces a multi-line string which that control is then filled with.
The routine which checks the last menu option selected and updates the display is on a callback timer. However, it is also run every time you select a different information display.
So if you want to force the display to update, you need only change what info is displayed, and change it back. (cumbersome, but do-able)
So it knows... it just doesn't tell you. All the details in that display change at the same time, but each individual value is constantly being updated internally. :wink: