Rematch 5.0

[Gello]

Just tried beta. Everything smooth and easy... nothing of mine lost that I noted (only done about 6 pet battles). But get these lua errors when I initiate a battle without a rematch string. -- If it makes a difference was in kul tiras for the battle (so older content).

Thanks for testing!

Those errors relate to Pet Battle Scripts. That's a separate project I really can't help with directly since it's not a project I'm involved with.

Tonight I did try the update at github (Gizzmo's version here) and I personally got a bunch of ace errors. Not sure if I'm missing a dependency (I have no other ace addons) or something I messed up. It may be something to try.

I also tried the main version for Rematch 4 which seems to work fine in 10.1.7, but unfortunately has errors in 10.2.

[Justgiz]

Since more and more people are talking about my edit I thought id chime in.

How is the Pet Battle Scripts project support for Rematch 5 going?

So far everything feels great. Only weird thing is doing stuff before "/rematch reset everything", requires hooking "Rematch.dialog,Register", to hook the "acceptFunc" for 'ResetEverything'. As the dialog is registered lines before its displayed.

I'm also still not entirely sure how to make use of REMATCH_TEAM_OVERWRITTEN and what to do with scripts.

it seems to not have Rematch 4 compatibility, which I'd personally prefer to have.

Yeah thats a tough nut to crack, while maintaining the database between those two versions. And doin the migration. Making a separate plugin may work (as that plugin name is the database key), but the loading of the plugins only checks addon names, and not versions.

Worst case I'll just merge Gizz's changes without looking

Hey, Its not that bad... may want to do a edit pass on the migration code. I'm entirely happy with how the backups in the savedvaribles are done.

But get these lua errors when I initiate a battle without a rematch string.

Are you sure you're using the correct (my) version. The official one doesn't supports it yet. I'm currently downloading the 10.2 ptr to test my edit out there, but it is working on live without any issues.

...and I personally got a bunch of ace errors.

Would really like to see those errors.

Final notes: @Schlumpf I haven't opened a pull request yet, as I was hopping for a new branch to do it on. Such a big change feels wrong to be on the master branch. But if you'd like, i can open it there.

[Justgiz]

I'm currently downloading the 10.2 ptr to test my edit out there.

So after loading in, I do see a ton of errors, but they're not due to my edit. First error was from AceDB library. And others are from tdGUI and possibly changes blizzard made to templates tdGUI uses.

After doin a messy edit fix to stop the errors. My edit seems to be working fine.

Unless any big issues or surprises

Not sure if this is a big issue, heck, could've always been this way, but... When copying over my character I didn't copy account data, so I didn't have any of the slots unlocked. And none of those notices show in Rematch. Meaning no errors, when trying to place pets in the slots, and it not happening. Sadly i didn't get a screenshot of those notices in the base UI, before coping over my account data. sorry.

[Gello]

Would really like to see those errors.

When I log in with only Rematch and Pet Battle Scripts enabled, these are the first 20 of 50 errors:

Code: Select all

Message: Interface/AddOns/tdBattlePetScript/Localization/enUS.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/enUS.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/deDE.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/deDE.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/esES.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/esES.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/esMX.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/esMX.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/frFR.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/frFR.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/itIT.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/itIT.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/koKR.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/koKR.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/ptBR.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/ptBR.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/ruRU.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/ruRU.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/zhCN.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/zhCN.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/Localization/zhTW.lua:4: unexpected symbol near '@'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Localization/zhTW.lua:4: unexpected symbol near '@'

Message: Interface/AddOns/tdBattlePetScript/UI/MainPanel.lua:20: attempt to index local 'L' (a nil value)
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/UI/MainPanel.lua:20: attempt to index local 'L' (a nil value)
[string "@Interface/AddOns/tdBattlePetScript/UI/MainPanel.lua"]:20: in main chunk

Message: Interface/AddOns/tdBattlePetScript/Rematch/Addon.lua:8: Usage: GetLocale(application[, silent]): 'application' - No locales registered for 'PetBattleScripts'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Rematch/Addon.lua:8: Usage: GetLocale(application[, silent]): 'application' - No locales registered for 'PetBattleScripts'
[string "=[C]"]: ?
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceLocale-3.0/AceLocale-3.0.lua"]:130: in function `GetLocale'
[string "@Interface/AddOns/tdBattlePetScript/Rematch/Addon.lua"]:8: in main chunk

Message: Interface/AddOns/tdBattlePetScript/Rematch/UI.lua:10: Usage: GetLocale(application[, silent]): 'application' - No locales registered for 'PetBattleScripts'
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Rematch/UI.lua:10: Usage: GetLocale(application[, silent]): 'application' - No locales registered for 'PetBattleScripts'
[string "=[C]"]: ?
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceLocale-3.0/AceLocale-3.0.lua"]:130: in function `GetLocale'
[string "@Interface/AddOns/tdBattlePetScript/Rematch/UI.lua"]:10: in main chunk

Message: Interface/AddOns/tdBattlePetScript/UI/PetBattle.lua:67: attempt to index upvalue 'L' (a nil value)
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/UI/PetBattle.lua:67: attempt to index upvalue 'L' (a nil value)
[string "@Interface/AddOns/tdBattlePetScript/UI/PetBattle.lua"]:67: in function <Interface/AddOns/tdBattlePetScript/UI/PetBattle.lua:16>
[string "=[C]"]: ?
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:66: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:61>
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:494: in function `InitializeAddon'
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:619: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:611>

Message: Interface/AddOns/tdBattlePetScript/UI/Import.lua:21: attempt to index upvalue 'L' (a nil value)
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/UI/Import.lua:21: attempt to index upvalue 'L' (a nil value)
[string "@Interface/AddOns/tdBattlePetScript/UI/Import.lua"]:21: in function <Interface/AddOns/tdBattlePetScript/UI/Import.lua:15>
[string "=[C]"]: ?
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:66: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:61>
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:494: in function `InitializeAddon'
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:619: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:611>

Message: Interface/AddOns/tdBattlePetScript/Plugins/Base.lua:16: attempt to index upvalue 'L' (a nil value)
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/Plugins/Base.lua:16: attempt to index upvalue 'L' (a nil value)
[string "@Interface/AddOns/tdBattlePetScript/Plugins/Base.lua"]:16: in function <Interface/AddOns/tdBattlePetScript/Plugins/Base.lua:14>
[string "=[C]"]: ?
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:66: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:61>
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:494: in function `InitializeAddon'
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:619: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:611>

Message: ...face/AddOns/tdBattlePetScript/Plugins/FirstEnemy.lua:15: attempt to index upvalue 'L' (a nil value)
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: ...face/AddOns/tdBattlePetScript/Plugins/FirstEnemy.lua:15: attempt to index upvalue 'L' (a nil value)
[string "@Interface/AddOns/tdBattlePetScript/Plugins/FirstEnemy.lua"]:15: in function <...face/AddOns/tdBattlePetScript/Plugins/FirstEnemy.lua:13>
[string "=[C]"]: ?
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:66: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:61>
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:494: in function `InitializeAddon'
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:619: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:611>

Message: ...erface/AddOns/tdBattlePetScript/Plugins/AllInOne.lua:15: attempt to index upvalue 'L' (a nil value)
Time: Tue Oct 17 04:59:05 2023
Count: 1
Stack: ...erface/AddOns/tdBattlePetScript/Plugins/AllInOne.lua:15: attempt to index upvalue 'L' (a nil value)
[string "@Interface/AddOns/tdBattlePetScript/Plugins/AllInOne.lua"]:15: in function <...erface/AddOns/tdBattlePetScript/Plugins/AllInOne.lua:13>
[string "=[C]"]: ?
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:66: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:61>
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:494: in function `InitializeAddon'
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:619: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:611>

Message: Interface/AddOns/tdBattlePetScript/UI/PetBattle.lua:293: attempt to index field 'ScriptFrame' (a nil value)
Time: Tue Oct 17 04:59:16 2023
Count: 1
Stack: Interface/AddOns/tdBattlePetScript/UI/PetBattle.lua:293: attempt to index field 'ScriptFrame' (a nil value)
[string "@Interface/AddOns/tdBattlePetScript/UI/PetBattle.lua"]:293: in function `UpdateLocked'
[string "@Interface/AddOns/tdBattlePetScript/UI/PetBattle.lua"]:230: in function <Interface/AddOns/tdBattlePetScript/UI/PetBattle.lua:208>
[string "=[C]"]: ?
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:66: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:61>
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:523: in function `EnableAddon'
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:536: in function `EnableAddon'
[string "@Interface/AddOns/tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua"]:626: in function <...tdBattlePetScript/Libs/AceAddon-3.0/AceAddon-3.0.lua:611>
[string "=[C]"]: in function `LoadAddOn'
[string "@Interface/FrameXML/UIParent.lua"]:547: in function `UIParentLoadAddOn'
[string "@Interface/FrameXML/UIParent.lua"]:752: in function `MajorFactions_LoadUI'
[string "@Interface/AddOns/Blizzard_ExpansionLandingPage/Blizzard_DragonflightLandingPage.lua"]:179: in function `SetUpMajorFactionList'
[string "@Interface/AddOns/Blizzard_ExpansionLandingPage/Blizzard_DragonflightLandingPage.lua"]:172: in function `RefreshMajorFactionList'
[string "@Interface/AddOns/Blizzard_ExpansionLandingPage/Blizzard_DragonflightLandingPage.lua"]:167: in function `RefreshOverlay'
[string "@Interface/AddOns/Blizzard_ExpansionLandingPage/Blizzard_DragonflightLandingPage.lua"]:158: in function <...sionLandingPage/Blizzard_DragonflightLandingPage.lua:154>
[string "=[C]"]: in function `CreateFrame'
[string "@Interface/AddOns/Blizzard_ExpansionLandingPage/Blizzard_DragonflightLandingPage.lua"]:122: in function `CreateOverlay'
[string "@Interface/AddOns/Blizzard_ExpansionLandingPage/Blizzard_ExpansionLandingPage.lua"]:63: in function `RefreshExpansionOverlay'
[string "@Interface/AddOns/Blizzard_ExpansionLandingPage/Blizzard_ExpansionLandingPage.lua"]:35: in function <...pansionLandingPage/Blizzard_ExpansionLandingPage.lua:33>

I tinkered with replacing the localization with a simple setmetatable(L,{__index=function(L,key) return key end}) but a lot of downstream stuff had to be changed to use it.

[Justgiz]

Those localization file errors, are defiantly not my edit. They're due to the build script that PBS uses after commits, and before uploading to curse. You'd get those if you downloaded PBS's master branch. The last message i believe is due to the other errors.

I've been editing my copy of what's on curse, and porting over the edits to the git project. Should've tested my "git download" copy.

Best bet is to download PBS from curse, and copy over my branch's "Rematch" folder. But then you'll get the errors I encountered in my prev post.

[Gello]

The beta version posted this morning (5.0.0-beta-19) is the "release candidate" for November 7. Next weekend before the patch I'll be reviewing all my active addons to make sure they're ready for 10.2; but let me know of any issues remaining with this.

Some notes on this before it goes live:

• The scrollframe speed options I'll review again after this goes live.
• Rematch 4 had an option to put little notes buttons on pets in the battle UI. Rematch 5 doesn't have it yet and I'm on the fence about adding them back. Let me know if they're missed. (Does anyone put notes on a pet they need to refer to in battle?) I've tried to keep this addon out of the battle UI; but I do intend to eventually add a notes button to the micro buttons in the battle UI for the current team. This seems much more appropriate than pet-specific notes.
• The "Pet Herder" (to more quickly favorite/level/cage/mark pets) will be added sometime after this goes live.
• Rematch 5 does not try to translate other addons' changes to the journal to the Rematch's version of the journal like it did in Rematch 4. This includes button/checkbuttons other addons put on the journal. In some ways I think Rematch is harmful to the diversity of journal addons because it necessarily takes over the whole journal. I'm hoping with journal-like 3-panel standalone view in Rematch 5 it can be used detached from the journal and let other addons do what they want to the journal. Fortunately, in the few months of beta nobody has mentioned any of these at all, so this may not be an issue.

[Justgiz]

I don't know if you forgot, or made the executive decision to keep it that way.

But what were your plans on the panel tabs mirroring the window anchor setting. You said:

it seemed frustrating to maximize the window and then the tab that maximized it is now across the screen, so to minimize it you have to move over to the tab and back and forth.

But its also frustrating to have the tabs on a different part of the window as one would expect, just because they want the window to be anchored differently, and have its resizing to move in a way they desire. I don't use clicking on the tabs to minimize, but instead use the button on the top of the frame as well as double clicking the title bar.

I'm curious if I'm the only one experiencing this. Are people keeping the anchoring defaulted to "Bottom Right" and not even noticing the moving tabs? Or are they ok with that decision?

[Gello]

To be fair, for people who chose to anchor bottom right (or either of the top corners) in Rematch 4 without checking Move Panel Tabs To Right, they may have gotten used to panel tabs being in a different corner regardless how it feels broken to me.

I'll add an option to move the panel tabs. If not a dropdown to choose where to put the tabs, a simple checkbutton to move it to the other side. Probably a dropdown since people who anchor to a top corner in Rematch 4 may be used to tabs being on the bottom. Choosing a new anchor will move the panel tabs to the new anchor but they can be changed.

edit: 5.0.0-beta-20 just posted adds a new dropdown:



But as the changelog and tooltip mention, choosing a new regular anchor (Anchor To) will switch this to follow; but it can be independently changed after.

[Justgiz]

Thank you, I appreciate the work to get this out so quick. And I hope others appreciate it too.

[Schlumpf]

If you're a Rematch 4 user, the first time you log into Rematch 5, it will make an internal backup of your Rematch 4 teams and settings and then convert everything to Rematch 5. The internal backup will persist for at least as long as the beta lasts.

Just to make sure: You will remove the backup from the final release, or will it stay for a bit? I'm a bit scared with people updating only one of our two addons and thus us missing the update event. I would like to integrate some detection for this (probably just "you have Rematch scripts, but all the teams are gone") but need to be able to tell the user something in that case. Do you have a flag explicitly indicating the update is done?

I don't see any alternatives to what Gizz is currently suggesting, i.e. "sorry sorry sorry, but please restore the Rematch 4 backup, then log in again". In the best case I'd be able to have a "let me try that for you" button which triggers your reset.I guess users will notice the scripts being missing quickly, and hopefully will only change a few settings before noticing it, so that should be somewhat fine (i.e. not losing teams), just annoying.

I aim for having a version released this week that's compatible with both Rematch 4 and 5, so the users that use addon managers already have time to update before updating your side.

REMATCH_TEAM_OVERWRITTEN teamID,oldTeamID Just before teamID is overwritten by oldTeamID (can be nil for import/received teams)

"teamID is overwritten by oldTeamID"? Are those two words the wrong way around?

My assumption to correctly handle overwrites and renames is:

• on REMATCH_TEAM_OVERWRITTEN
  • if no oldTeamID, nothing to do
  • if oldTeamID has no script, nothing to do
  • if teamID has a script, remove it
  • if oldTeamID has a script, add script for teamID, remove script for oldTeamID
• on REMATCH_TEAM_UPDATED
  • update team name

[Gello]

Just to make sure: You will remove the backup from the final release, or will it stay for a bit?

It will stay for a bit. Likely for a couple months at least. I'm fine committing through the new year.

I'm a bit scared with people updating only one of our two addons and thus us missing the update event.

If Rematch.convert:GetConvertedTeams() returns anything, then an upgrade happened at some point in the past. First return is a table mapping old team key to new teamID. Second return is true if upgrade happened in that session. This mapping will exist for at least as long as the Rematch4 saved data.

"teamID is overwritten by oldTeamID"? Are those two words the wrong way around?

Yes sorry, that should be oldTeamID is overwritten by teamID.

[Schlumpf]

I'm a bit scared with people updating only one of our two addons and thus us missing the update event.

If Rematch.convert:GetConvertedTeams() returns anything, then an upgrade happened at some point in the past. First return is a table mapping old team key to new teamID. Second return is true if upgrade happened in that session. This mapping will exist for at least as long as the Rematch4 saved data.

Oh that's perfect, so the order issue is implicitly fixed as well and no need for weird rollbacks I don't care for people losing teams in a few months that much.

function rematch.menus:AddToMenu(menuName,menuItem,afterText)

function rematch.badges:RegisterBadge(list,badge,icon,iconCoords,callback)

We can dynamically disable our integration. For menus I can GetDefinition(menuName) and fiddle around myself, but badges aren't exposed like that. Can you add a quick remove/unregister api?

[Gello]

Can you add a quick remove/unregister api?

I can add one but won't have time to do it until this weekend likely.

If you'd like to have something in the meantime, you can make the callback function return false when integration is disabled.

[Schlumpf]

Can you add a quick remove/unregister api?

I can add one but won't have time to do it until this weekend likely.

If you'd like to have something in the meantime, you can make the callback function return false when integration is disabled.

You sneaky genius. Take your time with adding the API, it works perfectly.

[Schlumpf]

Minor detail: Importing one team opens to that team in the list (since it loads), but importing multiple teams does neither. I understand not loading a random one of them, but was personally confused by the group not expanding.

Regarding "TEAM_OVERWRITTEN": "new team id" and "old team id" are misleading, I think "modified team" and "with data from team" are more fitting. The event seems to not really be usable other than to drop data on "modified team" and then hope for the following events to make sense, otherwise you'd have to track all information. Gizz gave some scenarios in https://github.com/axc450/pbs/issues/65 and I ended up implementing "giving up".

FYI: Bad event hooks can break Rematch. No idea whether you can prevent that. If the handler has an error, Rematch doesn't do the entire processing, e.g. just doesn't delete the team.

[Gello]

Multiple teams can also import into multiple groups. So it doesn't make an attempt to show what was imported. But expanding all groups that had teams imported is reasonable. I can do that.

On the overwrite bit, I'll take a look tonight or tomorrow at latest.

A hypothetical situation: It was mentioned earlier that it'd make your life easier if scripts can be embedded in the teams themselves. If this is still the case (it's mean of me to ask this so late, I know), what is the payload you'd need to have in the team (a single string, multiple strings, a table, etc?) If Rematch moves this payload around as teams are copied/saved, does your addon need to know about that movement? Do you use the teamID as a reference for the script or can you re-query for all scripts when your UI updates? Are scripts target dependent?

I'm not opposed to delaying the release a couple weeks to make sure you guys are comfortable with this. I suspect there are a lot of users of Pet Battle Scripts and I'm fine waiting to release until they're compatible.

[Schlumpf]

On the overwrite bit, I'll take a look tonight or tomorrow at latest.

I think we are in an okay state here. People probably don't overwrite teams *that* often, and if then scripts being gone is probably okay.

I'm not opposed to delaying the release a couple weeks to make sure you guys are comfortable with this. I suspect there are a lot of users of Pet Battle Scripts and I'm fine waiting to release until they're compatible.

I'm fine with releasing as-is. As long as we release at the same time or us slightly ahead of you, everything is fine. I just don't want all the lua error reports

A hypothetical situation: It was mentioned earlier that it'd make your life easier if scripts can be embedded in the teams themselves. If this is still the case (it's mean of me to ask this so late, I know), what is the payload you'd need to have in the team (a single string, multiple strings, a table, etc?) If Rematch moves this payload around as teams are copied/saved, does your addon need to know about that movement? Do you use the teamID as a reference for the script or can you re-query for all scripts when your UI updates? Are scripts target dependent?

We currently store your-key → {name, code}, where we keep name in sync with your name. So technically, a single string is enough if we store it in your data. Then again, I'd suggest you ask any plugin to give you a string and if they need to store more, use some serialisation.

If you move it around, we would probably need to hook team_created, team_changed and team_deleted.

• On deleted we delete our data,
• on wipe we delete all our data, on update we keep the name in sync.
• On overwritten, we now just delete our data.
• On created, we currently do a bit of a hack to handle imports of script and team at the same time: we can have plugin user data as well, which in the case of the rematch plugin is a team string. On an import on our side, we first tell you to import, and once there is a team_created, we check whether the team string is the same we imported and if it is, we store the imported script for us.

This would probably look quite the same if you stored the data with the only major string being that your team string already has the script attached and we hook team_created to notice you have a script instead. Given that people don't have *that* many teams, we probably would ignore all that and just hook teams_changed and team_changed and update a cached list of team ids with a script, storing nothing on our side at all.

We currently maintain the mapping manually based on team ids. If you maintain it, we don't care really. When we enter a battle, we already check what team you have loaded and whether we have a script for that. When we show our UI, we can just iterate all your teams and check whether they have a script.

Scripts are team dependent.

[Gello]

Thanks for details. I'll post Rematch 5 sometime after 4PM EST on Tuesday. And think on ways to extend data a team can carry.

Probably 95% of overwrites are going to happen from imported teams. Save As onto the same team won't trigger one (shouldn't trigger one).

[Justgiz]

In my browsing of the Rematch source i found the method "Rematch.dialog:GetSubject()", using that to access the saveMode really helped me properly figure out the OVERWRITTEN event, whether it's a save-as or an edit. I also see that you do not use that method anywhere else, and worry that the method may get removed. We should be safe to access that in our callback right? (or any other method we may find) Don't want to be touching too much in case something changes.

Mainly it comes down to knowing if the event is happening due to an edit, or a save-as. With an edit, no action is needed, but save-as overwrite would require a copy or removal of a script.

[Gello]

Rematch.dialog:GetSubject() is intended and it will stay, even if I don't use it yet. It's a good way to get the saveMode (or other context-specific details) of the current dialog.

Just about every dialog in Rematch passes the subject so I haven't had a need to specifically use it yet.