shoot insted of rotating camera at the left mouse button

[Demian]

Hello! I'm trying to make 3rd person shooter game. Decided to use ArcRotateCamera, but left mouse button rotates the camera. I need only shoot without rotating. Is there any way to disable rotation? Sorry if such question already was, but searching gave nothing.

[max123]

On 8/26/2016 at 6:39 PM, Nabroski said:

What is happening here?

http://threejs.org/docs/#Reference/Cameras/PerspectiveCamera

you have to resize the engine
http://doc.babylonjs.com/classes/2.4/Engine

you have to make you own input in babylonjs https://doc.babylonjs.com/tutorials/Customizing_Camera_Inputs
to detach the mouse wheel event from a oberver etc trigger

or use the javascript event handlers, 

http://www.babylonjs-playground.com/#TVP56#0

edit you already in changing the the fov mod .... perdefault
http://www.babylonjs-playground.com/#LYWVE#0

 

the answer from another topic.

[Demian]

max123, thanks for answering. But, I actually didn't find answer on the question - how to disable rotation camera at the left mouse button. The third link about camera inputs. There is mouse.detachControl() method, but it disables three mouse buttons, and I need only left one disabled. And other links about nothing. Or maybe I missed something?

 

[GameMonetize]

Hello @Demian

To deal with your issue you can either update the mouse input or udpate it:

https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/Inputs/babylon.freecamera.input.mouse.ts

 

[Demian]

Deltakosh, thanks for answer. I think I've found a solution. I've updated another class https://github.com/BabylonJS/Babylon.js/blob/5d8a17c6357ebf286b14f3e65eb8b6a1790abf89/src/Cameras/Inputs/babylon.arcrotatecamera.input.pointers.js. Tried to make it on playground, but some mistakes occured. After string

var evt = p.event;

wrote a condition only for the 2nd mouse button:

var evt = p.event;
if(evt.which == 2){ 
  ...
}

 

[Wingnut]

Hi guys.  Here's a playground for this issue.

http://playground.babylonjs.com/#EAIRW

This is really good code to learn things about our camera inputs system, and I'm quite impressed that @Demian jumped right into it and started doing test modifications.  Cool.

Included in the playground is the entire https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/Inputs/babylon.arcrotatecamera.input.pointers.js source code, unmodified.

This should work IF Demian wants to show us his modification, and we all can look at it, and do more tests.  Perhaps Demian is the first of many... to want this option. 

SO, Demian, everyone, do experiments, make more playground saves, paste the new URL's from the saves... here, and tell us about discoveries.  I always wanted to learn more about the camera inputs system (which is somewhat new to BJS), and this playground series will help.

Particularly, let's see if we can invent a way to make it super-easy for Demian and future users with similar requirements... to solve this.  In other words... let's see if a property like babylon.arcrotatecamera.input.buttonMask    ...could be considered...  to make this issue/feature easier to solve/do.

