Special effects

[KarenRei]

Hmm oki, but why you let them live that long so that they can reach those big numbers?

 

I don't let them live very long. Some particles, through a combination of steps of bad luck, manage to get that far away in a short period of time. Think of it this way -- if your magnitude doubles every step, it only takes 128 steps to bring a floating point value from 1.0 to inf. In the case of an IFS spawner, for example, it may run a few thousand times per summon effect.

 

So 'isfinite(0.0)' will fail where 'finite(0.0)' passed

 

I can't allow 0.0 to fail. But the man page for isfinite doesn't look like it would:

 

isfinite(x)

(fpclassify(x) != FP_NAN && fpclassify(x) != FP_INFINITE)

 

0.0 is != FP_NAN, and != FP_INFINITE, so it will return true.

[trollson]

When you make such statement please tell what architecture you mean, because GNU claims they are equivalent

and in libc6 they actually are.

Sorry, I misread the standard, they should be the same. See 7.12.3.2:

The isfinite macro determines whether its argument has a finite value (zero,subnormal, or normal, and not infinite or NaN).

Misread the parenthesis part as exclusions, not inclusions & exclusions combined. Duh!

[KarenRei]

No problem; I've misread worse

[Beaverhunter]

Once again some external symbol error:

1>Linking...

1>eye_candy_wrapper.obj : error LNK2001: unresolved external symbol "public: __thiscall ec::CandleEffect::CandleEffect(class ec::EyeCandy *,bool *,class ec::Vec3 *,float,unsigned short)" (??0CandleEffect@ec@@QAE@PAVEyeCandy@1@PA_NPAVVec3@1@MG@Z)

 

This line the linker doesn't like:

ret->effect = new ec::CandleEffect(&eye_candy, &ret->dead, &ret->position, scale, LOD);

 

Nevermind, a new file was in there, effect_candle.cpp and it wasn't included in project.

Edited May 4, 2007 by Beaverhunter

[KarenRei]

Yeah. I found it simpler to branch the existing lamp/torch effect into a new "candle" effect than to modify the existing one, in order to meet Roja's mockup for what a candle should look like. It's mostly the same code, but with its features pared down heavily and a few structural changes.

[Puntif]

I'm using Slackware linux (tried both slackware 9.0 and 10.2) and got:

In file included from eye_candy_wrapper.h:22,
			 from eye_candy_wrapper.cpp:5:
eye_candy/eye_candy.h: In member function `bool ec::Vec3::is_valid() const':
eye_candy/eye_candy.h:393: `isfinite' undeclared (first use this function)
eye_candy/eye_candy.h:393: (Each undeclared identifier is reported only once 
  for each function it appears in.)
make: *** [eye_candy_wrapper.o] Error 1
kevin@server1:~/elc$ g++ --version
g++ (GCC) 3.2.2
Copyright (C) 2002 Free Software Foundation, Inc.

 

Where should isfinite be defined?

[jamincollins]

Running CVS build checked out this morning (few minutes ago) and the restore spell no longer has any SFX. Changing back to a build from yesterday shows the restore effect.

[Beaverhunter]

Puntif:

As you should have read just a few posts above, we discussed which one to use. And isfinite is suppose to work but if it really doesn't work for you, then change those isfinite to finitef. If that doesn't work then you have to check with KarenRei if he can come up with something similar that activates only on your compiler.

[KarenRei]

Restoration bug is known, and will be looked into tonight.

[KarenRei]

Restoration: no SEND_SPECIAL_EFFECT packet is coming from the server. Someone with server access will need to look into this.

[KarenRei]

Restoration: two issues. One, no packet sent if the caster is full. The other, if they weren't full, was a bug. Fixed.

[Learner]

Restoration: two issues. One, no packet sent if the caster is full. The other, if they weren't full, was a bug. Fixed.

Please check how the restoration/special packets are being handled and how you checked for them. The server code related to this has not changed since December.

[Puntif]

Puntif:

As you should have read just a few posts above, we discussed which one to use. And isfinite is suppose to work but if it really doesn't work for you, then change those isfinite to finitef. If that doesn't work then you have to check with KarenRei if he can come up with something similar that activates only on your compiler.

 

 

I did read those posts above and none of them told me what I needed to know to get the unmodified source from CVS to compile on my system. If isfinite is a new addition to the c++ standard then it's a matter of me updating my compiler/library.

[Beaverhunter]

...

I did read those posts above and none of them told me what I needed to know to get the unmodified source from CVS to compile on my system. If isfinite is a new addition to the c++ standard then it's a matter of me updating my compiler/library.

 

