Roster import

[InfiniteStryker0]

This is the roster creator for MODAQ: https://www.quizbowlreader.com/createTournamentFile.html

It would be great if the output from this could be imported into YFT, rather than having to input the rosters manually. Or - if YFT could output this file that would also be great

[jonahgreenthal]

I think MODAQ has a significant bug related to this. It claims that the roster file is a QBJ file, but it's not valid QBJ. I think it's just a Tournament object that should be within a QBJ file. That is, MODAQ is outputting

{"name": "x", "registrations": […]}

but it should be outputting

{
  "version": "2.1.1", 
  "objects": [{"type": "Tournament", "name": "x", "registrations": […]}}
}

If MODAQ fixes this bug, then this YellowFruit feature request becomes a subset of #47.

[alopezlago]

MODAQ could be updated to support both formats (what it currently outputs and one with a version/objects field), and you could file an issue for that in the MODAQ project page. However, the files MODAQ outputs for matches and for rosters have been light-weight and haven't conformed to the serialization guidelines because the demo site can be run outside of a tournament context. If someone wants to use it as a one-off for packet reading or for something small, it doesn't make sense for them to input all of the information needed to create a tournament just to get a match or set of players. There is also, as far as I'm aware, no existing software that outputs tournament information as a QBJ file, although maybe NAQT has something that does (but NAQT also uses their own proprietary stuff, so it's not relevant to MODAQ).

For what it's worth, Yellowfruit imports MODAQ's Match QBJ files even though it doesn't follow the serialization guidelines (no version, no objects array, no Tournament information).

[jonahgreenthal]

However, the files MODAQ outputs for matches and for rosters have been light-weight and haven't conformed to the serialization guidelines because the demo site can be run outside of a tournament context. If someone wants to use it as a one-off for packet reading or for something small, it doesn't make sense for them to input all of the information needed to create a tournament just to get a match or set of players.

I don't follow this logic. Is it really worth creating a nonstandard serialization format just to be marginally lighter-weight than an already pretty lightweight format?

I don't really care what you do with your software on its own since I don't use it or otherwise have a stake in it. I do have a bit of a stake in YellowFruit: Many of my customers use it, so I want it to be easy to use (for them) and standards-compliant (so their files can integrate with other tools I use, including ones internal to NAQT). So I would ideally like it not to have a proliferation of support for proprietary options that will make the software more complex for seemingly little gain.

There's already a standard that covers this feature request and is partly supported by both MODAQ and YellowFruit. To me it seems like the obviously correct solution for MODAQ and YellowFruit to fix/update their standards support.

There is also, as far as I'm aware, no existing software that outputs tournament information as a QBJ file

YellowFruit does. (So does Tournament Director, but no one really uses that.)

[InfiniteStryker0]

Could MODAQ's roster utility just output a tournament file, and MODAQ accept one, instead of what it does now? I can't imagine you would use that utility unless you ran a full tournament instead of a one-off. Does a tournament object have more real information besides just a list of teams and who's on them? I see it has a version number, but is there anything else?

On Mon, Aug 26, 2024 at 8:41 AM Jonah Greenthal @.***> wrote:

However, the files MODAQ outputs for matches and for rosters have been light-weight and haven't conformed to the serialization guidelines https://schema.quizbowl.technology/serialization/ because the demo site can be run outside of a tournament context. If someone wants to use it as a one-off for packet reading or for something small, it doesn't make sense for them to input all of the information needed to create a tournament just to get a match or set of players.

I don't follow this logic. Is it really worth creating a nonstandard serialization format just to be marginally lighter-weight than an already pretty lightweight format?

I don't really care what you do with your software on its own since I don't use it or otherwise have a stake in it. I do have a bit of a stake in YellowFruit: Many of my customers use it, so I want it to easy to use (for them) and standards-compliant (so their files can integrate with other tools I use, including ones internal to NAQT). So I would ideally like it not to have a proliferation of support for proprietary options that will make the software more complex for seemingly little gain.

There's already a standard that covers this feature request and is partly supported by both MODAQ and YellowFruit. To me it seems like the obviously correct solution for MODAQ and YellowFruit to fix/update their standards support.

There is also, as far as I'm aware, no existing software that outputs tournament information as a QBJ file

YellowFruit does. (So does Tournament Director https://github.com/puls/tournament-director, but no one really uses that.)

— Reply to this email directly, view it on GitHub https://github.com/ANadig/YellowFruit/issues/64#issuecomment-2310248595, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHBWD62NWNUE47N6ZOERY2DZTMWCHAVCNFSM6AAAAABNBUW562VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJQGI2DQNJZGU . You are receiving this because you authored the thread.Message ID: @.***>

[jonahgreenthal]

Does a tournament object have more real information besides just a list of teams and who's on them?

It can (and often does) have tons more information, like the entire collection of results/statistics from the tournament. But it doesn't need to.

[alopezlago]

I can add some basic support to MODAQ first and then update the createTournamentFile page to create the serialized version. I don't really want to be in the business of supporting everything in the QBJ file like references, and eventually programs like TMS will handle most of this stuff and just pass in players to the MODAQ component.

Here's the first step, which adds support to MODAQ: https://github.com/alopezlago/MODAQ/pull/307

[InfiniteStryker0]

That would be great! Also what's TMS?

On Tue, Aug 27, 2024 at 2:36 AM Alejandro @.***> wrote:

I can add some basic support to MODAQ first and then update the createTournamentFile page to create the serialized version. I don't really want to be in the business of supporting everything in the QBJ file like references, and eventually programs like TMS will handle most of this stuff and just pass in players to the MODAQ component.

— Reply to this email directly, view it on GitHub https://github.com/ANadig/YellowFruit/issues/64#issuecomment-2311781209, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHBWD66QQKTWCASYUTKGQTTZTQT6RAVCNFSM6AAAAABNBUW562VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJRG44DCMRQHE . You are receiving this because you authored the thread.Message ID: @.***>

[alopezlago]

MODAQ and the createTournamentFile page have been updated to use the serialized tournament format.

TMS is a tournament management system current under development. It currently uses MODAQ for games, and it handles other aspects of tournament management (roster creation, schedules, displaying stats, etc.).

[InfiniteStryker0]

If the createTournamentFile page now uses the serialized format, can we now import the rosters directly into YF4?