Config bug?

#1 If the demo path is hardcoded anywhere (ie, "demo/foo/bar" instead of "~/foo/bar") then you'll get that behavior. Try doing a find in files for demo and changing the paths to be ~.

#2 Hi Ben,

Tried that already and there is nothing in any cs file. The word "demo" appears in hundreds of files of course (cpp files, header files, txt files, doc files, comment lines all over the place), but nothing in a cs file that is turning up in the windows search.

Can you (or anyone) try this out and see if you have the same problem please? Should take you less than two mins. Just copy the demo dir to a new name under the "example" directory, and change the main.cs file in the example directory to run that game. If it hangs, look near the end of the log file and see if it is trying to load the wrong mission file.

Thanks,

Dave.

#3 I just tried this for you.

It does hang, then I grepped for "demo" in .cs and .gui files and got a bunch of hits (I don't recommend windows search at all)

There was a couple of hardcoded references in createServer functions in client/init.cs and client/scripts/startMissionGui.cs - once I changed them it loaded up fine.

#4 Vernon, thanks very much, sounds perfect. I'll check those out and also see if I can find a copy of WinGrep somewhere.

Looks like it's a demo bug then, not a TSE bug :-)

Cheers,

Dave.

#5 Ben, the tilde (~) didn't work but hard coding the new game name did. So that looks like it might be a bug. Vernon, did you use tilde or a hard coded name?

demo\server\scripts\environment.cs also has "demo" hard coded for lightning textures if anyone is doing a cleanup of the demo any time.

Finally, I used "bare grep" which is free as far as I can see, but has an ad screen at startup.

Dave.

#6 It depends - ~ can be a little weird sometimes.

I use TextPad, which has a great find in files. Windows search lies to me 7 times out of 10, so I never use it for anything. (I go to my demo directory, do a search for "for" - no hits. Hmm....)

#7 Heh...doesn't something "being a little weird sometimes" = bug? :-)

#8 Not till there's a repro case. :)

#9 OK, just copy the demo game to a new name, change the files above to have a tilde, and try it out. That's how to reproduce it!

#10 Yea I tried the ~ first and looked in the logs and noticed it was searching for the ~/data/missions/features.mis but not finding it, which I thought was a little strange.

Then I hardcoded my own "mod" name in and it was fine.

#11 If you just change line 236 of ~/client/init.cs from:
createServer("SinglePlayer", "demo/data/missions/features.mis");
to:
createServer("SinglePlayer", "~/data/missions/features.mis");
it doesn't help, because the engine wants an absolute path, as always, and none of the script between you and the engine at this point (stuff in the common missionLoad.cs and missionInfo.cs) has you covered. So expand it to a full pathname in this line itself:
createServer("SinglePlayer", expandFilename("~/data/missions/features.mis"));
Of course, in a real project, it would be better to avoid hardcoding the names of specific mission files at random places, but this is a demo.

Whoa, just realized I'm a little late - I'm sure you guys have solved an issue this simple by now, but maybe other forum denizens will find this response useful.

#12 Oh, just read some names and wanted to point out that I'm a newbie and if Ben thinks this is a bug, he's right. I just thought, in my limited experience, that ~ isn't being weird, it always needs to have expandFilename used on it, right?

#13 There are plenty of places where tilde is used without expandfilename, so I guess that can't be right. I'm no expert with TSE, but it seems like a bug, or inconsistent behaviour at the least. Whether you call inconsistent behaviour a bug or not depends on your programming philosophy. If it was my product, I'd clean it up for the users. But then, there are probably more important things to get done. Just thought I'd flag it on the "to do" list for some time in the future.

If I ever get to understand the product I'll fix it myself if it's not already done.

Cheers,

Dave.

#14 Reason to Windows Search not functioning properly is that you need to change a few registery keys for it to work. Most people know this already and it has been outlined in a thread before, I think.

I really don't understand why Microsoft did it this way, it's stupid.

Glad you guys figured the problem out, though. I always go trough the demos to make sure they are looking for relative paths and not hardcoded ones, I think it's good practice before I use them.

#15 Ok Dave, I've looked, and you have a good point. There are a lot of places where ~, . and .. are automatically replaced with full path info, the most prominent cases being in exec() calls. So it would be fair to call this inconsistent behavior, at least.

What's happened here is a change in the behavior of the FileObject class between TGE 1.4 and TSE. In TGE, the method openForRead() was willing to take a relative path as an argument, and expand it automatically. In TSE, you must pass an absolute path to openForRead() or it will fail to open the file. I haven't checked whether there was a corresponding change in behavior in openForWrite().

If you'd like to see an example of this behavior, place the following script code at the top of the file demo/main.cs under TGE and TSE and compare output:

$myFile = new FileObject();
$myFile.openForRead("~/data/missions/features.mis");
echo("Without expandFilename():" SPC $myFile.isEOF());
$myFile.close();
$myFile = new FileObject();
$myFile.openForRead(expandFilename("~/data/missions/features.mis"));
echo("With expandFilename():" SPC $myFile.isEOF());
$myFile.close();

Under TGE, you'll see:
Without expandFilename(): 0
With expandFilename(): 0

Under TSE, you'l see:
Without expandFilename(): 1
With expandFilename(): 0

It's up to the GarageGames guys to decide whether this change in behavior actually constitutes a bug.

#16 Samuel,

Thanks for that. Good bit of work. I'm with Stefan on the relative path thing. Hard coding anything is anathema to me. In fact I'd like to be able to configure any paths in a simple properties file rather than in scripts all over the place (Oh wait, that's given me an idea, need to think about it for a while). But at least consistent behaviour in all scripts and progs would be good. Still, as long as we know about it we can work around it for now, it's no big deal, but it would be good to see it "fixed".

Dave.