playMaker

Author Topic: NGUI Button/Element Feedback  (Read 4606 times)

artician

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 298
    • View Profile
NGUI Button/Element Feedback
« on: December 07, 2012, 03:04:49 PM »
Hello,

I need a way to acquire feedback from NGUI buttons when they're clicked/touched.  I have tried several methods but have found nothing that works.

The issue is: My project has a large number of elements (~200-1000), so having a unique Event for each element to report to the playMaker FSM (the way that the UIEventsToPlaymakerFSM script expects) isn't feasible.

What I need is a reliable method to identify whatever element/button has been clicked by the user.  The most recommended method was to use the gameObject variables in the "GetEventInfo" action, however this action just returns whatever gameObject is housing the FSM component that receives the event.  It doesn't return the gameObject that sent the event, unfortunately.

I have tried several other methods such as using ScreenPick, RaycastHitInfo, MousePick and MousePickEvent actions to return whatever gameObject the click/raycast collided with, but have had no luck getting any return from NGUI objects.

Can you please recommend a way to get one of the above methods to work correctly, or suggest another method? 

Thank you as always.

DARK_ETERNAL

  • Full Member
  • ***
  • Posts: 110
    • View Profile
Re: NGUI Button/Element Feedback
« Reply #1 on: December 07, 2012, 04:03:22 PM »
Template FSM which captures the name of the object and send template info? I mean, you can build a string using the name of the object and a "User pressed this button" string.

The other thing is to do with a custom action. Since I haven't worked with NGUI, but with EZGUI instead, I'm pretty sure NGUI should have a function to get when user makes input on a button. I don't know, EZGUI has some events that fire when button state changes. Does NGUI have such? If so, it'd be easier to write a custom FSM that does such thing, calling the native NGUI function.
Check out our new game: Nitro Chimp. Now live in App Store!

Trailer:
Download: https://itunes.apple.com/app/nitro-chimp/id557150450?l=en&mt=8

artician

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 298
    • View Profile
Re: NGUI Button/Element Feedback
« Reply #2 on: December 08, 2012, 10:40:45 AM »
Thank you for the reply.

Are you saying there is an existing Template that does this?  Otherwise I don't understand what you mean by using a Template FSM as a solution.  I would create an FSM to do so, but that still leaves me without an action to capture the gameObjects name, which is the specific problem I'm encountering. 
At the moment I'm looking at having every button have its own FSM, and then sending the PlayMaker event to itself, which then sends the event to my main FSM.  Hopefully that method will allow me to identify the gameObject sending the events properly, but that's still several hundred/thousand GUI/FSMs in one scene. 
There must be a better way to do this.  I expected there to be an action that took care of this already, or for Alex or Jean to update the NGUI PlayMaker script at some point because its thread is still "WIP", but I've had very little in the way of suggestions or replies even to let me know if I'm going about it completely wrong. 
Creating the custom action to do this is looking like my only option, but that means asking the community for support again anyway. ;)

Thanks again.

DARK_ETERNAL

  • Full Member
  • ***
  • Posts: 110
    • View Profile
Re: NGUI Button/Element Feedback
« Reply #3 on: December 10, 2012, 07:40:08 AM »
I'd do so. Seems to be the right way to achieve your goal.

For the template, I mean, you have an FSM with a state that gets the owner's name (if you say each button has an FSM) and build a string with that. The only thing I think might be a problem is how you receive the NGUI button input; and is a problem for me because I haven't worked with NGUI, but with EZGUI instead. But, assuming you already get the input event from your buttons, you just need to transit to a state which does what I described above. Making a single FSM and storing as a Template FSM is a Playmaker Feature, so you don't need to repeat the same FSM, if you needed many of the same FSM.
Check out our new game: Nitro Chimp. Now live in App Store!

Trailer:
Download: https://itunes.apple.com/app/nitro-chimp/id557150450?l=en&mt=8

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15082
  • Official Playmaker Support
    • View Profile
Re: NGUI Button/Element Feedback
« Reply #4 on: December 14, 2012, 04:38:39 AM »
Hi,

Ok, I think I know where you get stuck, and it can be solved very elegantly without going wild into custom actions.

 your button should target a fsm on that button, and have a button prefab as is. Then you can implement a dedicated reference system that in turn call your sys_projectManager.