(I'm trying to gather a "campfire discussion group" around your issue, Demian.  Sometimes, cool things happen at these little forum gatherings.  Sometimes not.)    Be well, talk soon.

[Pryme8]

26 minutes ago, Wingnut said:

(I'm trying to gather a "campfire discussion group" around your issue, Demian.  Sometimes, cool things happen at these little forum gatherings.  Sometimes not.)    Be well, talk soon.

I'll bring the s'more snaups and smokables...

[Demian]

Well, Wingnut, thanks for supporting this issue and for the playground demo. So, here is what I have http://playground.babylonjs.com/#EAIRW#4. The 21 string had been added. But there is a problem. In Opera and Chrome this code works fine. In Firefox and MS Edge doesn't.

[Wingnut]

Good investigating, Demian.  Yeah, that if(evt.button == 1) might not be sufficient to cover all browsers.  hmm. 

Demian, have you thought/wished browser context menus would NOT activate with RIGHT click upon canvas?  

Then you could use right-mouse-button-drag (heretofore 'rmbd')... to pan camera?  Or even use center mouse button drag (heretofore 'cmbd').... to pan cam?  In brief, even when your left mouse button is the FIRE button, do you still want to allow camera panning?  Use a different button for that?  Thoughts?

    Flow:
- Disable browser-based popup context menu... when RIGHT click on canvas (clear the rmb binding).
- Move current LEFT mouse button operations - to RIGHT(or middle) mouse button (sort of like swapping mouse buttons).
- Clear all LEFT mouse button bindings, and let programmer have that for game stuff (fire button, etc).

Boy, if we could do all that... in 1-2 lines of easy code... in all browsers... and not break VR/gamepad/deviceOrient/touch... that would rock. 

This issue reminds me of the device-inputs/camera-inputs "patch panel" idea I once had.  It got no traction (no core programmers leaped in delight from the idea).    That's common for my hair-brained ideas, though.  heh 

Let's keep thinkin'.  Wonderful solution by Thursday?  EASY!  (ahem).

Wanna hear a funny story?  I knew ya did.  Sometimes I proof-read new docs (written by others), and make minor adjustments.  When the new camera inputs system arrived, I thought it sucked, and still do, essentially.  Un-intuitive, impossible to teach or remember the commands-for, long property and func names with 10 periods in each name... just... crap (as viewed from the user's perspective.  Code-wise, it could be wonderful. I wouldn't know.) 

I am a heavy-custodian of the BJS Cameras Tutorial, and I was REALLY hoping for some new inputs versatility that was very easy to teach (a patch panel).  Instead, the new system made the teaching much more difficult.

But I decided to give it a fair shake (give it a chance)... and try to learn it, and then later, see if I STILL thought it sucked. 

ANYWAY... during the "tweaking" of the Custom Inputs Doc, I thought that the document needed a "wrap-up"... a little sentence at the bottom.  See what I wrote?  

"Composable inputs is new, powerful, flexible, and extensible. Familiarize yourself with its simple interface, and you will enjoy more and better camera control than ever before"

Yep, just a line of BS advertising fluff.  I said the exact opposite of what I actually thought.  I didn't know if the new inputs system was powerful, or flexible, or extensible.  Hell, I just met it... how would I know?  But now... with Demian's issue... we will test my cock'n'bull advertising line.  IS the custom camera inputs system... ANYWHAT flexible?  Can it swap buttons, put LMB ops on RMB, and vice-versa?  In 3 lines of code or less?  hmm.

I put my own nuts in a vise, eh?  (put myself under extreme pressure).  Possibly, we will expose ME as "full of crap", right here, in this thread.  heh.  But then again, me being exposed as "full of crap"... is also commonplace, so I guess everything is normal. 

There ARE a few noteworthy things about the new custom camera inputs system.  First, it lets you do just what it says... build your own custom camera inputs... which sounds very promising (I have never done it, though).  And, a class called the UniversalCamera was introduced... and that... ALSO sounds promising.  Perhaps the new custom camera inputs system really IS powerful, flexible, and extensible.  Still learning. 

[Demian]

Wingnut, thanks for very interesting story) Now everybody knows how tutorials are written) So, about mouse. I can disable mouse and make panning from keyboard. Then assign shooting with left mouse button. I think it will be good to make mouse buttons for different actions, like shooting, alternative fire, panning, walking, running, zooming, changing weapon and so on.

[Wingnut]

Yeah, me too.  But those other input devices (fancy ones) seem to have removed the possibility for easy input routing.  For example, VR headsets.  Are they using device orientation?  Or do they have a mouse/gamepad active at the same time?  Do they ever use a "thimble" on a finger... that you drag through the air?  Only the Vive uses hand controllers with vr headset, not Occulus?  What about that Google cardboard thing?  Do people use trackballs at the same time as headsets?

What about touch screen/pad?  Which values... are patched to which arcRotateCam or universalCam properties?  How does the angularSensibility of a BJS camera... ratio-with the angular sensitivity of an Occulus head-turn?  Maybe there is a pad device, with BOTH touchscreen (pad swipe) and deviceOrientation abilities (at the same time)? 

