Page 1 of 1

Add optional filename argument to Zscript MakeScreenShot

PostPosted: Tue May 28, 2019 3:35 pm
by JPL
It's cool that screenshot capability is now exposed to ZScript (with safeguards to ensure it's not abused), but the feature would be more useful if we could optionally pass in an argument for the screenshot image's filename that, when provided, would be used instead of the current auto-generated filename. If a file by that name already exists in the screenshot directory, it could be overwritten - or add an additional optional bool argument to set overwrite preference.

I imagine we would definitely not want to let this be a full pathname, as that would open the door to arbitrary file system access. We already have the screenshot_dir cvar anyway, which the user controls.

Re: Add optional filename argument to Zscript MakeScreenShot

PostPosted: Tue May 28, 2019 3:44 pm
by Rachael
So MakeScreenShot("gzdoom.exe", MSS_OVERWRITE);?

Re: Add optional filename argument to Zscript MakeScreenShot

PostPosted: Tue May 28, 2019 4:10 pm
by JPL
Rachael wrote:So MakeScreenShot("gzdoom.exe", MSS_OVERWRITE);?


Does GZDoom write screenshots to its own EXE directory in Windows by default? If so I'd forgotten that, sorry yes I can definitely see how that would be a problem!

Writing files to the program directory itself instead of a "user directory" equivalent is a somewhat outdated practice, I believe, so if the devs are interested in changing that for those more general (possibly security related?) reasons, it would have the side effect of making this feature request more viable.

Re: Add optional filename argument to Zscript MakeScreenShot

PostPosted: Tue May 28, 2019 4:18 pm
by Rachael
I would tend to agree, but that's not my decision to make. I'm guessing it's for compatibility reasons.

Either way though, I don't think files should be overwritten at all, at least not by a mod. I would do something like what Zandronum does with log files, and append the date and time unconditionally, so that no vital files can be overwritten. Even in the user folder this could be dangerous without some sort of mitigation.

Re: Add optional filename argument to Zscript MakeScreenShot

PostPosted: Tue May 28, 2019 5:17 pm
by JPL
Rachael wrote:I would tend to agree, but that's not my decision to make. I'm guessing it's for compatibility reasons.

Either way though, I don't think files should be overwritten at all, at least not by a mod. I would do something like what Zandronum does with log files, and append the date and time unconditionally, so that no vital files can be overwritten. Even in the user folder this could be dangerous without some sort of mitigation.


All of these concerns sound valid and if it's a deal breaker, I'd settle for "nothing will be written if you specify an existing filename", thus guaranteeing data safety.

Re: Add optional filename argument to Zscript MakeScreenShot

PostPosted: Tue May 28, 2019 5:45 pm
by Enjay
Gah! the spectre of possibly yet more stuff being written to remote places on my HD gives me chills. I get that it is the current way to do things and it might even be for good reasons (e.g. perhaps security as suggested) but I find it horribly unintuitive for programs that I have deliberately chosen the location of to suddenly write files somewhere entirely different in a directory that they have created in a folder that the OS likes to pretend is somewhere else in the first place and clutter up my user directory to boot. I have always despised these fake/virtual/multi-user folders in Windows ever since they first started appearing. I like to know where stuff really is and I like stuff to be where I put it.

Mind you, I cut my computing teeth making directories in DOS and not having any of these new fangled user directories and so on, so things were always just where I put them and nowhere else. So, maybe it's just that there is a problem between my keyboard and my chair (specifically, that particular component being outdated). :P

Re: Add optional filename argument to Zscript MakeScreenShot

PostPosted: Tue May 28, 2019 5:57 pm
by JPL
Enjay wrote:Gah! the spectre of possibly yet more stuff being written to remote places on my HD gives me chills. I get that it is the current way to do things and it might even be for good reasons (e.g. perhaps security as suggested) but I find it horribly unintuitive for programs that I have deliberately chosen the location of to suddenly write files somewhere entirely different in a directory that they have created in a folder that the OS likes to pretend is somewhere else in the first place and clutter up my user directory to boot. I have always despised these fake/virtual/multi-user folders in Windows ever since they first started appearing. I like to know where stuff really is and I like stuff to be where I put it.

Mind you, I cut my computing teeth making directories in DOS and not having any of these new fangled user directories and so on, so things were always just where I put them and nowhere else. So, maybe it's just that there is a problem between my keyboard and my chair (specifically, that particular component being outdated). :P


Windows is actually kind of an outlier in that regard, in all UNIX-derived OSes (Mac OS X, Linux) an application's install directory and where it is allowed to write data to are kept deliberately separate. This has the advantage of keeping programs where every user can access them, and user data in a place that's easy to back up; if I install a new Linux distro I can leave my /home partition where it is and reinstall the entire OS and programs and everything works exactly as before. Whereas when I set up a new Windows system I have to re-download all the third party software I use (because Windows also lacks a package manager) and then re-configure every single application, unless it's easy to copy over config files and assuming the software doesn't use the registry for configuration.
More recent versions of Windows seem to enforce some sort of access control when writing to c:\Program Files\, mainly for security reasons. I guess ZDoom/GZDoom has avoided having to grapple with any of this by never having an installer. (Not that installers don't bring their own weird issues.)

Re: Add optional filename argument to Zscript MakeScreenShot

PostPosted: Wed May 29, 2019 1:05 am
by Graf Zahl
Even Linux allows portable installs and there the same issues apply. Most Doom ports on Windows are traditionally being designed as portable, but if you put GZDoom into Program Files it should use a directory in user space for writing as well.

So, regardless of platform, there will always be the issue that an app that allows writing to arbitrary places may stomp on data it has no business manipulating.