Well then you should have noticed the reason for the discussion about this function was that it didn't work on my compiler, Microsoft Visual Studio 2005. Then we found a similar/equal function called isfinite() instead, which worked on my compiler and those that had finitef() working before, so all should be happy.

 

But well I guess there still could be some compiler out there where this doesn't work. Basicly you cannot get an unmodified CVS to work unless your compiler and OS supports that function. So KarenRei has to add some different function that works for you but with an "#ifdef WeirdCompiler". So that both types are in there.

 

Maybe you can tell us what compiler your using? And yes maybe updating it helps.

 

Also as a first step you can do as I said, change those isfinite() to finitef() and see if it works, then it's easy to modify the code into 2 versions.

Edited May 6, 2007 by Beaverhunter

[KarenRei]

Please check how the restoration/special packets are being handled and how you checked for them. The server code related to this has not changed since December.

 

And I'm pretty sure that it's been there that long. Minor enough that nobody's complained, but I remember encountering it before.

[Learner]

Please check how the restoration/special packets are being handled and how you checked for them. The server code related to this has not changed since December.

 

And I'm pretty sure that it's been there that long. Minor enough that nobody's complained, but I remember encountering it before.

Restoration: no SEND_SPECIAL_EFFECT packet is coming from the server. Someone with server access will need to look into this.

 

The restoration effect still works on a client compiled May 2 (but not May 4). Unless the spell effects were handled differently, I don't imagine it really is server-side.

 

That last one is from the Problem with eye candy which helps show that the problem is client side.

[KarenRei]

Did you miss the part where I pointed out that there were two different bugs, one clientside, and an older one that is serverside? The clientside one always applied, and was new (and is now fixed). The serverside one only occurred when the person had full health, is old, and is still there.

[Florian]

Confirmed the restoration sfx bug: no sfx when health is already full. There is an sfx when health is not full.

 

Maybe this is intended?

Edited May 6, 2007 by Florian

[Learner]

Did you miss the part where I pointed out that there were two different bugs, one clientside, and an older one that is serverside? The clientside one always applied, and was new (and is now fixed). The serverside one only occurred when the person had full health, is old, and is still there.

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.

[KarenRei]

From a user's perspective it looks odd -- that's all. The spell seems to go off, but there's no effect.

[Learner]

From a user's perspective it looks odd -- that's all. The spell seems to go off, but there's no effect.

You're right this is no effect, it tells you you were already full, so it didn't help you. No need fo the visual. If other spells do have the effect, maybe they are the ones with the bug.

[bluap]

Noticed this a few times lately, pick-up or dropping a bag can sometimes produce a larger than normal effect. Most of the time its find, a small poof, occasional I get one of these. I'm pretty sure its reproducible by having your back to the camera and your perspective at its most horizontal. The actual bag does not have to be totally obscured though. Certainly it't happening all the time where I'm sitting ATM. Sorry I can't be more specific, I'll get you more information if needed and I can.... Latest CVS of this morning, on Debian Linux (etch).

 

Edit I: to fix typoes, there are probably more

 

Edit II: I have "Use isometric view" off and "Perspective" set at 0.45 in case its important.

Edited May 6, 2007 by bluap

[KarenRei]

Interesting, bluap. I'll look into that; perhaps it's even related to the crash.

 

Ttlanhil -- I just committed a fix for your limited color buffer resolution/transparency issue that we've spent weeks (over a month?) working on. Check the config options to enable it. I'm going to need you to calibrate it, though. On eye_candy/eye_candy.cpp, line 158, 160, and 161, you'll see the number 0.05. The lower you make this, the better it will look on a "normal" card. However, obviously, on your card, if the number gets small enough, your card will display it wacky. I want you to figure out what's the lowest number that you can use that will still look good. We know 0.2 works for you, and we know numbers like 0.008 or so don't. Just experiment.

[KarenRei]

Bluap: Good news, bad news. Good news: bag size bug fixed and checked in. Bad news: it was unrelated to the crash. The bug was due to a simple missizing on low levels of detail.

[ttlanhil]

I don't know how many sigfigs you want, but 0.0294132223353 works and 0.0294132223352 doesn't (only last digit is different)... I figure at this stage, it's close enough.

 

however, there are still some problems, as you can see in this picture.

 

there's the green off to the side. the teleporter effect is all line-ey, rather than being smooth. and the details tab is now full (is it worth doing away with the SFX code and having anything left in there under EYE_CANDY ?)