VOGONS

Common searches


DOSBox Game Launcher (DOSBox Frontend)

Topic actions

Reply 1021 of 1962, by The Devil Hunter

User metadata
Rank Newbie
Rank
Newbie

ah Flip.. Now I see where you was getting at. CTRL+F5 takes screenshots.. I was really talking about in the Frontend, where it grabs the Screenshots from Mobygames and Such. I just figured that out after I posted, and forgot to say. Ohwell.

Anyhow, just tested this out on my external drive.. Works as expected. Loving it all the way

Mess with the best, die like the rest.

Reply 1022 of 1962, by RetroFAN

User metadata
Rank Newbie
Rank
Newbie
RetroFAN wrote:
With 0.77 version I have some problems while querying Mobygames (in its new incarnation).. eg while querying "Fantasy Pack" I ge […]
Show full quote

With 0.77 version I have some problems while querying Mobygames (in its new incarnation).. eg while querying "Fantasy Pack" I get this error:

--------
Couldn't retrieve information from MobyGames for "Fantasy Pack" !

Technical information:
String index out of range: -20
--------

Do I nee to provide more infos?

Very stupid question... This error is related to the new MobyGames layout?

Reply 1023 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Yes, in combination with a programming mistake from my side. Here's the update, test build 0.77a:

* Fixing MobyGames query for games for which there is no developer data, and there are no credits links such as "The Complete Great Naval Battles: The Final Fury" and "Fantasy Pack"

All the latest files
To upgrade, grab the dbgl.jar as usual.

Regards,
Ronald

Reply 1024 of 1962, by kolano

User metadata
Rank Oldbie
Rank
Oldbie

In a future version could you make it possible to export from non-dosroot locations?

I currently store my games on a NAS so their profiles point there. It would be nice if the export process could handle the directory moves/profile changes related to migrating them to dosroot (since I presume that's where imported packages go to). Better yet would be to allow the import to alternate locations as well, perhaps set via a config param or directory selector on import.

Eyecandy: Turn your computer into an expensive lava lamp.

Reply 1025 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Kolano, I'll consider your suggestion. For the moment, have you considered changing your DBGL DATA directory? Please be sure to make a backup of your DBGL files prior to changing settings like that, though!

Now that MobyGames seems to be back to it's former glorious shape, I've prepared another small update, 0.77b, to fix data querying from the website (again).

All the latest files
To upgrade, grab the dbgl.jar as usual.

Regards,
Ronald

Reply 1028 of 1962, by collector

User metadata
Rank l33t
Rank
l33t

Hey Ronald, were you able to just revert to your code you had before they screwed up MobyGames?

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 1029 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Mostly, but not exactly; some of the HTML changes required small alterations to the Java code, and I had to write some code to ignore all the 'add cover', 'add ranking', 'add this', 'add that' hyperlinks.

I've attached both file revisions for your convenience.

Attachments

  • Filename
    moby.zip
    File size
    6.35 KiB
    Downloads
    126 downloads
    File license
    Fair use/fair dealing exception

Reply 1030 of 1962, by collector

User metadata
Rank l33t
Rank
l33t

I was mostly curious about if Moby was the same as before they screwed it up.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 1031 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Ah, well, mostly. The most annoying thing that is left over from the 'dark ages horror design' is that the search results come back in a rather arbitrary order; thus when results are spread out over multiple pages, one can never be sure to have obtained all unique results because pages can have overlapping items - really strange behavior.

Reply 1032 of 1962, by RetroFAN

User metadata
Rank Newbie
Rank
Newbie

Hi!

I'd like to update my >4700 game collection with some extra info from MobyGame online database; so I'd like to request (even if I know the answer will be "NO") if it's possible to modify DBGL to query MobyGames for some extra fields.

For example (The 11th Hour) I'd like to get in the Notes field this combined text (it's only an example...):

[MobyGames]

-----------
Description
-----------
The 11th Hour is the sequel to the widely successful game, The 7th Guest. It utilizes a much improved video compression engine by Graeme Devine and is also the game which brought forth Trilobyte's eventual demise.

