Re: [Opensg-users] Extending the Walknavigator

[Yvonne Jung]

Hi, Hi again, thanks for the hint. I want to have a walknavigator with a slightly different behaviour, first I want it to give a return value in case the person hit the wall and second I want to move with the function right aside instead of rotating (or have a different method like "aside(Real32)" or s.th. like that) the code is the same as in "forward(Real32)" except for that mv and sv have to be exchanged (and sign I don't know yet). just check out a version from one year ago in order to get the [walk|fly]navigator moving instead of rotating. But in most cases it seemed to be quite unhandy to me to have a walking mode that only allows walking around like a crab :-) You are right, it might be restricting to have only the possibility to move into a direction you don't see... but to rotate you also use the mouse already, so this is redundant in the user interface, which is not as bad as it sounds in my opinion, because you might have situations, where you don't want to grab the mouse or the other way round. I don't want to make this big, because I supouse you had some discussions already, when you changed this... But what about having just two keys more, like: ROTLEFT | WALK | ROTRIGHT LEFT | BACK | RIGHT ? Ok, that sounds better than only having this or that, perhaps PgUp and PgDown? And what about the second question, are there objections against having a return value in case of collision or gravity influence? Don't think so, this would only mean to exchange the return type from void to e.g. int. And last but not least, I have a model where the ground is not at one piece, so there are holes behind walls and it happens some times, that the person gets in an area, where the gravity check skips the action and the user can't move back. In my opinion this should continue at this point, because the movement is not directed upwards, so there is no reason for doing so, or did I get it wrong? Concerning gravity and collision the WalkNavigator is designed quite simple. The detection of smaller obstacles like bars is almost random, because momentarily only the old IntersectAction is used which in addition is not so fast. It would be better to check the geometry against a timely moved hull of the user. Thanks for your opinion, regards, Daniel Regards Yvonne ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users