Messages

1

Misc. Tools / Re: ESRganResizer 1.1.5 (a simple GUI for ERSgan + prefilter) (11/09/2019)

« on: 2020-03-21 19:28:14 »

Are there any plans to update this tool? It does not currently work with many filters (like any 1x model, which is all the noise/artifact removal ones) because the math for tile sizes/overlaps is broken for anything but the default 4x scale.

This is unfortunate because many of esrgan's 1x models are amazing, like the JPEG ones and dedither, and the only way to use them is to manually edit the bash scripts every time you want to change between models with different scales.

It's kind of amazing, really, how esrgan's JPEG models completely blow away any of the expensive commercial denoiser tools, even those that focus on jpeg specifically.

2

Troubleshooting / Re: FFVII Pc wrong textures\Vista Ultimate

« on: 2007-10-29 00:24:42 »

Got your PM, but unfortunately, I don't think I can be of much help. My concern was getting it running on Vista at all, and it doesn't seem to have any texture issues. So really, if you're trying to get it running in the first place, my steps might help, but otherwise... Perhaps it's the 8x00 series from nVidia. Does anybody else here have it running on Vista on an 8x00 series card? Mine is a GeForce Go 7900gs, so it's the previous generation.

3

Archive / Re: Fraps'ing or recording FF7 PC...

« on: 2007-08-15 20:48:42 »

The framerate in that YouTube video is pretty horrible. I wouldn't say that's perfect.

It looks like he was using hardware mode rendering mode, which may be faster to record.

4

Completely Unrelated / Re: Did Halkun die again? (A Little off-topic)

« on: 2007-07-22 07:57:41 »

I suggest you go and read Charlie Cleveland's blog, which details his founding of an indy dev studio (although the blog picks up long after development, there are some posts where he talks about the early process) with the goal of writing Natural Selection 2.

Here's the first post:

http://www.charliecleveland.com/archives/2005/03/

5

Troubleshooting / Re: So, uh, Vista?

« on: 2007-07-15 22:48:19 »

Here's what I did to get it running on my laptop (Core 2 Duo, GeForce Go 7900gs) with Vista Home Premium 32-bit:

1) Installed FF7
2) Installed 1.02
3) Installed video codec (trumotion one. Maybe try compatibility mode on the installer?)
4) Disabled ffdshow for it
5) Set Win98 compatibility mode for ALL EXECUTABLES in the ff7 folder

Then it just worked. The only config change I made was, IIRC, changing from 320x240 to 640x480. I didn't touch the other stuff, it was already set up and working for hardware mode on the GeForce Go 7900gs. I've also tried the highres patch, which worked nicely (but then again, my screen is 1920x1200, so I can support 1280x960 without difficulty)

6

Troubleshooting / Re: Midi issues

« on: 2007-07-15 22:37:43 »

You may want to try ff7music, if the music is your only problem. The downside is that from what I've heard it's not compatible with the high-res patch.

Fortunately, what you've heard is a load of bullsh*t 

Any advice for getting both of them working at the same time would be appreciated, then. I've "heard" it because a buddy of mine was trying to get both patches working and reported that he couldn't get them both installed at the same time.

7

Troubleshooting / Re: Midi issues

« on: 2007-07-06 04:43:23 »

You may want to try ff7music, if the music is your only problem. The downside is that from what I've heard it's not compatible with the high-res patch.

8

Q-Gears / Re: Uh, what button do I hit?

« on: 2007-07-06 04:21:58 »

I'll admit, I had a similar problem, and resorted to trial and error to figure out the keys

9

Q-Gears / Re: Little update and announce!!! [Mod title edit: Q-gears fork]

« on: 2007-07-06 04:20:11 »

Since my primary desire was to see a re-implementation of FF7 to the extent that I could play it again in a more stable state than FF7 on PC currently allows, I must admit I'm disappointed by this. I also don't think that the Q-Gears dev team is large or active enough to sustain two separate forks.

However, assuming that both forks do continue at a fair clip, this might be a good thing in the long run. It's just that big IF. With the development on Q-Gears already pretty slow and limited to just a few people, can both new forks succeed? I'm apprehensive, but optimistic!