What if the user wants to use touchscreen to control the .beta of the arcCam, and deviceOrientation (tipping the pad device side-to-side) for the .alpha?  How does the "wire-up" (configuration) procedure happen for that?  Would such a config give us a tumor by thinking about how to code that? 

And then... of course, great programmers want to give the USER... the abilities to config their input prefs THEMSELVES.  Can we give users a menu to config their inputs "patch panel"?  Can we draw them a diagram/map of their current input routing.  What happens when a user/programmer accidentally routes devOrient and a joystick X axis... to an arcCam .alpha... at the same time?  Are we even honoring joysticks?  Trackballs?

Perhaps, what I speak-of... is a layer above/atop custom camera inputs... and it just hasn't been coded by anyone, yet.

Personally, I love joysticks... non-auto-centering analog ones, auto-centering digital ones, and combinations of both happening at the same time (one analog joystick to set a throttle value and keep the joystick in its non-auto-centered position... and another auto-centering digital joystick... for flying or driving.) 

Got some cross-winds?  Pull the analog throttle joystick left or right a bit (it stays there) to set a yaw trim (crab the plane into the wind a bit).

Analog joysticks are good for driving, too, though.  If you drive trucker games, you want to hold that joystick in one place... to match the curvature of a highway turn.  Anyone who has driven cars in the Grand Theft Auto realm... knows that you have to keep "working" the mouse or keyboard... to match a highway curve (sucks). 

Analog joysticks are very cool.  Does anyone care about them anymore?  Do browsers cough them out like a Yak hairball?    Are they even available anymore?  I'm not sure if steering wheel input devices... use them.  Are steering wheel controllers... analog?  Or digital/auto-centering?  I wouldn't know.

What about joystick Z axis (twist)?  What about the flight sticks that have a throttle analog pot already installed?  Are we counting on end users... using their joystick config software... to do all the routing THAT way? 

There seems to be "patching" available at all sorts of layers, eh?  I think the BJS core programmers are following a "standard".  But, as the world of input devices grows and grows... we're going to get more questions.  "How do I hook my K41 Super FlightStick console pitch-trim control pot... to my mesh?"    I just start crying when I see forum friends ask questions like that.  heh

Making a skiing game?  Oh goody.  Do we need inputs from a floor board that users stand-on?  AND we want to wear an Occulus headpiece at the same time (good way to fall over in your house for no real reason)   Are we ready for the potential input device configuration festival that the future of web3D has on the horizon?  Is it our job to BE ready for that?  Is it some other layer's problem, not the problem of BJS Scene class?

There are value ranges and sensitivities/sensibilities fun to come, too.  When user detaches his Occulus, does the system see the detach, and fallback to the next input device available, such as a joystick?  Is the range of values coming from the analog or digi joystick.... sane?  Or do they still have the ranges and sensitivities of the Occulus... and so the joystick fallback works like crap?

It's a big big big subject.  The browser has its fingers in the pie (is heavily involved), too.  BJS only gets full control and monitoring of input attaches and detaches... IF the platform, and the browser software... don't impede.  Do plug'n'play events propagate to JS?  Can they cascade all the way to BJS Scene class? 

BJS could see the detach/attach of all input devices, and programmers could adjust the camera sensitivities to match.  Or they might have to invert some axes.  I really don't know much about the status of these things... but if we want a really powerful future for our cool scenes, we have work to do.  We have another layer to code... and it must speak browser... and perhaps Klingon.    And how does jQuery get involved in all this?

I'm glad there's work-arounds.  For now, I suppose our scenes will need buttons for the user.  Switch to this mode, switch to that mode, ertc.  The scene wouldn't listen to the input devices being attached/detached, but instead asks the user what the current config is.  *shrug*

Just thinkin'.  Nothing profound.  Sorry for yapping so much in your thread, Demian.  I just want BJS inputs to be as easy and powerful as possible, and I dream big.