This time you play the role of Carl Denning, boyfriend to the reporter Robin Morales. Robin has mysteriously vanished while trying to delve into the secrets of the rotting mansion of the once evil mastermind, Henry Stauf.

The game features new puzzles, redone graphics and indeed an improved engine - much smoother, with 16 bit graphics and an entirely new soundtrack. The basic gameplay is still similar to its predecessor: the player walks through the mansion, watches FMV sequences and solves logic riddles. The so-called GameBook, a laptop, can be consulted to receive puzzle hints.

-------
Credits
--------
Lead Programming Graeme J. Devine
Music George Alistair Sanger
Sound Programming George Alistair Sanger
Additional Graphics / Artwork Rob Landeros
Director David Wheeler
Writing Matthew J. Costello
Dialogue Matthew J. Costello
Story Matthew J. Costello
Sound Design Sherman Archibald
Engineering Sherman Archibald
Package Design (FRA+GER+UK) Root Associates London

---------------
Technical Specs
---------------
Business Model Commercial
Minimum CPU Class Required 80486DX2
Minimum OS Class Required DOS 5.0
Minimum RAM Required 8 MB
Media Type CD-ROM
Minimum CD-ROM Drive Speed Required 2X
Minimum MSCDEX Required 2.2
Video Modes Supported SuperVGA, VESA, VGA
Minimum Video Memory Required 1 MB
Sound Devices Supported Adlib, Adlib Gold, Ensoniq Soundscape, ESS AudioDrive, General MIDI, Gravis Ultrasound / ACE, Microsoft Sound System, Pro Audio Spectrum, Roland MT-32 (and LAPC-I), Roland RAP-10, Roland Sound Canvas, Sound Blaster, Sound Blaster 16, Sound Blaster AWE32, Sound Blaster Pro, WaveJammer (PCMCIA)
Input Devices Supported Keyboard, Mouse
Number of Players: Offline 1 Player
Miscellaneous Attributes Math co-processor
Notes Other minimum requirements:
Hard disk space : 4 MB

------
Trivia
------
Alternate Version

A more explicit "R-rated" version of the game with partial nudity was planned at one time. While it did not get to production the script for the R-rated version can be found in the Prima Official Strategy Guide. The bad ending of the game is actually from the R-rated version, but slightly toned down and missing one effects shot. No one seems to want to fess up to being responsible for this script either, as in interviews the writer, director, and Trilobyte all deny writing it.

Cancelled Port

A 3DO version of this game was in the works, but the project was scrapped due to the public's lack of interest in the console. Some promotional catalogs even listed this game with a firm release date of August 9, 1995, but needless to say, the game never came out. Still, references to this game in various catalogs and gaming magazines have resulted in countless books and web sites erroneously listing it amongst the 3DO software library.

References

The game is littered with visual references (some subtle, and some not-so-subtle) to its predecessor: The 7th Guest. One such example is a pile of old, dusty game boxes for The 7th Guest in the laboratory. Surprisingly (and somewhat shamelessly), the game developers even included a 7th Guest CD-ROM as an answer to one of Stauf's riddles!

In the chapel, click the "rolling eyeball" cursor on the small bowl off to the side. Upon closer inspection, you will notice a torn piece of paper sticking out with the word "MISSED" printed on it. This is a sly reference to (or possibly a jab at) the bestselling CD-ROM game Myst. The inclusion of a torn paper was probably meant to mock the plot of Myst, which has the player search out a series of vacant islands for pages that are missing from two mysterious books.

Game Updates

A new engine allows Windows '95 and DirectX compatible gameplay. Look for it in the company's website.

Hidden Features

Disc 1 came with wad file levels for Doom and Heretic modeled after the Stauf Mansion. Disc 1 also includes JPEG screenshots and WAV sound files from the game so that you can create your own Stauf desktop theme. Look for them in the GOODIES folder.

In the setup menu, users can choose between standard graphics and "spooky mode", which will transform the game's visuals from full color into faded black-and-white.

As many users recall, there was a cheat code in The 7th Guest that would unlock every room and puzzle in the house. Entering this cheat code ("Zaphod Beeblebrox") in The 11th Hour will only result in laughter and taunts from Stauf.