EDIT: Should this thread be stickied?

10

General Discussion / Re: Final Fantasy 7 1080p PS3...

« on: 2007-06-20 01:36:45 »

So the original models are, when unaltered, displayed at a lower resolution than they were designed?

This comes from the confusion about what the word "upscale" means.

It means taking a low-resolution image, and scaling it (stretching it) to higher resolution.

Allow me to demonstrate with an example, an NES screenshot, which I will "upscale" using a photo editor and a bilinear transform:

First, the original:



Now, the upscaled version, to 300% size:



That's all upscaling is, that's what it means. It means resizing the image to higher resolution. Some upscalers will use a higher quality transform that looks nicer on smooth images like video. A bicubic transform would have been sharper. But either way, you're not creating new data, because that's impossible. If you look at the upscaled image here, you can tell that there are no added details. It's just the same image, but bigger.

That's what the PS3 is doing, it's taking a low-res source image (from the PS1 in that case, not the SNES), and upscaling it to a higher resolution. While this probably looks nicer than not having it done at all (or using something like nearest neighbour filtering, like the PS3 did pre-update), it doesn't add new detail.

What the high-res patch for FF7 does is NOT upscaling, it actually renders the game at a higher original resolution (1280x960), so the image is higher resolution to begin with. This means that there IS more detail.

Of course, the background tiles in FF7 are a fixed resolution, so they're still scaled using nearest-neighbour, but all the 3D models (and the battle and world modules are entirely 3D) can take advantage of the extra resolution.

11

General Discussion / Re: Final Fantasy 7 Source

« on: 2007-06-20 01:27:24 »

Combine the first part of the rule (something worthwhile to add, which I do think I did, since it wouldn't do do have misconceptions about the engine flying about), and the fact that at the time the topic in question was still on the front page of the forum (which isn't part of the rule, but runs more in the "common sense" department), I don't think I did break it, no.

If you think my post would have been more worthwhile had I added MORE detail, I would be happy to do a bit of research and cite several examples of mods for engines with equivalent or less flexibility than Source that make change of a similar level of complexity. However, I think my post would qualify as "worthwhile" without such extra content.

12

General Discussion / Re: Final Fantasy 7 Source

« on: 2007-06-18 16:25:38 »

An RPG in a FPS engine.

No offense, there is no possible way you could scripy any encounters, materia, story, ANYTHING in Source, its not possible.

That, quite frankly, is BS. Source is a *game* engine, not an FPS engine. The FPS aspect is merely an artifact of the game code (which is available to modders).

You can implement any type of game you want in Source, or most moddable games. RTS, FPS, TPS, RPG, you name it.

There is absolutely zero reason you couldn't implement a mod for Source that featured a field module, a battle module, a worldmap module, and so on. Crazier things have been done with engines LESS flexible than Source.

From what you're describing, you seem to think that the most you can do with Source is make custom maps, when in fact Valve gives you access to the entire game (not engine) source code, allowing you to do whatever you want with the engine. Something like FF7 from a technical perspective is actually probably less effort than some of the crazy things other mod teams have done.

That said, the original proposition (remaking FF7 using the Source engine) is stupid, since it'd be shut down in no time flat. But there's nothing stopping anybody from creating a mod that is essentially the exact same thing as FF7, gameplay-wise.

I think the confusion stems from what a "mod" means for FF7 (usually just replacing media or manually tweaking the binary) compared to what it means for an engine like Source (having the entire game's (not engine) sourcecode available to play with).

In fact, I'd go so far as to say that the flexibility to do this sort of thing has probably existed as far back as Quake 2, although the further back you go the less suited the engine would have been for moving beyond the FPS genre. But modern engines such as Source and Unreal are regularly used by both modders and commercial teams for non-FPS games.

13

General Discussion / Re: Final Fantasy 7 1080p PS3...

« on: 2007-06-18 16:18:39 »

Umm, the PS3 doesn't render PS1 (or PS2) games at 1080p. Or 720p. It renders them exactly as they were rendered on the original hardware. That's because (excluding the European PS3s and possibly the newer NA ones too), the PS3 contains the actual hardware from the PS2 (which contained the hardware of the PS1) to run the game. There is no opportunity to render at a higher resolution.

What it does do is upscale the image from the PS1's native (somewhere about 320x240, I'd guess, although the PS1 supported from 256x224 up to 640x480) resolution to whatever the output is.

