Tbh at this point I don't know the difference between a coroutine and a method.
Also in your post you say you'd have it check the levels, what does that mean?
Coroutines don't run on the main thread, so they run 'when they can' (which is pretty much instant on modern multithreaded cpus) but in terms of flow control are pretty useful as they don't stop until their condition is met; so you've probably seen them mostly being used as mini-timers, with something like
[ienumerator,thing]
dostuff;
yield return new wait for seconds 5;
do some more stuff;
end code block
but you can make the yield condition pretty much anything you want; they're pretty useful.
For the level stuff, you can check level load progress, and instead of doing fixed time waits could do it as like, level loaded 20% this, level loaded 40% that, etc is what I meant.
Oh yeah if you need free photoshop: check out
www.photopea.com its basically web based photoshop
So I want to add a "Lives: 0" display in the UI to show the current lives outside of the debug screen.
The int with currentLives is in the health.cs script attached to the player.
The UI Display is in a separate script and using the class UIElements to override updateUI to display a text string. I can't get this to work under the health.cs script since it won't let me have the script be a child of MonoBehaviour and UIElement.
The simple thing would be to figure out how to grab that int currentLives that is on the Player in the Health.cs script from my Display script. But this is a bit beyond me and goes back to trying to get separate scripts to interact. I can find the gameObject that is player with Find.gameObject.Player, right? So how do I go from there to getting the variable from a script that's attached to it?
Not sure I'm following this, and it might just be using different terms, so lemme try and break this down with how I'd do it at beginner level;
So first off, when you say 'child', in Unity, a child object is like, attached to a 'parent' object, and its like a physical relationship in the heirachy; they're like folders and subfolders in windows explorer.
in code, when you do myclass : monobehaviour, youre not making it a child of monobehaviour, you're using whats called inheritance to get default code that you can overwrite - so like, all the builtin methods like update() onstart() oncollision() etc are all premade monobehaviour methods.
If you really want to inherit from multiple classes, you actually can't, but you kinda sorta can by using whats called an interface, but tbh I think this is a running before you can walk type of thing you don't need to do just to do UI stuff, so lemme show you an alternative and I'll cover interfaces if you do really need it?
You're best off - to start with - thinking about unity almost like plumbing; you set up the variables you're gonna want in script, but you then manually connect up the object refernce onto your script by literally dragging and dropping it, rather than doing finds for everything.
So if you have a UI Text component onscreen, you can make this script;
using Unity.UI; (this lets you acces the UI.Text directly)
class UI_Timer : Monobehaviour
{
public Text uiTextElement;
int timerValue=0;
Update()
{
uiTextElement.Text = "Timer: "+ timerValue;
timerValue++;
}
}
and drag and drop your Text Gameobject onto the Text variable space, and when you run it you'll have a running timer in that text field
Does that make sense? For updating UI information, as its onscreen all the time anyway, you dont actually need to 'search' for it, you can just point directly to the gameobject - this really is the easiest way of doing this stuff at this stage and for low complexity games
Sage, any chance you're available for a bit today to help me on some stuff? There's just a link of code that I don't know yet which is blocking off a ton of possibilities by having things interact with each other and I need help figuring that out if I want to do more interesting things with my game.
Like I'm trying to have a 3d polygon object attack the player in this 2d game. The problem being the physics colliding interaction between a 3d object and 2d object. Initially my bullets passed right through the 3d object even with the 3d collider on. I googled it and the get around I found was you make a hidden 2d object within the 3d object (as a child gameobject) and throw on the 2d rigid body & collider.
I've been drinking, so lemme get back to this tomorrow, but just make sure you're seperating 'FORM' and 'FUNCTION'; if you wanna combine 2D objects and 3D objects, that don't mean shit if its only the
visuals you're talking about, but you're gonna fuck stuff up if you start trying to use both Collider and Collider2D and Rigidbody and Rigidbody2D in the same script (or at the very least gonna make stuff way more complicated than it needs to be
So let's break this down to basics again; (also I don't think you need to care about child shit - if you destroy the parent object, the child goes with it)
So make a 3D Cube game object in the hierachy, then right click it and make a Sprite (or a Quad if your image is a texture not a Sprite).
When you right clicked it, you made it a Child of the based 3D cube.
Turn off / remove the mesh renderer on your cube, and you have an invisible 3D box as your parent.
If you put your movement script on that invisible box (and a Rigidbody), all your collisions and code will affect that invisible 3D cube, but from the players perspective, all they see is the 2D child object (because the 3D cube is invisible).
My best guess why your stuff isn't working with your 3D object, is because the script is called Rigidbody2D and Oncolision2D events rather than Rigidbody and Oncollision events?
Because the '2D' system in Unity is basically an entirely seperate physics engine bolted onto the existing one - IIRC, Unity uses Havoc for its 3D physics and Box2D for its 2D, so although they share a lot of similar commands in the API for interoperability reasons (and so its easy for coders to move from pseudo2D to actual 2D code) the two systems won't actually interact