after_the_tremor_combat shows incorrect controls

[wjt]

The controls are meant to be different for this scene: ⬅️ should cause the left-hand player to repel, while ➡️ should cause the right-hand player to repel. Both players are fixed in place. However now that we show the Input HUD at all times, incorrect controls are shown on screen.

XP Summary (total 475)

Subdomain	Skill	XP
Game Design: Game Feel & UX	Problem Solving	50
Game Design: Game Feel & UX	Creativity & Design Thinking	50
Game Design: Game Feel & UX	Technical Literacy	75
Engineering: Gameplay & Systems Programming	Problem Solving	75
Engineering: Gameplay & Systems Programming	Creativity & Design Thinking	75
Engineering: Gameplay & Systems Programming	Technical Literacy	150

[wjt]

The input hud is shown/hidden based on whether there is a node in the scene in the player group. There are indeed, so the HUD is shown.

The two players are instances of player.tscn. That scene places its root node in the player group. You cannot remove an instance from a group in the instancing scene, at least not in the editor, but you may be able to do so in code. I guess I would first try removing the two players from the group in _ready(), then calling into the InputHUD scene to refresh the HUD visibility if necessary. When full control is restored, readd only the "real" player to the group, and again tell the HUD to update.

For a fuller fix… Both players are fixed into place by setting their speeds to 0. The solution to this problem is complicated by the fact that, once the enemy is deleted, movement is restored to one of the players. But you could imagine making the second player, which never becomes fully interactive, be not an instance of player.tscn but of a copy of that scene which doesn't have any of the movement components, only the sprite, hitbox, and repel component. I think the primary player would still need to be moved in and out of the relevant group.

[felixwalberg]

@wjt @manuq Is there a reason why the InputHud Autoload variable is not allowed to be accessed directly in scripts? It seems to be the only global variable that does not have this enabled, and I was wondering if there is a risk in turning that on. If we can enable it, I can do something like this:

• Remove the main character from the player group: p.remove_from_group("player"). This is reflected in the visibility of the Input HUD.
• On defeat of the boss, restore the main character to the player group: p.add_to_group("player"). This does not automatically reflect in the HUD. If I am able to access the variable directly in the script, I can do InputHud._on_scene_changed(), forcing it to go back and look at what components exist in the scene (including the player group) and display the hints.

[wjt]

It's not so much a risk as a loose-coupling thing. The original implementation did have a global variable but I thought it was cleaner for the Player scene etc. not to be aware of the InputHud (given that the InputHud is aware of the Player - generally I try to avoid cyclic dependencies).

I think you could change that, but please don't have the scene call InputHud._on_scene_changed() without renaming it: the _ prefix indicates that it is an internal method, not public API.

[felixwalberg]

Yes, that is probably a good idea to avoid cyclic dependencies. Reviewing the Infinite Knight pr, they actually have a similar issue. They search through the scene tree and toggle visibility directly. It is based on hardcoded string values for each input hint, and I think it would break if the names for the hints were ever changed, but it is another approach.

if active:
		var root: Window = get_tree().root
		for node_name in UI_NODES_TO_HIDE:
			var node: Node = root.find_child(node_name, true, false)
			if is_instance_valid(node) and node is CanvasItem:
				node.visible = false
				_hidden_ui_nodes.append(node)
	else:
		for node in _hidden_ui_nodes:
			if is_instance_valid(node): node.visible = true
		_hidden_ui_nodes.clear()

[felixwalberg]

So far I have:

• Enabled InputHud as a global variable (we could try to find a way to do this without it. The issue is getting it to update the hints mid-scene)
• Added a function refresh_scene_status() to InputHud. Would it be better to remove the leading underscore of the existing function or use a separate one like this?
• Remove the main character from the node group "player" on _ready(), and then add him back when the boss is defeated (this is where I was forcing the input hints to refresh

Remaining todo:

• Disable the other player node so that it can only repel and is not treated as a full Player
• Possibly add different input hints specific to this challenge so that players know they can use left and right arrows (or A and D) to repel projectiles
• Think of a way we can avoid the circular dependency

This is being worked on in the remove-input-hud-after-the-tremor branch.

[felixwalberg]

Another thing I am noticing is that it is unclear how you advance once the boss is defeated. I don't seem to have the ability to interact with the sign, collectable, or any other item in the level, unless I am missing something.

[wjt]

The player is supposed to be restored to full motion. You could check how it works in the commit where this quest was merged?

[felixwalberg]

The player is supposed to be restored to full motion. You could check how it works in the commit where this quest was merged?

Turns out the PlayerInteraction node had been moved 2000 pixels off screen!