xgamebase.dsp

[bog18dy]

Originally Posted by vileaz

Did you compile the source code?

The 2009 one? Yes I did, though the client has a crashing issue that I didn't have the time to debug, but the compilation itself was succesful.

[annoyinglyUgly]

Can you send the 2009 server/client source? All I want is the old acclaim UI. You don't know how many hours I wasted trying to make the 2008 client and server work. The old UI only works with the old data folder + an old exe file that loads the stuff. Problem is I cannot log in with old ninedragons dot exe's because of f*cking
1.) packet size error
2.) bad sequence error
3.) LMBC (Login Mode By Company)
4.) Size Mismatch

I can compile an old Login_srv dot exe and I can alter the source but I don't know how to tell the login server to f*cking let me log in with any temp acc/id pw... otherwise I'd need a valid account and password to log in with, which is impossible because I don't know how the old DB structure is. This is beyond frustrating. Also, this "test login" BS that was created by Indy is just a declared bool and that's it. It has no functionality. Trash-*** lame Indy21 programmers. Worst coders in this universe.

[madmerlin3009]

Originally Posted by bog18dy

Not even Martin's source is fully compilable. There is some 2013/2015 source out there I heard it's full, but that won't get shared for free lol.

there are 2 missing library headers for the client bogdy already posted a while back.But also i guess people forgot to realise that the .dsp file alters when you alter the full compile paramaters.Ie include headers.The .dsp will self generate , so each time triggers and conditions are sent to the complier and linker. defined user space are made as line scripts into that file. Your complile and link space, is pre generated on your first attempt.

errors mainly occur due to you not scoping you environmental parameters to the correct folders.

[Adek]

Originally Posted by madmerlin3009

there are 2 missing library headers for the client bogdy already posted a while back.But also i guess people forgot to realise that the .dsp file alters when you alter the full compile paramaters.Ie include headers.The .dsp will self generate , so each time triggers and conditions are sent to the complier and linker. Jesus dont you know about defined user space, in .net. Your complile and link space, is pre generated on your first attempt.

errors mainly occur due to you not scoping you environmental parameters to the correct folders. jesus!!!

Just to clarify a lot of fake info you gave - .dsp file is a "project" file containing the information about its structure. You can easily open it in Notepad and check what does it contain. Well, it was used in old versions of Visual Studio, now you may know it as a ".vcxproj" - that's basically the same, but in XML. Don't take me wrong, I'm not here to humiliate you - just wanted to mention some facts why this .dsp file may be important.

!ELSEIF  "$(CFG)" == "EODLoginServer - Win32 Debug"

# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 1
# PROP BASE Output_Dir "Debug"
# PROP BASE Intermediate_Dir "Debug"
# PROP BASE Target_Dir ""
# PROP Use_MFC 0
# PROP Use_Debug_Libraries 1
# PROP Output_Dir "Debug"
# PROP Intermediate_Dir "Debug"
# PROP Ignore_Export_Lib 0
# PROP Target_Dir ""
# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c
# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /D "_WIN32_DCOM" /FR /YX /FD /GZ /c
# ADD BASE RSC /l 0x412 /d "_DEBUG"
# ADD RSC /l 0x412 /d "_DEBUG"
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept
# ADD LINK32 winmm.lib ws2_32.lib Iphlpapi.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /out:"ExeFiles/NDLogin_D.exe" /pdbtype:sept
# SUBTRACT LINK32 /pdb:none

It also keeps the data such as configs for the compilation and linking processes. It includes the names of the static libraries (.lib), defines the appropriate SDK, sets the flags, etc.

Also, correct me if I'm wrong, but calling clean C++ a ".NET" is kinda... incorrect. It's true that C++/CLI is a part of .NET platform, but:

• it's an extension for "managed c++",
• it's not a 'valid' ISO C++.

While it is true you can "regenerate" .dsp file, it's rather dubious it'll be correct. You can just recursively add all of the files in the project as a "source item", but you still won't get any configuration back.

Originally Posted by annoyinglyUgly

Can you send the 2009 server/client source? All I want is the old acclaim UI. You don't know how many hours I wasted trying to make the 2008 client and server work. The old UI only works with the old data folder + an old exe file that loads the stuff. Problem is I cannot log in with old ninedragons dot exe's because of f*cking
1.) packet size error
2.) bad sequence error
3.) LMBC (Login Mode By Company)
4.) Size Mismatch

I can compile an old Login_srv dot exe and I can alter the source but I don't know how to tell the login server to f*cking let me log in with any temp acc/id pw... otherwise I'd need a valid account and password to log in with, which is impossible because I don't know how the old DB structure is. This is beyond frustrating. Also, this "test login" BS that was created by Indy is just a declared bool and that's it. It has no functionality. Trash-ass lame Indy21 programmers. Worst coders in this universe.

