Forum rules - please read before posting.

How to use two Hotspot Detectors. (or simulate the second one)

edited November 2016 in Technical Q&A
Hi, I've been working on a project that has somehow gone VR. Now, I want to use the Player Vicinity feature so I can activate hotspots by touching them with a controller (simply by parenting the hotspot detector to the controller). I already have a way to fire AC's input using Vive VR controller events (and one to do the same but run actionlist assets instead), albeit they're still sort of green but work. Anyway, the problem I have is that AC's player only allows for one Detector... I need a second detector for the second controller too... so, how would I go about having another trigger that does the same as the regular hotspot detector? is there a way to have the AC player check two hotspot detectors? or will I need to somehow fake the second one? 

Anyway, as usual, any advice will be greatly appreciated.

Comments

  • Not without some custom scripting - you'd have to edit the DetectHotspots script to check the Trigger events of another object (i.e. placing the script on the left controller, and having it check for both).

    Are you sure you're in need of the Hotspot Detector method though?  All it really does is limit your interactivity based on vicinity - which should be built-in if you're physically selecting Hotspots with wands.

    As you're running ActionLists directly, I'd say you don't even need Hotspots - and could use your own intermediary script to convert controller "clicks" into ActionList activations.
  • edited November 2016
    ummm... the thing is that the game already has a lot of logic built-in from hotspots and I want to preserve all those if possible (game is practically almost done). It's a lot less trouble to get the controllers to popup the interaction and hotspot related menus when they get close to objects (and simulate interaction A and B, etc through the controls) than to redo all the logic for the entire game...

    Besides parenting a small Hotspot detector to the controller (in the VR rig controller 3D model) out to be enough to let the controller 3D model let highlight and open interaction and hotspost menus, without having to change the basic workflow in AC. I just think it'd be cooler to have both controllers have that functionality instead of just one. But I'll go ahead and take a peek at the Hotspot Detector script.

    By the way, what did you mean with "should be built-in if you're physically selecting Hotspots with wands." I'm using the SteamVR plugin with SteamVR Unity Tool kit as a base (setup for HTC Vive), but I didn't see any options in AC for, well, having hotspots automatically react to the controller 3D models which are parented to the VR rig object. Or where you referring to something else? ah maybe you were referring to the laser pointers?

    PS: Ah, and we are currently not using any pointers/cursor, just the vive controls (trigger/pad/button,etc). I want to avoid using pointer/cursor if possible (the guys in the team want for objects to be physically touched or picked up, not just pointed at...).

    PS-2: I mentioned "ought to" because I haven't tested it yet, though I don't see why it shouldn't work. (By the way, I haven't tested it because I don't own an HTC Vive... Sadly, I need to wait for a few hours so one of the guys can test the stuff  - the simulate AC input on controller events and run actionlist assets on controller events were already tested though).

    PS: Ah, and It's my first time working for a VR project so I apologize my ignorance, lol.
  • edited November 2016
    Think the second Hotspot detector will work if I just call it's _Update function from the Update() function in a monobehaviour script?

    The player script is practically just calling this:

    public DetectHotspots hotspotDetector;

    -inside an update-like function...-
    if (hotspotDetector)
    {
    hotspotDetector._Update ();
    }

    Or is the _Update function called inside the Player special? (it does mention it gets called from within the state handler, but is there anything different than a regular Update()?)

    PS: Lol, doing it that way seems to do something really interesting. It seems to create a "need" to hold it with both hands effect, which will be cool for some situations, though it's not what I had in mind xD. Anyway, I'll continue tinkering with the scripts later, it's rather late for me (or should I say, morning already, lol), but anyway, as usual any ideas or advice will be greatly appreciated.
  • edited November 2016
    What I meant was: the fact that you have to physically position the controllers in real-world space negates the need to manually disable Hotspots by proximity.

    But in terms of interactability, AC's Interaction system only allows for one Hotspot to be "selected" at a time - i.e. one Hotspot label, one Interaction Menu, etc.  Now you could still write your own system that incorporates existing Hotspots, but the fact remains you're still having to do this to a project that wasn't built with this system in mind when you were building it - so there's not going to be a "quick win" situation with this.

    That said, all of the main functions that AC's Interaction system uses are contained within the Hotspots themselves, including the ability to run associated interactions by icon ID number: see this page of the scripting guide.
  • Yeah, don't worry about it, lol. I just wanted to verify if I could get away with bending one of the current features to do it, but I was about to make custom solution anyways, lol. 
  • edited November 2016
    Ummm, just letting everyone know (for those who don't want to do any extra scripting), that the idea to use the hotspot detector to make only hotspots that "touch" the controller activate, really does work. But the result of my testing were a little inconsistent. I attached Hotspot scripts on some walls (which are just stretched cubes), but for some reason the hotsposts only activate when the hotspot detector is contacting/intersecting right at the center of the wall. Somehow the Hotspots don't activate if the detector is entering/intersecting only the edges (even though the hotspot should encompass the whole wall). This happens even if the Hotspot detector is not attached to the controls so I'm guessing something else is causing it. It's like the detector needs to be just in the right place inside the hotspot to activate it (by the way, the hotspot detector is like the size of a football, not the usual player size)...

    Still using the detector does work and gives the illusion that the controller is activating the hotspot.... We've also decided we want only the right hand to activate hotspots so I'll keep this option in mind. But for now I'll just make a custom script instead, cause sadly I can't afford the small inconsistencies in using the Player Vicinity/Hotspot Detector method. It might not be a problem for some other projects though.
  • edited November 2016
    Disabling the Interaction system using Engine: Manage systems Action would allow you to basically make use of Hotspots however you wish.  I think the ability to react to Hotspots with VR controllers would be something of interest to many people, so posting any code you write to the wiki would certainly be appreciated.
  • Alright, but first I'll have to get it working, right, hehe. Anyway, I'll have to check with the other guys in the team, though. Else, I'll try making a simplified version when I have the time.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.