The problem is, if you take a 320x240 image and upscale it to 1920x1080, it's just the original 320x240 image blown up. You can't create detail that isn't there. It doesn't really look any better. At best, you get smoother output, but no extra detail.

If you want high res FF7, the only option is the highres patch for the PC, which will render it at 1280x960. That's similar to 720p, except with a 4:3 aspect ratio.

14

Troubleshooting / Re: how do i fix this prob13m?

« on: 2007-06-18 01:59:56 »

i have an original copy.plz hlp im a noob!

so...is it an legal cd, or an illegal copy?

Umm, that's answered in the text that you're quoting... He said he has an original copy of the game. Not an illegal copy. I know this guy is hard to understand, but he was pretty clear here.

15

Q-Gears / Re: Anyone want to write a PSX file extractor?

« on: 2007-06-18 01:58:25 »

Ugh. Databases are not filesystems. They are not the ideal method of storing data. It's one thing to use a database to index or catalog data, it's enough to start shoving gigabytes of binary data into a database. Besides, if you're extracting data, it's better to stick them in files on disk where they can be properly managed/cached with zero overhead for accessing them.

I imagine it'd be much slower to start shoving FMVs into a database.

I've been a bit busy (Think finding a new job etc.).  So lets actually deal with this from a pragmatic point of view.

• Databases are ideal for storing data, isn't that what they are for?  If you mean 'game related data'. Then you are only partially right.
• Second there is a problem with 'sticking them in files on disk' you are making the assumption that using an OS's file system 'has to be faster', it in fact can be a lot slower.  Technically very few games these days are released without using a specialized database system to store the game. So the idea that "Database is an absurd idea", is going against what has become the most common method of handling information for games. That is a database.
• There is no such animal as zero overhead.  Each file occupies a physical location on disk. In the the FAT32 system it can be from 2K to 64K as a minimum.  So a small file whose size is say 120 bytes may actually use 32K. This is FAT only because cluster sizes for NTFS in general are much smaller. 4K being the norm. In addition to that it takes a certain amount of time seeking about to acquire said data.  So no matter what you do there will be overhead, it's just can you deal with it or is it overbearing.  This is something that can be tested quite affectively in a few minutes if someone running a light computer can run Q-gears and said database system without even noticing then I would say, there is no problem.
• FMV/Full Motion Video files are the exception not the rule of things, since they are at least 1M Byte in size, there are fewer than 100 of them per game. So yes it would be ludicrous to put them into databases.

The real reason you use databases is not because they are 'EASY' and 'CONVIENENT' if that's what you want, consider the number of relatively small files in the FIELD directory.  Square turned these into a database by making a special large file in that directory, that they used to find the length and sector start of each of the files that relate to field locations.  That's what there engine used with field locations, ours obviously does not.
So in summary the idea of using a database, is not absurd nor is it something 'no one else is doing', it's common as dirt in a field when it comes to handling vast quantities of game data.  In this case there is vast quantities of data.  I don't need to go very far to point out an example, see the PC version of FF7 (it uses a database archive system).  A simple flat file is all that's needed.   So instead of having a whole hierarchy if directories occupied by thousands of small files, one can have a few directories occupied by a few files.  I like the latter myself.

That was all I really wanted to discuss. It's not like using an archive/database system is suggesting we do something absurd at all.

In general this changes one problem for another, I think the trade off is less of a problem than the shear volume of files.

Cyb

I should clarify that I was thinking pretty much solely of FMVs when writing that post. Very large files that generally don't make sense to stick in a database. I also admit that I'm looking at this from a web programmer's point of view, where putting large files into a database is viewed as a big no-no for performance reasons.

