Page 1 of 1
[fixed] getType() always returns ESNT_UNKNOWN
Posted: Fri Mar 16, 2007 4:32 pm
by drewbacca
I recently updated my irrlicht to 1.3 and now I always get values of ESNT_UNKNOWN when calling getType() on pointers to my nodes.
I thinks its because in changing from 1.2 to 1.3, the ISceneNode.h file changed the function from
virtual ESCENE_NODE_TYPE getType()
to
virtual ESCENE_NODE_TYPE getType() const
but all the overloads in 1.3 such as in CMeshSceneNode.h
still have virtual ESCENE_NODE_TYPE getType()
and are missing the new const qualifier
I sometimes mess up the implications of const, so I may be mistaken, but it would explain the lack of polymorphic behavior on getType when upgrading Irrlicht.
Posted: Fri Mar 16, 2007 5:29 pm
by white tiger
i have also this bug and have lot of problems with it, because my library discriminates the type of nodes (cubes,sphere,animated,oc tree,exc..) using getType to apply appropiate physics body on them. As you saied ISceneNode::getType return always ESNT_UNKNOW (on my pc) and i have to set node types manually
Posted: Fri Mar 16, 2007 6:04 pm
by vitek
Well this isn't really a 'bug' in Irrlicht. Someone fixed a function to be const correct. Now you need to update your scene node derived classes to use the new function signature.
Correction: This is an irrlicht bug. Someone forgot to update the irrlicht scene node types!!! Duh.
Travis
Posted: Fri Mar 16, 2007 6:05 pm
by white tiger
Personally I don't use scene node derived classes
Posted: Fri Mar 16, 2007 6:28 pm
by hybrid
Well, the problem is that the overloaded methods are not called anymore, because they do not fit the signature and are thus no candidates for virtual calls. So it's a bug in Irrlicht, but it's also a hard one to spot (no compiler warnings etc., at least not for the standard compilers).
Posted: Fri Mar 16, 2007 7:03 pm
by vitek
but all the overloads in 1.3 such as in CMeshSceneNode.h
still have virtual ESCENE_NODE_TYPE getType()
and are missing the new const qualifier
Whoops, I missed the most relavent statement!!! Bug.
Posted: Fri Mar 16, 2007 11:39 pm
by bitplane
now fixed in svn.. perhaps we should release a bug-fixed 1.3.1 soon
Posted: Fri Mar 16, 2007 11:54 pm
by hybrid
Now all are fixed
I guess there is no minimal time between new releases
Posted: Sat Mar 17, 2007 2:55 am
by bitplane
Should we also update all the other getType's, for the sake of consistency? (skin, animators, affectors, emitters, gui elements, fonts)
If we do, then I guess .Net would need to be regenerated and compiled again if we were to do a bugfixed release.. Which also means I could commit the small GUI interface changes I've been sat on (env::getOSOperator, IGUIImage::setScaleImage and setColor)
Posted: Sat Mar 17, 2007 5:33 am
by vitek
BTW, this is a _perfect_ reason to implement a simple test suite. It seems like a lot of work, but it would catch bugs like this before they were ever released.
Travis
Posted: Sat Mar 17, 2007 11:45 am
by white tiger
I think i will stay with 1.1 since bug fix release
Posted: Sat Mar 17, 2007 11:47 am
by hybrid
I think we should change the other methods as well (and probably also the OnEvent
) but eventually lower the number of API changes!
I have already prepared some tests (which led to several fixes to matrix4 and stringc). Test suite writing is indeed time consuming and boring, but I'll commit the tests soon. And maybe someone else will also provide tests (e.g. for the larger structures, I currently focus on the low-level datatypes)
Posted: Sat Mar 17, 2007 2:00 pm
by kompromis
okay when will we get this updated version.
a version without this error
Posted: Sat Mar 17, 2007 5:42 pm
by bitplane
kompromis: you can get the latest code from the SVN repository, there are instructions in a sticky in the FAQ's forum. revision 561 and later have this problem fixed.
Okay I updated everything else.. hopefully I didn't break too much!
Posted: Sat Mar 17, 2007 10:41 pm
by kompromis
i don't understand a poop about how or what the svn thing is