Hi,

First, thanks so much for this great front end to dosbox you have made. Have been using it for a long time.

I've recently updated to the latest D-Fend Reloaded 1.4.1rc1 and dosbox svn r3869. I've always launched dfend via CLI like this: dfend.exe "game name"

I noticed that in the dosbox console window, it's always loading the dosbox.conf file from my temp folder, and no matter what I have tried, it won't read it from anywhere else.

DOSBox version SVN Copyright 2002-2013 DOSBox Team, published under GNU GPL. --- CONFIG:Loading primary settings from config fil […]
Show full quote

DOSBox version SVN
Copyright 2002-2013 DOSBox Team, published under GNU GPL.
---
CONFIG:Loading primary settings from config file C:\Users\djvj\AppData\Local\Temp\DOSBOX.CONF

In dfend's program options, it is sending the additional CLI as -conf "D:\Emulators\DOSBox\D-FendReloadedPortable\App\D-Fend Reloaded\Confs"

dfend deletes a dosbox.conf if I play one there. I also tried changing that folder to something else that did not help either. Dosbox recreates that dosbox.conf folder on each launch, so editing that file doesn't help as it gets restored again on each launch.

What am I missing here so I can have a launch through dfend cli load the correct conf file?

Hi djvj,

I do not understand your problem. The behaviour described is as intended. D-Fend Reloaded is using *.prof files located in <DFRBaseFolder>\Confs to store the configuration for each game. If you try to start a game via "DFend.exe game name", DFR is looking for the maching prof file there, is creating a temporary conf file to tell DOSBox what to do and is launching DOSBox with this file.

I you are using DFR you can forget about conf file. The conf file is used for communication between DFR and DOSBox. DFR is creating and deleting these temporary conf file. You are setting up what to do via the DFR GUI. DFR is doing the whole communication with DOSBox via its self created conf file. You cannot use DFR to configurate DOSBox and use some own conf file at the same time. If you want to use own conf files instead for configuration DOSBox you will need to run DOSBox without DFR.

Ok then there is a problem with how dfend is creating this temporary conf file. I have both (for example) Doom and Dosbox profiles in dfend set to not use fullscreen mode, yet whenever I launch Doom by sending "dfend.exe Doom", it launches in fullscreen mode. When I look in this temp conf file, it shows fullscreen mode is enabled.

However, if I launch Doom from within dfend by double clicking it, it launches windowed.

Thanks for describing how that file is created though. I couldn't for the iife of me figure out why dosbox kept reading from this file, now I know why, dfend always tells it to.

Hi djvj,

that's very, very, very strange. When double clicking a profile in DFR and when starting it via command line exactly the same configuration file is interpreted by the same function in exactly the same way. So if a profile is starting windowed when clicking it in the DFR window it should also start windowed when starting via the DFR command line option.

When starting a profile via a DFR command line parameter the game is identified by its name. DFR can handle multiple profiles with the same name (because they are distinguished by their always unique profile file names). But when saying "DFend.exe Doom" and there are two profiles named "Doom" always the first one is started. But I think that's not your problem.

