#I made my enemy wave script reference an enemies signal that was already in my scene.

1 messages · Page 1 of 1 (latest)

terse field
#

I need to remove the enemy from my scene, but upon doing so, the signals no longer work since they were referenced from the enemy.

I am attempting to reference the signal from instantiated enemies, but it attempts to reference the signal before they are created, which crashes the game.

Image 1: My wave script that references the signal from my enemy thats placed in the scene.

Image 2: My spawners script that instantiates slimes and attaches the signal to them, which works just fine

Image 3: If I remove the signal reference from the default enemy placed my in scene, things work, but the counting/wave completion announcement bugs out; after 10 enemies killed the wave ends and announces you completed the wave, after removing them it resets counting sometimes

Sorry, I'm very new here and to godot so I'm trying my best to explain what issue I'm having! Any help is appreciated, open to dm's as well.

wave_1script.png slime_spawners_script.png weirdcounting.png
grave tinsel
#

Can we see the code for Slime?

terse field
grave tinsel
#

Any reason you want to keep that slime in the scene tree? seems like it would be a lot easier to just let the spawner handle any and all spawning

terse field
#

upon deleting it my wave script loses the reference to the signal

#

i want the wave script to wait for signals from my created slimes from the spawner, but unsure how to do it

grave tinsel
#

Also, I would highly recommend a refactoring of your code because as an outsider it was especially hard to keep track of everything. Ideally, a node should not need any knowledge of anything that it's parent has directly.

terse field
grave tinsel
terse field
#

i guess what im trying to figure out, is how to reference a signal from an enemy that has yet to be instantiated

terse field
grave tinsel
#

do you have 2 instances of wave1 going?

#

because it looks like you have one counting up normally, and then a second one counting up more slowly

terse field
#

that was it

#

this whole time

grave tinsel
#

lmao

#

that would do it

terse field
#

i created a wave2 earlier that i forgot about, and hadn't detatched the wave1 script yet

#

thank you bro!!!

grave tinsel
#

lmao no problem

#

do look into doing a slight refactoring however, as I think it would be beneficial

terse field
#

im still sort of confused

grave tinsel
#

So in my opinion, you could make a wavehandler, and have waves be a purely data thing (a custom resource that could tell you like number of enemies, what enemies would spawn, and how fast the enemies would spawn. Your spawners would instantiate and return the instance they make, allowing the wavehandler to connect to each one of the monster's is_killed signals. the handler could then emit a signal of its own when the wave is over (num_killed = num_enemies_in_wave).

#

The biggest thing is trying to limit the number of times you set a node using "../", as a node has no way of knowing what nodes a parent even has

terse field
#

ahh i see

#

thank you for the advice, that seems much cleaner

#

i have some learning to do

#

its definitely messy at the moment lol, my wave node just has a bunch of slimespawners inside of it

grave tinsel
#

Fair

#

It's definitely a tough learning curve, but I promise that a better structured codebase is so worth it

terse field
#

is there any way to disable my wave node and its children? like
if wave_1_completed == true
wave_1_dont_start
start_wave_2

#

and yeah its been tough, just started last week lol

#

really appreciate the well thought out advice

grave tinsel
#

So the way I would do this is have a function in the wave_handler that starts the wave (so not in the on_ready), and a function for replacing our current wave (resource with information on how stuff should spawn in the wave)

#

So when you send the signal that the wave is completed, the "world node" (whatever the parent of the wave handler is), is listening to that signal, and knows that the wave is over, so it can send the next wave to the wavehandler and then call the wavehandlers start method, which would start that next wave

#

And the wave handler would just be doing all of the same things, but just with some different variables (maybe 30 enemies instead of 20, or maybe there are bats that are randomly spawned in instead of slimes)

terse field
#

yeah that definitely sounds like a great solution to my problem

#

i just need to figure out how to handle waves activating inside of the wave_handler function now, and how the wave activates spawners

#

yeah the signal for wave completion sounds way better, i was using booleans to handle that

grave tinsel
#

Made some pseudocode, abstracted a lot of the actual stuff away, want me to just send some screen shots of it?

#

just as like a how I would do it sort of thing

#

You also definitely shouldn't copy it and try to work it in, but could be a helpful example, your call

#

Definitely not fully functional, but gets the point across, obviously the parent of the wave handler would be calling to start the new wave, and feeding it with a wave resource, but the readability on it is much better, as there is a clear throughput, compared to randomly doing stuff with parent classes

#

AKA I have too much free time on my hands lol

terse field
grave tinsel
#

Definitely feel free to ask if any of the stuff is confusing

terse field
#

that is super clean, before you sent this stuff i took your advice and i was gonna redo all of my wave spawning/handling; i love that piece of advice for the UID; i was running into a lot of errors when i moved stuff around before

#

i think i understand most of this

#

i like the ability to spawn different enemies as well

#

i havent used arrays yet but was planning on implementing it as part of the wave management

grave tinsel
#

yep they are really useful, there is definitely an argument to be made of storing all of the current enemies in an array so that you can apply effects to all of them, or whatever else, I was just implementing a barebones version lol

#

Also typing (adding the colon and then the type of object after) is very nice because it means if you put an incorrect type in it will be a compiling error instead of a runtime error (which are significantly harder to track down)

terse field
#

oh yeah i learned about those, type hints, i havent used them enough but they seem super helpful

#

added you, thanks for all your help and effort, seriously awesome

#

best of luck on your projects as well!

grave tinsel
#

no problem, you as well, very refreshing to have someone who actually takes advice to restructure lol

#

although you're actually lucky in a way that you hit a critical point of spaghetti code relatively early

terse field
grave tinsel
#

Oh also, final piece of advice is to get some form of version control set up (github desktop is probably the easiest to set up) if you don't already. Basically lets you record the state of the game and revert to that state, so if you royally mess something up the project is salvageable. Additionally, if you upload to github then even if your computer or drive completely fails you'd still have a backup, very much worth the small amount of effort to set up

terse field