bemaniutils
bemaniutils copied to clipboard
DragonMinded
Jubeat webui needs improvement
This is another tracking issue since I'm already planning on getting this done. So there's several issues with jubeat's webui that could use some fixing.
- Emblem customization.
- Title and parts customization should also be added considering all the backend work already exists, it just needs a drop down box.
- Version derivation in global records page should be redone such that read.py simply retrieves that info while importing and then can be displayed to a more granular level. (I did the work figuring out the version flags already a long time ago, I just couldn't be bothered to do this part) This version derivation is actually doubly important because jubeat avenue actually breaks the assumption made in the records.js file because it doesn't add a digit to the music id, it instead just prefixes the songid with 11 and as a result is placed in the same folder as jubeat 1 without some hack applied. Since this breakage happened, I figured it'd be for the best to just get rid of the hacky version derivation entirely.
- Finally, Since jubeat festo added detailed levels for 9-10, the detailed level should be used rather than the integer one for those difficulties. While I did implement this for myself a long time ago I did it in a very hacky and breaking way.
With respect to emblem customization and title/part customization, does that hinge on either lobby support (for displaying emblems) or getting rid of the force unlock everything bits that are set by default? I was going to, as part of my festo research and implementation, go back and add actual "force unlock" flags like most of the other games and refuse to save things that would taint your profile if forced unlock was applied. I think that would make the JBOX stuff feel more useful, but that would obviously have to be coupled with the frontend stuff you were talking about to be completely useful.
Where does the stuff you're gonna push sit with respect to all of that?
I currently just let everything be force unlocked and show all emblems in the webui. And lobby support isn't needed since emblems are both shown at log in and during local matching against other players. ~~I also have just realized that the version flag issue is much more problematic than I thought because apparently the version flags for the same version change from game to game...~~ Figured this problem out but I'm going to need to ponder for a bit longer...
Ah, I nuke local matching on my cabinet since I don't have another one (I have matching enabled on both my Reflec Beats but that's it really) so I never thought about it being shown there. I guess showing emblem parts "correctly" means either checking that the game force-unlocks everything or by checking ownership of them, however.
Lobby support wouldn't be terribly hard to throw in, the infra is all there from implementing reflec beat lobby support. All the global IP routing is there for proxy support and you even pick the public port you assign to cabinets specifically so that port forwarding can be applied for games to make global lobbying work. So it would be mostly a matter of actually implementing the packets.
There's a bug in this section and I'm not sure how to resolve it because I don't think I fully understand how that flag is created: https://github.com/DragonMinded/bemaniutils/blob/6f56e9240ef2f5fd1dd0ef47cdb569ce9da22189/bemani/backend/jubeat/clan.py#L1223-L1225 The issue I noticed is that if this is set to True after the first profile load, category select is somewhat broken (at least in festo). So this should actually only be True on first profile load and then False afterwards...
If I understand correctly, the culprit is these lines right here: https://github.com/DragonMinded/bemaniutils/blob/6f56e9240ef2f5fd1dd0ef47cdb569ce9da22189/bemani/backend/jubeat/base.py#L97-L100 Since this bit of code is only executing after the new profile has been created already. So I think the resolution is to just delete them? This isn't a fix that's testable with traffic tests though so I would need to actually boot up the game to know that it does what I want.
If you remove the 'has_old_version' stuff, you will re-enable tutorial on first play for migrated profiles. So that's not a good idea. None of the other ones seem to care that the inherit flag is set after the first load. I think the best way to fix is to just persist a "saved" entry into the profile blob on unformat_profile for all jubeat versions, and change the inherit flag set to profile.get_bool('has_old_version') and not profile.get_bool('saved'). That way it'll set the inherit if you have an old profile, up until the game saves the profile (you're guaranteed to have played a round). Then on, it'll set back to false again.
Based on the PR you put up and merged code in my festo branch, I think 3 and 4 are both complete, which leaves 1 and 2 to work on. I'm trying to get my head around the rest of festo core functionality and see what (probably all honestly) of your festo changes can just be merged into trunk. After that I'll have a bit more time to dedicate to looking at the emblem and jubility code you put up. Sorry I'm not in a state to work on this faster.
Note that I pushed a few somewhat-nasty hacks for the version stuff, but it boils down to "we used to infer version on the UI, but now we import it. however, in the places on the backend that request it, if its not available we infer it with the old ruleset". I'll take the blame for the nasty hacks so you don't have to. But anyway it should mean that existing installations that don't re-import data won't break. Its good enough for me TBH.
At this point, all 4 bits are integrated into trunk. However, we still don't have a generic way to specify resource directories for in-game assets such as the emblem art.
Okay, the in-game assets bit is worked out and pushed to trunk and also live on my instance. The only thing left really is title and part customization. I think @Subject38 was going to tackle that independently?
I think we can safely close this issue. Massive strides have been made towards improving the webui in general and the initial reasoning that made me open the issue has been long resolved <3. Once I get a chance, I'll look into how exactly the title and parts customization should look in the ui because there's some template rendering magic going on where inside a title, there can be some text filled in with a part.