Completing the game will add a new saved game in slot 0 called "Open House". Using this game, players have full access to the entire house, and can play any of the puzzles as many times as they'd like.

Awards

In the German gaming magazine PC Player (issue 01/1997) The 11th Hour received a special award for the "Worst Script in 1996".

-------------
Tips & Tricks
-------------
Warning! Clicking on one of the links below will give you information that could possibly spoil or ruin or otherwise make the game less fun. Once you've seen how to cheat, it's hard to forget. Click at your own danger or flee now while you still have the chance.

General Hints/Tips - DOS
Skip introductory sequence Sep 01, 2000 STING007 (34)
Cheats/Codes - DOS
Cheat Dec 13, 2001 Jim Fun (222)
Skip Discs Cheat! Dec 11, 2006 Echidna Boy (503)
Easter Eggs - DOS
Unusual video on Dutton's TV screen Dec 11, 2006 Echidna Boy (503)
Screen saver

Reply 1033 of 1962, by krull1981

User metadata
Rank Newbie
Rank
Newbie

How exactly do i import from D-FEND reloaded ive tried all the export options in D-FEND Reloaded but DBGL complains about a lack of profiles.xml I have a good 80 games setup in Dfend and wanted to add them to my old linux laptop running DBGL and don't fancy adding them singularly.

Reply 1034 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

DBGL simply does not 'understand' the contents of the files that you are giving it. As far as I know, D-Fend Reloaded cannot create the GamePackArchives that DBGL expects.

What you can do, however, is put an empty DBGL installation on the machine next to DFR, and import your DFR games into DBGL. You can find this feature in the main menu (Profiles -> Import D-Fend (Reloaded) profiles). Please note that DBGL will also require .conf files for all DFR profiles; you can easily create these files with DFR (File->Export->Create conf files).

Once the games are imported into DBGL, you can than select all games (ctrl-a) and choose Profiles->Export to create a big GamePackArchive (.dbgl.zip file) that you can import into any DBGL installation, including your Linux one.

Reply 1036 of 1962, by krull1981

User metadata
Rank Newbie
Rank
Newbie
rcblanke wrote:

DBGL simply does not 'understand' the contents of the files that you are giving it. As far as I know, D-Fend Reloaded cannot create the GamePackArchives that DBGL expects.

What you can do, however, is put an empty DBGL installation on the machine next to DFR, and import your DFR games into DBGL. You can find this feature in the main menu (Profiles -> Import D-Fend (Reloaded) profiles). Please note that DBGL will also require .conf files for all DFR profiles; you can easily create these files with DFR (File->Export->Create conf files).

Once the games are imported into DBGL, you can than select all games (ctrl-a) and choose Profiles->Export to create a big GamePackArchive (.dbgl.zip file) that you can import into any DBGL installation, including your Linux one.

great that worked a treat thanks, I did have to migrate the profiles first before it would let me package them as the games were in the DFR's VITRUALHD . DBGL is a a great program and it runs much better on my old laptop than DFR+DOSBOX under WINE.

Reply 1037 of 1962, by Baldy_Old_Fart

User metadata
Rank Newbie
Rank
Newbie

