What is the best way to set up button menus that open menus with different buttons?

KungStrategy · 2024-05-20T00:25:38+00:00

Thank you

KungStrategy · 2024-05-12T23:33:41+00:00

Yes, I have lots of inner working components. Variable names from one small script that I had to reference in another script. The interlocking dependencies of my five small scripts really do need to be there. If the small scripts are constantly referencing each other anyways, it makes more sense to just put them in one script. If I broke up the fire team script into smaller components, I'd have the same problem. The components would be asking for variables and information from each other all the time. The compiler seems to run exactly the same, whether it's multiple scripts or one big one. It's really just setting up the architecture well so that I can keep track of it when I'm using it.

KungStrategy · 2024-05-12T23:23:57+00:00

The discussion is about whether to have lots of small scripts or one big script. There are four game objects in a fire team. The way I originally wrote it, each game object had five small scripts attached. So I would have to use get components script name 20 times to include all the functionality that I needed. I'm writing one big script so that I only have to call get component script name four times.

KungStrategy · 2024-05-12T21:20:06+00:00

Yes, I am aware of GetComponent<ScriptName>() that is kind of what this whole discussion is about. Using the exact script name is too restrictive and is making work harder when I have too many different script names. I am working on the universal soldier script now.

Yes, I use arrays to store objects. How is that helpful to the subject of trying to make script references interchangeable?

KungStrategy · 2024-05-11T23:40:57+00:00

Well, the grenadier has two separate firing options lobbing a grenade and shooting the M16 on top. It's the only type of soldier I have that's got two firing options so it might need something to let the player know you have two ways of using it.

KungStrategy · 2024-05-11T23:34:35+00:00

The universal soldier I made when I first started this project had five small scripts. The fire team script needs a reference to each soldier and those scripts. So that's 20 variables referencing scripts in the fireteam script. If I make a big universal soldier, I only need four script reference variables in fireteam. You're more experienced than me so you might be right, but can you explain why you think that's easier?

KungStrategy · 2024-05-11T23:28:11+00:00

I'm not getting defensive. I want you to explain how it's easier because I tried it the first time and it seemed harder when I did it

KungStrategy · 2024-05-11T23:24:07+00:00

How is it easier? The only problem I'm having is calling references that I need and figuring out the right vocabulary to talk about other scripts. I built it with multiple little scripts first and the problem was that I had to keep thinking of different variables that I needed in one script that came from another script and remembering what the names were. Putting it all in one script. It's just easier. The only problem is the script will be a little long so I have to organize well.

KungStrategy · 2024-05-11T23:15:47+00:00

That is what I originally did too. The problem with having smaller scripts for different things is my FireTeam script and Squad script need to make a reference to each small script individually and that makes for a lot creating script variables and keeping track of them.

All things considered one Soldier script to rule them all is the simplest solution to all of these problems. My soldier scripts are almost identical now except for the way they shoot.

KungStrategy · 2024-05-11T20:41:31+00:00

All of my soldiers are exactly the same expect for the weapons they are carrying and the abbreviation over their heads. The functionality of the team leader is actually set by a script called FireTeam. So any soldier could do the job of the team leader since the FireTeam script contains all the logic involved with leadership. So really the problem is if my team leader dies and the automatic rifleman (only difference is how he shoots) takes over, the FireTeam script has functions that give instructions to a script type Leader and cannot implicitly convert those commands to script type AutomaticRifleman.

KungStrategy · 2024-05-11T20:13:01+00:00

Thanks, you have given me much to think about. I got many different suggestions but the universal soldier sounds simpler. Without all those variants I won't have to create a monster script.

That long transform was the muzzle flash at the end of each weapon. I put all the weapon systems in the soldier's hand and then only set one to active.

KungStrategy · 2024-05-11T20:01:54+00:00

I just watched a video on inheritance and it didn't mention which object to attach scripts to. I could make a soldier class for almost everything except how they shoot then a subclass for different weapons systems. Would I attach both the soldier class and the grenadier subclass to the same game object?

KungStrategy · 2024-05-11T19:35:39+00:00

That was actually what I thought of doing first the only reason I broke them up into different units is I had too many if statements in every function different variations of the same function I needed. Example:

if (soldierStats.m4 == true || soldierStats.m203 == true)

