Preservation of Teleported Parties (Quite wordy!)

[colbert2677 (ImagineerColbert)]

Currently, a game I am reworking is intended to have a party system and I would like to ask about the preservation of parties. I have not really tried anything myself yet, but I need to gain an understanding about the approach I have in mind or any suggestions on how to do so.

A party system is defined as a group of players that can work collaboratively on a game. This includes mutual alliances (unable to damage each other), location markers, distribution of benefits (i.e. dungeon quests) and so-on; co-operative play, to be short and concise. A party is often started with a leader who holds administrative permissions over this party; disbanding, removing, inviting and other configuration factors.

My current party system paradigm shouldn’t require any editing necessarily. I will be having my parties contained within modules which will indicate parties as data. As far as handling in-server parties, I should be fine. I don’t account for any special circumstances (such as disconnections) or any storage of parties. The only thing I haven’t a clue of what I am to do is how to preserve those parties if players are teleported only - any other circumstance should remove parties (or in the leader’s case, disband it). I also need to be able to account for players who did not make it from the teleport.

The current idea I have in mind is to use the JobId of the target server as a key for a DataStore of parties, whether that’s of a scope of an existing DataStore or a separate one altogether. The value of this would be the members of the party and any additional data.

local TeleportService = game:GetService("TeleportService")
local DataStoreService = game:GetService("DataStoreService")

-- ...

local PartyDataStorage = DataStoreService:GetDataStore("Parties")
local PartyMembers = {} -- In here is a table of Player objects representing the party
local success, TargetJobId = pcall(TeleportService.TeleportPartyAsync, TeleportService, 0, PartyMembers, PartyData, nil) -- PartyData exists elsewhere
if success then
    DataStoreService:SetAsync(TargetJobId, value) -- Haven't determined what value will be
end

My worries with this approach and similar approaches are as follows:

• DataStores are only meant for communicative reasons. Everything stored here is throwaway. I’m wasting value budgets on throwaway requests.
• I cannot guarantee that MessagingService will quell my worries when it goes live, though it might somewhat be able to handle processing of groups post-teleport. MessagingService is more for cross-server communication over sending data - the data should only work its magic after all players are done or after a certain time has passed.
• I can already foresee this posing problems as I typed it. I’m saving the JobId of the server. Multiple parties can go to a single JobId. This will obviously destroy my code later down the line.
• There does not exist a server-side method for checking when a player arrived from a teleport explicitly, only for when they joined the server at all. This presents me with a race condition of trying to determine who came from a teleport and who did not.

I have thought about using the leader’s UserId and the JobId together as determinants for storage keys or TeleportService settings while using party data and members, but they’re all mostly ugly workarounds that I feel are not appropriate. There’s also the potential edge case of a failed teleport wherein my server wouldn’t know what to do with the data it has or it’d just keep it stored without ever touching it again.

---

Worst case scenario, I can’t “preserve” parties or I overcomplicate my situation, I throw the system out and instead make a “trusted players” list, A fairly simple system to make in which should not pose me many or any problems at all.

The list of players that a player trusts carries through servers and places but does not save on a whole. Mutual trust establishes an alliance, while one-sided or non-set trust does not create an alliance. This can also allow me to white list groups as automatic trust between members, in case I support factions for the game. Factions aren’t the hugest thing on my mind though: getting the party system down is.

This new system wouldn’t necessarily achieve my original goal, though the importance of a party-esque system to my game is of fairly high priority for game play purposes (and as per the expectations of the person employing me).

[colbert2677 (ImagineerColbert)]

Due to a lack of noise on this thread and my inability to reasonably figure out this system, I have decided to abandon the idea of parties and will just make an ally whitelist, if that’s even plausible at this point. Users will be responsible for opening up the tab and setting allies. Mutually set allies will be considered an alliance. Essentially, I’m going with the alternate system and abandoning the initial one.

This is going to be absolutely garbage for UX which is one of my main worries as this is one of the game’s core systems, but there’s quite literally nothing I can do about it. The least I’ll be able to do is send lists along with the player via TeleportData and hope that something sensible can be made out of that. That being said, there still comes the final issue of trying to handle that data after players get to the target place. So I’m at a huge loss.

MessagingService is not going to help in this scenario necessarily, nor do I know how to configure it in such a way that will help me achieve what I initially set out to do in the OP. I still have to account for race conditions, edge cases and several more cases. I’m almost about to throw the whole idea out the window which is not pleasing to me for my progress as a programmer and the developer of this game, nor would that be very pleasing for the product owner to hear.

_{Unfortunate, but I guess that’s the life of a person who never gets replies on a thread with an abstract problem.}

[TheAviator01]

Overall it’s a little unfocused / confusing and not to the point.

@colbert2677

Unfortunate, but I guess that’s the life of a person who never gets replies on a thread with an abstract problem.

You posted a thread with 725 words FYI

[GreekForge]

Try simplifying what you want to do. Many of us are willing to help, we just dont understand what you are trying to say.
The party system seems cool, but what exactly is your problem?

[Hexcede]

You can use Teleport data since this can safely be accessed from the server now. Teleport your party and with each player send the party they’re in and who’s in it. This way you can maintain your party system through teleports.

[colbert2677 (ImagineerColbert)]

@colbert2677

