rec.autos.simulators

Can anyone help me with this problem. In Sports Car GT a number of tracks
(not all) fail to load and crash me back to the desktop when I select
1024x768 mode. The error messages indicates a .bmp file failing to load even
though I know the file is there inside the .mas file. I tried a fresh
install to no avail. Any ideas?

Thanks,
Neil F.

Running at only 800x600 is the safest, though least satisfying,
solution.

I have an ATI All-in-Wonder RADEONI.  This issue occurs on about 6
tracks only (I think they were all done by the same guy.)  Chatham,
Sebring, Road Atlanta... I can look up the others if you need.

Alternate solution (works for all tracks except Sebring).

Get Ban Scene and extract all the track files. In /dat go into the
xxxx4.scn the file for the track -- make a copy -- then edit out the
anim code referring to the file you just got the cube error with
(flga, etc).

This doesn't work at Sebring (but does work with the Sebring99
add-on). I haven't been able to find anyone with a  fix for the
original Sebring.

--Morton

Morton's method works, but with one qualification.  The number at the
end of the filename, e.g. the 4 at the end of atln4.scn, represents the
track detail level.  The levels are 1=low, 2=med, 3=high, and 4=max.  So
if you are running at max track detail do what he said, but if you are
running at some other detail level use the number corresponding to the
detail level you are using.  I found that max track detail really hurt
my frame rate on some tracks, so I am running at med. detail level,
therefore to fix road atlanta I had to edit atln2.scn.  I still think
the real problem is in the .mas files themselves, but I haven't been
able to find it yet, so just use Morton's fix.

HTH,
Hal

Oh... I thought the number represented the resolution. Apologies and
thanks for the correction.

--Morton

I thought the number represented the resolution too, at first.  So since
I wasn't running at max detail edited the xxxx4.scn file failed to fix
the problem for me.  So I looked at the file and noticed that the files
set LOD levels for the different track shapes.  Played around with it a
little and confirmed that the numbers represent track detail level.

All of which confuses the picture more, I think.  I did confirm that the
only tracks which were having problems were ones which had AnimRuleName
entries in the .scn file.  But there does not appear to be anything in
the anim code that would be resolution dependent.  I also confirmed that
the named files are not missing, they are in the track .mas file right
where they belong.  But for some reason SCGT can't find them when it is
run at 1024x768.  The only thing I can think of is that maybe SCGT does
not allocate sufficient memory to load all of the graphics when run at
that resolution.  Do you know of a way to cause SCGT to allocate more
memory for itself?

Thanks,
Hal

"Morton Chalom"  wrote :

Thanks Morton. I'll give this a go. 800x600 just doesn't cut the mustard
these days. Looks like a rather major bug to have slipped through.

Neil F.

As you can see by my  other posts I get the dreaded Cube Error too.  I've
isolated the error to Chatham when using add-on cars.  It shows up in
800x600 too. Doesn't really bother me in that Chatham is a silly little
track but it ***s up seasons.  Is there a way to choose your tracks for
seasons?

Also, all the F1-2000 tracks CTD when I use my Touring Car Patch EXE, but
the same cars from the spcar EXE work perfectly.  Any known issues why this
would be?

TIA

I haven't had that exact problem, so I'm not sure how to fix it, but it
might help if you would tell me specifically what the error message is.
Does it say there is a missing file?  If so, what is the name of it?

Also I haven't tried a racing season yet so I am not sure how to set
that up.

Question: What video card are you using, please? I'm trying to find a
pattern.

Download & run BanScene to split the game into separate files. Then
(make a backup copy and) edit matrix.mc with the tracks you'd prefer.

Time Saving Hint: Register .mc with WordPad, also.

Sorry, I don't know anything about F1-2000 though.

--Morton

I *think* we'll find that it's a bug that is tied to newer video cards
(released after the game was released). What's your video card,
please?  I'm trying to find a pattern.

--Morton

