There’s been ongoing discussion about a new file format to store chart data for songs in Etterna in a better way than the others have done so far. Some of the goals of this new and improved format are to compress the data (not like that part matters too much) and make the plaintext more human-readable.
Some other ideas that have been mentioned are to add new features to the game that utilize the file format to implement – for example, adding segments to songs and/or charts that label different sections by difficulty, patterns, etc. (think guitar hero segments) (thanks providence).
I’m making this forum post to catalogue any feature suggestions for the .ett format so we don’t just forget them. Any ideas are appreciated.
Jole mentioned adding more quantisations to the game to aid charting, currently they need to be hand placed as 192nds, if the following are made into real snaps they will help alot.
Adding new snaps to the game is probably a lot more work than it’s worth and will probably break noteskins, so maybe making the .ett reader interpret measures of arbitrary row counts (<= 192) in a sensible way could work for this purpose.
On human readability issue, is there anyone who actually opens up the .sm file on a text editor?
If everyone who edits charts uses some sort of dedicated editor e.g. AV , then striving for human-readability inside the .sm file itself makes little sense.
I want to add that actual human readability of a text format like this is pretty much impossible and will never be viable when compared to an actual editor. It makes more sense to use a binary format that’s more designed towards being small and simple to write an interpreter for. You can store any notes data in 4 bits (3 might work too but ewww 3) and since this leaves room for additional special characters it would be easy and efficient to implement culling of zeros, or any other feature you might want to implement I dunno. You can only have up to 16 tho so this might be restrictive for future implementation of some new stupid feature, but those features are as stated stupid and should not be implemented, so this would just serve as a deterrent which can be considered good.
On a more practical standpoint, as it stands there are much more important things to potentially work on than an .ett. In game editor (AV and DDream could be so much better, but even so you kind of need this if you even want to be able to make an .ett), calc (though in fairness that’s afaik dependant on Mina’s motivation to work on it, which he apparently doesn’t have any rn), general QOL/bug fixing, the millions of backend optizations/reworks still in progress, ReplayV3, new player streamlining of Til Death, etc. I doubt that the amount of work that making a new file format would necessitate would be worth right now.
On a theoretical standpoint, there’s a decent amount that could stand to be gained from an .ett. Assuming it’s made after an Etterna editor, the possible creature comforts would be nice but not numerous. The aforementioned additional 192nd-based snaps, additional file options (forced lifts/xmod/cmod/judge/etc), a “.paq” that auto-installs itself to your etterna folder (though that could probably be implemented with sm/ssc) and probably a few others I’m not thinking of. Data compression of the file that’s already far smaller than the gfx/music (unless done for the sake of significant performance upgrades) and readability of something no one wants to read in the first place isn’t an issue.
Also 300 iq idea: Why not just further develop .ssc instead of making a new file format? It is the most feature rich format we have so far, after all. I don’t imagine an .ett would be made without porting over some of it’s features anyways, so why not keep improving it? I do imagine taking this path would likely mean having to deal with more sm5 dev spaghetti though.
Exactly, don’t abandon .ssc unless there are good reasons to do so, we already have enough formats. While making a new format is definitely easier, it creates unnecessary friction. In the end, both Stepmania and Etterna would have to support both formats, otherwise steppers would need to create versions for both games.
What is the advantages of an in-game editor? I’m worried that there will be a lot of duplicated effort if every DDR engine needs to implement their own editor, and we will end up with a bunch of mediocre editors instead of having a few polished ones.
This could be added as a sidecar file and actually probably best that way. It doesn’t have any impact on gameplay/scoring, so there is not any reason to enforce a strict coupling between the stepping and the segments. And by keeping it separate you can easily add it to old charts not using .ett, so people could create segments to existing song packs and users could apply them while being sure that it does not affect the stepping.
Two conflicting features, compressing the data would make it unreadable. Though to repeat what others have said, neither really matters and are certainly no reason to create a new file format for. I think it would be more important to make it as flexible and extendable as possible, so there would be less reason to create yet another new format in the future.
There’s no feature-specific advantage I have in mind to a theoretical new editor being in-game, I just imagine that if a new one were to be made it would be based off the existing sm5 editor as a good portion of the work would already be done. If a new editor were to be made, there wouldn’t really be a reason unless it’s better than AV. The thing is that AV is closed source and Fiet doesn’t seem to have any interest at all in further developing it, with sadly still a lot of room for improvement (see: everything about the Rhythm Horizon editor and DDream syncing). If any progress were to be made, the only two options are convincing fiet to share source code or making a completely brand new editor. I have a feeling the former isn’t going to happen any time soon.
I didn’t know that they were abandoned closed source projects, then any progress is better than nothing I guess. I still think not being too tightly coupled with a specific engine/simulator is better for such a project in the long term though.
maybe the ability to define sections that repeat in the song, represented with a key of some kind? should allow you to cut down on file size on charts that repeat a lot
