58 replies to this topic

[Timelord]

Having no posts in two years, I'm assuming that this project is dead; however, if you feel any need to resurrect it inthe future, I do have some suggestions:

 

Option: +Name screenshots, based on quest sav name.

Option: +Create directories for screenshots, based on quest .sav name.

Option: +Create directories for screenshots, based on date.

Option: Names take precedence for directories.

Option: Dates take precedence for directories.

Option: Names take precedence for filenames.

Option: Dates take precedence for filenames.

Option: Allow multiple instances (2.50.1) of ZC/ZQ.

Option: Create script subset archive on compiling (read all script files that are imported, and save them, with the buffer to a ZIP file).

Option: Create .txt file of slot assignments (ZScript Compiler, ffcs, items, globals), on compiling.

 

(I'm assuming that these things are reported in some way.)

 

I'd also highly suggest switching from a JRE to C++, with direct API code: The JRE takes a good amount of system resources away, and if you run it on any kind of portable system, or a 32-bit system, every bit of memory, and every PU cycle wasted on the JRE is precious. The JRE is quite susceptible to memory leaks too, and version incompatibility/interoperability between various JAVA releases can be a fantastic pain to sort out.

[LinktheMaster]

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.

 

Do you mind explaining what you mean about names/dates taking precedence?  Not sure I follow there.

 

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.

[Timelord]

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.

[LinktheMaster]

The simplified interface is something I'm not going to give up on.  It's something I want it to include since I don't want the program to have a bunch of extra bloat in it.  Remember that you're not going to customizing stuff every time.  So why have all that stuff viewable when you're just launching ZC?  Plus, as I said, I don't think those scripting functions are really possible since I don't have access to all that stuff.  I believe it may output compiling results to allegro.log, but I'd have to check.  However, there would be no way for me to obtain the buffer.

 

I definitely do see your point for allowing more customization for screenshot organization,t hough.  So, if I ever do work on this more, I'll definitely put thought into that.  But, there is definitely a balance that I'd aim to achieve.  I'd want to offer more customization, but not to the point where doing the organization would be complex and unintuitive.

[Avaro]

Wow, this looks really useful actually. I like the organization factor of this, my ZC folder is indeed a huge clutter xD

 

Looking forward to see this finished.

[Timelord]

The simplified interface is something I'm not going to give up on.  It's something I want it to include since I don't want the program to have a bunch of extra bloat in it.  Remember that you're not going to customizing stuff every time.  So why have all that stuff viewable when you're just launching ZC?  Plus, as I said, I don't think those scripting functions are really possible since I don't have access to all that stuff.  I believe it may output compiling results to allegro.log, but I'd have to check.  However, there would be no way for me to obtain the buffer.

 

I definitely do see your point for allowing more customization for screenshot organization,t hough.  So, if I ever do work on this more, I'll definitely put thought into that.  But, there is definitely a balance that I'd aim to achieve.  I'd want to offer more customization, but not to the point where doing the organization would be complex and unintuitive.

 

Well, that's a user choice, IMO. Make a full interface, and a 'small' interface, that doesn't show all of the options; and give the user a toggle-switch between the two. 'Small' can be the default, whereas users that will need to constantly change information, can use the large interface as their default, giving them the entire options pane as their initial view, as a preference setting.

 

With regard to gaining output from the compiler, I would assume that if you can interrupt ZC/ZQ, that you could catch the files that it processes, when it compiles them, and make a ZIP archive, without needing to extract the assembled code; however, extracting the assembled code would be a good feature, and would need decryption routines provided to you, in order to add something of that sort.

 

In any event, I would think that it would be possible to detect what files the compiler buffer is reading from imports, by basic monitoring routines, and when ZC reads any files with .z, or .zh extensions, or 'Plain text' filetypes, you can mark those, as a list, and create a ZIP file with all of them, duplicating their directory structure, while excluding any other files; then compress into a package (.ZIP or .tar.gz), with a filename derived from quest name, and/or date, as selected by the user.

 

In this instance, you don;t need to extract the buffer itself: The point would be to make an easy to use package, that only contains files that are in-use, called by import commands. It's a lot of work to maintain, and organise, dozens, to hundreds of iterations of 15,000-20,000 lines of active code, plus at least twice that in archived, inactive code, that is not yet included, plus other text files.

 

Producing a repository for a quest project, for co-developers, testers, etc.; that contains only what you're actually using, as an automatic process, would be pretty wizard.

[LinktheMaster]

Yeaaah.  I get that would be nice, but I don't have the time to invest into figuring that out.

[Evan20000]

Something I wanted to point out:

 

It's well known that ZC 2.50 stable likes to eat people's save files, but for whatever reason when launching it through ZCM I have never had this happen to me. ZCM is pretty amazing in that regard alone.

[Timelord]

I only had that problem when launching ZC directly. ZLaunch also seems to prevent this little conundrum; but force-closing ZC at any time, will kill a .sav slot, because when you save a game, the save isn't committed until you close ZC in a clean manner. I believe that a game save is dedicated to a temporary file, and when you exit ZC, that part of the exiting routine adds the new save datum to your .sav file.

 

You can test this for yourself: Launch ZC< make a new save file, play for a few seconds, save the game, then force-quit ZC; and relaunch. Your latest save files--any that you added since you last properly exited ZC--will be gone. I'm sure there's a temp file on your system that has the information, but I don't know what is is, or where it lives.

 

@LTM: I don't blame you. The method of reading what files are being accessed, is going to be different for each platform, and each filesystem structure. It's no walk in the park. It would still be brilliant to be able to condense the scripts that are in use, without needing to do it manually; and that's sort of a missing feature in ZQ. I never understood why when you import something into the compiler (with the import command), that you couldn't later export it again (or why there isn't a menu option Quest->Scripts->Slot Assignments, even if it's read-only).

Edited by ZoriaRPG, 02 June 2014 - 02:54 PM.

[TheLegend_njf]

Would this help me display a 2.10 quest in Windows 8 better? I found when I imported the launcher it would open a tiny window, and if I didn't import the launcher, it would only play in full screen.

[Timelord]

Would this help me display a 2.10 quest in Windows 8 better? I found when I imported the launcher it would open a tiny window, and if I didn't import the launcher, it would only play in full screen.

 

I take it you have scale set above 1x in ZLaunch? I don;t even remember what the 2.10 options were: I use 2.50 to play 1.92, and 2.10 quests. 2.50 is far more stable., and has enough backward-compatibility rules to permit most 1.9x/2.1x quests to run.

 

ZCM is for ZC 2.5, and was designed to work with 2.50.00RC3. I don't believe it works with 2.10, and even if it did, it wouldn't fix the inherent problems with Win8 that cause conflicts with Allegro. (Short answer, no; use a VM with XP on your W8 system.)

[SyrianBallaS]

Bump

 

This program (windows version at least) triggered windows smart screen and blocked it and was marked as a virus.

[DCEnygma]

Bump

 

This program (windows version at least) triggered windows smart screen and blocked it and was marked as a virus.

 

Depending on your AV settings this can happen, because it's classed as an uncommon or unknown program. I can assure it is not a virus.

[Timelord]

[Gravedig]

Matthew, if you are still around, and you want to dump the latest source for this, I might update it for future ZC builds; or convert it from JVE format to something that is precompiled.

[/Gravedig]