Was mean to say inputEvent.handled = true; when you use the input events from the mapper.GetInputContext() directly.
http://realxtend.org/doxygen/class_mouse_event.html http://realxtend.org/doxygen/class_mouse_event.html#a79db1699ac80c530e34a21453de0349e http://realxtend.org/doxygen/class_key_event.html http://realxtend.org/doxygen/class_key_event.html#a8d20c553f74dedee87aa160b3901a60e Best regards, Jonne Nauha Adminotech developer On Sun, Oct 16, 2011 at 11:03 PM, Jonne Nauha <[email protected]> wrote: > 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