However, I'd posit that many of those games you mention are really using archives as more of a virtual filesystem rather than a proper relational database. To me, the idea of sticking FMVs into a regular relational SQL-based database just seems... bad.

As for zero overhead, assuming the file allocation tables (or inodes, or whatever the filesystem in particular is using) are stored in memory, there really is almost no overhead to access a file on the disk, as far as I know. You know what sector on disk you want to read, the disk seeks and reads it. With a database, it would seem like it might have to query the disk multiple times (depending on caching) to find the information through a query.

Flatfiles or other archive-based methods, though, would probably have very little overhead, since you'd know where the data you want was in the file, so you could just seek right to it...

I think I just made my point really poorly

16

Troubleshooting / Re: FF7 on Vista (suggested hack not working for me)

« on: 2007-06-12 00:32:17 »

Here's what I did to get it running on Vista on almost identical hardware (Core 2 Duo, GeForce Go 7900gs) with Vista Home Premium 32-bit

1) Installed FF7
2) Installed 1.02
3) Installed video codec (trumotion one. Maybe try compatibility mode on the installer?)
4) Disabled ffdshow for it
5) Set Win98 compatibility mode for ALL EXECUTABLES in the ff7 folder

Then it just worked. The only config change I made was, IIRC, changing from 320x240 to 640x480. I didn't touch the other stuff, it was already set up and working for hardware mode on the GeForce Go 7900gs.

17

Archive / Re: Remaking FFVII Backgrounds: An Art Project (For Now)

« on: 2007-06-11 07:13:03 »

Before you guys get too far ahead of yourselves, you should note that Q-Gears isn't going to allow you to replace models/backgrounds/cinematics/etc. They're planning to either allow no modified content, or entirely new content, but not a mixture of Square data and new data.

See this FAQ question:

Can you make it mod friendly? How about some mod tools?
No, not right away. I'm keen on using Square's original data first. If anything at least our engine will be a little more forgiving with what's accepted as input. However, there is a large likelihood that the system will be designed to make Square and non-Square data non-interchangeabe. This means you won't be able to add your mods to a stock game, but use new data with a different format to create new games. (most likely, text or XML) The less we step on Square's toes, the better.

Of course, there is no way for them to prevent you from using third-party content; Q-Gears is open source, so such restrictions can easily be disabled. Personally, I think the idea of trying to limit modified content is ridiculous, but that's just me.

18

Q-Gears / Re: Anyone want to write a PSX file extractor?

« on: 2007-06-05 17:24:02 »

