Player Progression Portals

[Vapok]

Hey Spike,

I am working on a project where a feature request has come up for XPortal-like functionality but with the added twist that the only portals that show up in the list, on a per-player basis, are portals that the user has actually interacted with.

I'm thinking I can make this as an overlay mod that sits on top of XPortal (making XPortal a dependent mod), but before I go that route, I wanted to get your thoughts on whether that's functionality that you'd rather build yourself in XPortal, or if the overlay mod I'm thinking of would be OK.

Thanks!
Vapok

[SpikeHimself]

I guess from a content perspective it makes sense that this would be included in XPortal.

Just.. how would you achieve this? Since the Hildir update (or a minor one after it), ZDOIDs do not persist, so if a server restarts how do you know which portals a user has interacted with? Now, for XPortal I "solved" this issue by saving the current ZDOID in a separate property ("PrevousId"), so I can search for that afterwards, but if there are 2 reboots between a user joining, then that wouldn't work anymore either. Or I guess store the UserIds in the portal ZDO instead of the other way around?

What are your thoughts?

[Vapok]

So I think what you are asking is where would I store data between player sessions and reboots (if I understand your line of questioning).

In these cases, what I was planning on doing was utilizing the m_customData field on the Player.m_localPlayer object. This is a dictionary, where you can create a unique key for Xportal usage, that can then store a string of information. I generally use JSON serialization/deserialization to store data in this field for other mods that I use.

So then I would create an object that could track which portals I know (maybe by name? by ZDOID? or another field) and store the data with the Player. That's one way.

Alternatively, and I do this with EpicLoot on Bounty Kill tracking, you can save a binary file on the "server" (whoever the server might be, dedicated or not) that tracks an object that also keeps track of portals and player knowledge.

So it sounds like, as long as you can track the "previous" portal ID from the current Portal ID, which maybe that's something that happens at Game.Start(), and then track the sessions, this is pretty doable.