So, this may be complicated, my code is probably not the most streamlined, but the basic point is I have a left click select func, and a right click attack func, these use for loops. The select func that I have made seems to do what I want it to, however the attack func will only do what I want it to for the first ship in my array. If I do the same thing with the second ship it returns my else statement in the attack func. Why would this sorting possibly be causing an issue like that? Here is the code I believe would be relevant.

func selector(source):
	selectorActive = true
	var selected = get_tree().get_nodes_in_group("selected")
	var origin = get_node(get_path_to(source.find_child("Selection")))
	var ship = get_node(get_path_to(source))
	for selector in selected:
		selector.visible = false
	if ship.select == false:
		for ships in arrShip:
			ships.select = false
			origin.visible = true
			ship.select = true
	else:
		for ships in arrShip:
			ships.select = false
			origin.visible = false
	selectorActive = false

func move_turn():
	var sortNum = 0
	#Sorts the ships based on initiative in order to call turn order
	if sortNum == turnMove:
		arrShip.sort_custom(func(a, b): return a.initiative<b.initiative)
		sortNum += 1
	if theUnit.turnCount == turnMove:
		ship_cycle()
	else:
		end_move_turn()
	show_buttons(theUnit.active)

func attack_action(attacked, attacker):
	var origin
	var target = get_node(get_path_to(attacked))
	for ship in arrShip:
		if ship.select == true:
			origin = ship
			attacker = get_node(get_path_to(origin))
			print(attacker,' ', attacked,)
		else:
			print('why does my second ship choose the else statement rather than the first')
			return

When are you calling selector(source) ?

The loop (and the function) will exit as soon as it encounters a ship whose select flag is false. You probably want it the other way around - loop until you find the selected ship and then exit.

However 🙂

Your code looks quite problematic in general. There's a lot of logical and stylistic problems that add up to a very tangled piece of code. To name just a few:

  • get_node(get_path_to(X)) is exactly the same as just using X, and you do this in many places, completely needlessly.
  • Using selector as a local variable in a function named selector
  • Using a loop iterator with plural name ships, while at the same time having a singular ship as a different variable inside the same loop. This would confuse even experienced coders, let alone beginners.
  • Having function names that are not clear and not verb-oriented like selector or attack_action. A functions represents work. It does something. Its name should clearly tell us what it does. For example: select_unit, deselect_all_units, attack, move, sort_by_initiative

I could go on. I recommend scraping this and starting over. Start by writing low level helper functions with verb-focused names that do simple tasks you know you'll need later, like select_unit. Then build higher level functions that call those lower level functions.

When you write each function, test it to check if it does exactly what you want it to. Only move on to building the next function once you're sure that there are no problems with previously added function. You test a function by calling it from another place with different inputs and check if its outputs and/or behaviors are as expected.

Before you start, decide how the system should behave and write it down in plain language. This will make easier to figure out what functions you need and how to organize them. For example:

Attack phase:

  • If player left-clicks on an unit

    • clear existing selection and select clicked unit

  • If player left-clicks outside any unit

    • clear existing selection

  • If player right clicks on a non-selected unit, while some other unit is selected

    • attack clicked unit with selected unit

And so on. From such a description you can immediately see possible function candidates. For the above example they might be: clear_selection(), select_unit(unit), get_selected_unit(), is_unit_selected(unit), attack(source_unit, target_unit), `

Hmmm, yeah, it's a bit difficult to understand what is supposed to be going on here. The naming is problematic, everything sounds the same.