I believe this thread is about providing a tool to automatically upgrade old functions to new functions. This is different to deprecation.

Just curious, will the old functions be removed entirely?

Perhaps the idea board should reflect these numbers you're quoting? I don't see them there. I can only look at the numbers on left side. If you are implementing the good suggestions, that's excellent! :-)

Ahh I just realized I can use "On Peer Connected" in the peer logic rather than "On Peer Created"

Thanks for your help! This will work

My first approach would be to have all npcs created and handled by the host, with their own events. Copy whatever events you need to initialize them and set up their behaviors. Smart use of functions will allow some event logic to be used by both peers and hosts, but it's generally best to keep them separate.

To answer your question specifically, you can set a flag/variable during an on peer connected event to signal that the peer object is being created for a player. Otherwise, you can use on peer object created (with the condition flag = false) to differentiate for npcs.

So you're suggesting I use a synced variable to check if newly created Peer Objects are NPCs or players?

Yes, but the peers use "On Peer created" to initialized players

I'm looking for a way for the Peer to tell whether or not the Peer that was just created is a Player or an NPC

The reason the clamp isn't working is because you're using a local number to represent Max Jump Height

Local numbers are reset to their default value each time the event they're nested in runs

In this case your local numbers are "out in the open" under a group, so each tick the local number is reset to 20

Change it to a static local number to solve this

Been going through all the multiplayer tutorials & documentation these days and everything's fine by now except the following. I cannot textually wrap my head around what is meant here and I would appreciate it if someone could explain to me what is meant by this:

> The client value tag is used if the instance variable also corresponds to a client input value. In other words if a peer's client input value is set from that instance variable, setting the corresponding tag here allows the multiplayer engine to know they are linked. The host can use this information to reduce the latency when relaying the inputs to other peers.

Normally syncing is done One-Way

Host ----> Peers

The host controls the game, what's happening, where things are, etc, and tells all the Peers.

When you add a client value tag you are allowing the syncing to be done two-way

Peer ----> Host -----> Peers

The peer sends inputs to the host, like "the A key is being pressed", then the host uses that information to control the game, and then it sends "the A key is being pressed" to EVERY peer

Did you use a loop to check each tile's # and then change it to another tile. Because I'm pretty sure that would work