in short, building "Manager" this way will always give you trouble down the line and you will end up with spaghetti fsm with lots of hardcoded referencing where if you give your buttons more responsibilities, it all becomes a lot cleaner and easier to maintain.

sub fsm in this case would be an very clear example. If you define in your button prefab a reference to the kind of behavior that is expected, then when a button is instanciated, you can assign to ait a sub fsm matching the expected behavior, so you end up with one button prefab, and several sub fsm template. Very powerful!


Does that make sense? Are you part of the beta?

bye,

 Jean

artician

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 298
    • View Profile
Re: NGUI Button/Element Feedback
« Reply #5 on: December 14, 2012, 07:47:27 AM »
Hi Jean,

Yes that makes sense, and it was a solution I arrived at also, however that would mean I may have up to 1,000 - 10,000 FSMs in my scene.  Will that not cause performance issues?  I will test it later today.

Do you need me to send you another package?

I think I am in the beta, but unfortunately, and I feel really bad about this, I have never been able to participate due to time.  :(

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15082
  • Official Playmaker Support
    • View Profile
Re: NGUI Button/Element Feedback
« Reply #6 on: December 14, 2012, 08:31:09 AM »
Hi,

 Don't worry about beta, we all have these "time" problem as developer, this is fine, don't feel bad about it.

I don't think it's realistic to build any game that has more thousands of gameObjects ACTIVE at a time. It's clearly a alert that optimization at the core of the application is required. you should always optimize this and at the very least disable all gameObjects and fsm not currently active.

 Can you tell me more about them 1,000-10,000 fsm? is it elements in your scene, players? ennemies? at a given time, a  layer only have so much gui element on screen, 200 elements is already A LOT, that is including layout gameObject etc etc. one way to optimize this is to have less items per screen and some menus and wizard to take a more discrete approach to gui.

Same with actual content, "active" content should always be kept minimal, you can't really expect 1000 ennemies running and firing after you isn't it? You may have 10,000 objects in your projects globally, but they will likely not be all active/loaded at a given time.

Also, bare in mind that it may slow down during editing, but the only true performance test must be done when published. Even Unity own interface dramatically slow down perfs, PLayMaker editing interface is no exceptions. When running, PlayMaker is nothing less than c# all the way and will be just as efficient as any other frameworks in place. It will have an impact because more classes and variables are used to run the framework, but it's clearly incomparable to what you experience during editing.

bye,

 Jean

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15082
  • Official Playmaker Support
    • View Profile
Re: NGUI Button/Element Feedback
« Reply #7 on: December 14, 2012, 08:41:29 AM »
Hi,

 the likely best to go about this right now without you doing a lot of re factoring would be to modify the ngui bridge to allow for a "reference" string that would be passed in the event, so that when your sys manager receive that event is would get the string value and it would be the button reference.

 would that work for you?

bye,

 Jean

artician

  • 1.2 Beta
  • Sr. Member
  • *
  • Posts: 298
    • View Profile
Re: NGUI Button/Element Feedback
« Reply #8 on: December 15, 2012, 01:15:27 PM »
Okay, lots to reply to, but for the most part I think I can work it out with what you've suggested.  For one thing though: I actually do use multiple FSM's for various components in the game, but I generally have a "projectManager" gameObject that manages all the other parts.  It's clean enough, and was easier for me to have a single point of reference that everything must pass through.

To explain the project a bit - basically this is an app that records user input, and then displays a record of the recorded history at a later time.  Each user has a session ID, and then 15-20 variables store each sessions details. 
This is for public use though, so the number of sessions can go well into the thousands.  In fact I scripted it so it can record up to 99k records (to be dumped to a text file or database later), to give you an example.
The issue I encountered was when I created the interface to display the records. 
The application only loads the session ID's at first, and assigns each to a button element in the GUI.  The details of the session are loaded when a session ID (button) is selected.  Because of the potential number of session ID's, I didn't want to load a list of 10k ID's, and have 10k buttons each with an FSM on them, just to convert the event ID for the display script. 

From everything you've told me so far, it just sounds like I need to test that method, or simply move to a system that only loads a few session IDs at a time, which isn't too much trouble.  I was just hoping I could retrieve each gameObject easier, because I felt that there must be a simple way to do so. 

Thanks for taking the time to look at the situation and suggest different solutions.