The tooltip information box of DBGL (0.77b) is a bit too persistent for my liking, and often interferes with edits and even other work. Maybe there is insufficient checking for loss of focus?
The current version (0.77b) certainly fetches screenshots from Moby Games, but it does NOT obey the restriction of the number of screenshots to fetch - this really takes so little time anyway, that it could just be left out - fetch all available screenshots at all times unless in a multi-edit session.
I wonder at the necessity to even check Poeut and HotU, how many users actually use any information from these two?
The actual space allocated for the images in tile or box views is NOT EQUAL TO the specified sizes - the specs are used for the OUTER BOUNDING BOX, leaving the images shy of the expected size, and inducing cropping when not expected.
DBGL settings.conf originals:
[code]small_tile_width=100
small_tile_height=82
medium_tile_width=132
medium_tile_height=102
large_tile_width=164
large_tile_height=122
small_box_width=75
small_box_height=100
medium_box_width=120
medium_box_height=150
large_box_width=150
large_box_height=200[/code]I find a more acceptable setup (IMHO) to be:
[code]small_tile_width=100
small_tile_height=94
medium_tile_width=132
medium_tile_height=118
large_tile_width=164
large_tile_height=142
small_box_width=100
small_box_height=118
medium_box_width=132
medium_box_height=150
large_box_width=164
large_box_height=182
[/code]and this provides a lot less cropping, as it allows for the highlight surround as well as the text below the image(s).
Also, if I set Preferences to:
Profile Defaults:
Configuration file > "In game directory" + "Filename by profile title"
then the:
[code][dosbox]
captures=..\captures\nnn[/code]entry needs to be set to:
[code][dosbox]
captures=..\..\captures\nnn[/code]and if one goes through and manually sets these, (tedious indeed!), and then makes the mistake of "edit"-ing the game settings, the DBGL editor resets those fields to:
[code][dosbox]
captures=..\captures\nnn[/code]and naturally, DOSBOX gags on that, refusing to save captures because it cannot locate the captures directory because it is pointed to the wrong place! - Then I have to re-edit all those damned .conf's!!! - doubled tedium! Then if I want to play with some of the .conf parameters, I'd better do it without the DBGL editor, because it will wreck my hard work yet again.
Although it might be a PITA to modify DBGL and write a program to swap the captures and .conf files back to where I believe they should be kept:
DBGL_BASE\infroot\GAME_abc\
I feel that it would be worthwhile in the long run. Surely this would also make ex/importing packages a whole lot simpler - Just Zip the .\dosroot\GAME_abc\ & .\infroot\GAME_abc\ folders. Certainly, for a while after the change, compatibility with the older packaging method would need to be retained, but in the long run, packages could be built OUTSIDE DBGL quite simply, and DBGL would become easier to use overall.
With the current (0.77b) setup, it is a right royal pain to try and decode the DBGL numbering in order to "Correct" or add to or remove any screenshots fetched from Moby Games or created by myself. Having everything for a particular game under its own relevantly named directory would certainly make life easier in that regard.
No need for database cross-referencing "GAME" to "nnn", just TOTAL relative addressing. In fact, the games information currently held in the database could be kept in the .\infroot\GAME_nnn\ folder, in a "profile" (I know that starts to sound like D-Fend Reloaded) or "ini" file. - The few global settings retained in the db could then be stored in a dbgl.ini file, and no database operations would be needed at all. - The .ini files could be handled in the same way as screenshots as far as pre-loading is concerned - only need to have the displayed group of entries actually loaded into RAM, maybe +/- one more page to allow for fast scrolling the picklist.
The file references would all boil down to:
[code].\infroot\GAME_abc\ GAME_abc_nnn.jpg - [Ctrl+F5] captures
.\infroot\GAME_abc\ GAME_abc_nnn.wav - [Ctrl+F6] recorded sounds
.\infroot\GAME_abc\ GAME_abc_nnn.avi - [Ctrl+Alt+F5] recorded videos
.\infroot\GAME_abc\ GAME_abc.conf - DOSBOX partial .conf file
.\infroot\GAME_abc\ GAME_abc.ini - DBGL extra information file[/code]and, of course,
[code].\dosroot\GAME_abc\ - all GAME_abc files & folders here[/code]with:
[code][dosbox]
captures=.\[/code]ie the SAME folder as the .conf file.
This gets rid of three folders at the dosroot level (profiles, captures & db) and adds one (infroot) within the DBGL_BASE folder. Reading the dosroot directory would provide the base GAMES LIST info, and the absence of .\infroot\GAME_abc\GAME_abc.ini could trigger an auto-setup reaction from DBGL asking the user for the pertinent information. This way, if a savvy user unpacks an archive into the .\dosroot folder, and creates the appropriate .\infroot\GAME_abc\GAME_abc.ini etc, no further setup is required - the newly unpacked game is ready to run. Similarly, unpacking a multi-game package would require NO database fiddling about, NO checking for ID or duplicated numbers and correcting those potential errors, just unpack and refresh the Games List. Creating a Game-Pack or Multi-Game-Pack would only require the archiving of two folders & contents per Game, with no need to search for .\captures\what_was_that_number? and no need to build an XML reference list within the archive. Neither would there be any need to muck about changing those numbers on import, - just "does .\dosroot\GAME_abc\ exist?" - if true, complain; if false, unpack that part of the archive.
Thus, a structure of:
[code]BASE
+--captures
| +--1
| +--2
| \--3
+--db
+--DOSBox-0.74
| +--Documentation
| \--Video Codec
+--dosroot
| +--GAME_abc
| +--GAME_def
| \--GAME_ghi
+--export
+--lib
+--profiles
+--templates
\--xsl[/code]would become:
[code]BASE
+--DOSBox-0.74
| +--Documentation
| \--Video Codec
+--dosroot
| +--GAME_abc
| +--GAME_def
| \--GAME_ghi
+--export
+--infroot
| +--GAME_abc
| +--GAME_def
| \--GAME_ghi
+--lib
\--xsl[/code]with an obvious relationship between the Game data folder and the captures etc. folder.
Having mentioned DFR, it has one particular feature which I do find useful - right-click any screenshot and select "Use as screenshot in Games List" - Beats the heck out of having to find where the captures folder is, then rename the image files to put the one you want as Game List Screenshot as the first in the folder.
Overall, I find DBGL excellent to use, keeping in mind that it is "a work in progress". It is especially useful when set up for Linux, and built into a "Live" Linux Distro, purely for gaming. That setup makes for a really useful CD or DVD "BOOT and PLAY" disk for my grandkids - they can recognise the games from the screenshots, and be playing their favourite game VERY quickly, albiet without Savegames; for those games which need/use Savegames, building a "Live" Linux USB Drive can overcome that little peeve, and all games can then be played WITHOUT any disruption to the host PC's data. Once set up, it needs no fiddling by the end user, they can just "BOOT and PLAY" - (once Poppy has done all the setting up and produced the CD/DVD/USB Drive).

