[Luke]

I am lazy, so i repeat was i wrote in the WCS forums. ^^

from WingCenter (german)

1. Usage

Download WCS Debug-Build Support-Tool (short: DBST) ZIP and unzip it, then start WCS_Debug-Build_Support-Tool.exe and press <Start Debug Build and create Support ZIP>. After DBST ends, you will find the fs2_open_SupportTool.zip at your desktop and this file can directly attached to a posting in the forum.

• Info: The WCS Debug-Build is included in DBST, there is no need for an additional download of the Debug-Build.

Privacy
dxdiag.log and dotnet.log contains the computer name (network) and fs2_open.log contains the user profile name (Windows).

Screenshots


GUI from DBST


Create system report


Installation check

2. Download

WCS_Debug-Build_Support-Tool1.1.2.5.zip
(2013/8/1)

3. Background & Functions (primarily interesting for supporters)

3.1 Background

The idea for this tool i had last year. I thought about how the handling for the debug build and the log can be simplified. And i wanted a simple way to give the supporter a system report for the most important windows and hardware values. For this i found a way to create a system report with DXDIAG.

3.2 Functions

DBST have the following functions and reduces all needed steps to a minimum:

• Copied the officially debug build into the correct WCS folder. If UAC is active, then a thread called "WCS_Debug-Build_Support-Tool_copy.exe" will be started to ask the user for permission to write in the WCS folder. DBST have a version check, so if the local debug build is older then the one in DBST, the local debug build will be replaced. Info: In the properties of the DBST EXE you can find the debug build version under "ProductVersion". This info will also shown in the DBST GUI.
• Starts the debug build. You can use all commandline parameters from the official debug build in the commandline textbox. Info: You can test this very simple with the parameter -nosound as example. [fs2_open.log]
• After the debug build ends, because of normal end or because of a CTD (Crash To Desktop), DBST creates automatically a system report with DXDIAG (if enabled, standard). In this log, the supporter can find the most important Windows and hardware values from the users computer. Info: This log includes information about the Windows version, processor, memory, graphic card type and graphic card driver version. [dxdiag.log]
• The possibility to check the WCS installation for errors and add the result to the Support ZIP. (if enabled, not standard). Possible results for the separate files: [MD5 OK    ] = File exists and is OK, [MD5 WRONG!] = File exists but is corrupt, [NOT FOUND!] = File is missing. [md5check.log]
• The feature to add all WCS game profiles to the Support ZIP. (if enabled, not standard) [profiles]
• The feature to detect all installed .NET Framwork versions with their servicepacks. [dotnet.log]
• All actions from DBST will logged in a separate log file. [dbst.log]
• At last point, DBST creates automatically a ZIP with all logs and the WCS profiles, depending on selection. The user can then find the Support ZIP (fs2_open_SupportTool.zip) on his Desktop very easily.

[The E]

This is pretty cool, however, I wonder if it could be even better if it supported fs2_open proper (Not just WCS). Most of these tasks are, after all, the same for fs2_open; a tool like this could simplify support for FSO massively, if it can be extended to more than one game.

[Luke]

Hi The E

Yes i heard this argument before.  But let me say some clarifying words:

I am not a WCS Team member, i am just a WCS fan and a coder (commercial & freeware) too. I wrote several tools for WCS, this here is one of them.

DBST is specialised for WCS but it is possible to write special versions for other games, i think. And if anyone from other FSO games is intererested in a special DBST version we can talk about it. But only if i get enough informations, data, files and help. I am NOT willing to spend my rare free time to write several DBST versions for other FSO games without any help. I must say this because after 30 years programming and lots of freeware tools (i gave up to count it) i learned that everybody wants all without giving me support. Hard words? Maybe... i am a little bit frustrated. So my priority is the FSO game WCS because this is a absolut fantastic game for me and i want to support it in the way i can support it. I don't make any advertisement for my WCS tools in other FSO game forums here. But i repeat, if anyone is interested, we can talk about it. 

[The E]

I think going the "Special tool for each game" route is not optimal, considering the amount of games and mods we have produced here. I was hoping that your tool could be written in such a way as to not be specialized for any one game, but rather serve as a generalized tool for everything.

Have you considered releasing the tool as Open Source? I am quite certain that you do not need to do all the work yourself; there are a few people here (myself included) who would probably help out with this.

[Luke]

I think going the "Special tool for each game" route is not optimal, considering the amount of games and mods we have produced here.

Like i said, my priority is WCS. I am not familiar with the FSO environment, i am no game designer, 3d-artist, sound-artist, mission-designer etc. I am working in a completely different IT sector that have nothing to do with game development. And WCS was (and is) my only FSO game i know and this only since march 2012. If this sounds egoistical now, this was not my intention, it's only a fact.

With this background: DBST is not only the Support tool, it contains also the official WCS debug-build. My intention when i began to write DBST was to create a simple-to-use support tool so the WCS supporters can point the pilots (users) to this tool and the users can collect all needed informations inclusive automatically creating the support ZIP with all logs and game profiles with only a few clicks and very easy. So the main advantage of DBST is to have all support tool features AND the debug build in only one tool.

Yes it is possible to create a more "generalized tool", but then some advantages of the tool are no longer given. DBST was NOT created for FSO freaks or IT gurus or geeks, it was created espacially for "normal" users/gamers without big technical knowhow.

Thinking loud: maybe it's possible to create a neutral version of DBST without the WCS debug build but with a INI file. So it's possible that any debug build can be used and DBST have his "own" messages, textlabels, buttons. In this INI then all things can be configured individually like the specialised MD5 check feature.

[The E]

Thinking loud: maybe it's possible to create a neutral version of DBST without the WCS debug build but with a INI file. So it's possible that any debug build can be used and DBST have his "own" messages, textlabels, buttons. In this INI then all things can be configured individually like the specialised MD5 check feature

That would be what I was thinking about.

Sooner or later, functionality like that will be integrated into our cross-platform launcher, but until then, having a little tool like yours would go a long way toward making support much easier.