New GB version coming... feature requests, anyone?

[Jimbo]

But what if games, screenshots, extras or photos are stored on a shared network drive?
For example \\NAS\Emulation\Gamebase\C64\Games is an absolute path, but hasn't a colon at the second position. So it seems that it is treated as a relative path.

The way around this at the moment is to map a drive letter to the network share, but I'll look to see if allowing \\ as an absolute path has any unintended side-effects in the rest of the code. If not, it should be easy to add.

I can't work on GB anymore this week, so it'll be a few days till the next update.

James

[K.C.]

Another issue with packing/unpacking archives:

Suppose I have a .ZIP archive TESTGAME.ZIP containing 3 zips:
version1.zip, version2.zip and version3.zip.

Version1.zip contains a file GAME1.EXE, version2.zip contains GAME2.EXE and version3.zip contains GAME3.EXE.

When I add TESTGAME as a new record to a Gamebase collection, it does this:
In the GBGAME folder, it creates:
- a subfolder Rezip, containing the contents of version1.zip (GAME1.EXE)
- a subfolder P1, containing the files version2.zip and version3.zip

This works fine if you want to use version1 (including rezipping if selected), but there is no way to choose GAME2 or GAME3 to be the preferred game.

It would be better to pop up a window that asks which file to use instead of auto-choosing the first one. This could be recursive (so if the archive you choosed contains multiple archives, a new window appears), until a supported file type is found.

This way different versions of a single game can be stored in one archive, but can be used for different database entries. This could be interesting in combination with the new "game is a clone of..." link type.

[Jimbo]

Sure, I'll take a look. I always hated the way it chose the first file.

[K.C.]

Great, thanks again!

Just a quick question about the kvsets you implemented in the upcoming version:
Is is possible to clear key=value pairs?
For example: if you specify somesetting=anything as a global key=value pair, can it be cleared in a kvset or a per-game key=value pair with somesetting= ?

[Jimbo]

yep it can be cleared by using an empty value

[edit]
Well, not really cleared, but set to an empty string, so currently you'd still have to test for that in a script.

[K.C.]

Hmm, so, in the example above and somesetting= specified in the per-game key=value pairs, will this GEMUS code:

Code: Select all

if %somesetting_value% contains(*)

be true or false?

[Jimbo]

should be false

[Jimbo]

Managed to add a "Review Rating" field tonight. If a game has a review rating, it will show a review bar like this: -



Rating bar gfx and text are customisable as usual, if you don't like the defaults.

I want to get the rest of the outstanding stuff done now so that I can release a new beta asap, so if you guys have any new feature requests please wait until the new beta is out, if that's ok (quick bugfixes are still ok tho)

cheers

[ldaneels]

Awesome. Thanks for all your hard work.

[K.C.]

Don't know if you call this a feature request or a quick bug fix, but could you please add a message box "Discard changes? Yes or No" when clicking Cancel or pressing Esc in the GEMUS edit window?

[Jimbo]

Just been thinking about the way Gemus extracts and rezips games, and I've come up with the following (hopefully improved) system, so I'm running it by you guys to see you if can spot anything I've missed, conceptually or algorithmically!...

This example assumes that d64 is a Gemus emulator compatible filetype and you have an archive game.zip, containing the following: -

Code: Select all

game.zip
	-> a.zip
	-> b.zip
		-> c.zip
		-> foo\bar.d64
		-> foo.d64
		-> foo\d.7z
			-> bar\baz.d64
	-> x.d64

EXTRACTING THE GAME

1. extract game.zip to \GBGame\P1\: -

Code: Select all

	\GBGame\P1\a.zip
	\GBGame\P1\b.zip
	\GBGame\P1\x.d64

2. ask user to pick either a sub-archive or a compatible file (user picks b.zip).

3. create gemus log file in P1\ to store chosen sub-archive: -

Code: Select all

\GBGame\P1\__gemus	(contains text:  "b.zip")