No matter what happens within DBGL, the USER MUST remember that DOSBOX provides a DOS environment, and can handle ONLY the old 8.3 file naming convention. The numbering and filename changes are NOT as one might expect - and NOT necessarily in the same sequence as the alpha sequencing of the LFNs!
viz:
1) Create 6 files in reverse numeric order

E:\TEST>for %F in (5,4,3,2,1,0) DO ECHO TEST>>".\Long Filename %F.TXT"
E:\TEST>ECHO TEST 1>>".\Long Filename 5.TXT"
E:\TEST>ECHO TEST 1>>".\Long Filename 4.TXT"
E:\TEST>ECHO TEST 1>>".\Long Filename 3.TXT"
E:\TEST>ECHO TEST 1>>".\Long Filename 2.TXT"
E:\TEST>ECHO TEST 1>>".\Long Filename 1.TXT"
E:\TEST>ECHO TEST 1>>".\Long Filename 0.TXT"

2) Check the 8.3 and LFN names:

E:\TEST>dir /X *.TXT
Volume in drive E is WORKDRIVE
Volume Serial Number is 1AB9-1234

Directory of E:\TEST

21/01/2014 02:50 PM <DIR> .
21/01/2014 02:50 PM <DIR> ..
21/01/2014 02:50 PM 6 LO1CA2~1.TXT Long Filename 0.TXT
21/01/2014 02:50 PM 6 LO4981~1.TXT Long Filename 1.TXT
21/01/2014 02:50 PM 6 LONGFI~4.TXT Long Filename 2.TXT
21/01/2014 02:50 PM 6 LONGFI~3.TXT Long Filename 3.TXT
21/01/2014 02:50 PM 6 LONGFI~2.TXT Long Filename 4.TXT
21/01/2014 02:50 PM 6 LONGFI~1.TXT Long Filename 5.TXT
6 File(s) 36 bytes