Personally what I would prefer to do is use a nice DB manager (ala SQLite or something) and create BLOB databases with all the binary data in it.  That would be the idyllic thing to me.
As for reading the data off the disk etc.  Do we know EXACTLY what files are used on the FF7 boot up sequence for the PS1?
We also know something about the FIELD directory and the reason Square used direct sector access (it's in another diatribe of mine regarding said file etc.)
There is a large file in that directory that contains everything you wanted to know about the field directory in it.
I think for installation wise since the disks are NOT identical in the FF7 PS1 it might be good to create big BLOB archive packs (not the same as an LGP archive but similar in concept).  It might work to have 'Same'/Union information in a single archive and DIFF/difference/different information in DISK related databases.  This would end up one BLOB for the main data and 3 smaller BLOB archives for what remains.

I prefer something like SQLite to manage a data base.  It's over kill? Yeah it is .. well at first it might appear to be.  However being able to know what's in the data base and access it with a more standard interface (IE SQL statements) might be a godsend.  Especially when dealing with things that aren't labeled (IE FF8 Xenogears FF9 data).  It's just a thought.

Data extraction from the disks, can be done via ye olde PS1 plugins for emulators. These are ideal for this type of thing.  Since we know what we are looking for off the disk and can make a utility that will create whatever we want in the end this seems practical.  I don't know about distributing a PS1 plug-in though (details?)  Anyhow one should be able to invoke from the installer script the external program to perform the file gathering for the game.

To simplify my thoughts

So in summary:

• Create a Q-gears specific utility program that slurps data from a disk.  This utility likely should have it's own specialized script for said extraction.  This utility should be able to identify which disk it is looking at to extract said data (IE FF7 disk 1 etc.)
• Optionally utilize a real database system ala SQLite (public domain), and sqlite3x (c++ wrapper also PD) to create the databases for the games stored information on the target system. This adds the possibility of later improvements in Q-gears in terms of functionality and dealing with large volumes of data consistency of the interface to run the games etc. Unfortunately SQLite is limited  to 2 telibytes (2^41 bytes) sized databases and Strings and BLOBs up to 2 gigabytes (2^31 bytes). 
• The utility should be able to be invoked from an installer with it's correct script information for it to acquire data etc. from the CD.

I don't think everyone will like the idea, however it will do some things, first keep the data from being strewn all over, second keep the data better organized, and thirdly give the option of doing more with data later on.  Most groups consider a database expost facto in such things. Considering the volume of data we are dealing with, it might be better to do so before things get really unweildy. The Database idea perhaps will also help with the injection of XML scripts etc into the engine later on. Remember it's only an idea.   I just hate everything being piled like a junk yard into directories.

On a side note most of these objects are accessed via numerical values from the script no?

Cyb

Ugh. Databases are not filesystems. They are not the ideal method of storing data. It's one thing to use a database to index or catalog data, it's enough to start shoving gigabytes of binary data into a database. Besides, if you're extracting data, it's better to stick them in files on disk where they can be properly managed/cached with zero overhead for accessing them.

I imagine it'd be much slower to start shoving FMVs into a database.

19

Archive / Re: New Project: Final Fantasy VII 2D remake

« on: 2007-06-05 17:18:10 »

I know this topic is quite dead and dead topics should not be brought back to life.

Then why did you?

And if this "project" is freezed because of that copyright thingy.. just send them a letter. It cannot harm anyone. If they dont give the permission to use they're consept then we can just move on other things

It's illegal. Move on. Feel free to send a letter, you won't get a response.

Heck, while we're busy performing thread necromancy, I should mention in response to the earlier comment by Elentor about modifying the game being illegal. It isn't. It's in violation of the EULA, which is not law. You can't just create laws because you feel like it. You will not and cannot be arrested for violating a EULA. However, it does give them grounds to sue you.

What does this mean? It means you're still not allowed to do it, but it isn't illegal. It's not permitted.

20

Troubleshooting / Re: FF7 on Vista :/

« on: 2007-06-04 21:04:32 »

I got the PC version working on Vista fine. Here's what I did:

1) Installed patch 1.02
2) Disabled FFDshow's TruMotion decoder to avoid interference
3) Installed the FMV driver (http://aaronserv.dyndns.org/hosting/ffsf/downloads/ff7betap1.zip)
4) Set Win98 compatability mode on ALL executables. That includes ff7, ff7config, even the cdcheck one.

The game then worked perfectly fine

21

Q-Gears / Re: Q-Gears 0.13 Windows Installer is here!

« on: 2007-06-01 07:54:48 »

Yeah, I can confirm that Vista ships with xcopy by default. It just doesn't seem to like dealing with the mixed mode disc in certain circumstances. I was unable to get it to copy directly from the image at all, no matter what virtual drive app I tried. I wish I had a PSX disc handy instead of a PC disc, because I suspect that a real disc wouldn't work either...

I should note that CloneCD VirtualDrive didn't return the error, but still failed to copy properly. As in, it stalled.

As I mentioned before, I ended up having to extract the files manually using an app that could read CCD images, and then xcopy was perfectly happy to copy the data from a network share.

It's been suggested before, but what about a custom extraction app that used the disc DLL or SO component from a cross-platform PSX emulator? Those interfaces are usually standardized and documented. Although I'd imagine that they'd work on a lower level than exposing the filesystem to the PSX game (or whatever app), but I know nothing about that.

Vista also seems to have a commandline app named "robocopy" for "Robust Copy". Here's the /? from it:

Code: [Select]

C:\Users\gus>robocopy /?

-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows

