In re-reading the documentation for R2GED, Commsoft's GEDCOM utility for converting Roots III to a GEDCOM file, I see now that it will include only those external text files that have an extension of TXT. This leaves out any SRC files you may have created. Furthermore, those TXT files have to be a regular TXT file, not an event text file. A regular text file has the name with an R in the 3rd position of the file name. It's possible that you could have created other text files with an E in the 3rd position.
Therefore, a file name like HAE00500.TXT will not be included in the GEDCOM file, but a file like HAR00500.TXT will be. Roots III used the last 5 positions of the file name to denote the internal Record number of the person in your Roots III database. So if you see a file and look at it with Notepad or whatever, and don't recognize who it relates to, go get into Roots III and bring up that person by their record number.
If you did like Commsoft suggested, each Roots III database you had should have been isolated in its own directory on the hard disk, or on its own diskette. This would keep the files for different databases from getting co-mingled. If all your databases were in one place, you may have a real problem, especially if your database names started with the same 2 characters.
For example, I have a Roots III database for HARNEY and another for HARROD. If these were in the same place on disk, and I created any text files for either database, how am I going to know what text files go with what database? Because the text files names both start with HA. If you have this situation, stop! Consult with someone who knows how to help you to get things straightened out. But read on before you do that.
If you do not have co-mingled files, then maybe all you need do is simply rename some files. For example, a friend of mine had all her Roots III text in SRC files. In DOS, I simply renamed all her SRC files to TXT files with one command, like so: REN *.SRC *.TXT.
If you have TXT files and SRC files, you need to consolidate them for each person in your database. For example, if you have both a HAR00500.TXT and a HAR00500.SRC file, these need to be combined into the TXT file and the SRC file deleted. One of the first things you need to do is to figure out what you have, by seeing some sorted lists of your file names. There are several ways to do this, but I'd suggest doing it from DOS, so you can get a printout of your file names.
Go to DOS, and then go to the place on disk where your Roots III files are stored. If you followed Commsoft's advice, your Roots III software should be in C:\ROOTS3. And under the ROOTS3 directory, you should have one or more sub-directories, one for each Roots III database. In my case, I have a HARNEY sub-directory and a HARROD sub-directory. If you have a sub-directory, go to it now.
Once you're where your Roots III data is, do a DIR command like so:
DIR /ON > PRN
Be sure to have your printer on, that's what the PRN is for. The /ON tells
DOS to order the list of files by their name. This way, you can see if you have
files of the same name, at least the first part of the file name, not the file
extension. If you find two files with the same name, you'll need to combine
them into the TXT file, using whatever text-editor you desire, such as QEdit,
Roots Writer, Notepad, or even EDIT, which comes with DOS. It's also good to
have a list of these file names, on paper, simply for reference.
I can't believe that Commsoft's R2GED doesn't include these other text files in your GEDCOM file, or at least give you the option to do so. To my knowledge, it doesn't even give you a warning.
I can see why Commsoft didn't put anymore effort into their GEDCOM utility. Their software after Roots III allowed you to import a Roots III database directly, without having to go thru GEDCOM. And why should Commsoft care about letting us create a GEDCOM file when that probably meant we were going to another software package anyway.
And I can see why Broderbund has not put a whole lot of effort into taking care of Roots III users who wanted/want to come over, so I really didn't expect them to take of these little 'gotchas' that Commsoft left us. But I don't see why, in FTMW's import screen you have to go thru the mapping exercise, and then have to remember to turn around and customize the Fact fields. It leaves users wide open for making mistakes. At least they could go ahead and assign the GEDCOM tag, such as BURI, to the Fact field, rather than leaving it as 'Fact', which means nothing. At least if you see 'BURI', or even 'MISC', you've got an idea if that Fact field is being used, and where the data came from in your old software.
I know these folks could have done better, but then, what may make sense to one person may leave others clueless. It's very difficult to give a program lots of flexibility and yet keep it simple to understand. With today's Windows apps taking tens of megabytes, I wish messages weren't so brief. Brothers Keeper is a good example of how software ought to be done.
But here I am, offering up R3GED2FT to the world, and I'm sure that some folks have taken a look at it, shook their heads, and then tossed it, because it appeared to be too difficult. But give it a try. The price is right... it's free.