NOTE the GROSS DIFFERENCE between the 8.3 filenames, and that which you would at first expect!
OOPS! You CAN NOT ASSUME where the changes will occur! In the above example, one might logically expect that the 8.3 filenames would be LONGFI~1.TXT to LONGFI~6.TXT, but such is DEFINITELY NOT SO!
So, whenever working within DBGL / DOSBOX, one needs to lose the LFN mentality, and think in 8.3 - ie you only have a narrow space to label your folders! Although you can often get away with: GOODGAME.110, GOODGAME.240, GOODGAME.450 folder names for three versions of "GOODGAME", depending on if / how "GOODGAME" checks its home directory. - Yes, even DOS allows for 8.3 Foldernames, not just the more usual 8.0 naming convention.

Good Gaming to all, and HUGE THANKS to R. Blankendaal for his efforts in producing DBGL.

Reply 1038 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for the extensive feedback, I'll see if I can answer your questions and comments step by step.

Baldy_Old_Fart wrote:

The tooltip information box of DBGL (0.77b) is a bit too persistent for my liking, and often interferes with edits and even other work. Maybe there is insufficient checking for loss of focus?

I assume you mean the tooltip information in Gallery view mode when hovering over an item? That's certainly possible. maybe you can provide an example usage scenario in which the tooltip is not properly removed, for me to analyze? if you mean the tooltips inside the template/profile editing screens, there is not much that I can do as these tooltips are handled by SWT. I can however make them optional, if you think that's better.

Baldy_Old_Fart wrote:

The current version (0.77b) certainly fetches screenshots from Moby Games, but it does NOT obey the restriction of the number of screenshots to fetch - this really takes so little time anyway, that it could just be left out - fetch all available screenshots at all times unless in a multi-edit session.

This behavior is fully intentional, exactly as you describe. Do you think something is broken here?

Baldy_Old_Fart wrote:

I wonder at the necessity to even check Poeut and HotU, how many users actually use any information from these two?

Well, this feature was specifically requested, so that's why it's here 😀 If you don't need it, don't use it.

Baldy_Old_Fart wrote:

The actual space allocated for the images in tile or box views is NOT EQUAL TO the specified sizes - the specs are used for the OUTER BOUNDING BOX, leaving the images shy of the expected size, and inducing cropping when not expected.

Well, as I said earlier in this thread:

...Where width=imagewidth+4 and height=imageheight+22. However, I agree that having many different dimensions of tiles can be rather troublesome to display nicely.

The default settings/dimensions are optimized for a 1.6 aspect ratio (320x200). Any images in another aspect ratio will either be displayed in the wrong aspect ratio, or cropped. That's why I made this configurable, it's pretty hard to 'determine' the 'right' values and depends on the images and your personal taste.

Reply 1039 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie
Baldy_Old_Fart wrote:
Also, if I set Preferences to: Profile Defaults: Configuration file > "In game directory" + "Filename by profile title" then the […]
Show full quote

Also, if I set Preferences to:
Profile Defaults:
Configuration file > "In game directory" + "Filename by profile title"
then the:

[dosbox]
captures=..\captures\nnn

entry needs to be set to:

[dosbox]
captures=..\..\captures\nnn

and if one goes through and manually sets these, (tedious indeed!), and then makes the mistake of "edit"-ing the game settings, the DBGL editor resets those fields to:

[dosbox]
captures=..\captures\nnn

and naturally, DOSBOX gags on that, refusing to save captures because it cannot locate the captures directory because it is pointed to the wrong place! - Then I have to re-edit all those damned .conf's!!! - doubled tedium! Then if I want to play with some of the .conf parameters, I'd better do it without the DBGL editor, because it will wreck my hard work yet again.

To be honest, I was a little surprised to find that no one had reported this problem to me when I discovered the issue myself, some 6 months ago, or so. I guess it goes to show how few users decide to tweak this setting to "In game directory". It is a bug, indeed.

DOSBox behavior has changed somewhat since I was building this feature back in 2007. DOSBox versions 0.72 and older will require the captures folder (inside the .conf) to be set relative to the CWD when starting up DOSBox, while versions 0.73 and up expect the path to be relative to the profile's .conf file. I do not know which exact SVN commit revision is responsible for the change, or what the reasoning is behind the change in behavior.

Anyway, it will be fixed in the upcoming test build. You might have saved yourself some time and agony if you had simply reported the issue 😐 .