Cevaplandı Client x64, speedtree 4.1, audiolib, HLSL shader, DX9, python 2.7, granny2_x64

[Loki70]

ROHAN2 WORLD 1-120 TR TİPİ OFFICIAL YOHARA, BALATHOR VE AMON! 80. GÜNÜNDE! +10.000 ONLİNE! HİLE VE BOT %100 ENGELLİ HEMEN TIKLA!

Hello everyone,

I've just migrated my client to x64. This included recompiling all the libraries like Python, Granny, and SpeedTree, as well as replacing the Miles audio system (which wasn't x64 compatible) with audiolib. I've also implemented memory management via mimalloc and coded the HLSL shader management (vertex and pixel). I can successfully log in-game without any issues on that front.

I did have to add the following to userinterface.cpp:

C++

extern "C" {
// Renaming internal functions to prevent the compiler from getting mixed up
int wrapper_fileno(FILE* f) { return _fileno(f); }
int wrapper_ferror(FILE* f) { return ferror(f); }
void wrapper_clearerr(FILE* f) { clearerr(f); }

// Binding the pointers expected by libconfig++ to our working functions
int(__cdecl* __imp__fileno)(FILE*) = wrapper_fileno;
int(__cdecl* __imp__ferror)(FILE*) = wrapper_ferror;
void(__cdecl* __imp__clearerr)(FILE*) = wrapper_clearerr;
}

However, when closing the client in-game, I get the following errors:

Plaintext

close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

---

A Runecaster's Insight​

Those specific Python errors at the end of your battle usually mean the C++ client is destroying the Python interpreter (Py_Finalize()) before all Python objects or threads have finished their tasks. The system is trying to write an error to the console or flush an open file, but the great tree of sys has already been cut down.

Would you like me to analyze your client's shutdown sequence or C++ Python wrappers to help you vanquish this destruction-order beast?

 

[ıTEOREMı]

Hello bro! Thank you so much for the code and for taking the time to help me out.

I tested your function, but unfortunately, it didn't fix the issue on my end. The error was still showing up in the syserr. However, I managed to finally solve it by completely redirecting the standard error output right before the client destroys the UI and the Python environment.




I added these two lines inside bool Main(HINSTANCE hInstance, LPSTR lpCmdLine), just before app->Clear();:

C++

fflush(stderr);
freopen("nul", "w", stderr);

This successfully bypassed the hardcoded error in the Python DLL from reaching the text file, and I don't have the problem anymore! Thanks again for your support!

Hello bro! Thank you so much for the code and for taking the time to help me out.

I tested your function, but unfortunately, it didn't fix the issue on my end. The error was still showing up in the syserr. However, I managed to finally solve it by completely redirecting the standard error output right before the client destroys the UI and the Python environment.

I added these two lines inside bool Main(HINSTANCE hInstance, LPSTR lpCmdLine), just before app->Clear();:

C++

fflush(stderr);
freopen("nul", "w", stderr);

This successfully bypassed the hardcoded error in the Python DLL from reaching the text file, and I don't have the problem anymore! Thanks again for your support!

I'm very glad your problem was solved, brother. If there's anything else I can help with, I'll do my best. Have a good time on the forums.

 

[ıTEOREMı]

yokhu123 Sorun çözülmedi diyor musait vakitte tekrar bi bakarmısın rica etsem .​

Sorun çözülmüş.