Question Switching on and off UI toggles through scripts

I've been trying to make a feature where you can switch 2 cards by selecting them with a toggle, and after the switch turn off the toggles used for the switch. The first 2 card toggles don't turn off but the switch button that starts the action correctly does, am I missing something?

if(numberOfSelectedCards == 2) //Switching the 2 selected cards
{
cardObjects[selectedCardOne].transform.position = cardPlacements[selectedCardTwo].transform.position;
cardObjects[selectedCardTwo].transform.position = cardPlacements[selectedCardOne].transform.position;

cardSelectionToggles[selectedCardOne].GetComponent<Toggle>().isOn = false; //not working
cardSelectionToggles[selectedCardTwo].GetComponent<Toggle>().isOn = false; //

switchToggle.GetComponent<Toggle>().isOn = false; //working

numberOfSelectedCards = 0;
}

 

I wouldn't expect that mess to work ever. YIKES!!! That's crazy code.

If you have more than one or two dots (.) in a single statement, you're just being mean to yourself.

Putting it all one one line DOES NOT make it faster. That's not how compiled code works.

How to break down hairy lines of code:

http://plbm.com/?p=248

Break it up, practice social distancing in your code, one thing per line please.

"Programming is hard enough without making it harder for ourselves." - angrypenguin on Unity3D forums

"Combining a bunch of stuff into one line always feels satisfying, but it's always a PITA to debug." - StarManta on the Unity3D forums

Once you break it apart, NOW you can begin to reason about the code. Reasoning about the code involves:

- finding what's wrong
- finding why it is wrong
- fixing that

Anything else is just fooling around.

Time to start debugging! Here is how you can begin your exciting new debugging adventures:

You must find a way to get the information you need in order to reason about what the problem is.

Once you understand what the problem is, you may begin to reason about a solution to the problem.

What is often happening in these cases is one of the following:

- the code you think is executing is not actually executing at all
- the code is executing far EARLIER or LATER than you think
- the code is executing far LESS OFTEN than you think
- the code is executing far MORE OFTEN than you think
- the code is executing on another GameObject than you think it is
- you're getting an error or warning and you haven't noticed it in the console window

To help gain more insight into your problem, I recommend liberally sprinkling

Debug.Log()

statements through your code to display information in realtime.

Doing this should help you answer these types of questions:

- is this code even running? which parts are running? how often does it run? what order does it run in?
- what are the names of the GameObjects or Components involved?
- what are the values of the variables involved? Are they initialized? Are the values reasonable?
- are you meeting ALL the requirements to receive callbacks such as triggers / colliders (review the documentation)

Knowing this information will help you reason about the behavior you are seeing.

You can also supply a second argument to Debug.Log() and when you click the message, it will highlight the object in scene, such as

Debug.Log("Problem!",this);

If your problem would benefit from in-scene or in-game visualization, Debug.DrawRay() or Debug.DrawLine() can help you visualize things like rays (used in raycasting) or distances.

You can also call Debug.Break() to pause the Editor when certain interesting pieces of code run, and then study the scene manually, looking for all the parts, where they are, what scripts are on them, etc.

You can also call GameObject.CreatePrimitive() to emplace debug-marker-ish objects in the scene at runtime.

You could also just display various important quantities in UI Text elements to watch them change as you play the game.

Visit Google for how to see console output from builds. If you are running a mobile device you can also view the console output. Google for how on your particular mobile target, such as this answer for iOS: https://forum.unity.com/threads/how-to-capturing-device-logs-on-ios.529920/ or this answer for Android: https://forum.unity.com/threads/how-to-capturing-device-logs-on-android.528680/

If you are working in VR, it might be useful to make your on onscreen log output, or integrate one from the asset store, so you can see what is happening as you operate your software.

Another useful approach is to temporarily strip out everything besides what is necessary to prove your issue. This can simplify and isolate compounding effects of other items in your scene or prefab.

If your problem is with OnCollision-type functions, print the name of what is passed in!

Here's an example of putting in a laser-focused Debug.Log() and how that can save you a TON of time wallowing around speculating what might be going wrong:

https://forum.unity.com/threads/coroutine-missing-hint-and-error.1103197/#post-7100494

"When in doubt, print it out!(tm)" - Kurt Dekker (and many others)

Note: the

print()

function is an alias for Debug.Log() provided by the MonoBehaviour class.

 

Heya, well I'm only just starting with unity so I didn't even know you can split these actions into separate lines, I would appreciate to know how my code could look written well. What my question was, is there a mistake in the code because it all runs properly and does everything I wanted it to but it only skips the 2 lines I commented on.
Sorry if I'm asking for a lot, I just thought this forum would be the best place to find answers for my many questions

 

You're good dude, you'll find that Kurt is a well fine tuned hammer of information. Funny he didn't hit you with code tags:

Code (CSharp):

1. // class name
2.    // code, etc...
3.    // code, etc...

as it's much easier to read and understand seeing code the way it's meant to be wrote:
https://forum.unity.com/threads/using-code-tags-properly.143875/

But really depends on how many times you have to use the same GetComponent(), and just get it once for multiple uses. I would research into "Caching Variables", as it makes code faster and cleaner/easier to type out.

 

Ohh I see, will keep it in mind. Right so I don't have to get a component every time I would like to use it ?

 

Not if it's cached in some way, nope. But a simple example would be:

Code (CSharp):

1. Toggle toggle1 = cardSelectionToggles[selectedCardOne].GetComponent<Toggle>();
2. if (something) toggle1.isOn = false;
3. if (nothing) toggle1.isOn = true;
4. if (otherthing) toggle1.isOn = true;

But if you had a class of said card, you can cache all those things in that class, and then just get the component of said class(once), and say it simpler:

Code (CSharp):

1. // in main class
2. card1.SetToggle1(true);
3.  
4. // in card class
5. public Toggle myToggle; // set in Inspector
6. public void SetToggle1(bool check)
7. {
8.    myToggle.isOn = check;
9. }

 

Ah I see now, all tho I didn't get

Code (csharp):

1.  
2. Toggle toggle1 = cardSelectionToggles[selectedCardOne].GetComponent<Toggle>();
3.  

is Toggle a type of variable in Unity? never seen it before

 

It's a component. A component is basically a script, so "Toggle" is just the type(name) of that component(script), it's the thing you're calling that has the method of

isON

which you show you want to change true/false.

 

I don't believe there is enough code here to determine what is up But what I can see suggests that a custom class should enhance whatever your cardObjects and cardSelectionToggles are. The give away is that the positions and the Toggle component are not exposed and need to be "gotten". A little work should produce a method that can toggle two card objects if you pass their indexes and the <Toggle> wouldn't need to be fetched each time you need it.

 

As always, go straight to the Unity UI docs... none of this is seekrit.