Check out the details of the inputmapper http://realxtend.org/doxygen/class_e_c___input_mapper.html#details
I don't think it has bugs like that in the mapper itself. The bugs come from the using code. When you mix and match multiple input mappers + the main input context of the InputAPI you easily get yourself into situations where you stop getting events for certain contextes. Here is some tips and things you want to check. - Check all scripts for EC_InputMappers. Always set contextPriority<http://realxtend.org/doxygen/class_e_c___input_mapper.html#a33fb8dc4f7fac389d3024a684bde5155> to the order which is reasonable. Higher context gets the actions executed first. - Always set takeKeyboardEventsOverQt<http://realxtend.org/doxygen/class_e_c___input_mapper.html#a1a54f846e2c178bf0653bb62d684dd45> and takeMouseEventsOverQt<http://realxtend.org/doxygen/class_e_c___input_mapper.html#a94447033036d169b439e0eef11fa6c60> to false if you really are only interested when your entities are clicked. You almost never want events over UI with input mapper, I suggest using input.MainInputContext().mouseEvent.connect(myhandler) etc. if you want to do that kind of logic (just my preference). - Always set enabled<http://realxtend.org/doxygen/class_e_c___input_mapper.html#a7c231a4906cc9c545b5f6d814c0e863d> attribute to false when you are not using the mapper. Good example is in the avatar demo scene where both avatar and freecam has own mappers. If your avatar camera is not active, you should also set its inputmapper to be disabled. With inputmapper you have two options of usage. Either use entity actions or using its input context directly with http://realxtend.org/doxygen/class_e_c___input_mapper.html#ae4acb0a5309bc50dbe579a6556ce1107 If you want to be able to say inputEvent.handler = true; to make it not send the event to lower priority contexts youll have to use the InputContext signals that send the event object so you are able to do this. This can be many times better if you find yourself in these buggy situations, to explicitly mark events handled when you know you dont want them to trickle down the context chain anymore. Unfortunately right now debugging input context bugs is very hard, you basically have to have full control over the scripts that have intpumappers and do prints in the handlers :P You will find this issue in our tracker https://github.com/realXtend/naali/issues/197 reg. the problem. In short: There are some pits you can fall into with complex/multiople input context (via InputMapper entity actions especially) usage. It might be confusing and hard to debug, but you can do it and the base mechanics in EC_InputMapper are quite solid. I know couple of bugs in inputmapper but those are spesical chars/modifier related things :) But your mind into it, I'm sure you can find the bugs. If not please zip up a minimal .txml with assets and scripts and post them here, describe how to reproduce the bugs and I'll take a look. Best regards, Jonne Nauha Adminotech developer On Sun, Oct 16, 2011 at 5:32 PM, Teemu Siltanen <[email protected]>wrote: > Thanks for testing it. I might have given wrong impression of what > doesn't work; I ment the problem you encountered too that rightbutton- > drag stops working (other mousebuttons work, can't get debug prints > from MouseMove events though). > > As a workaround I customized my avatar script by combining some parts > of avatarscript in Tundra 1.0.8 with Tundra 2.1.1 script and got a > script that works now. > > Still the rightbutton-bug exists: it looks like something takes that > input so that any other inputmapper can't use it. I had one qt-widget > where I wanted to use rightbutton for interaction, but couldn't use it > because that mouse-event never reachs the widget. I made workaround by > changing interaction to ctrl+leftbutton and it works fine (plain > leftbutton would've worked too but it is in other use). > > I can stop using mouserightbutton everywhere, no problem with that, > but I'm just saying if someone finds it to be some sort of bug > somewhere which may need a fix. > > - Teemu > > On 15 loka, 03:28, Toni Alatalo <[email protected]> wrote: > > On Oct 15, 2011, at 3:02 AM, Toni Alatalo wrote: > > > > >> Tundra 2.1.1 without any traces of old version and still I have some > problem with Avatar-demo. It looks like the Avatar-entity loses > mouse-inputmapper totally when its entitynumber is around 100 and up. > > > was not able to repeat this. Did this on Tundra 2.0 on Mac OS X: > > > > oh I think something weird did happen to me too: mouse scroll (to move > cam closer / further from av, the third person cam) continues to work, but > looks as if doing the rotation with rightbutton-drag stops working. > connected a mouse to the mac to be able to test better. > > > > will test on other platforms too later. > > > > as Jonne said there are scenes with hundreds of entities, which are used > with av app, and we haven't been aware of probs .. i guess people do use > mouse rotate for av so often that it would have popped out. is possible that > is a version diff, at least the admino hosting system has some modified > version of the av app. > > > > > ~Toni > > > > same. > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > -- http://groups.google.com/group/realxtend http://www.realxtend.org
