What I am doing is scanning a ZIP file which contains the games default levels and basically counting the number of levels available. Then I switch out of the ZIP to the exe directory and scan for any additional user made levels so I can get an accurate count of the total number of levels available.

There are 10 levels in the zip ("level001.dp2" to "level010.dp2") and 1 level outside the zip in the same directory as the exe named "level011.dp2". It finds the 10 inside the zip just fine, but doesn't see the one in the exe folder. The path functions work well and get the proper path but nothing. I switch off the physfs interface okay so I don't see where I am going wrong here.

The printf() shows the path and filename as being totally correct. Also, just a little bit later in my code I load in levels for the game and they all load just fine, whether they are in the ZIP or in the main directory with the exe, no problems, they load fine. I do the same thing in this code where I switch to the standard file interface and then open the file. It works, no problem. Yet in the above code, it won't file the level outside the zip no matter what I do. I tried al_fopen() as well and nothing. This is really strange and starting to drive me nuts! :/

You'll want to use absolute paths with those functions.

Personally I'd just al_read_directory the dir your levels will be in, and look for level\d+.dp2 files.

Thanks.

I replaced the al_filename_exists() with the following code and it is working now...

      ALLEGRO_FILE *file = NULL;
      file = al_fopen(levelname, "rb");
      if(file) {
         levelcount++;
         al_fclose(file);
      }

...which ironically, was the way I was originally going to do it until I made the mistake of discovering al_filename_exists()

To be honest, al_filename_exists should work. I suspect you weren't building the path right.

Next time you want to play with paths, ALLEGRO_PATH might be a good way to go.

I used the same path for al_fopen() that I used for al_filename_exists(), I only changed the code that opens it.

The old code is above, here's the new code with changes:

One thing I changed with regard to the path was I used levelname which was a variable I already had created so I didn't need a filename variable, but that didn't effect anything, and I tried the code with it and al_filename_exists() and still no go. The path is built the same way, I thought of that too. I built it several different ways, which is why I needed to know how to get the directory path that the executable was in (in another thread) and that didn't help either. Speaking of which, I just realized that code is still in there and no longer needed. It wasn't until I changed it to al_fopen() (originally tried fopen() and that worked, then the Allegro versions). So there seems to be some sort of bug with al_filename_exists(). There's absolutely nothing I done wrong, it's not a complicated task, my game builds the file name and loads the levels all the time, they have for over a year now, it's a straight forward task. I have a level editor that I worked on long before this and of course I have worked with C programming and files since the 1990s. I have trouble the odd time with Allegro 5, but not with C and files.

One bonus to all this, the new C standard C2011, adds a new standard subspecifier ("x"), that can be appended to any "w" specifier (to form "wx", "wbx", "w+x" or "w+bx"/"wb+x"). This subspecifier forces the function to fail if the file exists, instead of overwriting it. Could be handy, I may update my level editor to use it.

I don't suppose you could print out the actual filenames you're trying to al_fopen, and al_filename_exists? I half expect you're missing a slash in the latter, or some similar issue.

In both cases I initially just used "level011.dp2" as my filename, no path, which works fine with al_fopen but not with al_filename_exists. I added in a path later on in an effort to get it to work but it wouldn't. al_fopen has zero problems opening the level files and reading in all the data.

Strange anyhow. Would look more elegant with just al_filename_exists but it's not vitally important for me. If it is a problem with the library it should be looked into though.

it's probably a bug then...

Okay, this is strange... but I just went back on a whim, to rewrite the code again and clean it up and I decided to try out al_filename_exists again. And it worked. Which is really strange as the filename hasn't changed at all. I am totally stumped as to why this would work now, and not last night.

I don't know, must have been something I done I guess, but I can't see what.

Maybe last night you were running your application from the wrong working directory?

The main difference I see is that you were prepending the path variable to the levelname. If levelname is missing a trailing slash on path, it'd fail to find the file.

Which by the way, is why I wanted you to print out (and post) the paths it was trying to test.

I always run it in the same directory.

This was not the problem as I used printf to show me the path+filename it was searching for in the console window. Plus it also happened when I didn't use a path at all (which is what it does now), the reason why I added the path in there in the first place was because it wasn't working. Just one of many attempts to get it working. Strange problem.

I thought for a while it could have been because I had temporarily renamed the file to "level001.dp2" in order to test if the game would load it in rather than the default from the zip file, and the game loaded it no problem so it could see it in the directory with the game. I renamed it back to what it was then just tried al_fopen and it worked. When I switched back to try al_filename_exists one last time (because I am stubborn like that, ) it suddenly was working. shrug

Ok, I suspect typo now

You're probably right. It was late. But I honestly went over it quite a few times and didn't see any. I DID play around with other functions which I suspect may have effected it somewhat. I know I used the wrong functions a few times while trying to figure it out. Ah well, it works now.

Love Allegro 5 for the most part (though I still don't like how the audio is implemented, but that's another subject).

Anyhow, I should probably close this topic.