http://www.mircx.com/cgi-bin/forum.cgi?forum=Tracked
collected and (very little) formatted by addie walti
The start of a thread is on top right below the title
GP3 Freez after clicking
Pit crew disappeared
Tracks menu?? (17 tracks?)
Blue Jam (transparency)
jam file problem
Jip lenght limit?
Texture mapping on road
Unk Jam Flags?
split times (shifting them)
Posted by David Schneider from 62.202.82.207:
Hello
I`m making my own Track, but after clicking on the "Drive"-Button GP3 freez.
I checked the Troubles Shooter at addies Homepage, but nothing helps. So can anybody
help me? Maybe you have more chance. I can also send you the Track file.
Thanx and bye David Schneider
Posted by Speedee from 202.22.162.176:
Hi David,
If the track you made is shorter than the track that was originally in the slot,
then the Bump Table data(not in track file) may be wrong.
Duplicate Pit Commands will cause this.
Missing Pit Parking area command.
Duplicate scenery commands.
A bad CC-line possibly (try removing).
My best suggestion is:
1. Backup your track file.
2. Remove CC-line & test.
3. Check Pit Commands.
4. Start deleting things & testing till it works.
When it does finally work, restore your original file & change whatever it was
that finally got the track to load.
Send me the file if you like, but I may not get a chance to look at it straight away.
Regards....
Speedee
Posted by Maverick from 209.88.143.115:
Hi speedee. My track freez also, and is shorter, so how i fix the problem of bump
table?
Posted by Speedee from 202.22.162.132:
Hi Maverick,
You need to get hold of the Cmagic data editor.
Open your track file, Create Magic Data file from exe.
Open the newly created magicXX.md file in a text editor & remove the Bump Table
entries that are past the length of your track. Save the file.
Select the magic data file in the Cmagic editor, Click Insert magic data into track
file.
Now use GPXpatch to use your track reading the magic data in it instead of the data
in the exe.
Happy Racing....
Speedee
Posted by Maverick from 200.41.109.40:
Thanks man!
I'll make that!
Posted by PP from 213.116.154.214:
It freez also with my track but if I remove the cc-line, it works, how come?
Posted by Speedee from 202.22.162.183:
Hi,
If you modify the Line (sometimes even the height) of the track, then the CC line
gets off-line enough for the track to refuse to load.
It is allways best to leave the CC line till last when creating a new track because
of this.
Once you have finished modifying your track, then add the CCline as normal.
Regards....
Speedee
Posted by Luigi Campastri from 212.171.91.139:
At a certain stage of the development of my track the pit crews had disappeared from
the pits .Pit crews of single teams appear instead by time to time in certain locations
along the track.
I did not realized this immediately, so I'm not able to reproduce the situation that
could have caused this happening (maybe importing/removing objects).
Sanity check is OK , pit crew object is still in object definitions,I compared also
with a previous version of the track , everything seems OK,including pit commands.
Could anyone help ?
Posted by Slick from 195.121.116.152:
I had this once also,but it was on a test-basis so I got rid of the trackfile immediatly...
The pitcrew replaces the trackmarshalls...
Really don't know what does this,anyone?
Marcel.
Posted by Speedee from 202.22.162.183:
This will fix it....
You must have deleted an object definition that was before the Pit Crew definition.
This changes the object ID Offset. The Pit Crew should be Offset 64.
The rule I discovered is "Do not delete any Object Definitions that are before
the Pit Crew.
Cheers.....
Speedee
Posted by Luigi Campastri from 212.171.91.168:
Thanks Speedee,
it was really as you said:removing an object caused pitcrew ID offset to shift from
64 to 48.
That's worth knowing!
Many thanks again,
Luigi
Posted by Dav from 204.101.17.99:
Hi, everybody!
The original version of the game has 16 track choose menu,
do I have some chance to change it to 17 races or download new track menu?
Thank you in advance.
Posted by Augusto Dewey from 24.232.1.223:
Wait for the add-on Gp32000, you will have 17 tracks there
Posted by Kev C from 213.1.179.17:
I need more jams with the light blue
back ground colour. When I grab one from another track it no longer retains the see
through
ability. can this be fixed?
Posted by John Verheijen from 213.17.87.103:
Yes this can,
but you have to do it in a Hex Editor.
But if you don't know how it works, I don't suggest to do that.
That light bleu is used for the tranparancy part of the Jam.
And you must set the transparancy flag, so that the light blue becomes transparent.
John Verheijen
Posted by Kev C from 194.207.89.156:
Hi John thanks I will have a go. I do have an old hex editor program. Wish me luck
!
Has any one done a guide on this ?
Thanks again .love your tracks keep it up.
Kev C
Posted by Kev C from 62.7.50.77:
John
Would it be the location the jam file is stored in that is going to have the value
0x00 changed to 0x08 in the main program?. Or is it the jam file thats changed?.
The jam I wish to change is in silverstone jam id 860 ox35c
(00 256 64)
Posted by John Verheijen from 213.17.88.57:
Kev
Right after the TextureID 860 (5c03) you find the flag for the transparency flag.
You are right if you change it from 00 to 08.
The when you use the ligth bleu color this becomes tranparent.
John
Posted by Kev C from 213.122.72.105:
Thanks John I take it that its in the sil3jam and its the banners.jam I am going
to edit.As thats what I am looking at at the moment?
Thanks Kev C.
Posted by Kev C from 62.7.64.41:
Thanks very much John
860 0x35c
---------
5c03 00
to
5c03 08
WORKS OK!! THANKS
Kev C.
Posted by John Verheijen from 213.17.88.79:
:-)
John
Posted by addie from 194.191.82.27:
btw you also could use a slightly different light blue to conserve it when the transparent
flag is set ...
but its a good thing to know how to switch the transparent flag anyway in the hw-jams
and i'm very glad john spotted the flag in the jam-header and described here how
to switch it !
thanks
addie
Posted by Andrew Smart from 195.92.168.165:
when i go to insert a new jam file or an object it always says that it cannot find
the jam file. for some reason it is looking a gp2 location that looks something like
this c:\gp2\\gp3jams etc. why is this? please help
Posted by addie from 194.191.82.27:
maybe you missed to set the gp3-location ?
menu "options / gp3.exe location"
Posted by Hernán from 200.16.157.47:
Hi,
I want to insert two white lines that go all the track lenght on the road surface
Monterrey CART) but when i insert a value around over 600 in arg2 cmd:0xe8 GP3 falls
back to windows desktop, the track lenght is about 713 units. I try more 0xe8 cmds
with a smaller value in arg2 but it also falls back to windows desktop when it goes
over 600 in total.
What can i do?
Posted by James Knopp from 195.92.194.18:
Use the latest GPXPatch and have a look at the log that's made when GP3 crashes (that's
what it was put there for, so you can check what happens before GP3 crashes). You
should get some info from there.
James
Posted by Hernan from 200.16.157.47:
Thanks, That works great, it seems that a2 couldn't be over 1000 track+pits.
Hernan.
Posted by SDI from 194.109.166.235:
You got this message from GPxPatch? :
"Mapping jip onto track surface (cmd 0xe8) Total number of repeats (a2) = 1000."
If so, cool, seems to work then :)
Posted by Hernán from 200.16.157.47:
Hi again,
Is it possible texture mapping 0xe9 onto the road surface, like monza with a darker
tarmac in the chicanes, i try with 0xe9 but i doesn't work, the texture gets kind
of mixed with the original one.
Any ideas?
From one slot to another(+jams)
Posted by Kev C from 213.1.146.95:
Hi all
I started with Silverstone as a base track but as time went on and the track got
shorter I had to move to another slot to get it to run.That slot is No12,however
my jams are all made with the sil/ extension location.Question how can I tell the
track to look in the new track folder(NEW TRACK) etc to find my jams.
Thanks Kev C.
Posted by Speedee from 202.22.162.210:
Hi Kev,
There should be no need to do anything.
The reference to the jam file location is stored in the track file.
Cheers...
Speedee
Posted by addie from 194.191.82.27:
confirmed.
but if you have custom made jams you may want to put them in a custom dir ...
make this for hardware and software mode by using the same subdir-name.
in the trackfile you can change the reference easily by rightclicking the jam in
the tree and choosing "rename jam file". just be sure to ALWAYS choose
the software jam there. gp3 will make the proper choice then depending on the gfx-mode.
addie
Posted by James Knopp from 195.92.194.12:
Just been doing a little looking around and even though GP3 has hardware support,
not all of the textures have been filtered (to stop looking 'blocky' and basically
blurs the texture a little). Looking at the track data, there doesn't seem to be
any unk flags when specifying textures so the best look is in the jams.
What seems to be happening, jams that are filtered have a 4352 value of flags. Those
that don't usually have a random number. This really doesn't help things :\
I've started a list of textures that are and are not filtered, if you would like
to forward some, plz do so :)
Could you send the format as so:
JamName | TexID | Flag Value
Cheers
James
Posted by James Knopp from 195.92.194.18:
It turns out that the jams filtering is defined in the jam's header, and can be turned
on and off. To be on, 4352 can be used, and to be off, use something like 4360. The
only way is to hex edit the textures.
To see what happens, open bar_ads2.jam goto 0x0000001C (0011) and edit it to 4360
(0811). Look closely at the advert and you'll see once edited, it looks blockier
than before.
James
Posted by John Verheijen from 213.17.86.177:
James,
the part that you found is to set the transparency flag.
4352 is no transparent 4360 is transparent.
John Verheijen
Posted by addie from 194.191.82.27:
so the transparent-flag seems to b a multipurpose-flag ?
Posted by James Knopp from 195.92.194.15:
Ok fair enough, but it does effect the graphic's quality ;)
http://gp3ed.f1-grandprix3.net/images/screenshots/jameditor/gpx_0005.jpg - Filtered
http://gp3ed.f1-grandprix3.net/images/screenshots/jameditor/gpx_0003.jpg - Unfiltered.
Are these flags in the HW jams, the same in SW jams?
Another value which causes no filtering is 4096. I'm not convinced that the HW flags
are the same in SW - there must be some new ones and functions around.
Anyway, best be off to school ;)
James
Posted by John Verheijen from 213.17.88.136:
I think I will look this weekend at that part of the flag.
Maybe we can find more about this part.
John Verheijen
Posted by James Knopp from 195.92.194.12:
It looks like what might happen is that filtering doesn't occur when another flag
is set (e.g. the transparency flag). There are a number of flags causing this to
happen I think and we need to indentify them.
My best guess for no filtering in the transparency area is due to filtering causing
some graphical bugs? Ever notice that when a sprite is filtered, on close inspection,
the edges are softened?
Posted by James from 195.92.194.18:
Util out now to edit this flag. Get it here.
http://gp3ed.f1-grandprix3.net/jameditor/
Posted by SDI from 194.109.167.183:
I've hacked a bit in the gp3 code and I managed to filter the fences, but not the
trees and stuff. This was hardcoded set to point filtering.
Posted by James Knopp from 195.92.194.19:
Well done rene :) Is there any other info you've found concerning the filtering?
Is there anything pointing to certain commands or flags in the jam files?
James
Posted by SDI from 194.109.164.105:
I'm only seeing compares with numbers like 3c0, 345, 2eb, 2f0, etc. Maybe those are
jam id's?
Posted by addie from 194.191.82.27:
hardcoded jam-ids could be gravel and tarmac to force the well known special behaviour
...
$3c0 is decimal 960 which is the id of the texture with the spectators which has
a very special (astonishing, if you ask me) behaviour. the other three ids i could
not localize in a minute.
rene, could you post the complete list or is it too long ?
addie
Posted by addie from 194.191.82.27:
yes i was refering to that one, and the astonishing part is the way the lines “stand
up” if you approach the stands in the game. and another special property is the several
choices the game makes depending on the wheather and the race type. there are at
least three different textures with id 960 and the game makes its choice.
as for the other ids, maybe a look at the “reserved-ids”-primer compiled by john
verheijen may give more ideas: http://www.grandprix3.ch/TEIC/primer/resTexIds.htm
addie
Posted by SDI from 194.109.165.197:
The id's are a bit spread over the code, and each id has special code for it. Thanks
John and Addie for the list of reserved id's. I think it it will help me understand
the code better. I haven't been into jams until now though, everything is new for
me :) I only know that hw jams are 16-bit, sw jams 8 bit, and that they have a different
transparency color.
I'll see if I can compile a list of these special id's in the code.
Posted by SDI from 194.109.169.30:
I'm afraid all special id's are used in the code. I found that in one case the bilinear
filtering and specular was enabled when bit 3 (flag value 8) was not set at offset
20 of some structure (probably a jam texture header or something?). The total size
seems to be 32, and at offset 18 was the jam id.
I don't know what the jam file format is, couldn't find it on the net (the link http://gp3ed.f1-grandprix3.net/jameditor/jaminfo/hardware/index.shtml
doesn't work...).
Posted by addie from 194.191.82.27:
SDI, i recall one detail of the (hardware)-jamheader where you could bring in some
light maybe: garrenT, author of gp3jammer mentioned there are two different sizes
of jamheaders, or i should better say texture-headers (as a jam-file includes several
textures most of the time, and in the file you find the headers of all textures first,
then the textures themselfes. but those texture-headers seem to have two different
sizes and as garrenT noted its difficult to identify the switch for this).
HOW does gp3 recognize the size of a texture-header ? (or maybe this is already old
news to james or anybody ?)
2nd, SDI, in case you see “hard-coded” texture-Ids that are not in the list of reserved
ids could you post them ?
Posted by James Knopp from 195.92.194.14:
Addie: yeah, the function there is quite a simple one. What is used is planes, and
they in there as a form of detailed modelling to allow more speed in GP3. There must
be some code to bring these planes in (but that's another story ;))...
JE is able to get the header size when opening the jam... I'll need to check on what
I do to get it though. I'll post something later.
SDI: I'll have to get that page up and running asap. If you would like to forward
any or all of your info to be put on the page, please email me it and I'll post the
info asap.
To all: GarrenT might be able to shed some light on these issues. He sent me an excel
document of each jam header, so I'll see whether he'll allow me to post it on the
net at some point.
Any specular lighting is likely to be just found in the texture headers of the car
textures (only texture I've seen where any shininess is used, perhaps something we
might want to use in other textures such as barriers). I've seen though that there
is a texture for specular lighting for the armco in the GP3JamsH/TechJam/ folder.
Anyway, I'll make a start on the HW jam info, and any info you would like to add
to it, please email us ;)
Posted by SDI from 194.109.168.209:
Here's a list of jam id's that I found in gp3.exe. There could be more, but I think
this is most of it. I've added a ? behind it if I didn't find it in John's list.
BTW, can someone explain me the jam header format and texture formats?
256
288
747
752
753
756
757
761
762
764
765
767
768 ?
787 ?
799 ?
802
803
804
805 ?
806 ?
807 ?
808 ?
809 ?
818 ?
823
827 ?
828
830 ?
831
835
837
960
977
1000 ?
1015 ?
1016
1020
1024 ?
1039 ?
1040 ... 1055 ?
1056 ... 1067 ?
1068 ?
1100
1102
1108
1118
1280
1728 ?
1741 ?
1745 ?
1749 ?
1753 ?
1759 ?
1760 ?
Posted by John Verheijen from 213.17.88.164:
The JamId's 1000....1015 are for the horizon.
You will see them in every track.
Maybe James can give you some info about the header.
The texture formats are also in the header.
Maybe I can fill in some gaps.
John Verheijen
Posted by James Knopp from 195.92.194.16:
The header goes as follows:
File Header: 8 bytes
Image Header(s): variable
Canvas Data: variable.
The File Header
------------------
key?: always in 16bit jams & is 4 bytes.
num_tex: the number of textures in the jam & is 2 bytes.
Canvas_Height: height of canvas (obvious). Need need to go into canvas width as it's
always 256 pixels. 2 bytes.
The Canvas Data
---------------------
Working out the canvas data is something that should be done first to figure out
other details of the image header...
Here's some info from GarrenT
"The image data contained in the Jam file is 16 bit, stored in a 5:6:5 format,
with blue occupying the the upper 5 bits, green the middle six, and red the lower
5. The Canvas Data is run length encoded. Each RLE block begins with a counter byte,
which I'll call C. If C 128 (ie. bit 7 is zero), then the word of image data that
follows it must be repeated C times, and the length of that block is 3 bytes. If
C = 128 (ie. bit 7 is one), then (C-128) words of image data follow, and the length
of that block is 1 + 2 * (C-128) bytes. This is why 16 bit Jam files are much smaller
than their 8 bit counterparts. This was a clue as to how the data was stored. This
is also why, when using GP3 Jammer, edited Jams are different sizes to their originals."
Image Headers
----------------------
The image header is called for the number of textures there are in the jam. So if
there were 7 textures, you will see 7 sections of data relating to the Image Header.
To find out where it is add up the lengths of all the Image Headers and add 8 (the
size of the File Header).
I'll now turn to more information supplied by Mr GarrenT
"If you are devising your own method, I would also perform these checks, on
all Jams Sure it may look like it works, I found that out. But if you haven't got
exactly the right amount of data being extracted, you could end up with at best a
few glitches at the start of your image, or at worst, causing GP3 to throw a memory
exception by overrunning the end of an allocated image buffer.
There are four important bytes within each Image Header that allow you to determine
its length. The diagram below represents these bytes :
A B C D
D is the last byte in the header and always contains the value 32. But its position,
as with the positions of A, B and C are all variable. I have figured out the positions
of other fields, such as the offset into the canvas of the image, width, height,
whether or not it has transparency, etc, but whilst most seem to fit, there are others
that don't. Some fields seem to change their size and position at a whim. Anyway...
So we have A, B, C and D. Their offsets from the beginning of the Image Header we'll
call PosA, PosB, PosC, and PosD.
To find PosA, run through the header until you find the word 0xFFFF. PosA is the
position of the first 0xFF. Then,
PosB = PosA + 6
PosC = PosA + 9
The value of B will be either 2, 3 or 4. One Jam (Landscap.Jam) has a value of 0
for B. Since its the only one, I left it. I couldn't be bothered figuring it out,
since its only a generic grass texture. Maybe someone else will. Having determined
B, then
PosD = PosB + 9 - (B - 2) * 2
In the majority of cases, PosD is now at the end of the header and D = 32. Sometimes
though, its not, and there's an extra zero before it. So keep moving PosD forward
until you hit a value of 32. Now PosD is definately at the end of the header and
you can calculate its length. Do this for each Image Header, add all their lengths
up, and you can find the position of the start of the Canvas Data.
You may have noticed we haven't used value C at all. We will now. This bit caused
me a right headache. If the Canvas Data starts with a non-repeating block (ie. the
counter byte = 128), then this counter value is omitted from the beginning of the
Canvas Data, and the Canvas Data is 1 byte shorter than it should be. Obviously we
need this counter value to decode the Canvas Data, so where is it? Its in the value
of C (and B) for the very last Image Header (or the first if there's only one). What's
in the value of C for the other Image Headers I don't know. We'll define a new value,
E, where :
E = C + B - 5 (last Image Header only)
If E = 128 then the first RLE block in the Canvas Data is repeating, and nothing
needs to be done - decode the Canvas Data as normal. However, if E 128 then E becomes
the missing counter for the non-repeating block. Jesus!!!!
Once you know how to decode the image, its easy to substitute another one into it.
The File Header and the Image Headers all remain the same (except for one value -
yep, you guessed it, the value of C for the last Image Header), so just RLE encode
the new image and stick it on the end of the headers. Obviously the overall size
of the file will change.
What I decided to do about the value of C for the last Image Header was to fuck it.
Even if the image begins with a non-repeating block, I include its counter at the
beginning, and ensure that the calculated value of E always equals 128. I do this
by setting the value of C for the last Image Header to 128 + (5 - B). It seems to
work just fine and dandy."
Anyway, I hope this will help you... thanks to GarrenT for sending me a lot of info,
since without it, I wouldn't have been able to get my head around things a little
quicker ;)
James
Posted by SDI from 194.109.169.129:
Ok, I've found the hw jam reader. I saw it determines the size by:
P = pointer to jam file buf
S = P + 4
t = num textures (at S)
h = canvas height (at S+2)
size = 6 + 32 * (16 * h + t)
it allocates new buffer of this size in which it copies file buf (excluding 4-byte
id):
loop {
n = next byte.
copy (n-0x80) words if n = 0x80, or n times the next word if n 0x80.
}
Seems less complex than what you posted, but maybe I'm missing something.
Posted by SDI from 194.109.171.188:
This might be a stupid question but here it goes: are you RLE decoding the image
headers or not? If you do you simply get the all the headers with length 32. All
this hacking with bytes A, B, C and D is a non-issue as far as I can see.
Simple, or not? :)
Posted by SDI from 194.109.168.214:
I've got some new id's (tagged with '!').
146 !
256
288
289 +team_nr*3 !
679 !
747
752
753
756
757
761
762
764
765
767
768 ?
787 ?
799 ?
800 !
802
803
804
805 ?
806 ?
807 ?
808 ?
809 ?
818 ?
820 !
823
827 ?
828
830 ?
831
832 !
833 !
835
837
843 !
845 !
848 !
849 !
908 !
960
977
1000 ?
1015 ?
1016
1020
1024 ?
1039 ?
1040 ... 1055 ?
1056 ... 1067 ?
1068 ?
1085 !
1086 !
1087 !
1088 !
1100
1101 !
1102
1108
1118
1280
1728 ?
1729 ?!
1730 ?!
1731 ?!
1732 ?!
1733 ?!
1734 ?!
1735 ?!
1736 ?!
1737 ?!
1738 ?!
1739 ?!
1740 ?!
1741 ?
1745 ?
1749 ?
1753 ?
1759 ?
1760 ?
Posted by John Verheijen from 213.17.87.28:
Rene, can you tell me which track you did use for this?
This way I can update the used JamID's list.
John Verheijen
Posted by James Knopp from 195.92.67.65:
Are we any further with flag values in HW jams? I'm having next to no joy unfortuantly
:(
James
Posted by SDI from 194.109.169.138:
This wasn't for a specific track, they are simply used in gp3.exe.
I haven't looked into the jam headers, because I'm not getting any clarity about
what's known or not known. I even get the wrong information :)
Posted by luca from 212.171.158.73:
how can i change the split time positions in created and default tracks?
thanks
Posted by SDI from 194.109.171.249:
By editing the GP3INFO split tags in the track editor, and then using GPxPatch.
end of list