The only thing I haven’t a clue of what I am to do is how to preserve those parties if players are teleported only - any other circumstance should remove parties (or in the leader’s case, disband it). I also need to be able to account for players who did not make it from the teleport.

@colbert2677

There does not exist a server-side method for checking when a player arrived from a teleport explicitly, only for when they joined the server at all. This presents me with a race condition of trying to determine who came from a teleport and who did not.

@colbert2677

There’s also the potential edge case of a failed teleport wherein my server wouldn’t know what to do with the data it has or it’d just keep it stored without ever touching it again.

I’m aware a server-side implementation of TeleportData exists. This doesn’t address several points in the thread though. This information adds nothing new.

[colbert2677 (ImagineerColbert)]

@TheAviator01

@TheAviator01

Overall it’s a little unfocused / confusing and not to the point.

In what way is it unfocused? I described my problem fairly clearly, a summary is available on the title and I’m not sure how to condense this post further to make it supposedly “on point”. Cutting out parts of the post is going to lead to unhelpful truckloads of “not enough information” responses.

@GreekForge

See above. Also not sure how I can “simplify” the problem. The problem is exactly as stated in the OP.

If it’s that confusing then I’ll have this thread locked and write another, though I resolved my issue already as marked by the solution.

[Hexcede]

I apologize for not reading your post thoroughly, I was in school. I don’t know how teleport data responds to not teleported players but this should be very easy to check or circumvent. If there’s an error use pcall, if it returns something check if this value is valid or not.

Simply update your data on the server based on the Teleport data… If you are missing players than any other player who teleported should have brought this info with them and when they do make it in this info should be available for the server to use already.

If you want the party to require a leader simply wait for the party leader to join. If they don’t join for long enough you can disband the party. If you want to make it more reliable instead of auto disbanding the party select a new leader.

Server side teleport data is the only solution if you aren’t going to use data storage of some kind. MessagingService would be finicky to use and that’s why these other services exist instead.

[colbert2677 (ImagineerColbert)]

@TheAviator01

You went from talking about a party sytem, to datastores, to teleportation service, to messaging service, and finally to an alternative solution

All of these points are directly related. The party system is the item in question that is trying to be created. Teleportation service is relevant because I’m attempting to carry parties around places. DataStores and MessagingService are relevant as methods I attempted. The alternate solution was if neither of those things worked out. If that didn’t make sense to you, you should’ve said that. Everything in the OP is completely relevant.

@TheAviator01

Simply telling us the intended functionality / end goal, backed up with a little context, would have been much more useful to work with as compared to what it is now.

Yes that’s exactly what the OP says. Preserve parties through places.

See:

@colbert2677

I described my problem fairly clearly, a summary is available on the title and I’m not sure how to condense this post further to make it supposedly “on point”. Cutting out parts of the post is going to lead to unhelpful truckloads of “not enough information” responses.

---

Please DM me with any further concerns about my thread, despite the fact that they’re now moot at this point.

[colbert2677 (ImagineerColbert)]

@Hexcede

I don’t know how teleport data responds to not teleported players but this should be very easy to check or circumvent.

It doesn’t send. Each player carries their own copy of TeleportData to the next place and instance. It can then be accessed by the server or the client once they teleport over.

@Hexcede

Simply update your data on the server based on the Teleport data… If you are missing players than any other player who teleported should have brought this info with them and when they do make it in this info should be available for the server to use already.

The thing is that I’m not sure how to process this data. There already doesn’t exist a server-side method of checking teleportation arrivals, only player joins. I’m not able to check:

• When a party has successfully arrived from a teleport
• How many players from the party made it over to the new instance
• Who the aforementioned players are

I’m able to process the TeleportData off of a single player but then I also need to factor in other players and their own data. The problem is trying to understand how to construct my parties again at the new place without conflictions or hitting edge cases (i.e. what I said earlier about parties not making it, or a leader not making it through the teleport, etc).

@Hexcede

If you want the party to require a leader simply wait for the party leader to join. If they don’t join for long enough you can disband the party. If you want to make it more reliable instead of auto disbanding the party select a new leader.

I can disable the party system for a while, but that’d just be horrible UX design. I wouldn’t even be able to accomplish further functionality such as this if I’m not able to decipher how to get the base concept down in the first place, which is trying to check for teleportation arrivals and handling a party as one unit.

Perhaps a Feature Request is needed for my use case.

[TheAviator01]

If this concept is not realistically manageable via your code, I would recommend sending a Feature Request to a Top Contributor (:

[Hexcede]

You don’t need to check if a player is teleporting. You misunderstood the first quote entirely. I know no teleport data is sent but can’t you just pcall getting the teleport data?

[colbert2677 (ImagineerColbert)]

@Hexcede

You don’t need to check if a player is teleporting. You misunderstood the first quote entirely.

I don’t see in what circumstance I’m misunderstanding. I also do need to check player teleports so I can handle the parties in the first place and differentiate between who teleported with a party and who didn’t, or who joined normally or from a teleport.

@Hexcede

can’t you just pcall getting the teleport data?

Yes I can. That’s far from the issue; getting teleport data isn’t the issue.

@colbert2677

I’m able to process the TeleportData off of a single player but then I also need to factor in other players and their own data. The problem is trying to understand how to construct my parties again at the new place without conflictions or hitting edge cases (i.e. what I said earlier about parties not making it, or a leader not making it through the teleport, etc).