alex9490 / editor-on-fire

Automatically exported from code.google.com/p/editor-on-fire
Other
0 stars 0 forks source link

Allow Load OGG to read OGGs from folder's other than the current chart's folder #201

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Currently EOF only allows you to use Load OGG to load an OGG that is in the 
current chart's folder. This limitation was put in place to prevent some bugs 
from occurring with OGG profiles and leading silence manipulation.

To solve this issue we need to change the way OGG profiles work. Instead of 
storing a filename when creating a new OGG profile (by using Load OGG) we 
should copy the selected OGG into the song's chart folder with a filename that 
reflects which OGG profile it is tied to (we can't use the original OGGs 
filename due to the possibility of loading two files with the same name causing 
it to fail to work properly). "guitar.ogg" is always tied to profile 0. 
Subsequent OGGs can be set up sequentially (e.g. profile1.ogg, profile2.ogg, 
etc.).

A binary file compare would need to be run on a newly loaded OGG against all 
the profile OGGs to determine if a new profile needs to be created. Alternately 
we could store a checksum for each profile so we only need to build a checksum 
for the newly loaded OGG and see if it matches any of the existing profiles.

Original issue reported on code.google.com by xander4j...@yahoo.com on 11 Nov 2010 at 1:32

GoogleCodeExporter commented 8 years ago

Original comment by xander4j...@yahoo.com on 11 Nov 2010 at 1:33

GoogleCodeExporter commented 8 years ago
A binary file comparison doesn't take that long, I don't personally know if 
it's faster or slower than generating a checksum and comparing it to another 
checksum though.

I like the idea with the OGG naming, it should prevent lots of problems.  
Perhaps when we add an OGG profile management dialog menu, we can let users 
rename the profile (ie. from profile2 to drums), and it would rename the OGG 
accordingly.  Does Allegro really not have a file rename function though?  It 
seems wasteful to have to do a copy operation just to be able to rename..

Original comment by raynebc on 11 Nov 2010 at 1:40

GoogleCodeExporter commented 8 years ago
Allegro has no rename function.

A checksum is definitely faster (assuming we are talking about a basic checksum 
and not an MD5) because you are only reading the bytes of the file the first 
time it is loaded. Afterwards you are just referencing the file by the checksum 
which is stored in RAM. Binary compare is probably good enough, though.

The ability to rename profiles sounds nice. It might also be a good idea to 
allow some comments to be added to a profile in the proposed new project format.

Original comment by xander4j...@yahoo.com on 11 Nov 2010 at 1:51

GoogleCodeExporter commented 8 years ago
Perhaps a rename utility (which calls a platform specific system command) could 
be rigged to rename a file?

Original comment by raynebc on 27 Dec 2010 at 5:26