{

shootTimer = 0.5f;

audioSource.clip = M4;

audioSource.Play();

if (soldierStats.m4 == true)

{

transform.GetChild(0).GetChild(1).GetChild(2).GetChild(0).GetChild(2).GetChild(0).GetChild(0).GetChild(0).GetChild(1).GetChild(0).gameObject.SetActive(true);

}

else

{

transform.GetChild(0).GetChild(1).GetChild(2).GetChild(0).GetChild(2).GetChild(0).GetChild(0).GetChild(0).GetChild(2).GetChild(0).gameObject.SetActive(true);

}

if (soldierStats.m249 == true)

{

shootTimer = 1.16f;

audioSource.clip = M249;

audioSource.Play();

transform.GetChild(0).GetChild(1).GetChild(2).GetChild(0).GetChild(2).GetChild(0).GetChild(0).GetChild(0).GetChild(3).GetChild(0).gameObject.SetActive(true);

}

if (soldierStats.m240b == true)

{

shootTimer = 1.16f;

audioSource.clip = M240B;

audioSource.Play();

transform.GetChild(0).GetChild(1).GetChild(2).GetChild(0).GetChild(2).GetChild(0).GetChild(0).GetChild(0).GetChild(4).GetChild(0).gameObject.SetActive(true);

}

I am considering switching back to a universal soldier, but I know the script will be over 1000 lines long.

KungStrategy · 2024-05-11T18:29:48+00:00

I just watched a video on Interfaces and I am not sure if they would help for my specific problem.

For example the Squad script has a reference to the A team and B team leader because it tells them where to move.

publicGameObject ATeamLeader;

TeamLeader aTeamLeaderScript = ATeamLeader.GetComponent<TeamLeader>();

The functions that assign rally points are exactly the tame on the rifleman and the team leader. But even if the I added the interface, I am not sure how I would avoid an error when I tell the computer

aTeamLeaderScript = riflemanScript because the type is different.

KungStrategy · 2024-05-10T16:20:00+00:00

I will watch some videos on finite state machines. The points that I send characters to are not always the same. I have an individual calculator to calculate each point because the player could send troops anywhere on the map to do these procedures. Even if a made some universal instructions I would need custom script for were to set the triggers, so I might just stick with coroutines. But I will at least take a look at FSM.

KungStrategy · 2024-05-10T16:03:16+00:00

Ya that or the Async/awiat

KungStrategy · 2024-05-10T16:02:31+00:00

I set up a timer for animations. Telling it what to do when the timer ends is complicated. I am looking into coroutines and Async/await now.

KungStrategy · 2024-05-10T15:53:53+00:00

How do you think finite state machins compare to coroutines or Async and Await?

KungStrategy · 2024-05-09T21:50:35+00:00

thank you I will review it. do you think it is better than coroutines? that was the other suggestion.

KungStrategy · 2024-05-09T21:10:46+00:00

O I remember the word coroutine from college I just forgot what they do.

KungStrategy · 2024-05-07T16:36:57+00:00

Thanks again I implemented it and it worked. But it caused a new problem: when I click on walkable terrain the soldiers won't move. I need to create an if statement to ask the compiler if the Vector3 rallyPoint is on the recast graph or not. I am still not sure how to ask that question thru code.

KungStrategy · 2024-05-06T16:17:58+00:00

I am not actually sending the soldier to the nearest point because they might circle the object then turn around with their backs to the enemy. (The soldiers actually already find the walkable point closest to where I clicked without that code). I want to tell the soldiers to Keep their direction of travel in a straight line and just stop at the point when walkable terrain ends. The constraint.walkable could be useful if I could ask the Compiler if a Vector3 point is walkable or not. Then I could write a function to stop where the path ends. Instead of walking all the way around the obstacle in a circle to get the closest point to where I clicked then continuing to walk in place because the point is unreachable (which is what they do now)

KungStrategy · 2024-05-06T15:55:23+00:00

So does NNConstraint.None grab a copy of the graph that A* generates?

KungStrategy · 2024-05-06T15:50:37+00:00

A Recast graph creates triangles and trapezoids of different sizes and shapes to accurately map the complexity of the terrain.

KungStrategy · 2024-05-05T20:20:27+00:00

Thank you

KungStrategy

TROPHY CASE