#Akizuki
1 messages · Page 1 of 1 (latest)
so aye
"so I'd recommend that in the enemy's script, you have say public void TakeDamage(int Damage){ BLAH BLAH BLAH }"
yeah i have something similar one moment
the second one is the bullets script
the oncollisionenter2d void works how i want it to... the ontriggerenter2d one doesnt
back
sorry about that, just checking up on the dogs
ah so
just quickly looking at that, trigger is a different thing from collisions
there's just some checkbox for it in the inspector on the object
it's a bit messy
np man... honestly still really stuck... ive tried putting the script under ontriggerenter 2d under oncollisionenter2d instead but then it says that getcomponent doesnt exist...
i think ive literally just understood what you mean by that....
if this works imma be very happy
it.... did not
try collision.collider.getcomponent etc.
i tried ticking "is trigger" under the 2boxcollider on the inspector for enemy... but instead the bullets pass right through
actually sorry, collision.gameObject.GetComponent<Health>();
hmm not sure it changed anything
so put it back under OnCollision, and we'll ignore the whole trigger thing
ok one sec
so put all that relevant code under OnCollisionEnter2D() instead of OnTriggerEnter2D()
done although now its saying it doesnt recognise tag
hmmm no error there... ill test now
is there any way i can use a debug command to make it show taking damage in the console? or should the "current health" float update in the inspector if its taking damage
nevermind it works! i love you man i cant thank you enough
i spent hours at that earlier
im gonna study whatver it is you did to fix it until i understand it for the future
thanks again
glad to hear it man
I've been in the exact same situation before
bit of googling refreshed my memory
i only started trying to learn again recently, i figure itll be a lot of trial and error
I think the trigger thing is ultimately useful but yeah it doesn't seem to like to work out of the gate
im more of an artist than a programmer 😅
and because it's so similar a lot of documentation blends together
it's a very subtle thing especially with that .tag bit
with collisions you have to first reference the actual game object, with trigger that's assumed already in the parameter
like in the unity documentation that exact thing came up
hmmm, i thiiiink i understand, ish
is that so itll show whats happening in the console?
i think thats what debug is used for right?
i should learn how to use it then 😅
whenever you're writing a new bit of code, it's handy to have it just so you know the program actually gets to that bit
I've had errors come up and I've literally just moved a Debug.log("IT GOT ALL THE WAY HERE") around the block of code until I figured out what line messes it up etc.
hmmm, i think i understand how to use that then...
youve been a great help, im sure well cross paths again at some point but hopefully i can figure out the next problem a bit better myself aha
very versatile as well, you could make it print say Debug.log("Enemy got hit with a bullet, it's taken " + amount + " damage, and its health has went down to " + CurrentHealth + "!")
so when you test it, you'll expect the unity console to print "Enemy got hit with a bullet, it's taken 2 damage, and its health has went down to 1!"
so i can make references in the debug line to make it show whats happened so far?
yes exactly
hmmm im gonna try that now
I think technically stuff like break points and variable watching etc. is cleaner and more robust
but it's far more annoying to set up compared to just writing debug.log
heavily recommend you clean up and get rid of debug.logs after you're happy with a particular block of code
it doesnt seem to like my references
make sure it's in the TakeDamage function
like I'd pop that under line 18 in that screenshot with TakeDamage that you posted
well "CurrentHealth" is a public float... cant i reference it in a different script?
if you pop that in any other bit of code it'll not work
you could, but you'd need to still reference the specific object
so I think if you did it under the collision code on your bullet
it'd be something collision.gameObject.getcomponent<Health>().CurrentHealth
yeah i think then i could reference "Health"
so basically i still need to tell it to find out what "CurrentHealth" even means, right?
yeah
coooool
if you just say CurrentHealth to the bullet, it hasn't a single clue what you mean
right... makes sense when you put it like that aha... so you referenced the class "Health" and then told it to find out what "CurrentHealth" means to that class?
yep
also there could be more than one enemy and more than one instance of the Health script as a result
also there could be a whole other script that also has CurrentHealth as an example
so then would i need to reference gameObject.tag again?
right... see i thought thats how id distingush which enemy i mean
ah yes right
so yeah, to be clear that tag part is important because like you said you only want it asking for the health script for certain objects
if you didn't make that distinction, it could collide with like a wall or a powerup or anything else and be like "here where's your Health script I need whatever integer you have under CurrentHealth"
right... but for now i have such little script written that it has nothing to get confused with aha
yep
technically you have the player, it could collide with that
I know because I've had that happen
true, good job i havent given the player health yet xD
havnt had a need to yet as my enemy cant hurt me yet
thats my next goal
but currently my game of "shoot the stationary square 3 times" is really quite captivating... i could win an award
but aye referencing is not the most intuitive thing in the world at first
you just gotta force yourself to remember that computers have 0 intuition
quick question, so like, as an experienced programmer, if you wanted to make something, lets just say like making an enemy teleport in combat.... would you just be able to figure it out on your own or do you guys look up what other people have done to solve it too?
cause like, i just cant imagine knowing how to build scripts from scratch...
which begs the question, how did the first person solve the problems im googling in the first place lol
hell I'm not particularly experienced, I actually came on since I was wanting a second opinion on something for a picross clone (whether using all the button shit that unity gives you for the grid is worth it)
oh aye you're not alone in that at all
well as far as im concerned, youre a wizard, enjoy that admiration lmao
you will be googling stuff all the time don't worry about it
doesn't make you less of a programmer or anything like that, it's all magical hocus pocus to trick a bunch of silicon into thinking and there's no way of remembering all the magic words and minutia for each bit
well, hopefully i get my head around it at some point aha
its a lot harder than making sprites, thats for sure... and im not even great at that lol
yeah, the bit you do get better at is framing the questions you ask I find
im only really trying to learn unity so that i have a reason to make sprites aha