The most annoying part of dealing with it would be actually refactoring the code and analyzing it to get the valid structures. Even if you manage to deal with LS, you still would have an incompatible GS, and that one is a pain in the ass. Trust me on this one.

Well, if you're still going, your safest bet would be changing the COLE_DB_Executer::AcclaimLogin method - as long as you're not going to use the database. It's basically the dead-end street. You may consider analyzing the DS for the database structure. At least for the DB part. For the packet stuff, you are probably going to RE a bit to get the packets right. Both the ones sent by the client and the GS responses.

[madmerlin3009]

Originally Posted by adek1994

Just to clarify a lot of fake info you gave - .dsp file is a "project" file containing the information about its structure. You can easily open it in Notepad and check what does it contain. Well, it was used in old versions of Visual Studio, now you may know it as a ".vcxproj" - that's basically the same, but in XML. Don't take me wrong, I'm not here to humiliate you - just wanted to mention some facts why this .dsp file may be important.

!ELSEIF  "$(CFG)" == "EODLoginServer - Win32 Debug"

# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 1
# PROP BASE Output_Dir "Debug"
# PROP BASE Intermediate_Dir "Debug"
# PROP BASE Target_Dir ""
# PROP Use_MFC 0
# PROP Use_Debug_Libraries 1
# PROP Output_Dir "Debug"
# PROP Intermediate_Dir "Debug"
# PROP Ignore_Export_Lib 0
# PROP Target_Dir ""
# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c
# ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /D "_WIN32_DCOM" /FR /YX /FD /GZ /c
# ADD BASE RSC /l 0x412 /d "_DEBUG"
# ADD RSC /l 0x412 /d "_DEBUG"
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept
# ADD LINK32 winmm.lib ws2_32.lib Iphlpapi.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /out:"ExeFiles/NDLogin_D.exe" /pdbtype:sept
# SUBTRACT LINK32 /pdb:none

It also keeps the data such as configs for the compilation and linking processes. It includes the names of the static libraries (.lib), defines the appropriate SDK, sets the flags, etc.

Also, correct me if I'm wrong, but calling clean C++ a ".NET" is kinda... incorrect. It's true that C++/CLI is a part of .NET platform, but:

• it's an extension for "managed c++",
• it's not a 'valid' ISO C++.

While it is true you can "regenerate" .dsp file, it's rather dubious it'll be correct. You can just recursively add all of the files in the project as a "source item", but you still won't get any configuration back.

Thats what i love about intelisense. The Compiler will warn of old operands and state, alternative Psuedo reference. But it still compiles. I am sorry for not Using the correct references. As the old vs6 studio was non .net framework references.Luckily for alot of old school companies, who wish to migrate their applications, have a brilliant interface to work with

[bog18dy]

Originally Posted by annoyinglyUgly

Can you send the 2009 server/client source? All I want is the old acclaim UI. You don't know how many hours I wasted trying to make the 2008 client and server work. The old UI only works with the old data folder + an old exe file that loads the stuff. Problem is I cannot log in with old ninedragons dot exe's because of f*cking
1.) packet size error
2.) bad sequence error
3.) LMBC (Login Mode By Company)
4.) Size Mismatch

I can compile an old Login_srv dot exe and I can alter the source but I don't know how to tell the login server to f*cking let me log in with any temp acc/id pw... otherwise I'd need a valid account and password to log in with, which is impossible because I don't know how the old DB structure is. This is beyond frustrating. Also, this "test login" BS that was created by Indy is just a declared bool and that's it. It has no functionality. Trash-ass lame Indy21 programmers. Worst coders in this universe.

We discussed just today implementing the old UI on the 2012 client via RE, it'd take a bit of time, but it's doable, I get what you're saying, we do like the old UI too.

After thinking a bit, I start to believe the old sources are not of interest to us unless there will be a full client/server leak of the 2009 files or someone with enough time to debug my 2009 client source (the environment is nicely set).

We'll take a shot at the emu and 2012 + RE.

TL;DR : When I decide that we have fully given up on 2009, I will share my virtual machine with the environment for 2009 client.

You need to disable UI_RENEWAL_KUKURI or smt along those lines on the 2009 client and connect it to the leake KR internal binaries that you have.

P.S. The errors you're getting are because you're connecting anything but the KR internal test client to the KR internal test server, also you're likely mismatching the version if you're trying to connect with KR client.

[12sky2Server]

not 2010 client source? i have client source,,,but dont have server source..

[vileaz]

Originally Posted by bog18dy

The 2009 one? Yes I did, though the client has a crashing issue that I didn't have the time to debug, but the compilation itself was succesful.

Which source code do you use? can share it
I am using source code that is downloaded from a Chinese site. Can you tell me what I will be able to do with that source code?

Originally Posted by bog18dy

After thinking a bit, I start to believe the old sources are not of interest to us unless there will be a full client/server leak of the 2009 files or someone with enough time to debug my 2009 client source (the environment is nicely set).

i'm conducting debugging, I will send it to you after I finish