-------------------------------------------------------------------------------

  Started : Fri Jun 01 03:51:07 2007

              Usage :: ROBOCOPY source destination [file [file]...] [options]

             source :: Source Directory (drive:\path or \\server\share\path).
        destination :: Destination Dir  (drive:\path or \\server\share\path).
               file :: File(s) to copy  (names/wildcards: default is "*.*").

::
:: Copy options :
::
                 /S :: copy Subdirectories, but not empty ones.
                 /E :: copy subdirectories, including Empty ones.
             /LEV:n :: only copy the top n LEVels of the source directory tree.

                 /Z :: copy files in restartable mode.
                 /B :: copy files in Backup mode.
                /ZB :: use restartable mode; if access denied use Backup mode.
            /EFSRAW :: copy all encrypted files in EFS RAW mode.

  /COPY:copyflag[s] :: what to COPY for files (default is /COPY:DAT).
                       (copyflags : D=Data, A=Attributes, T=Timestamps).
                       (S=Security=NTFS ACLs, O=Owner info, U=aUditing info).

           /DCOPY:T :: COPY Directory Timestamps.

               /SEC :: copy files with SECurity (equivalent to /COPY:DATS).
           /COPYALL :: COPY ALL file info (equivalent to /COPY:DATSOU).
            /NOCOPY :: COPY NO file info (useful with /PURGE).

            /SECFIX :: FIX file SECurity on all files, even skipped files.
            /TIMFIX :: FIX file TIMes on all files, even skipped files.

             /PURGE :: delete dest files/dirs that no longer exist in source.
               /MIR :: MIRror a directory tree (equivalent to /E plus /PURGE).

               /MOV :: MOVe files (delete from source after copying).
              /MOVE :: MOVE files AND dirs (delete from source after copying).

     /A+:[RASHCNET] :: add the given Attributes to copied files.
     /A-:[RASHCNET] :: remove the given Attributes from copied files.

            /CREATE :: CREATE directory tree and zero-length files only.
               /FAT :: create destination files using 8.3 FAT file names only.
               /256 :: turn off very long path (> 256 characters) support.

             /MON:n :: MONitor source; run again when more than n changes seen.
             /MOT:m :: MOnitor source; run again in m minutes Time, if changed.

      /RH:hhmm-hhmm :: Run Hours - times when new copies may be started.
                /PF :: check run hours on a Per File (not per pass) basis.

             /IPG:n :: Inter-Packet Gap (ms), to free bandwidth on slow lines.

::
:: File Selection Options :
::
                 /A :: copy only files with the Archive attribute set.
                 /M :: copy only files with the Archive attribute and reset it.
    /IA:[RASHCNETO] :: Include only files with any of the given Attributes set.
    /XA:[RASHCNETO] :: eXclude files with any of the given Attributes set.

 /XF file [file]... :: eXclude Files matching given names/paths/wildcards.
 /XD dirs [dirs]... :: eXclude Directories matching given names/paths.

                /XC :: eXclude Changed files.
                /XN :: eXclude Newer files.
                /XO :: eXclude Older files.
                /XX :: eXclude eXtra files and directories.
                /XL :: eXclude Lonely files and directories.
                /IS :: Include Same files.
                /IT :: Include Tweaked files.

             /MAX:n :: MAXimum file size - exclude files bigger than n bytes.
             /MIN:n :: MINimum file size - exclude files smaller than n bytes.

          /MAXAGE:n :: MAXimum file AGE - exclude files older than n days/date.
          /MINAGE:n :: MINimum file AGE - exclude files newer than n days/date.
          /MAXLAD:n :: MAXimum Last Access Date - exclude files unused since n.
          /MINLAD:n :: MINimum Last Access Date - exclude files used since n.
                       (If n < 1900 then n = n days, else n = YYYYMMDD date).

                /XJ :: eXclude Junction points. (normally included by default).

               /FFT :: assume FAT File Times (2-second granularity).
               /DST :: compensate for one-hour DST time differences.

               /XJD :: eXclude Junction points for Directories.
               /XJF :: eXclude Junction points for Files.

