koobas.hobune.stream
Raycast and OnMouseButtonDown combination problem
My game is your typical point-and-click adventure puzzle game. You have an inventory of items that you can select and use on your surroundings. I'm having trouble getting my code that will allow you to use an item on something else in the scene.
Using the debugs it appears that the raycast is working correctly, so it appears that the GetMouseButtonDown(0) is where I'm running into problems. I also tried GetButtonDown("Mouse X") but that didn't work either.
I've gotten one iteration of this code to work when I applied it to the object, however it stopped working whenever I made a build or closed unity and opened it up again. It was very strange... Thanks in advance for any help!
var camera2 : Camera;
var inventoryDropDown : inventory_drop_down;
function Update(){
//sees if the candle is selected from the inventory and to make sure the main camera is enabled and not one of the zoomed in ones
if (inventoryDropDown.item_candle == true && camera2.enabled == true){
interact();
}
}
function interact(){
var mousePos : Vector3 = Input.mousePosition;
var ray : Ray = camera2.ScreenPointToRay (Input.mousePosition);
var hit : RaycastHit;
if (collider.Raycast (ray, hit, 100.0)){
Debug.Log ("candle is hoving over curtains");
if (Input.GetMouseButtonDown(0)){
Debug.Log("Interacted with Object. fun times.");
Destroy(gameObject);
}
}
}
Do you want it to be a single-click thing, or a constant hold thing? What exactly is the failure mode?
Single click is what we're going for. I'm sorry, what do you mean by failure mode? I'm new to coding, so I'm pretty ignorant of a lot of the lingo.
Sorry, that wasn't programmer lingo- it was engineering lingo. I sometimes forget that not everyone is constantly surrounded by engineers...
By 'failure mode' I mean the exact circumstances and method my which it fails. The assumption is that if something fails, it will fail in a way that is identifiable and quantifiable. A 'failure mode' is a way of identifying specific types of failures (so that you can apply certain troubleshooting patterns to them depending on the mode).
From the looks of things, the object should delete itself if you click the left mouse button while hovering over the 'curtain' object. I assume from your question that the 'hovering' is working correctly- which makes this a tricky one, because I'm not aware of any way in which Input.Get$$anonymous$$ouseButtonDown can fail on you like that! It's possible that there's something else going on here. Do you have any GUI code that might be interfering with the mouseClicks? Any GUI component that receives mouse clicks can prevent Get$$anonymous$$ouseButtonDown from working (because it eats the UI events). Try disabling all the other objects in the scene, and see if it works then.
Ah okay, yeah the failure mode appears to occur when it tries to access the Get$$anonymous$$ouseButtonDown. I took your advice and disabled all the scripts containing OnGUI and the above code now works. Thank you! I did not realize that GUI could screw with the Get$$anonymous$$ouseButtonDown function.
Is there a way to get around this problem? The way I have the inventory set up is that you can mouse over the top part of the screen and it comes down. You can then click on an object and it becomes the cursor to indicate that it's the object you're about to use. Would I have to design another way to use items? I uploaded a screenshot to my original post so you can see what I mean.
you need to get the "if (Input.GetMouseButtonDown(0)){" into the update function.. Try this:
var camera2 : Camera;
var inventoryDropDown : inventory_drop_down;
var canInteract : boolean;
function Update(){
//sees if the candle is selected from the inventory and to make sure the main camera is enabled and not one of the zoomed in ones
if (inventoryDropDown.item_candle == true && camera2.enabled == true){
interact();
}
else
canInteract = false;
if (Input.GetMouseButtonDown(0) && canInteract){
Debug.Log("Interacted with Object. fun times.");
Destroy(gameObject);
}
}
function interact(){
var mousePos : Vector3 = Input.mousePosition;
var ray : Ray = camera2.ScreenPointToRay (Input.mousePosition);
var hit : RaycastHit;
if (collider.Raycast (ray, hit, 100.0)){
Debug.Log ("candle is hoving over curtains");
canInteract = true;
}
else
canInteract = false;
}
No, I'm pretty sure that's not it. The Input function is already inside Update- Update calls to 'interact', and the Input function occurs inside that. There's nothing that says that you can only put Input functions directly inside Update- they work perfectly well outside of there so long as the stack eventually leads back there. In any case, there are bugs in this code. If the camera gets disabled, or the inventoryDropDown changes while the mouse is over the object, canInteract will remain true.
ok, logic wasn't perfect, bug was easy enough to fix though (fixed it now).. I still think this may be the issue though..
Or not, you may be right
I think there's something else happening here. What you've done there is a simple enough refactoring, but it doesn't change anything about what actually gets called when (it just rearranges the parts of the code). Here's a slightly cleaner alternative:
function Update(){
//sees if the candle is selected from the inventory and to make sure the main camera is enabled and not one of the zoomed in ones
if (inventoryDropDown.item_candle == true && camera2.enabled == true){
if (interact() && Input.Get$$anonymous$$ouseButtonDown(0)){
Debug.Log("Interacted with Object. fun times.");
Destroy(gameObject);
}
}
}
function interact(): boolean{
var mousePos : Vector3 = Input.mousePosition;
var ray : Ray = camera2.ScreenPointToRay (Input.mousePosition);
var hit : RaycastHit;
if (collider.Raycast (ray, hit, 100.0)){
Debug.Log ("candle is hoving over curtains");
return true;
}
return false;
}
touche... Anyway, you're probably right about the GUI thing, you seem pretty sure of yourself :)... Still, I would start with this, to eli$$anonymous$$ate the possibility..
Well, I'd never be one to turn down good troubleshooting, so it's worth a shot. Even still, I'm convinced that it's not that. If I had a Unity installation on the computer I'm using right now, I'd check it myself, but until then it's up to the original poster to decide what works and what doesn't.
