[fixed] getType() always returns ESNT_UNKNOWN
[fixed] getType() always returns ESNT_UNKNOWN
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.
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.
-
- Posts: 269
- Joined: Tue Oct 31, 2006 3:24 pm
- Contact:
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
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
Correction: This is an irrlicht bug. Someone forgot to update the irrlicht scene node types!!! Duh.
Travis
Last edited by vitek on Fri Mar 16, 2007 7:02 pm, edited 1 time in total.
-
- Posts: 269
- Joined: Tue Oct 31, 2006 3:24 pm
- Contact:
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)
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)
-
- Posts: 269
- Joined: Tue Oct 31, 2006 3:24 pm
- Contact:
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
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)
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)