To find out what's happening here I have added some more logging functions to DFR. If you replace your DFend.exe by the file from this archive:
dfendreloaded.sourceforge.net/Files/DFend.141rc1-test.zip
you will have some more testing options. If you create a file named "D-Fend-Reloaded-Log.txt" on your desktop, DFR will log the program start there (that's also available in regular 1.4.1rc1). If you additionally create a file named "D-Fend-Reloaded-DOSBoxStartLog.txt" on your desktop, DFR will log the DOSBox startup process there.

The "D-Fend-Reloaded-Log.txt" file should contain at the end lines like:

xx:xx:xx Process parameters
xx:xx:xx Trying to find "xyz" in game db.
xx:xx:xx Found DOSBox game "xyz" in game db.
xx:xx:xx Running profile <ProfFile>
xx:xx:xx Fullscreen mode: no

And the "D-Fend-Reloaded-DOSBoxStartLog.txt" should tell you at the beginning which prof file is going to be used. At the end of the DOSBox start-up log file there will be a complete copy of the prof file and the generated conf file. In the prof file you schoud find a line like "fullscreen=0" in the [sdl] section. In the conf file there should be a line "fullscreen=false" in the [sdl] section.

If some of the lines say fullscreen yes and some fullscreen no there is a bigger problem. In this case you could try to delete the "Cache.dfr" file in your "conf" folder (if there is any; its only used when there are more than 20 profiles).

I have a question.

I want to install DFR on my desktop but I don't like very much that I have to respect the folder structure. DFR offers me the possibility of a portable installation, but that's really only desirable for portable drives. Is there any advantage to the regular installation on a desktop? Because it seems to me that being limited by the folder structure isn't very good, since I can't have my games where I want them.

Thanks for DFR btw, it's a great program.

Hi ColdBrain,

you can set up custom folders for your games etc. on the "Directories" subpage of the "General" page of the program settings dialog. But anyway the portable installation is not limited to portable devices. You can use it anywhere. The advantage of the regular installation is that program files and data are in different folders and files in the program files folder can only be changed with admin rights. That part of the Windows security strategy. If you are using a portable installation as your default installation you are just bypassing this features. Also using the default installation means you have one installation (in your program files folder) but have individual data files (in the user account folders) for each user.

So Alex, I grabbed your debug exe (thanks!) and after running it once, it rebuilt the cache once and started to work correctly again... Loading via CLI is now working correctly with fullscreen. I tried putting the non-debug exe back and still works. I'm not sure what changed, but I did already try deleting the cache and it didn't help. Somehow just running that debug exe once fixed everything.

Thank you.

Alexander wrote:

Hi ColdBrain,

you can set up custom folders for your games etc. on the "Directories" subpage of the "General" page of the program settings dialog. But anyway the portable installation is not limited to portable devices. You can use it anywhere. The advantage of the regular installation is that program files and data are in different folders and files in the program files folder can only be changed with admin rights. That part of the Windows security strategy. If you are using a portable installation as your default installation you are just bypassing this features. Also using the default installation means you have one installation (in your program files folder) but have individual data files (in the user account folders) for each user.

Thanks Alex. 😀 Actually I wanted all my DFR files in the "Games" folder I use for all my games. I'm the only user of my PC, and UAC is disabled in my machine anyway, so it might be more advantageous to use the portable install.

BTW I have a bug to report. Sometimes, when I add a game through the wizard, the window closes automatically and doesn't allow me to download info about the game.

Hi ColdBrain,
the new game wizard by default tries to display as less as possible pages. If the game can be identified via the checksums in some auto setup template, DFR is using this template (which also contains game meta information) and does not show the game meta information dialog page (from where the download of additional information can be started). If you want to see always all pages of the wizard dialog, you have to select "Always show all setup pages of this wizard" in the "Wizard mode" drop down box on the first page of the dialog.

Is everything fine with 1.4.1rc1? If yes, I'm going to release 1.4.1 next week.

Français Canada, French Canada 2014-07-25
Français, French 2014-07-25

See files included, ...
Voir les fichiers inclus, ...

@Alexander:
You have released 1.4.1rc1, then i have complete the 1.4.1 translation, and fixed grammaticaly the translation.

Hi sst,
thank you very much for updating your language files. I will use them in 1.4.1.

I have just released D-Fend Reloaded 1.4.1. I hope this release will fix all problems and issues for the next time.

So this is a dead feature for me and I'm thinking about removing it because it's just making problems.

Please don't! Please leave it there. It is a fantastic feature! I plan to have all my games available on my file server and will use D-Fend's package format for that. Besides, now, that the issues have been ironed out, it works pretty well. And, who knows, maybe the feature will become used more in the future.

And 1.4.1 works very well here, automatic update was also straight. Great work!

Hello,

Thanks for all the great work on DFR! I have been using it since the beginning and find it to be invaluable. I recently updated to 1.41 and I have been having the same problem as the prior poster for accessing mobygames:

"First I get:
"Error reading data from dfendreloaded.sourceforge.net

then I get:
"Access violation at address 005C3421 in the module 'DFend.exe'. Read of address 00000010"

The when I have the first download it is fine. However, when I move to another profile this error start to occur and DFR start to crash. I can close and reopen and do one profile again with no problem but on the second it crashes.

Any help would be appreciated!

Gates

Hi gates007ca,

I really cannot reproduce this error. For me downloading game information from Mobygames works fine, also when trying to download information for more than one profile. But by looking at the source code I have found one possible cause for the problem: "Error reading data from dfendreloaded.sourceforge.net" means there is a problem connecting to the given URL (either on your internet connection or on the sourceforge server). There is nothing I can do about this itself. But DFR is not handling this error correctly. Instead of switching back to The Games DB as game information source it tries to work with the invalid configuration file, which of course fails. I have just uploaded an rc1 of 1.4.2. In this version DFR is switching back to The Games DB when loading the configuration file for Mobygames fails. I hope this will solve your problem.

Hi Alex,
I've just started using D-Fend Reloaded and it's blowing me away! It's really great and does exactly the things I've wished for. I only have one problem - I cannot get starting from a zip-archive to work. I tried various ways: making my zip file and importing it, adding the game the normal way then make a zip file with the program. Whatever I do, when I try to change the Folder under Drives from Harddisk to Harddisk (archive), I get the error message: "There is no mounted drive that is allowed to reach the physical folder..."

Could You please tell me what I'm doing wrong?

Thank You very much,
Andreas

Hi paladin5000,
the profile editor cannot look inside an archive file. Therefore you will have to give the system some hints. Lets assume you have mounted a zip file as DOSBox drive D: and in your zip file there is a folder named "game" containing a "start.exe" you want to start. In this case you have to select the "File path is relative to the DOSBOX directory structure" below the "Program file" input box on the "Profile" page of the profile editor (which is broken in 1.4.1 see currect testing release.) Then you can enter "D:\game\start.exe" in the file name edit line. D-Fend Reloaded will pass this command directly to DOSBox without trying to map the path name from the Windows directory structure to the DOSBox directory structure.

Hi Alex,
thank You for Your quick reply. I tried the 1.4.2 release candidate as well as 1.4.0. Unfortunately, there is no "File path is relative..." under the Program File input box, only under the setup input box. I tried that but it didn't work.
Here is what I tried to do:
I have a zip file bstone.zip. In it, there is a folder bstone and in this folder is bstone.bat
I have input the following configuration: Profile - Program File D:\bstone\bstone.bat; checked "File path is relative..."
Drives: Archive File - Folder to mount: .\VirtualHD\BSTONE\; File to mount: .\VirtualHD\BSTONE.zip; Drive: D

Could You please tell me what I'm doing wrong?

Thank You very much,
Andreas

Hi Alex,
I don't know if that helps, but when i try to start the game, I get the error message immediately. I would expect a few seconds delay while the zip is extracted, but I don't think the program extracts the zip at all.

Thank You,
Peter