Irrlicht Engine

Hi there,

Id like to package Irrlicht for MacPorts. MacPorts is a package manager for Mac, similar to dep/rpm packages for linux. In contrast to deb/rpm it doesent distribute pre-compiled software, but source code. The MacPort software fetches the files, applies patches, compiles everything and ...

Okay I think I got it now. Thx!

Hmm sorry for my ignorance, but I still dont get it.
If there was one animator, and it called removeAnimator() on itself, the iterator ait would be incremented past the end.

Suppose we have only one iterator in the list. If this animator removes itself
core::list<ISceneNodeAnimator*>::Iterator ...

hmm I just realized that in IUnknown.h you'll find this: Im my theory, as stated above, this should be dangerous. It seems my theory is wrong.

Hi there,

This is not really a request for help, because I solved the issue already. I just would like to get some comments in order to find out whether my solution is a good one.

The Task:
Im currently programming a CnC-like RTS game. I needed an animator that followed some waypoints on a virtual ...

Ok I have to add sth here, in case someone tries sth simmilar. vitek pointed out that...
void MySceneNodeAnimator::animateNode(ISceneNode* node, u32 timeMs)
{
//...

if (m_finished)
{
node->removeAnimator(this);
m_finished = false; // very bad!!!
}
}

but to be really precise it should be ...

Ok thanks vitek, things are clear now.

Conclusion:
My fault was to use the delete operator on an Object which is derived from IUnkown. Those Objects are deleted automatically when there refenrece counter is set to 0. This is true as soon as you have one drop() call more than grab() calls.

Ok after looking at IUnknown, I think I do understand a bit more. But...

You should only call drop() if you have called grab() or were given a pointer via the create method.
I think I should also call drop if I created the object myself via the new operator. True?

And what exactly is the benefit ...

Hi guys,

I wrote a custom animator which should remove itself after it is done. For this purpose I store a reference to the scene node to which the animator is attached in the animator.

My animateNode() looks like this

if( m_finished )
{
mp_sceneNode->removeAnimator( this );
delete this ...

PS: I am confused you say the callback only works when the loop mode is set to false but so far it only crashes when you set it to false?
Yep thats right. The callback works, but in the next render loop somwhere in CAnimatedMeshSeceneNode->render() the app crashs if setLoopMode is set to false.

I ...

Isnt setLoopMode for actual animated meshes?!
I think you are right, but it doesent really matter in my case. I only call setLoopMode( false ) because if I would'nt, the OnAnimationEnd() callback won't be triggered. And the OnAnimationEnd() callback does work, it gets called after my animator is ...

My meshes are OBJ files. I experimented a lot with diferent formats and obj was pretty much the only one that worked. I only animate them within irrlicht (e.g. move the whole object form one point to another.

I already thought about coding my own animator but I always try to make as much use of ...

No the pointer is valid. I tried what you told me. It's in fact not the setLoopMode() method where the app crashs, but the next CAnimatedMeshSceneNode->render() call in the next render loop. If I omit setLoopMode() the app doesent crash at that point.

I would step through the irrlicht code but gdb ...

Hi there,

I use static meshes and animate them with flyStraightAnimators. I'd like to create a new animator whenever the last animation is finished. I thought the OnAnimationEnd callback would be a good solution for that. The callback stuff seems to work but as soon as I call setLoopMode( false ...

ok it didnt work cause I forgot to return false in my event listener, so the mouse events were captured preventing the list box to work. Thx guys.

Janosch