Sleep(5.0) seems optimistic here, did you try it on Switch or mobile ?
Also, if I may, when players join, the PlayerAddedEvent fires, then (seconds/minutes) later, they get assigned a fort character and a spawner (no nameplates still), then they get assigned another spawner and their nameplates show, atleast that’s what I noticed on some settings.
I agree that this invisible spawn flow is hard to work with but I’ve made my own workaround by waiting for players to actually move (forcefully or not)
Btw the HUD message device has an option for JIP players, I think it uses the queue which has a default decay time of 15s, so you might want to tweak that maybe ?
The teleporter and hud device i show/teleport via verse only and not on device states ect
I am on pc and joining on Xbox series x
Also when the player joins it shows
Name has join the world
Then i assume when active ect it says
Name have joined the island
Even after that without that Sleep(5.0) it doesnt work with those 2 devices
Very odd and tbh ive never used them in this way before so it could be the norm i thought it was worth mentioning for others as they could think they have issues ect and it turns out its just a time delay is needed for the system to catch up
Yes it doesn’t work because the fort_character is not spawned in yet at this point. Because you’re not actually teleporting the player but the character in this case
A lot of devices would be failing up so early in the joining flow, you need to enhance your detection
I experience 2 primary issues in my games in regards to JIP.
The Player Joined Playspace event will pass an invalid Player or FortCharacter
The Joined Event never even fires
They have some sort of reactive handling for player server initialization while they’re constructing all the objects and for whatever reason they don’t bother doing any validating before handing us these game objects nor do they disclose or discuss this anywhere.
This is probably the most minimal straight forward handling methodology.
player_manager := class(creative_device):
@editable JIPMutator:mutator_zone_device=mutator_zone_device:
var Players:[]player=array:
OnBegin<override>()<suspends>:void=
# Add async looped listener or subscription for playspace join
# Same as above for mutator's agent enters event
# Add handler for flickering mutator (loops enable/disable)
# Route both of the detection methods into this function
(Player:player).OnJoin()<suspends>:void=
Result := Player.Validate
if(Result?, not Players.Find[Player]):
set Players += array{Player}
# Add whatever handling after this point
# Ensures you only get valid players past OnJoin
(Player:player).Validate()<suspends>:logic=
var IsValid:logic=false
race:
loop:
if(Player.IsActive[],Player.GetFortCharacter[].IsActive[]):
set IsValid=true; DPrint("Valid Player"); break
else:
Sleep(0.0)
Sleep(60.0) # 1 minute timeout
IsValid
Ensure that the mutator zone wraps the player spawn pads or location that new players will be at.
The idea here is that where the playspace join event fails the mutator zone will detect the player and with the validation handling and managed array of already valid players you can ensure that your players are always valid before you ever pass them into handling, and you can catch players that epics handling fails over silently on or whatever its doing.
OnJoin is a collective handler for these enter and join events, it routes into the validation handler, this will handle immediately for a larger percentage of players were just here to catch the stragglers (slow loaders and whatnot), and theres a timeout so you dont infinitely loop handling for people who aren’t able to validate or leave during the validation to prevent infinite looping.
The verification that the player is not already in your map or array is very important here as well because you need to know who still needs to be initialized and not repeatedly initialize already initialized players.
You can use a standard map here, or use an array, use the agent type or player, and handle your asyncs how you’d like, this is adapted from my somewhat unconventional handling for the purposes of demonstrating how to get reliable handling of the playspace.
I tried mutators and it was triggering too early (since you can spawn twice), not sure if setup related or if it depends on what you’re trying to call after they “joined”
After some very extensive troubleshooting after still getting JIP errors this is what I landed on, and what tested stable. Single PlayerCounter, with a validating array, and a new confirmation state in the Validating function for Players.
An important part of this is that I found even when a player passed Player.IsActive[] and FortChar.IsActive[] that essentially means nothing, because you will still have players failing initialization after those checks. The only way to truly validate everyone is to require the player to move themselves. No amount of additional detection methods between the Player Counter (which is an actual reliable Playspace) and this input has any relevance due to the existence of these failures without this additional handling.
The only thing from the Playspace i use at this point is the PlayerRemoved event, as as far as I know once they’re in and leave the Playspace functions properly but if you’d heard otherwise let me know and I suppose I’ll finish the full replacement.
Yeah it absolutely is. I was having players miss 1.0 only device triggers for item grants, or switch state changes, etc.
I just spent 3 weeks bugfixing JIP issues, more than just this too… Net replication issues, device failures, etc. I have a pretty good handle on the Player Validation situation right now in live games and on Epics side they are passing us invalid objects, and the checks they’ve provided us also do not actually ensure that we can start handling as they’d like to suggest.
There is a serious problem with their lack of proper player object validation before they pass the object through to us, and their lack of accountability on this. There is also a big issue with the lack of control over net replication which is another component of JIP issues that are a lot harder to understand (game objects including objects with collision can be in separate states on separate clients at the same time).
I will take some time to formally address these details with staff as soon as I get some time. Still have to recover from all of the lost time here solving all this stuff… (There’s a whole teleports failing at long distance thing too I don’t even care to get into right now, lets just say its been a long month).
I would add the validation requiring the sprinted event to complete after both the player and fort_char active checks pass, and see if that reliably solves your issues. I would be willing to bet it does and it would be nice to have the confirmation in the thread here.
I believe that this can impact purely 1.0 setups as well, not even having to do with code, because of their lack of proper object validation before passing it through into additional systems at the playspace level.
