Jump to content
Eternal Lands Official Forums
Sign in to follow this  
Beaverhunter

Success comes with failure...

Recommended Posts

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 by Beaverhunter

Share this post


Link to post
Share on other sites

"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

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 by Beaverhunter

Share this post


Link to post
Share on other sites

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

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 by Beaverhunter

Share this post


Link to post
Share on other sites

 

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 :fire:

Share this post


Link to post
Share on other sites

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 by ttlanhil

Share this post


Link to post
Share on other sites

 

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 :fire:

 

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 by Beaverhunter

Share this post


Link to post
Share on other sites

 

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. :fire:

 

 

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. :P

 

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 :P 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 by Kindar Naar

Share this post


Link to post
Share on other sites

...

Ok, I'm almost sure I know what is going on. I had the same problem. :fire:

 

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 :P At least that's what I remember from my fights with building EL client :P

 

 

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 by Beaverhunter

Share this post


Link to post
Share on other sites

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

...

 

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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×