#Need help regarding "await" and signals in multiplayer

1 messages · Page 1 of 1 (latest)

fickle torrent
#

I'm trying to make an initiative based turn order game and I'm stuck on the part where the code has to await an end turn signal. Here's the relevant code:

func start_turns() -> void:
    # Loop through the initiative order
    for combatant in initiative_order:
        var character = combatant["node"]
        #var combatant = find_combatant_by_name(combatant["name"])
        if character.is_in_group("enemy"):
            print(character["name"], " initiative: ", character["initiative"])
            enemy_turn_start(character)
            character.act.rpc()  # Call the act function on the active character
            print("came here, wolf")
            await UiEventBus.turn_end # Wait before the next turn
        elif character.is_in_group("player"):
            ally_turn_start.rpc_id(character.player_id, character.name)
            await UiEventBus.turn_end
            print("came here, player")
            character.turn = false
    start_turns()

The problem line is: "await UiEventBus.turn_end". When Player1 ends their turn, the print after the "await" prints out. When Player2 ends their turn, it doesn't. The thing is, they're using the same script to send out the signal:

func _on_end_turn_button_pressed() -> void:
    end_turn_button.disabled = true
    UiEventBus.turn_end.emit(self)

I'm using an event bus which allows the player to communicate with the UI. It works flawlessly so I know the signal is being emitted. Initiative order array of dictionaries is also correct since it's printing everyone correctly and it worked before I started messing with multiplayer. I think the issue lies somewhere in the await async routine or something.

mighty orchid
#

Well, the print statement comes before the await statement.

#

I'm not sure if this matters.

#

But I thought I'd point it out. Since there are two different patterns where I expect two similar ones.

#

I think it probably doesn't matter in this case since we're talking two players, not a player and a monster.

#

If the signal is indeed emitted, then the only explanation I can think of is that the signal isn't awaited the second time.

fickle torrent
#

sorry, I meant the "came here, player" print, but you're right - only the player's print matters. I'll get to cleaning up this code once I get this working.

fickle torrent
#

and it's weird because afaik, we don't need authority to send signals

mighty orchid
#

I've never even heard of authority issues.

fickle torrent
#

me neither until I started working on multiplayer

#

it's driving me nuts

mighty orchid
#

Either way, either it's not being emitted or it's not being awaited. It has to be one of these two things.

wheat wigeon
#

@fickle torrent when doing multiplayer (I'm assuming you are doing online multiplayer and not local) the server determines what happens. It is the source of truth, unless you specifically assign authority to something else.

#

What I would do is make a small proof of concept to figure out how signals work in an online multiplayer environment with clients and servers. Once you figure that out, you can come back to your actual game

#

FYI, just because a client fires a signal doesn't mean that the server will see it or any other client for that matter

fickle torrent
fickle torrent
#

ended up scrapping this version of the turn code and replacing it with something completely different (without awaiting anything and especially signals lol)

#

but I'm sure this issue will arise again, multiplayer is very complex

wheat wigeon
#

In my experience, it's a lot easier to have a dedicated server than a P2P connection. This would allow you to have two separate projects. One for the clients and one for a dedicated server. The code starts to get really really messy when it's P2P and the game logic gets mixed in with networking logic

#

Not only that but, if the game is a 1v1, having p2p means the host of the game lobby can cheat. This wouldn't happen with a dedicated server

#

Also, since your game is turn based, it would be easier to send/receive messages to/from the server from each client then it would be for one client to also be the server

#

Just my 2¢

fickle torrent
#

interesting, when I started I thought p2p would be easier. So far, almost every rpc call has either been any_peer, call_local or straight up directly using rpc_id. Everything works right now, even got hamachi to work, so I'm kind of afraid to touch it anymore haha.