search

Gamer125 / fofix

Automatically exported from code.google.com/p/fofix
0 stars 0 forks source link

Move scores and savegame handling into separate database. #346

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Right now, highscores and the "unlock_completed" parameter (for careers)
are inside the song.ini. This is messy, because song.ini should only
contain information about the SONG, not the user's "save data". It's hard
to explain, but the song.ini should just be metadata added by the fretter,
and the user's highscores and unlock_completed parameter don't belong there.

When the game detects highscores and unlock_completed inside the song.ini,
it would automatically move it to "highscores.ini" (or whatever the
appropriate name is), so the change would be completely invisible to the
user (he wouldn't have to run an external program to do the conversion).

It also has the added benefit that career downloads containing just
song.inis and title.inis can be "installed" onto an existing song library
without losing highscores.

Original issue reported on code.google.com by coolguy5678@gmail.com on 4 Dec 2008 at 4:04

GoogleCodeExporter commented 9 years ago 
I think this could be considered if FoFiX would be more "mature" but since it's 
still
a moving target i think this could quickly become a mess.

Having a seperate DB would have its pros and cons.

Original comment by evily...@gmail.com on 4 Dec 2008 at 4:14

GoogleCodeExporter commented 9 years ago

Original comment by aked...@gmail.com on 11 Jun 2009 at 9:10

GoogleCodeExporter commented 9 years ago 
I feel like doing this for the release after next.  It would open up very many
possibilities for better song handling and allow the songs folder to be used 
from a
read-only area of the filesystem (which is much more important than it sounds).

A single SQLite database whose location follows the same rules as fofix.ini 
ought to
do the trick.

Original comment by john.stumpo on 11 Jun 2009 at 11:35

GoogleCodeExporter commented 9 years ago 
Ouch. Seperate.

Anyway, my thoughts on this would be to put other player data with it - namely
users/controllers - as additionally it would be nice to link players with 
scores.

Original comment by aked...@gmail.com on 13 Jun 2009 at 11:47

GoogleCodeExporter commented 9 years ago

Original comment by Qst...@gmail.com on 16 Jun 2009 at 2:32

GoogleCodeExporter commented 9 years ago 
wouldn't there be issues with updating songs with new/loss of notes? if you 
were to 
update a song with say new solos, overdrive and general notes, the high scores 
would 
change. with a seperate database, you would have to clear the highscores for 
the 
fresh scores.

unless I'm missing something with how FoFiX deals with high scores.

Original comment by aus_fla...@live.com.au on 19 Nov 2009 at 4:31

GoogleCodeExporter commented 9 years ago 
that happens now.

if you change the midi, the song.ini will ignore past scores as the song is 
seen 
different.

Original comment by pvsou...@gmail.com on 20 Nov 2009 at 5:32

GoogleCodeExporter commented 9 years ago 
In my opinion, SONG.INI should only be used to store the original song metadata 
(song names, artists, fretters, etc) so it can be opened as READ-ONLY. I agree 
with 
the original poster (coolguy5678) that the highscores and stuffs like setlists 
unlock info don't belong here. 

If the SONG.INI is READ-ONLY, it will probably solve issue 729 also, since 
fofix 
don't need read/write access to the folder. See http://code.google.com/p/fofix/
issues/detail?id=729

As a side note, DTXMania uses a variation of this approach, but instead of a 
separate centralized database for scores, it creates another INI file inside 
the 
folder, so you'd end up with SONG.INI and SONG.SCORE.INI. Personally i'd prefer 
if 
the program don't modify the song folders at all. 

Regarding updating songs (Comment #6), i suppose we can implement some simple 
hashcode checking, see if the current song hashcode differs from the one we 
have in 
the database. If it is, treat it as a new song, with separate highscore list.

Original comment by truesa...@gmail.com on 24 Nov 2009 at 2:13

GoogleCodeExporter commented 9 years ago 
That is essentially our plan, though we would use SQLite instead of .ini files 
for
the data that the game needs to modify.  song.ini would indeed become read-only.

Original comment by john.stumpo on 24 Nov 2009 at 6:11

GoogleCodeExporter commented 9 years ago 
Issue 746 has been merged into this issue.

Original comment by john.stumpo on 24 Nov 2009 at 6:34