Closed Kewlan closed 1 month ago
The SeedData was intended as a flexible structure that is saved off to be used for analytics later. So it wasn't designed to be deserialized as part of the operation of the site. If we start deserializing it, then we have to think about how things could break if its structure changes. We've thought about moving in that direction, and it may be worth it but I think it needs some more discussion. We did start reading the "ultra_low_qol" setting from the SeedData during customization, but it's done in a way that doesn't depend on the overall structure of the SeedData remaining stable. If we are going to deserialize the whole structure, then one strategy could be to convert all its members into Option types, as a way to ensure it can continue evolving without getting so easily broken. Still we can run into trouble if we end up assuming non-None values for entries. The trouble is these things are not very easy to test, as you would have to try opening the seed pages for old seeds to see if there are problems. Avoiding dealing with this is a lot of why we pre-render most of the seed page, since it sidesteps the need for newer versions of the server to need to understand the data of old seeds. We haven't decided on how committed we are long-term to backwards compatibility with old seeds, but people do sometimes look up old seeds on #interesting-seeds for example, so it's a use case we'd like to continue supporting if we can.
I'm not sure about 12 hours as it seems a bit arbitrary. If we add an auto-unlock feature, then it should probably be customizable on the Generate page, e.g. as a setting that is hidden except when Race Mode is selected. I think the ideal solution is an integration with Racetime that unlocks the seed after the race is finished, but that is probably a lot more complicated; a time-based auto-unlock feature could still be useful in the meantime. With the unlock time being configurable, the default setting could probably be significantly lower than 12 hours, which could make it more useful.
Normally we try to roll race seeds just before the race, to show nothing has been pre-examined or shared.
In the situation where racers cannot find a time that works for both runners, the seed can be run asynchronously. And I've seen the gap between the first runners playthrough and the second being 5days, but its supposed to be less than a week. #community-seeds
style async racing, like what the alttpr spoiler tournament is doing, has seeds generated 3 weeks in advance. A work-around could be to distribute the roms and not the seed link.
Default unlock time depends on the settings - our extreme challenge race had runners going for 17 hours of playtime. The hard tricky races don't usually have anyone go much past 4hours.
SeedData
Would it be fine to deserialize it into a HashMap and check for the timestamp
key, or should the creation timestamp (or the unlock time) be saved to a separate file?
Unlock time
I can make it an option, but what should the default time be? If default is never, then I would assume those that forget to unlock it would also not set an unlock time. For racetime seeds, having the bot auto-unlock it when everyone is done is for sure the best solution, but for other cases it sounds like there isn't a good solution. If there's a need to manually set when to auto-unlock it, it feels almost pointless as it's the same effort as unlocking it manually. But if it's hard-coded to be a week, then that could be annoying for other reasons. So maybe it's best to not have this feature?
Yeah, I'm not sure. It seems like the feature can help in some cases but could also create new problems. The existing manual solution of "ask the race creator to unlock the seed" seems to mostly work all right, even if not always convenient. I don't have strong feelings one way or the other. A proper integration with Racetime would still be the long-term goal either way.
In the place where we're currently reading the SeedData, what we do is parse the JSON to a json::JsonValue and then extract the specific key that we're looking for:
https://github.com/blkerby/MapRandomizer/blob/65b272d075aaf6f2cf0f7e9c9dc73249c172f97f/rust/maprando-web/src/web/seed/customize_seed.rs#L105. Parsing to a HashMap sounds similar and would probably work too. I have been interested in potentially migrating away from json
crate in favor of serde_json
. A lot of the manual JSON parsing we're doing is in game_data
module for loading the sm-json-data, and that will eventually get replaced by the sm-rs-data
crate.
Racetime integration is what the racing community wants to move towards. Where a bot rolls the seed and can unlock the spoiler when the race finishes.
A personally rolled seed, you'd have control over. e.g. #interesting-seeds
someone would ping the roller to unlock it if it wasn't already. But it could be a little useful here.
An admin rolled seed, you would have to keep this feature in mind if not turn it off.
Gonna leave it for now.
The check happens when the get request for the main seed page is called. Auto-unlocks if 12 hours has passed.
In
view_seed
, usespoiler_token
to check if it's a race seed, andunlocked_timestamp_str
to see if it's already unlocked.