Beaverhunter Report post Posted April 8, 2007 (edited) Oki, so of course when I just got the EYE_CANDY to work... I get other problems. 1. Currently for about 24-48 hours I haven't been able to connect for a new CVS update, it says some kind of Socket error occurs. I also tried to ping the server and I get that the endcomputer is not reachable, no time out or such... What is this about? And no, it cannot be firewall or such.. I allready checked + then it would be Time out. I haven't changed anything, it just started to do this socket error some day ago. 1. Fixed, a 3rd party program got auto updated and started to block that specific IP under the name GMD Fokus, really weird that I didn't spot that one before, also weird that it was added to blacklist... 2. When finally getting EYE_CANDY to work I also recently have had problems with Debug mode, when I compile it works fine but when I try to run the Debug version client I get this: "R6034 An application has made and attempt to load the C runtime library without using a manifest. This is an unsupported way to load Visual C++ DLLs. You need to modify your application to build with a manifest. For more information see the "Visual C++ Libraries as Shared Side-by-Side Assemblies" topic in the product documentation. (Press Retry to debug the application)" Also recently I have had to put msvcr80d.dll and msvcp80d.dll in the EL folder to get "further" in the client loading, but I get to the message above after adding these. What has changed recently that makes the client require these files? Is it about the windows.h ? Have I done something? Please help! Without debugging possibility I cannot simply take part in testing code or finding bugs. Update: I now get alittle further, when I expect the client to just say "Test Server!" I instead get an Assertion error. "Debug Assertion Failed! Program: c:\...\Eternal Lands Dev\elc.exe File: isctype.c Line: 56 Expression: (unsigned)(c+1) <= 256 For more information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts. (Please Retry to debug the application)" This is not EL code but inside the msvcr80d.dll: #if defined (_DEBUG) extern "C" int __cdecl _chvalidator( int c, int mask ) { _ASSERTE((unsigned)(c + 1) <= 256); return _chvalidator_l(NULL, c, mask); } Should I try to compile with out the _DEBUG? Or would that ruin the whole debug thing, not being able to follow call stacks and such? Or how can I fix assert errors like this? 3. I currently use these preprocessors: _DEBUG ELC EYE_CANDY WINDOW_CHAT NEW_WEATHER NEW_FRUSTUM BUG_FIX_3D_OBJECTS_MIN_MAX NEW_TEX OPTIONS_I18N NEW_ACTOR_ANIMATION AUTO_UPDATE COUNTERS SFX FONTS_FIX COMMENT_BUFFER AFK_FIX CUSTOM_LOOK CUSTOM_UPDATE SIMPLE_LOD USE_ACTOR_DEFAULTS NOTEPAD USE_INLINE ZLIB PNG_SCREENSHOT MINIMAP And these linker inputs: shell32.lib SDL.lib opengl32.lib libxml2.lib user32.lib SDL_net.lib kernel32.lib ALut.lib OpenAL32.lib iconv.lib Cal3d.lib glu32.lib vorbisfile.lib SDL_image.lib zlib.lib libpng.lib Can I remove any of them? Am I missing something? 4. What does the define "Wall" do? 5. Sorry for bringing up new problems to an allready tight schedule. Edited April 8, 2007 by Beaverhunter Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 9, 2007 "R6034 An application has made and attempt to load the C runtime library without using a manifest. This is an unsupported way to load Visual C++ DLLs. You need to modify your application to build with a manifest. For more information see the "Visual C++ Libraries as Shared Side-by-Side Assemblies" topic in the product documentation. (Press Retry to debug the application)" Also recently I have had to put msvcr80d.dll and msvcp80d.dll in the EL folder to get "further" in the client loading, but I get to the message above after adding these. What has changed recently that makes the client require these files? Is it about the windows.h ? Have I done something? I think that with Visual C++ 2005 the way that C/C++ runtimes (msvcr80d.dll, msvcp80d.dll <- debug runtime) are handled changed to more .NET like and you just can't put them into the folder. They need to be versioned and loaded via system wrapper (at leat that is what I understand). The dll you mentioned were always needed, but they are system ones so you should have them properly installed when doing the installation of Visual C++ 2005. Should I try to compile with out the _DEBUG? Or would that ruin the whole debug thing, not being able to follow call stacks and such? Or how can I fix assert errors like this? There are projects setting that allow you to see call stack / variables regardless of _DEBUG define. That's how I've been able to 'debug' a release build. If you are interested I could send you my .sln/.vcproj files so that you can see how they differ from yours. Share this post Link to post Share on other sites
Beaverhunter Report post Posted April 9, 2007 (edited) Hmm oki, but what do you say that can possibly have changed this lately? It did afterall work properly some days ago, the only possible changes I can have caused is the testing of different Preproessors + linking the libpng to get EYE_CANDY to work. Also CVS has updated, but you say this isn't a code problem? It's a system/project setting problem? Removing the _DEBUG resulted in the same error message about assertion. How exactly am I suppose to make the dlls be loaded in the system wrapper instead of the EL folder? Yes, maybe the project/solution files can solve some problem, Ill try some stuffs first though. Update: Oki, I searched the net and found these: http://www.thescripts.com/forum/thread63935.html http://www.gamedev.net/community/forums/to...e=1? I added /J switch and I actually get further! But when I just has loaded the map and such I get a message about vector out of range: "Debug Assertion Failed! Program: C:\...\Eternal Lands Dev\elc.exe File: c:\...\microsoft visual studio 8\vc\include\vector Line: 756 Expression: vector subscript out of range. For more information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts. (Press Retry to debug the application)" Edited April 9, 2007 by Beaverhunter Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 9, 2007 Update: Oki, I searched the net and found these: http://www.thescripts.com/forum/thread63935.html http://www.gamedev.net/community/forums/to...e=1? I added /J switch and I actually get further! But when I just has loaded the map and such I get a message about vector out of range: "Debug Assertion Failed! Program: C:\...\Eternal Lands Dev\elc.exe File: c:\...\microsoft visual studio 8\vc\include\vector Line: 756 Expression: vector subscript out of range. For more information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts. (Press Retry to debug the application)" Great find. That's exaclty what has been happening. I build the current DEBUG version and also got an assertion. The assertion was in function isalpha in filter.c I think the problem is that there have been recent changes to the types. The types were UInt8 before and are char now. UInt8 was unsigned and seems that char is signed by default in VC. The /J switch got the job done, but I don't know if this change didn't affect anything more. I think you should post this problem into this thread Share this post Link to post Share on other sites
Beaverhunter Report post Posted April 9, 2007 (edited) Hmm yes, I also tried to check on the new vector error that occurs, I found that it had something to do with ZeroMemory() calls but there are only 2 of these in ELC and I tried to exclude these and it was no difference. So there must be something else about vector resizing and allocating memory for the vectors or overloading the vectors without it having any space left. Did the /J switch get you passed any errors or do you also get this vector error? And yes the isalpha and alike are the problem, and using chars instead of strings or UInts is considered bad along the net. A pretty fun quote: "As a general rule, if you post in For Beginners and your code contains the word 'char', you have a bug. std::string roxors teh big one one one one." Since ttlanhil is reading this anyway the warning thread should not need this aswell but well maybe, I'll test some more stuffs later probably. Edited April 9, 2007 by Beaverhunter Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 9, 2007 Did the /J switch get you passed any errors or do you also get this vector error? I didn't get the vector error and just logged in into test server with debug build. Try doing a 'clean' on the whole solution and deleting any intermediate files, the rebulding. Maybe it will help Share this post Link to post Share on other sites
ttlanhil Report post Posted April 9, 2007 (edited) that other thread was so that people who had reason to edit the code would have some warning that there were going to be a lot of changes coming. it's not about fixing any bugs don't use any command line switches (all the options are available in the project settings, and that means you can read more about what they do when you come back later). don't treat chars as unsigned, that will probably cause problems later. I know of one place where MSVC gave an assert in pm_log.c, which I fixed. if you want to report a problem, include a line number and/or the offending code fragment (there are several isalpha calls in ELC) and it should be able to be fixed pretty quickly when you find the offending one, and want to try to fix it (make sure it's the same one), you can change from something like isalpha(ch) to isalpha((unsigned char)ch) don't read anything that mentions C++. in many cases it will be wrong here. ed: that goes for anything starting std:: as well... unless it's in the eye_candy code or the cal wrapper, it's wrong if you don't want asserts, don't set NDEBUG in your preprocessor line dlls are loaded from directories in an environment setting (win->settings->control panel->system->advanced->environment, maybe? been a while since I had to mess with that, and it varies depending on which windows version you have) my suggestion as far as extra libraries is to have somewhere you do your coding (eg: c:\dev) which has folders for your projects (like ELC) and for dlls, libs, includes, etc (you'll know what else, as this is the stuff many of the downloads have already), you set up windows to use dlls in the dlls dir, and MSVC to use includes and libs from those dirs and then there's no need to put any of the above in the EL directory Edited April 9, 2007 by ttlanhil Share this post Link to post Share on other sites
Beaverhunter Report post Posted April 9, 2007 (edited) Did the /J switch get you passed any errors or do you also get this vector error? I didn't get the vector error and just logged in into test server with debug build. Try doing a 'clean' on the whole solution and deleting any intermediate files, the rebulding. Maybe it will help Hmm oki, weird, well all this kind of points to that the elc contains code that is "dangerous" and not 100% working on all platforms. I tried clean and rebuild and build, no difference=( ttlanhil: I'm not really sure on how to find a proper line in the EL code that is causing the problem since when debugging it points to: #ifdef _DEBUG _MRTIMP2_NCEEPURE void __CLRCALL_PURE_OR_CDECL _Debug_message(const wchar_t *message, const wchar_t *file, unsigned int line) { // report error and die if(::_CrtDbgReportW(_CRT_ASSERT, file, line, NULL, message)==1) { ::_CrtDbgBreak(); } } _MRTIMP2_NCEEPURE void __CLRCALL_PURE_OR_CDECL _Debug_message(const unsigned short *message, const unsigned short *file, unsigned int line) { // report error and die _Debug_message((wchar_t *) message, (wchar_t *) file, line); } #endif Hmm oki, but I'm not using NDEBUG. In debug mode it's _DEBUG. And I have tried both with and without this. The weird thing is that even without _DEBUG it jumps into this #ifdef.... that must mean that by default _DEBUG is set. The reason we/I found out it was isalpha is because I saw it on a website, but the vector problem I have no clue about where to look except that I read about a ZeroMemory() call problem on a site, but as I said I allready tried to exclude those calls without better result. Ooh, this might not be a proper found but maybe... the last EL code that is called is this: extern "C" CAL3D_WRAPPER_API CalMesh *CalModel_GetAttachedMesh(CalModel *self,int i) { return self->getVectorMesh()[i]; } Inside cal3d_wrapper.cpp, Line 14. That is some iterator that causes this to act: #if _HAS_ITERATOR_DEBUGGING if (size() <= _Pos) { _DEBUG_ERROR("vector subscript out of range"); _SCL_SECURE_OUT_OF_RANGE; } #endif /* _HAS_ITERATOR_DEBUGGING */ Edited April 9, 2007 by Beaverhunter Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 9, 2007 (edited) The reason we/I found out it was isalpha is because I saw it on a website, but the vector problem I have no clue about where to look except that I read about a ZeroMemory() call problem on a site, but as I said I allready tried to exclude those calls without better result. You should have the call stack window at the bottom right of Visual Studion when the assert hit. From there you should see the last ELC function that has been called before assert. Ooh, this might not be a proper found but maybe... the last EL code that is called is this: extern "C" CAL3D_WRAPPER_API CalMesh *CalModel_GetAttachedMesh(CalModel *self,int i) { return self->getVectorMesh()[i]; } Ok, I'm almost sure I know what is going on. I had the same problem. You need to build your Cal3d library with the same settings as your client. Moreover, you need to have two libraries: one debug and one release. You need to link a debug version of library to debug client and release version of library to release client At least that's what I remember from my fights with building EL client As I remember it had something to do with heaps from different runtimes, the client using a debug and library using a release, but I never fully understood it. ED: Oh, and you should get the same problems with vorbis I think Edited April 9, 2007 by Kindar Naar Share this post Link to post Share on other sites
Beaverhunter Report post Posted April 9, 2007 (edited) ... Ok, I'm almost sure I know what is going on. I had the same problem. You need to build your Cal3d library with the same settings as your client. Moreover, you need to have two libraries: one debug and one release. You need to link a debug version of library to debug client and release version of library to release client At least that's what I remember from my fights with building EL client As I remember it had something to do with heaps from different runtimes, the client using a debug and library using a release, but I never fully understood it. ED: Oh, and you should get the same problems with vorbis I think Aah yes, that did the trick, I compiled a Debug version of Cal3d and linked cal3d_d.lib in Debug mode. But I'm getting some heavy FPS drops though, but that might because of running it from inside MSVS. I do have abit of a problem with getting sound to work yes but no complaints about vorbis. I do crash when I enable music and wait abit. Also there is no file "sound/sound_config.xml" that it wants. Note though that this was using NEW_SOUND, is that experimental so far? Oki, without NEW_SOUND and now linking with vorbisfile_d.lib I crash when pressing "Enable Music" in the options while opening it´and loading the ogg files: > elc.exe!load_ogg_file(unsigned char * file_name=0x00da8340) Line 305 + 0x14 bytes C elc.exe!play_ogg_file(unsigned char * file_name=0x00da8340) Line 263 + 0x9 bytes C elc.exe!update_music(void * dummy=0x00000000) Line 1104 + 0x13 bytes C Edited April 9, 2007 by Beaverhunter Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 9, 2007 Aah yes, that did the trick, I compiled a Debug version of Cal3d and linked cal3d_d.lib in Debug mode. But I'm getting some heavy FPS drops though, but that might because of running it from inside MSVS. I do have abit of a problem with getting sound to work yes but no complaints about vorbis. I do crash when I enable music and wait abit. Also there is no file "sound/sound_config.xml" that it wants. Note though that this was using NEW_SOUND, is that experimental so far? The frame drop is normal (3 FPS on IP beam for me). It's beacause you have Cal3d in debug. I think NEW_SOUND is very experimental. I don't use it. Share this post Link to post Share on other sites
Beaverhunter Report post Posted April 9, 2007 ... The frame drop is normal (3 FPS on IP beam for me). It's beacause you have Cal3d in debug. I think NEW_SOUND is very experimental. I don't use it. Oki, nice then at least something works now=) But well can you check if we link the same libraries? (go up to the first post and check) Note thought that I now have cal3d_d and vorbisfile_d. Am I missing something? Should I link something like ogg.lib or is that included in the vorbisfile? Are you able to hear music and Enable it with the new CVS? Share this post Link to post Share on other sites
Kindar_Naar Report post Posted April 9, 2007 Here are my defines: ELC WINDOWS NEW_FRUSTUM BUG_FIX_3D_OBJECTS_MIN_MAX NEW_TEX ATI_9200_FIX NEW_ACTOR_ANIMATION AUTO_UPDATE OPTIONS_I18N PNG_SCREENSHOT NOTEPAD ANTI_ALIAS COUNTERS AFK_FIX CUSTOM_LOOK CUSTOM_UPDATE USE_INLINE FONTS_FIX SIMPLE_LOD ZLIB FUZZY_PATHS SFX MASKING ACTOR_ALPHA NEW_ALPHA EYE_CANDY __SSE__ NEW_LIGHTING and libs: shell32.lib libxml2.lib vorbisfile.lib user32.lib SDL_net.lib kernel32.lib glu32.lib opengl32.lib SDL.lib ALut.lib OpenAL32.lib iconv.lib Cal3d.lib libpng13.lib zdll.lib SDL_image.lib Both from release. I can click on 'enable music' and the client doesn't crash.. but don't have the music either... Share this post Link to post Share on other sites