Ah, thanks for finding that out (I hadn't checked).

Yep, I concur. And if you extract them, they look just fine.

Hmm, I don't know that but... seeing as you're doing well at the
analysis, could I send you in a new direction?  That is, why does the
Sebring track give an error when the animrule code is edited out? If
you could figure that out, we'd have a means to play at 1024x768 at
all tracks.

Possible hint: It can successfully be cut from Sebring99 (though I
don't know why).

Time saving hint: Register .scn with WordPad (or the editor of your
choice) in Windows.

--Morton

8x6 with a V5 and 4xfsaa is the bestest!
dave henrie

I have figured out how to make Sebring work, although it's not really a
fix, it's more like a work-around to your work-around.  ;o)   Apparently
if there is a texture named FLGA in the track file, and an AnimRuleName
named FLGA with 3 frames, it will look for bitmaps for each of the
frames as follows: FLGA00.BMP, FLGA01.BMP, and FLGA02.BMP.  Those are
the files that for some reason it can't load at 1024x768.  So when you
edited out the AnimRuleName, it now knows nothing about those files, and
just goes looking for a texture with the name FLGA.BMP.  There isn't one
in the sebamap.mas file, so it gets an error.  I found a FLGA.BMP in
some other .mas file (sorry, can't remember which one) and also copied
FLGB00.BMP to FLGB.BMP, since FLGB is the other AnimRuleName in the
Sebring scene file.  These two new bitmaps do not need to be packed back
into the .mas file, you can either leave them in the MAS directory or
the PATCH directory, either way they will be found.  Once you have done
that, Sebring will work, although you will now have unanimated flags all
over the track (not that you are likely to notice that after the first
lap!).

This compound error also happens with several other tracks, though not
in the dry condition.  I haven't tested them all yet, but Lime Rock Wet
for example is missing a cloud map.  So this fix may be helpful for
other tracks as well.

In case that was too confusing, or someone hasn't bothered to read this
whole thread, here is an all too brief summary of what you have to do to
get all tracks working at 1024x768:

1) Install "Ban scene.mas" (available at theuspits.com).
2) In the "dat" directory, open each of the scene files for the track
(xxxx1.scn, xxxx2.scn, etc.) and find the "AnimRuleName" code.
3) Note the name of the AnimRuleName for later use.
4) Comment out the AnimRuleName code (by putting "//" at the beginning
of the line), including the block of code in curly braces that follows
it.  I do not recommend deleting the code, as you might want it back
later if someone ever finds a real fix for this problem.
5) Check the track texture map .mas file (filename will be xxxymap.mas,
where xxx refers to the track and y refers to the track conditons) using
Maspuce (also available from the Pits) to ensure that it contains a
bitmap with the same name as the AnimRuleName that you commented out.
If it does, you are done.
6) If it doesn't then extract one of the animation frame bitmaps (e.g.
flga00.bmp for AnimRuleName of "flga") and rename the extracted file to
match the AnimRuleName (e.g. flga.bmp).  Place this file in either the
"patch" directory or the "mas" directory.
7) Oh yeah, don't forget to back up everything first!

The catch is that there are over 80 files that need to be edited, and I
still haven't figured out for sure how many bitmaps would have to be
created.  It would be much better to have a REAL fix for the problem.
As it is, the best I can recommend is that people only follow this
procedure on specific tracks that they have had a problem with, and only
on the detail level that they are actually using.  If I had more time, I
suppose I could zip up the missing bitmaps and create a program that
edits the files, but I don't, so I won't.  ;o)  Perhaps some young guy
with a lot of time on his hands could do that for us.  Anyway I would
much rather find a real fix.

Speaking of which, I wonder if this affects D3D only?  Does anyone using
Glide have this problem?  Maybe running a Glide wrapper would be a
better fix.

Regards,
Hal

I made one important mistake in the previous post.  Not all of the scene
files that have the AnimRuleName code in them will fail when the
corresponding track is played at 1024x768.  So my comment about needing
to change over 80 files is incorrect.  Just change the ones for which
you get an error, otherwise don't worry about it.

Oh Cool!  WELL DONE Haqsau!!  

I'll confirm this works on my system too and then we'll have a way to
play at 1024x768 everywhere! Thanks!

--Morton