::
:: Retry Options :
::
               /R:n :: number of Retries on failed copies: default 1 million.
               /W:n :: Wait time between retries: default is 30 seconds.

               /REG :: Save /R:n and /W:n in the Registry as default settings.

               /TBD :: wait for sharenames To Be Defined (retry error 67).

::
:: Logging Options :
::
                 /L :: List only - don't copy, timestamp or delete any files.
                 /X :: report all eXtra files, not just those selected.
                 /V :: produce Verbose output, showing skipped files.
                /TS :: include source file Time Stamps in the output.
                /FP :: include Full Pathname of files in the output.
             /BYTES :: Print sizes as bytes.

                /NS :: No Size - don't log file sizes.
                /NC :: No Class - don't log file classes.
               /NFL :: No File List - don't log file names.
               /NDL :: No Directory List - don't log directory names.

                /NP :: No Progress - don't display % copied.
               /ETA :: show Estimated Time of Arrival of copied files.

          /LOG:file :: output status to LOG file (overwrite existing log).
         /LOG+:file :: output status to LOG file (append to existing log).

       /UNILOG:file :: output status to LOG file as UNICODE (overwrite existing
log).
      /UNILOG+:file :: output status to LOG file as UNICODE (append to existing
log).

               /TEE :: output to console window, as well as the log file.

               /NJH :: No Job Header.
               /NJS :: No Job Summary.

           /UNICODE :: output status as UNICODE.

::
:: Job Options :
::
       /JOB:jobname :: take parameters from the named JOB file.
      /SAVE:jobname :: SAVE parameters to the named job file
              /QUIT :: QUIT after processing command line (to view parameters).

              /NOSD :: NO Source Directory is specified.
              /NODD :: NO Destination Directory is specified.
                /IF :: Include the following Files.

22

Q-Gears / Re: Q-Gears 0.13 Windows Installer is here!

« on: 2007-05-30 22:23:43 »

Didn't work on Windows Vista, said something about '/EXCLUDE:exclude.txt' and 'C:/Program Files/Q-Qears/something /I /H /something' :/.

I had a similar error attempting to extract with one specific virtual drive program, but not another. Are you trying to use a real disc, or an image?

The game itself works properly on Vista, although it's incredibly slow even on powerful hardware.

23

Scripting and Reverse Engineering / Re: What are all the XA format files from the FF7 PSX disk (disk 1)

« on: 2007-05-28 03:40:43 »

But, are you ever going to get data from the MODE2 sections copied with just regular file copies? You're going to need an abstraction layer at least for each platform anyhow, no?

24

Troubleshooting / Re: Problems with FF7 : Menu crashing T_T

« on: 2007-05-28 03:36:21 »

You sort of forgot to mention what OS you're running. XP? XP SP1? XP SP2? XP x64? XP x64 SP1? Vista? Vista x64? etc.

25

Q-Gears / Re: Q-Gears 0.13 Windows Installer is here!

« on: 2007-05-25 05:51:06 »

For fun, try and select different directories when it asks for the PSX disk. It should try and detect the disk and not allow you to pass unless it's in the drive.... (I'm proud of that part)

I managed to trick the installer into extracting data from an arbitrary folder on my computer. Since you wanted us to report flaws in your disc check, here we go:

Here's how I managed to get Q-Gears to extract from an image:

1) I extracted the contents of the CCD image of disc one using a disc image utility (the Q-Gears installer couldn't directly extract off the mounted image)
2) I stuck those files into c:\temp
3) I shared c:\temp as \\laptintosh\temp
4) I mounted \\localhost\temp to drive Z (Z:\)
5) Ran the Q-Gears installer, it extracted the files from disk and ran just fine.

So in conclusion, the PSX disc protection can be foiled by simply mounting a folder (through network, or maybe a junction link or similar method) as a drive letter. The installer won't know better, even though it's possible to check what type of drive a drive is.

Possible methods to prevent it? Check if the drive letter being provided is a network mounted drive, and check if there's a junction link present. If there is, it's not an FF7 disc!

So yeah, being able to mount any folder as a drive letter and pass that to the installer means that you can get the installer to extract from anywhere