How to create a log file

[RavenMacDaddy]

I saw these instructions in another issue:

"To see if EAX is actually used by a game run it with DSOAL and these environment variables set:

DSOAL_LOGLEVEL=3
DSOAL_LOGFILE=1_dsoal_log.txt"

Sadly I don't get how you're supposed to set those variables as I haven't been able to get it working so far.

Can someone explain in more detail how to get DSOAL to create a log file?

[kcat]

On Windows, open a command prompt/shell in the folder with the executable, and run:

set DSOAL_LOGLEVEL=3
set DSOAL_LOGFILE=1_dsoal_log.txt
application.exe

where application.exe is the program you want to run. You may also need to set a path for DSOAL_LOGFILE if it's in a folder you can't write to.

[RavenMacDaddy]

Thank you, that worked, then to turn off, is it "0"?

What are the different log levels, if you don't mind?

[Kappa971]

There is no way I can produce a log file in games that use DSOAL. I'm on Windows 11, I have tried with PowerShell and Command Prompt, I have tried to run both as administrator, I have changed the destination folder of the log file, none of this has helped. I run the game and no files are created (with all the games I have tried). I'm sure it is recognized by the games because I can activate EAX. Maybe in a future version of DSOAL you could have it produce a "minimal" log file automatically (like EAXEFX).

[mirh]

Set those as environmental variables in the windows system properties.

[Kappa971]

Set those as environmental variables in the windows system properties.

Thanks, it works! I hope that in the future you will also implement an eaxefx-style automatic minimal log.

[ThreeDeeJay]

@Kappa971 Similar to our recent conversation in #34, this issue also seems to be caused by the wrong combination of registry and executable permissions, not sure it has to do with Windows 11 in particular.

Like, setting variables normally will just apply to sub-processes called within the same CMD.
If CMD thinks the process was stopped before it had a chance to call DSOAL/OpenAL Soft, the variable might not have any effect (this is common if you call the game's launcher instead of the true executable and I think games run as administrator from a non-elevated CMD window/batch script).

So if you set variables via the user/system environment, the game should be able to read them without manual declaration via CMD BUT if the executable is in a protected folder (like Program files\*\) and is not run as admin, it will still not be able to create log files.

So I upgraded a script I made to easily enable logging, now taking this into account by warning the user to run it as administrator to set variables as system environment variables that point to the script folder.
This way, logging can be enabled for executables in protected folder that for whatever reason aren't run as administrator.
Executables in writable folders just need simple drag and drop and log files will be created next to the executable tho.

Demo
DSOAL+ALSOFT_log.zip

[mirh]

if the executable is in a protected folder (like Program files*) and is not run as admin, it will still not be able to create log files.

It should be redirected to virtualstore AFAIU.

This way, logging can be enabled for executables in protected folder that for whatever reason aren't run as administrator.

I mean, just about every program is run like so.
Maybe writing to %temp% would be better.

[ThreeDeeJay]

Dang it, I keep forgetting VirtualStore is a thing. Temp also sounds like a good idea, but it's notorious for being a massive dumpster of logs and forgotten files.
Perhaps if OpenAL can't create a log in the executable folder, it should log into something like %APPDATA%\OpenAL\DATEANDTIME_EXECUTABLE.log when the ALSOFT_LOGLEVEL variable is 1-3 and ALSOFT_LOGFILE path isn't defined.
DSOAL could also behave the same way, perhaps even having it's own folder or just reusing %APPDATA%\OpenAL.

[mirh]

Dang it, I keep forgetting VirtualStore is a thing.

That is, for programs without a modern manifest at least.
So, say, retail mass effect (steam would change the folder permissions) wouldn't be redirected, but SCPT would.

Temp also sounds like a good idea, but it's notorious for being a massive dumpster of logs and forgotten files.

I see what you mean, but AFAICT this only happens if you have frequent power outages.

Perhaps if OpenAL can't create a log in the executable folder, it should log into something like

It would be certainly better than nothing, but at the same time I kinda feel like "predictability" is a big
On the other hand, I feel like not having the log in the same folder of the game/dll at least when possible, would be a big blow for accessibility for noobs.

I guess this conditional behaviour is really the best way eventually (even though, I don't know, I still feel like %temp% is more appropriate).
https://stackoverflow.com/questions/14005081/how-to-detect-file-redirection-to-the-windows-virtualstore
This is important too though.