I might pick this back up at some point, if just to fix a couple bugs and maybe add a couple small features to it.
I've thought about switching to C++, but there are some issues regarding this. I've always wanted to try to make something that is compatible with Mac, and this is something that is difficult to do with C++. Not impossible, mind you, but I've tried doing cross platform development with C++ before, and it can be a huge pain in the butt. If I pick this back up to a large extent, I might switch it over to C++. But I'll have to think about it.
While that's fantastic, as a Mac user, I have to say that ZC on MacOS X is somewhat broken, and not-supported. A G4 mac, running Tiger, with XCode Tools is all you'd need for porting this, which would set you back for about £10-£15 ($20-$25), but you'd need to pick an XCode version, and if you select something to new, you isolate yourself to the latests OSX releases, which in turn require the latest Apple HW, and your market is going to be limited to the two or three users that might have the configuration that you need.
I'm not certain if straight C, C+, or C++ would serve you best for cross-compatibility. Anything that gcc will accept is a good start, but you still need to code API functions for each platform's frameworks.
The best thing to do, is to make the programme with XCode 3, as a FAT Binary (PPC/X86), but you'd need a system on which to compile it. Part of the reason that ZC for OSX is so broken, and never used, is because no PPC version exists, that someone could run on a £10 laptop; and the reason for its non-extant nature, is because none of the developers have a Mac. I've offered a G5 to Saffith, but he doesn't have the time to learn XCode, so ZC on OSX is a duck at present.
If any of the devs want to make a proper port to OSX (PPC/intel, 10.4 or later), I;d happily donate a G4 or G5 system to them; but no-one is interested in doing this, which makes a special launcher for OSX impractical. beyond this, I think you'd find that using a JRE to take control away from another programme running in a *nix environment would create a lot of security holes, and that the OS itself may make it difficult to perform that kind of task.
It would be best to ensure that ZC itself allows direct input from this kind of programme, and that ZC/ZQ, when launched through a special launcher, run as independent child-processes, so that the programme can kill them politely, but also so that if the launcher terminates, that the other processes do not.
Do you mind explaining what you mean about names/dates taking precedence? Not sure I follow there.
I think you;d know, that I don't mind explaining anything.
Here's the idea:
If you include options to name files, or store files in a hierarchical filesystem, using quest names, and using dates, you need to establish which of the two takes priority.
Let's establish some quest names, and dates:
Quest Names: Golf, Echo, Foxtrot
Dates, 4th May, 2014; and 5th May, 2014.
Example 1, 'Dates Take Precedence for Directories', your filesystem will look like this.
/04MAY2014/Golf/
/04MAY2014/Echo/
/04MAY2014/Foxtrot/
/05MAY2014/Golf/
/05MAY2014/Echo/
/05MAY2014/Foxtrot
Example 2, 'Names Take Precedence for Directories', your filesystem will look like this:
/Golf/04MAY2014
/Golf/05MAY2014
/Echo/04MAY2014
/Echo/05MAY2014
/Foxtrot/04MAY2014
/Foxtrot/05MAY2014
For filenames, it would be similar:
Example 4, Dates Take Precedence for Filenames:
/04MAY2014_Golf_001.png
/04MAY2014_Golf_002.png
/04MAY2014_Golf_003.png
/05MAY2014_Golf_001.png
/05MAY2014_Golf_002.png
/05MAY2014_Echo_001.png
Example 3, Names Take Precedence for Filenames:
/Echo_04MAY2014_001.png
/Echo_04MAY2014_002.png
/Echo_04MAY2014_003.png
/Echo_05MAY2014_001.png
/Echo_05MAY2014_002.png
/Foxtrot_04MAY2014_001.png
/Foxtrot_04MAY2014_002.png
/Foxtrot_05MAY2014_001.png
This determines first, if nesting of directories uses dates first, then quest names; or quest names first, then names.
That;s assuming that the user wants a programme to have the ability to create directories, or wants auto-sorting. Thus, we also have the filename options.
These allow the user to avoid auto-sorting, but will name screenshots based on (1) the quest name, (2) the date, (3) both, (4) none.
Because the file number is the least critical, and the most useful in determining only the progression in a given sequence, it's going to be last in the filename, to allow proper sorting in lists. The other options, determine if the screenshots are named by date first, or by quest name first. Each, has its merits, advantages, or disadvantages.
With this set of options, the user may selectively enable sorting by quest name, and naming by date, or the reverse. Each of these, is something the user can turn on, or off.
You'd need these options for files, and directories:
+Append Quest name to Screenshots
+Append Date to Screenshots
+Append/Use Quest Name for Directory Naming
+Append/Use Dates for Directory naming
+Use Quest Save Name / Use .qst Filename for Naming (choose one; else, you need to add an order of precedence to this too).
+Dates take Precedence in Filenames / Names Take precedence in Filenames (choose one)
+Dates take Precedence in Directories / Names Take precedence in Directories (choose one)
You may also want to include a user-defined date format:
DD/MM/YYYY
MM/DD/YYYY
YYYY/MM/DD
YYYY/DD/MM
As far as the last two things, I'm not sure if that is possible, really. Plus, one big thing I wanted to stress with ZCM was its simplistic main interface. I wouldn't want to include much to make it more complex.
Glad to hear that people are still using this, though. Once I made this, I can't go back to ZCL due to screenshot organization.
I'll be honest: I see this kind of tool as most useful for questmakers, not players. That;s where those later options would be extremely useful, particularly as there is no way to do them directly in ZQ, but there should be a way to extract all of the script files (very useful, for many people, especially if they lose datum), or to easily filtrate out only what is in use, and send it to a clean directory; and to quickly view your slot assignments, in any given file.
Anything that a user isn't going to use, they can ignore. Who cares what options are visible, or available in a menu pane? The idea of over-simplification seems viral these days, and is responsible for de-contenting everything from computers, to cars, to periodicals.
The over-simplified interface is one reason that I wasn't too keen on it, and possib;y the reason that many developers don't use it (not being able to user-define its 'auto-sorting' makes it quite unfriendly, IMO, and the present structure doesn't make that sorting efficient).
I did like some of the functions, such as auto-killing ZC/ZQ, for developing quests; and those features don;t do anything for plahers; nut are useful for game developers who focus on ZScript. ANyone else, wouldn;t really need a one-key method of killing ZC., and would probably have a rather large dent in their wall, after using it, one time, unintentionally.
I'm not even certain if those functions still work, and I don't know how OS-friendly that task was handled, especially with a JRE. (I think that many anti-virus utilities would detect an operation like that, and attempt to stop it, because the process is not a child-process of the program trying to terminate it.)
On *nix, you're also probably giving sudo access to a widget, which is bad.
Most people that need to take many screenshots, are developers, and development testers, and the people that would get the most out of this, aren't particularly fond of the auto-sorting; quite possibly because they can;t define it in the way they are used to sorting files. Freeware, such as Irfanview, is generally what people will use, to auto-rename screenshots, by adding things such as the project name to them, as a precursory segment of the filename, usually followed by a date, or a sequence number, or both, in that order.
Some people may need to sort by other details first, so adding a user-defined field, would be good.
I wouldn't find sorting by date alone, to be useful in the least; I can already do that with one click, and needing to search through directories by date, would be a nightmare, but if the programme sorted based on quest name, or quest filename (both of these are important to separate from one-another, especially for development users), I'd probably use it regularly.
I do think that if you turned this into something useful for ZQuest users, to aid with dev projects, that it could be fantastic. I had actually forgotten about it, until I noticed it in your signature, and though 'I wonder if that was ever updated...'
Edited by ZoriaRPG, 02 June 2014 - 10:14 AM.