Special effects

[KarenRei]

Green off to the side: have you turned off -DDEBUG_TTLANHIL_TRANSPARENCY?

 

Line-y: Yeah, that's kind of unavoidable, at least in the general case fix.

 

Sig figs: I'll go with 0.03

 

Space: I think it's about time eye candy got it's own tab. What do you think? I have a couple other things I could put in there, too, like disabling specific kinds of effects for people whose systems are limited in various ways.

Edited May 7, 2007 by KarenRei

[ttlanhil]

Green off to the side: have you turned off -DDEBUG_TTLANHIL_TRANSPARENCY?

nope, guess that's it

Line-y: Yeah, that's kind of unavoidable, at least in the general case fix.

yeah, that's what I guessed

Sig figs: I'll go with 0.03

please don't... it's subjective, but I think the lines and all were a little better as I went into more sigfigs, 0.0300 and 0.0294 looked, at least to me, to be different (not having them next to each other, but as I narrowed it down it seemed to get a bit smoother

ed: as for a new tab... that would probably work, but you'd need to make the options window larger to fit it in, and then run at 640x480 windowed to make sure it still fits (which it may not)

Edited May 7, 2007 by ttlanhil

[KarenRei]

Looks like the most blend your system can handle is 1/34th. Funky

 

I'll have it use your number. Just so you know, effects may go off a bit early in some places; I'm working on narrowing down the range for which effects are active to help the people whose systems are running slow as much as I possibly can.

[ttlanhil]

yeah, pretty close to 1/34, odd, eh?

anyway, I forgot before, but there was another issue:

eye_candy/eye_candy.cpp: In member function ‘virtual void ec::Shape::draw()’:
eye_candy/eye_candy.cpp:139: error: cast from ‘void*’ to ‘unsigned int’ loses precision
make: *** [eye_candy/eye_candy.o] Error 1

fortunately, I know exactly what this is, it's a 64bit issue... that's what the typedef'd 'point' in global.h is for (which I'm pretty sure I've used to fix eye-candy code before), except that it's not finding the 'point' type now

under -DX86_64 , pointers are long ints, rather than ints

it's trivially easy for me to hack the code to use a long int, but that's not portable... I'd use 'point' if it was found... anyway, since you're probably more familiar with it all, and it should be a simple issue, I'll leave it with you

Edited May 7, 2007 by ttlanhil

[Beaverhunter]

Hmmm just a quick check:

Are the "great swords" suppose to have special effects? I see ppl going around with jagged sabers getting all pink colored particles around them... Didn't Ent request it to not apply to those swords? Or is this a bug?

 

 

Update:

I have recently goten exception crashes on client when quiting with alt+x and the client seems gone but then I get EternalLands.exe... and so on. I'll try to debug this some time but it doesn't happen every time... seems to be related to longer time of playing... I had been on 9 hours last time, time before was probably 13 hours... but still not everytime even if long play, so not sure what it is.

Ooh and this was with client from 5 May, maybe something changed, sorry if so.

Edited May 7, 2007 by Beaverhunter

[KarenRei]

Swords: Haven't gotten around to that yet.

Crash: This may be the big one that nobody has been able to reproduce reliably or get a stacktrace on. If you could get a stacktrace on it, it would be a *big* help.

[Beaverhunter]

Crash:

LOL Oki I just compiled debug version, started it within the compiler and went inside Test Server... Logged in at PL storage... Gotta go for school so logged out... Got Exception error and had ability to break!

 

> elc.exe!ec::LampBigParticle::`scalar deleting destructor'() + 0x3c bytes C++

elc.exe!ec::EyeCandy::~EyeCandy() Line 1215 + 0x3b bytes C++

elc.exe!`dynamic atexit destructor for 'eye_candy''() + 0x28 bytes C++

msvcr80d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 553 C

msvcr80d.dll!exit(int code=0) Line 398 + 0xd bytes C

elc.exe!__tmainCRTStartup() Line 610 C

elc.exe!WinMainCRTStartup() Line 414 C

 

 

 

- this 0x130108f8 {LOD=56797 } ec::LampBigParticle * const

+ ec::Particle {mover=0xdddddddd velocity={...} pos={...} ...} ec::Particle

LOD 56797 unsigned short

 

 

EyeCandy::~EyeCandy()

{

for (std::vector<Effect*>::iterator iter = effects.begin(); iter != effects.end(); iter++)

delete *iter;

for (std::vector<Particle*>::iterator iter = particles.begin(); iter != particles.end(); iter++)

>>> delete *iter;

for (std::vector<GLenum>::iterator iter = lights.begin(); iter != lights.end(); iter++)

glDisable(*iter);

 

}

 

 

 

 

- iter 0x130108f8 {mover=0xdddddddd velocity={...} pos={...} ...} std::_Vector_iterator<ec::Particle *,std::allocator<ec::Particle *> >

+ ptr 0x130108f8 {mover=0xdddddddd velocity={...} pos={...} ...} ec::Particle *

- iter 0xcdcdcdcd {base=??? motion_blur_points=??? motion_blur_fade_rate=??? ...} std::_Vector_iterator<ec::Effect *,std::allocator<ec::Effect *> >

- ptr 0xcdcdcdcd {base=??? motion_blur_points=??? motion_blur_fade_rate=??? ...} ec::Effect *

__vfptr CXX0030: Error: expression cannot be evaluated

base CXX0030: Error: expression cannot be evaluated

motion_blur_points CXX0030: Error: expression cannot be evaluated

motion_blur_fade_rate CXX0030: Error: expression cannot be evaluated

state CXX0030: Error: expression cannot be evaluated

born CXX0030: Error: expression cannot be evaluated

dead CXX0030: Error: expression cannot be evaluated

pos CXX0017: Error: symbol "" not found

obstructions [...]() std::vector<ec::Obstruction *,std::allocator<ec::Obstruction *> > *

particles [...](... std::map<ec::Particle *,bool,std::less<ec::Particle *>,std::allocator<std::pair<ec::Particle * const,bool> > >

active CXX0030: Error: expression cannot be evaluated

recall CXX0030: Error: expression cannot be evaluated

desired_LOD CXX0030: Error: expression cannot be evaluated

LOD CXX0030: Error: expression cannot be evaluated

Edited May 8, 2007 by Beaverhunter

[KarenRei]

That is one of the most confusing stacktraces I've ever seen. I'm not sure what to make of it. Here's my take so far:

 

eye_candy.cpp, line 1219 deletes particles when the EyeCandy object is destroyed. One object in its list seems to be bad. So, when you quit, the bad object gets deleted, which causes the crash. A bad object has the potential for random crashes at other times, so that's good. The bad object seems to be of type LampBigParticle.

 

Now it gets confusing. We see garbage in a LampBigParticle; my best guess is that this is worthless data from a particle that's already freed and has been written over. Then the stacktrace, for some reason, prints some of my code. Twice.

 

I can't make anything out of the last paragraph. Anyone have any ideas what we're looking at there?

 

Alternative theory to the above: it's *not* a particle that's been double deleted (there's only a few places in the code where particles are ever deleted, and they all appear to remove themselves from the array). Rather, we're looking at an ordinary, utter-pain-to-debug memory leak.

 

I'll mess around with this a bit more tomorrow; it's too late tonight. It's not perfect, but it's something -- who knows, it may just be enough. Thanks, Beaverhunter!

Edited May 8, 2007 by KarenRei

[Beaverhunter]

Well basicly I logged in like 1 minute before posting and had to hurry to school, so logging in, out, copying stacktrace + various variables and outputs that I could find in the debugger, and posting... took approximited 2-3 minutes so I was kind of in a hurry, that's why it's messy. But I assumed you could make something out of it, at least it points very directly on destroying LampBigParticle.

 

The double stuff came because of the forum somehow... it was not included in the "trace"... The stacktrace as I see it is only the first block of stuff... The rest is from Autos and Locals, being variables/pointers defined and set at the time. And as you see in the last block of code some could not be evaluated, meaning it crashed.

 

Update:

I just got home and logged in and out to test this again... log in at PL storage, and out... and I got crash again! 2 out of 2 times... so I can reproduce it at least.

 

But you have to tell me what your searching for, I can get tons of info it seems. But the main thing is the destruction of LampBigParticle... so "fix" that and it's done.

 

This might give nothing but:

"HEAP[elc.exe]: HEAP: Free Heap block 1300d7b0 modified at 1300d8c0 after it was freed

Windows has triggered a breakpoint in elc.exe.

 

This may be due to a corruption of the heap, and indicates a bug in elc.exe or any of the DLLs it has loaded."

 

It seems like you try to modify a pointer that hasn't been initiated, or even created. Is it really possible to destroy/delete a pointer that hasn't ever been created? And what if iter == NULL?

Edited May 8, 2007 by Beaverhunter

[KarenRei]

More like sounds as though it's writing to freed memory. Which could be anything writing to it, not just something that would have written to it when it was valid. I.e., a memory leak.

 

I'll rule out the non-memory-leak options this evening, if I can. At least we know that A) for you, and the PL magic school, together make for a crash.

Edited May 8, 2007 by KarenRei

[Beaverhunter]

So you mean there is something else that is messing with that poor LampBigParticle and its *iter and *ptr ?

Cause same crash+output and reproducable most of the times equals "We found the problem!"

PL magic school? There's crashes there too?=P Or are you too tired to read PL storage properly?=D

 

But well why don't you try, compile and run Debug version inside, the compiler. Make sure you are on test server and log in inside PL storage, then you wait abit, don't do anything, at most walk some step. Then log out using alt+x. If you crash, then send KarenRei a PM, or write him a note and put it on his desk, or maybe even phone him so that he wakes up;D

[ttlanhil]

But you have to tell me what your searching for, I can get tons of info it seems. But the main thing is the destruction of LampBigParticle... so "fix" that and it's done.

only if that's where the trouble is caused, and not just where it's seen

Is it really possible to destroy/delete a pointer that hasn't ever been created? And what if iter == NULL?

most pointers are never new/free'd... and you can try to free an invalid pointer, but the system should throw an error. and iter will not be NULL, C++ concepts like iterators are safer because they range from the start to the end of a list... although they can be invalidated if you remove an element from the list while an iterator is still pointing to it (which makes iterating a list fun if you want to remove some elements)

Cause same crash+output and reproducable most of the times equals "We found the problem!"

no, it means we have a good idea where to look... and a large part of that is a developer being able to reproduce it (I've tried a couple of times now. I can't. good luck to karen)

But well why don't you try, compile and run Debug version inside, the compiler.

here be some problems. you say it like this because you're an MSVC user. most of us aren't (although I was), and it doesn't make sense. on the typical install, one compiles with debugging symbols (-ggdb, the default in the makefiles) and then runs under or attaches a debugger (meaning gdb, most of the time). conversely, to karen, that's why his output above looks wonky. MSVC gives you output in a number of windows, for the call stack, variables, and a bunch of other stuff

If you crash, then send KarenRei a PM, or write him a note and put it on his desk, or maybe even phone him so that he wakes up;D

not to be the pestering a dev I imagine reports with info here are the best, then others can look as well. and... he?

[Beaverhunter]

Ooh oki thanks for info. So I guess KarenRei got quite alot of work to do then, but is there anything I can do to try and figure out if this is a local problem or not? (Only happening on my comp)?

I mean, different compilers should compile abit different but this kind of error, shouldn't it be present on both? Or is it that MSVS is superior and detects this memory leak as a breakpoint while your linux stuff don't?

 

The last part was a joke;D I meant for KarenRei to PM himself or leave himself a note or even phone himself... But sure it would be nice for us too to read that note The note containing debugging info and possible solution attempts.

Edited May 8, 2007 by Beaverhunter

[ttlanhil]

but this kind of error, shouldn't it be present on both?

not necessarily. commonly, memory management problems will be the same, but not always, considering how different linux and windows are, in fundamental design, libraries, and tools (mostly the libraries used, I would imagine).

Or is it that MSVS is superior and detects this memory leak as a breakpoint while your linux stuff don't?

boszhe moi, just how inflammatory is that... MSVC is quite a good IDE on a mediocre compiler (it doesn't support the current standard of the language, let alone support standard libraries and library calls)

while being point-n-click makes it easier to use the debugger and all than a linux user on gdb, there are frontends that make the usability of the direct tool irelevant (like kdevelop, which fills the roll of IDE with debugger and a bunch else... in some areas it's better than MSVC, in some areas not as good, so I rate them about even). so as to the superiority? there's a far larger developer community that has used/built and uses/builds tools for *nix over the years than MSVC has ever had. they're also often trained to a higher level, since windows is typically for games and word processing, and you get an operating system based on *nix or vms or something like that when system stability and performance matter enough that you'll spend a month learning how to use it

Edited May 8, 2007 by ttlanhil

[ttlanhil]

And the serverside one isn't a bug, the spell is not completing properly because you are at full health, so no health increase of effect to increase is sent, which is correct. Thats why the server complains that you are already at full health, and Entropy is being nice and allowing you to earn exp even when the spell is wasted that way. We don't want people lagging other people FPS if we can avoid it.

I didn't post before, but now I have more to add:

 

fair enough, but... it's not consistent. not only with the other spells in general, but even with 'heal'. if you cast heal and are at full health, you still get an effect. I suspect it's related to the issue I noted here

players are also asking why it's broken... while I agree with reducing traffic and graphics requirements, this is one of those things that everyone has to know about, or it'll get asked again and again (like some of those "is this a bug?" issues we see on the forums already. double OA xp on scholars, etc)

[KarenRei]

Ooh oki thanks for info. So I guess KarenRei got quite alot of work to do then, but is there anything I can do to try and figure out if this is a local problem or not? (Only happening on my comp)?

 

No, it's not only on your comp. It's just not widely reproducible for different people in the same circumstances. However, if it's consistent for you in a certain circumstance... would you be available late this evening or tomorrow? I could make a special debugging flag just for you (Ttlanhil knows where this one is going ), and keep refining it until we figure out where the problem is. Instead of debugging statements, however, this flag would start shutting down more and more parts of Eye Candy until the problem disappears. Then we'll know where it really is.

 

I mean, different compilers should compile abit different but this kind of error, shouldn't it be present on both

 

No; the systems handle memory differently, and this seems likely to be a buffer overflow. Different pieces of memory will get corrupted on different systems. Some will cause crashes, others won't. Part of the nature of buffer overflows is that they're unpredictable. They're also darned annoying. For all we know (and this has happened several times before!), the buffer overflow is in the main part of EL, but only causes crashes when it overwrites part of eye candy's memory space.

 

The note containing debugging info and possible solution attempts.

 

I tend to have a pretty open development process Check through the history for my continual boggling at Ttlanhil's transparency problem that we just recently figured out.

 

not to be the pestering a dev I imagine reports with info here are the best, then others can look as well. and... he?

 

Heh, I'm used to it. Seems to be the default assumption online these days ( even though there are more women online than men).

[ttlanhil]

well, location plays a big part in that, I'm sure... plus many women probably don't advertise it because of the teenage lusers... (not that they're all teenaged)... but still... I hear it from so many people, and I'm like... "look at the name"

 

but anyway, the real point to this post...

I'm almost afraid to bring it up, but the last part of the shield effect does the green-tint thing that teleport pads use to... and unless the higher part of smoke is supposed to give a red tinge, that might too...

unfortunately, that alpha cap might have to be applied to all alpha effects *hides*

[Beaverhunter]

Hmm oki, but I can give you the hint that the alt+x crash only started happening about max 7 days old CVS from now... I'm at least sure of the May 5th got crash on the "Release" version, but then I updated May 7, and compiled Debug version and got 2 out of 2 crashes on Alt+X. I rather not try this too often on Main server as I don't want to risk my Counters or interupt gameplay too much.

So maybe we can test this on test server, what ever you now what to test?

 

When it's night for you it's morning for me so it might be abit hard to keep some kind of active discussion. Especially now as it heads towards the spring term end and 2 exams. Not sure what kind of info you want and why you would need to so to say "watch" me crash?

 

But maybe we can do something like this in the weekend?

For example now it's 11 PM, so going bed soon since school and such tomorrow awaits.

 

Ooh, it's a she?=O Nu uh? *hides*

Edited May 8, 2007 by Beaverhunter

[KarenRei]

I'm almost afraid to bring it up, but the last part of the shield effect does the green-tint thing that teleport pads use to... and unless the higher part of smoke is supposed to give a red tinge, that might too...

unfortunately, that alpha cap might have to be applied to all alpha effects *hides*

 

Yeah, I was afraid of that You hadn't complained yet, so I was hopeful... We'll see when I have a chance to get to it, but at least I know exactly what to do now.

 

Beaverhunter: The point of being on at the same time would be to follow this procedure:

 

I make a change. You cvs update, rebuild, and try to log in. If you crash, you log in on a stable client to tell me so; otherwise, you tell me so through the cvs client. I made another change and commit it. You cvs update, rebuild, and try to log in. And so forth.

 

I don't want this fix to take weeks, so I'd rather not have to have to wait a day between me making a change and it being tested, if at all possible.

 

Sure, if I haven't found a solution by this weekend, that would work out fine.

[Beaverhunter]

Oki, sure. But I just don't want you to spend too much time on this if it isn't major. But well I just did some debugging and I tried to just comment it like this:

 

for (std::vector<Particle*>::iterator iter = particles.begin(); iter != particles.end(); iter++)

// delete *iter;

 

Maybe this was trivial for you, but...

That made it not crash... so what ever tries to change that iter after it has been deleted, is the theif we are looking for. And since it only have been present since last few updates of CVS it should be very narrowed down right now.

 

I'm currently trying to find a solution for the Counter bug when it comes to the Skill Schools in game... either it adds to wrong category, or it adds nothing at all if you log in, inside a school. But well that's abit offtopic=D

 

But off to school now again, tell me if there's something you want me to pretest before you start doing some heavy specific config just for me.

[bluap]

I'm currently trying to find a solution for the Counter bug when it comes to the Skill Schools in game... either it adds to wrong category, or it adds nothing at all if you log in, inside a school. But well that's abit offtopic=D

Is that this bug? Or ex-bug, hopefully it has ceased to be, gone to meet it's maker....

Edited May 9, 2007 by bluap

[bluap]

With latest CVS, I get a compier warning in an otherwise unblemished compile. Standard options on Linux with gcc version 4.1.2. Could have been there for a while, I don't often watch each file compile

gcc -march=i686 -Wall  -O0 -ggdb -pipe -DLINUX -DELC  -DAFK_FIX  -DALPHA_ACTORS  
-DATI_9200_FIX  -DAUTO_UPDATE  -DBUG_FIX_3D_OBJECTS_MIN_MAX  -DCOUNTERS  
-DCUSTOM_LOOK  -DCUSTOM_UPDATE  -DEYE_CANDY  -DFONTS_FIX  -DFUZZY_PATHS  
-DIDLE_FIX  -DMASKING  -DNEW_ACTOR_ANIMATION  -DNEW_ALPHA  -DNEW_FRUSTUM  
-DNEW_TEX  -DNOTEPAD  -DOPTIONS_I18N  -DSFX  -DSIMPLE_LOD  -DUSE_INLINE  
-DZLIB -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 
-fno-strict-aliasing  -c -o gl_init.o gl_init.c
gl_init.c: In function ‘init_video’:
gl_init.c:386: warning: implicit declaration of function ‘ec_clear_textures’
gl_init.c:565: warning: implicit declaration of function ‘ec_load_textures’

[Alia]

Well, why you dont use valgrind?

Just run elc under it and you'll find solution for your BigParticle problem:

in EyeCandy destructor we first destroy all effects and then all Particles, but if you'll look

into LampBigParticle destructor you'll see this:

 

~LampBigParticle() { ((LampEffect*)effect)->big_particles--; };

 

we use already destroyed effect :/

[KarenRei]

for (std::vector<Particle*>::iterator iter = particles.begin(); iter != particles.end(); iter++)

// delete *iter;

 

That's just hiding it. Don't do that. The bug is still there underneath, causing problems in other, more subtle ways.

 

With latest CVS, I get a compier warning in an otherwise unblemished compile. Standard options on Linux with gcc version 4.1.2. Could have been there for a while, I don't often watch each file compile

 

Nor do I I'll commit the fix this evening.

 

in EyeCandy destructor we first destroy all effects and then all Particles, but if you'll look

into LampBigParticle destructor you'll see this:

 

Oh. Well, then it's not the source of other peoples' crashes, only Beaverhunters', since other peoples' were in-game, not on-quit. Still, I'll fix that; nice catch.

[Beaverhunter]

LOL, good job Alia, but KarenRei, that must be an embarrassing thing to find out?=P Everything pointed towards that destructor and not you or I checked the actually destructor obviously... I mean you were ready to go the "ttlanhil-debug way" =p But well I haven't really tried to remove that part to see if it fixes it but that must be the thing so I'll leave it to you to commit it and we see.

 

I'm searching for the in-game crash with my debug client... cannot get crashed:P Tried to fight stuff and so on but nothing...

 

Was the fighting crash fixed?

 

Do you have any clue on what could trigger the crash we are looking for? If you find someone who has the slightest clue I could test and get a stacktrace on it, as long as it's not about summoning or fighting high level creatures.

 

Update:

I have been fighting some animals on test server, no crash but I get some kind of sparkle/flash effect. Is that critical hits or is this a bug?

Edited May 9, 2007 by Beaverhunter