4. extract b.zip to \GBGame\P2\: -

Code: Select all

	\GBGame\P2\c.zip
	\GBGame\P2\foo\bar.d64
	\GBGame\P2\foo.d64
	\GBGame\P2\foo\d.7z

5. ask user to pick either a sub-archive or a compatible file (user picks foo\d.7z).

6. create gemus log file in P2\ to store chosen sub-archive: -

Code: Select all

	\GBGame\P2\__gemus	(contains text:  "foo\d.7z")

7. extract d.7z to \GBGame\P3\: -

Code: Select all

	\GBGame\P3\bar\baz.d64

8. single compatible file found, no further sub-archives found. Stores the default runnable file for game.zip (in the db) as: -

Code: Select all

"b.zip:foo\d.7z:bar\baz.d64"

When running games from GameBase, the above string is used to auto-select sub-archives and the default file to "run", so it doesn't ask the user every time. This should be backwards compatible with the existing gemus extraction routine.

REZIPPING THE GAME

9. game is run and emulator closes, user chose to rezip....

10. starting at last \GBGame\Px folder (e.g. P3\ in this example), it checks for additional files and asks use whether he/she wants to rezip them also.

11. chosen P3\ contents are zipped into whatever is stored in P2\__gemus file (foo\d.7z), overwriting the existing file (\GBGame\P2\foo\d.7z)

12. Contents of P2\ are zipped into whatever is stored in P1\__gemus file (b.zip), overwriting the existing file (\GBGame\P1\b.zip)

13. Contents of P1\ are zipped into game.zip

14. game.zip copied back to game path

[K.C.]

At first glance this seems to be the right way for handling archives for me.

What I miss is a check if the found sub-archives contain any supported file types. This could lead to browsing to a dead end in the archive/folder structure.

This could be solved this way:

At the beginning, before anything is extracted, these actions are performed:

• Main archive is opened, contents are checked for supported archive types and runnable files.
  If the archive contains subfolders, also these subfolders are checked for archives and runnable files.
  Every folder that contains a runnable file type is flagged somehow (1 or True).
  If it is in a subfolder, the parent folder(s) are also flagged.
• If supported archives are found, they are also opened one by one and also checked like in the previous step.
  If a supported file type is found, the parent folders/archives are also flagged.
• When the contents of all archives is checked, Gamebase will know what archives contain supported file types (or sub-archives containing supported file types).

Everytime Gamebase asks a question about what to do (run file or open subfolder), it has to exclude archives from the list of choices that do not lead to a supported file type.
If only one choice remains (runnable file in selected archive or one runnable file in one of the sub-archives), it has to skip the question and perform the actions automatically.

[Jimbo]

Good spot.

I had assumed the user would know what was in the archive, but this is not probably always the case. Your suggestion seems workable, as long as the command-line version of 7-Zip (what I now use for extracting) has the option of listing all files/folders in archives without actually extracting them. I'm imagining that it does, but I haven't checked yet.

Cheers

[K.C.]

... as long as the command-line version of 7-Zip (what I now use for extracting) has the option of listing all files/folders in archives without actually extracting them. I'm imagining that it does, but I haven't checked yet.

Created a test .zip file with the following structure:

Code: Select all

test.zip
    text1.txt
    text2.txt
    -> subfolder
          sub1.txt
          sub2.txt

the command 7z l \test.zip does this:

Code: Select all

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  -----------------------
2010-01-19 12:45:28 ....A           13           13  subfolder\sub1.txt
2010-01-19 12:45:38 ....A           35           33  subfolder\sub2.txt
2010-01-19 12:44:56 ....A            9            9  text1.txt
2010-01-19 12:45:10 ....A           32           30  text2.txt
------------------- ----- ------------ ------------  -----------------------
                                    89           85  4 files, 0 folders

I assume this is what you need to search for supported file types before extracting.

[Jimbo]

Yep. Looks good. I assumed it would have an option to do that, just didn't get around to looking yet