Camera mocement code
by arteria3d · in Torque Game Engine · 12/22/2004 (7:17 am) · 67 replies
Which script actually contains the movement code for the camera - i.e. when keys are pressed it moves the camera. I want to know this as i wish to have a go at implementing some swim code, and i will need to use this camera move code to be able to do this. I have looked in camera.cs but i cannot see commands such as 'if w key pressed. then move camera..... etc.
Also how would i disable the editor functions in my finished game?? i.e. All the F functions?
Okay i may want the game to have an editor, but i want to know how i disable stuff like this
Cheers
Steve
Also how would i disable the editor functions in my finished game?? i.e. All the F functions?
Okay i may want the game to have an editor, but i want to know how i disable stuff like this
Cheers
Steve
About the author
Owner of uk based Ltd company ArteriaMediaLtd. with a trading name of Arteria3d Website;arteria3d.com
#2
i.e. if key(w) pressed then move up... etc etc
Also a main thing where i am confused with TGE is this....
When all the movement code, etc etc is already written how do my scripts actually override, some of the details contained in them.
In Db Pro my movement code could be as follows, which would only allow movement within the stated X and Z boundaries. ( i do find it odd that tge has its Z value for its up value - every other app uses Y!!)
SO the line would be:
if keystate(w) = 1 and x>-1000 or x<2000 then move camera up
not actually hard db pro code as such, but pseudo of how it would be written
This now stops the player moving out of those x positions - i.e. makes a boundary set where the player cant move out of. In torque how would i do similar. The player boundary scenarios i have seen on the forumns dont meet this simple process i wish to do.
In general how do scripts interact with hard written TGE code - i.e. if i make a swim routine, to allow free movement within the water, i would in db pro use the GET TERRAIN HEIGHT, and use this to determine if the player is below a particular height he is in fact swimming. Whilst below this height the player is not glued to the terrain floor, but can essentially have free movement, up, down, etc etc in accordance with the position of the camera that it is facing.
In general i know in my head how i shuld go about coding such things as swim code, player boundaries, but because of the lack of documentation on every single script command, it is very diffucult to learn at a competent level.
There is loads of TGE docs, but none on the pure basics, of how TGE interacts with scirpts and how they work to maybe overide fucntions already there, etc etc
I hope someone can understand my comments and maybe help - especially in understanding the simple commands of the camera. What is it that acutally hard code the movement - cos i would then be able to add some simple logic like in DB PRO, to allow only movement within certain bounds
Steve
12/22/2004 (9:51 am)
I looked in there but it doesnt contain much info at all. Is there not a script that is actually writen as fololwsi.e. if key(w) pressed then move up... etc etc
Also a main thing where i am confused with TGE is this....
When all the movement code, etc etc is already written how do my scripts actually override, some of the details contained in them.
In Db Pro my movement code could be as follows, which would only allow movement within the stated X and Z boundaries. ( i do find it odd that tge has its Z value for its up value - every other app uses Y!!)
SO the line would be:
if keystate(w) = 1 and x>-1000 or x<2000 then move camera up
not actually hard db pro code as such, but pseudo of how it would be written
This now stops the player moving out of those x positions - i.e. makes a boundary set where the player cant move out of. In torque how would i do similar. The player boundary scenarios i have seen on the forumns dont meet this simple process i wish to do.
In general how do scripts interact with hard written TGE code - i.e. if i make a swim routine, to allow free movement within the water, i would in db pro use the GET TERRAIN HEIGHT, and use this to determine if the player is below a particular height he is in fact swimming. Whilst below this height the player is not glued to the terrain floor, but can essentially have free movement, up, down, etc etc in accordance with the position of the camera that it is facing.
In general i know in my head how i shuld go about coding such things as swim code, player boundaries, but because of the lack of documentation on every single script command, it is very diffucult to learn at a competent level.
There is loads of TGE docs, but none on the pure basics, of how TGE interacts with scirpts and how they work to maybe overide fucntions already there, etc etc
I hope someone can understand my comments and maybe help - especially in understanding the simple commands of the camera. What is it that acutally hard code the movement - cos i would then be able to add some simple logic like in DB PRO, to allow only movement within certain bounds
Steve
#3
1) Get Ken Finney's book, and do the exercises in it from start to finish. It's the best way for someone with your type of experience to become acclimated to TGE.
2) Get an editor program (such as UltraEdit for example) that lets you search within a group of files. For example, if you look in config.cs, you see things like:
MoveMap.bind--search for MoveMap.bind in files, both script and code, and you will find how it works and what it does.
For each of the mapped keys, the reason for the .bind command is to assign a function (or two depending on how it's used) that will be executed when that key is pressed. Search for those functions in your files, and they will show you what is executed!
3) Become very proficient at "deskchecking", or manually stepping through code. Inheritence based languages such as C++, and indirectly Torque script (while it isn't inheritence based directly, it uses a lot of the same concepts) make this somewhat harder because many different functions in the inheritence tree can be called due to one "event", but if you take TGE in very small bites and figure out exactly what is happening (which is a big part of what the book will help you with) is the only real way to learn about, and then master something as function rich and, well, big, as TGE.
P.S.: I think some of your "I'm lost" issue is due to the fact that TGE is inherently not designed to let you make simple games simply. It's designed to allow for the most feature rich and modifiable development environment possible. For example, based on your comment about how to do movement bounds checks easily in DB, that's because it appears that mission bounds are the major boundary in DB games. Not so in TGE, at all. mission bounds are really simple numbers used by the engine in laying things out. "bounds" in TGE are handled by setting up your mission area in 3-D so that players simply can't move with the physics you provide outside of the area you want them in. The reason for that is that:
1) What if you don't want a world that is bounded by anything? The old Tribes game for example didn't have bounds (as far as I am aware)--the terrain repeated endlessly, and you could go pretty much as far as you wanted.
2) What if your player objects don't even have a physical location in space? Card games for example don't care about a "players x location", nor do games like an RTS where there isn't a "player" at all, but a set of units, buildings, and a map to play in.
12/22/2004 (10:09 am)
I would highly suggest that you do two things Stevie:1) Get Ken Finney's book, and do the exercises in it from start to finish. It's the best way for someone with your type of experience to become acclimated to TGE.
2) Get an editor program (such as UltraEdit for example) that lets you search within a group of files. For example, if you look in config.cs, you see things like:
MoveMap.bind--search for MoveMap.bind in files, both script and code, and you will find how it works and what it does.
For each of the mapped keys, the reason for the .bind command is to assign a function (or two depending on how it's used) that will be executed when that key is pressed. Search for those functions in your files, and they will show you what is executed!
3) Become very proficient at "deskchecking", or manually stepping through code. Inheritence based languages such as C++, and indirectly Torque script (while it isn't inheritence based directly, it uses a lot of the same concepts) make this somewhat harder because many different functions in the inheritence tree can be called due to one "event", but if you take TGE in very small bites and figure out exactly what is happening (which is a big part of what the book will help you with) is the only real way to learn about, and then master something as function rich and, well, big, as TGE.
P.S.: I think some of your "I'm lost" issue is due to the fact that TGE is inherently not designed to let you make simple games simply. It's designed to allow for the most feature rich and modifiable development environment possible. For example, based on your comment about how to do movement bounds checks easily in DB, that's because it appears that mission bounds are the major boundary in DB games. Not so in TGE, at all. mission bounds are really simple numbers used by the engine in laying things out. "bounds" in TGE are handled by setting up your mission area in 3-D so that players simply can't move with the physics you provide outside of the area you want them in. The reason for that is that:
1) What if you don't want a world that is bounded by anything? The old Tribes game for example didn't have bounds (as far as I am aware)--the terrain repeated endlessly, and you could go pretty much as far as you wanted.
2) What if your player objects don't even have a physical location in space? Card games for example don't care about a "players x location", nor do games like an RTS where there isn't a "player" at all, but a set of units, buildings, and a map to play in.
#4
From what you have said, programming in Torque is very different from programming in DarkBasic.
You mentioned swimming in DarkBasic. In DarkBasic, you know whether you are swimming based on how high you are (your statement, I never used DarkBasic). In Torque, there's no way that would work because there is no standard waterlevel. Imagine an above ground swimming pool. One person can be outside the pool (standing) at height 0 while another person can be in the pool (swimming) at height 2. Torque allows you to define waterblocks of arbitrary shape. If you wanted to check if a player was swimming, you would have to check if he was in one of these waterblocks. This is a much more flexible system, but of course it's also more complicated.
12/22/2004 (1:31 pm)
@StevieFrom what you have said, programming in Torque is very different from programming in DarkBasic.
You mentioned swimming in DarkBasic. In DarkBasic, you know whether you are swimming based on how high you are (your statement, I never used DarkBasic). In Torque, there's no way that would work because there is no standard waterlevel. Imagine an above ground swimming pool. One person can be outside the pool (standing) at height 0 while another person can be in the pool (swimming) at height 2. Torque allows you to define waterblocks of arbitrary shape. If you wanted to check if a player was swimming, you would have to check if he was in one of these waterblocks. This is a much more flexible system, but of course it's also more complicated.
#5
I could make a simple calculation, based on my own parameters. So i could check for the terrain z height, and then make my own assumptions, so that i could determine that the water height will be 90 - there fore if the player's z height goes below that i make my code realise that the player is underwater. If he is on the surface, of the water then i glue the player to the water height. If for example the player is near the water-edge and hiz z terrain height is just a few metres away(virtually) from the terrain shore then the player walks again - exactly like in games like Farcry - my swim code was exactly like that. Correct there is no set water height in torque, neither is there in DB PRO - but what i am saying based on the water height on the terrain, i can do a multitude of get terrain height calculations at the player's coord. As torque uses a terrain height command, surely it would be simple to do some similar coding - but i would need to hardwire this into the general movement code.
Also as to the mission area. Againi in db pro - nothing is hardwired. I mean in affect in db prro - nothing is done already for you like torque!! Everuthing has to be coded - its just that it is BASIC and easier to get to grips with. A simple test to keep the player within the mission or game area is to attach limits on the x and Y coords actually in the player movement code as already indicated.
I have got the Ken Finney Book - maybe i should just completely plow my way through this book and see where i am at, at the end.
Steve
12/22/2004 (2:46 pm)
No - u get me wrong Eric - maybe its the way i explained it. In dark basic u dont even have a water block - u make ur own. All i am saying say i put my waterblock to the x, z position of 400,400 with a z value of 90.I could make a simple calculation, based on my own parameters. So i could check for the terrain z height, and then make my own assumptions, so that i could determine that the water height will be 90 - there fore if the player's z height goes below that i make my code realise that the player is underwater. If he is on the surface, of the water then i glue the player to the water height. If for example the player is near the water-edge and hiz z terrain height is just a few metres away(virtually) from the terrain shore then the player walks again - exactly like in games like Farcry - my swim code was exactly like that. Correct there is no set water height in torque, neither is there in DB PRO - but what i am saying based on the water height on the terrain, i can do a multitude of get terrain height calculations at the player's coord. As torque uses a terrain height command, surely it would be simple to do some similar coding - but i would need to hardwire this into the general movement code.
Also as to the mission area. Againi in db pro - nothing is hardwired. I mean in affect in db prro - nothing is done already for you like torque!! Everuthing has to be coded - its just that it is BASIC and easier to get to grips with. A simple test to keep the player within the mission or game area is to attach limits on the x and Y coords actually in the player movement code as already indicated.
I have got the Ken Finney Book - maybe i should just completely plow my way through this book and see where i am at, at the end.
Steve
#6
If you're excited and comfortable with how DB does things, then maybe that's the way you should go--not every tool, nor every engine is for everyone.
12/22/2004 (8:31 pm)
Man, I don't know what to say, really. TGE isn't going to hand you things on a platter--it's too powerful for that. If you're excited and comfortable with how DB does things, then maybe that's the way you should go--not every tool, nor every engine is for everyone.
#7
I would suggest looking at the movementmanager code and the camera code...
Look at the Advanced Camera Resources' code. That should give you a general idea how the camera works
12/22/2004 (10:28 pm)
Like Zepp said... It's not that simple...I would suggest looking at the movementmanager code and the camera code...
Look at the Advanced Camera Resources' code. That should give you a general idea how the camera works
#8
Steve
12/23/2004 (1:37 am)
Stephen neither does DB PRO!!. I cam here becasue DB PRO lacks performance, but really my swim code was quite intricatate. I think again u have misinterpreted my points. I have no asumption and never have that TGE will hand me on a plater. I mean ironically it does hand me more on a plate than any other platform!!!!!! as DB Pro doesnt have physics, doesnt have anything built in and no editor. So in affect, i am more in realm of 'doesnt hand it on a plate' with db pro than TGE, cos TGE has more features as standard, i.e. foilage rep, LOD, camera movement that stays to the terrain, and moves over objects accoridingly, without flying in the air!! (have u ever tried to code that yourself.... man.... try it in db pro or blitz, its a nightmare) - so what i am saying - is that TGE is slightly more easier than the other platforms on the outset - cos it has tons built in. I just find it diffiult addressing the things i need to program in, cos of a lack of a good script guide.Steve
#9
Torque script guide
Read this, the whole thing. It is easy reading and gives you basic idea of how Torque works.
Script help file
This one is the first place I look when I'm trying to figure out how something works or how to do something new. It is a bit lacking in details and explanations, but it tends to point me in the right direction.
Torque source guide
Will help you to understand/navigate the c++ source, and you will need to do that (see next reference)
Torque source code
When all else fails (and it does surprisingly often) check the source code. Everything you could possibly want to know about TGE is in there. Found a script command in the script help file? Can't figure out what it does? Find where it is defined in the c++ source. Look for where the command is exported, then backtrack to its original definition. You are an SDK owner, so you can do this :)
Forums
Guess you already knew about this one :) This is what makes it all bearable. However bad the docs are, you're not alone. There are people here who are more experienced with Torque and can point you in the right direction.
12/23/2004 (1:30 pm)
Yes, documentation is probably one of TGE's biggest weaknesses. It is always getting expanded, changed, improved in various way very quickly, and the documentation just doesn't keep up. Here are some of the references I use:Torque script guide
Read this, the whole thing. It is easy reading and gives you basic idea of how Torque works.
Script help file
This one is the first place I look when I'm trying to figure out how something works or how to do something new. It is a bit lacking in details and explanations, but it tends to point me in the right direction.
Torque source guide
Will help you to understand/navigate the c++ source, and you will need to do that (see next reference)
Torque source code
When all else fails (and it does surprisingly often) check the source code. Everything you could possibly want to know about TGE is in there. Found a script command in the script help file? Can't figure out what it does? Find where it is defined in the c++ source. Look for where the command is exported, then backtrack to its original definition. You are an SDK owner, so you can do this :)
Forums
Guess you already knew about this one :) This is what makes it all bearable. However bad the docs are, you're not alone. There are people here who are more experienced with Torque and can point you in the right direction.
#10
It's not set up to give you cookbook approaches to do whatever you want. It is however set up to give you the information you need if/when you look where you need to look, and use the copious amount of examples, including the code itself to accomplish what you want.
To many people jump right to the forums asking questions they could answer themselves if they just spent some time with the code!
12/23/2004 (2:49 pm)
I frown upon calling it a weakness--people just need to be willing to spend the time to actually read it.It's not set up to give you cookbook approaches to do whatever you want. It is however set up to give you the information you need if/when you look where you need to look, and use the copious amount of examples, including the code itself to accomplish what you want.
To many people jump right to the forums asking questions they could answer themselves if they just spent some time with the code!
#11
Even those docs listed above are not very well explained...
We need one manual, with a full listing of all script commands - listing how they are used, and the info each command needs.
Like the one i need to use to find the terrain height - isnt it strange that i cannot find a listing for a similar command anyway at all, not even in the docs - then just by chanse i do find that TGE has a Get.terrain height command.
It seems ludicrous that there are tons of commands that are not listed anywhere - and it seems trial and error and a hunting scenario are needed to find them. Okay, this product might be aimed at the higher end user, not the users initially who approach the likes of blitz and db pro - but please - everybody could do with a proper script guide.
Steve
12/23/2004 (2:53 pm)
But it is its weakness.....Even those docs listed above are not very well explained...
We need one manual, with a full listing of all script commands - listing how they are used, and the info each command needs.
Like the one i need to use to find the terrain height - isnt it strange that i cannot find a listing for a similar command anyway at all, not even in the docs - then just by chanse i do find that TGE has a Get.terrain height command.
It seems ludicrous that there are tons of commands that are not listed anywhere - and it seems trial and error and a hunting scenario are needed to find them. Okay, this product might be aimed at the higher end user, not the users initially who approach the likes of blitz and db pro - but please - everybody could do with a proper script guide.
Steve
#12
I won't give up on Torque though. It's hard to learn, but the power is well worth it. Besides, searching through the engine source is kinda fun :)
12/23/2004 (2:58 pm)
A good script guide would be nice. Being able to search the forums would also be nice (as in Google style, not going through a category thread by thread). I used BlitzBasic before this, and it was very good in both respects. I won't give up on Torque though. It's hard to learn, but the power is well worth it. Besides, searching through the engine source is kinda fun :)
#13
hey remember that nice guide for all the commands u got with blitz - thats the sort of thing we need here.
I find myself constantly frustrtaed - because like u say, the search engine on here aint that good, and the docs arnt too! From doing blitz and db pro i fundamentally have the no-how, how to aproach things here, but i need a good guide to reference commands too.
Eric seems like you and me both need this bad!!
Steve
12/23/2004 (3:01 pm)
Hi Blitz User!!!hey remember that nice guide for all the commands u got with blitz - thats the sort of thing we need here.
I find myself constantly frustrtaed - because like u say, the search engine on here aint that good, and the docs arnt too! From doing blitz and db pro i fundamentally have the no-how, how to aproach things here, but i need a good guide to reference commands too.
Eric seems like you and me both need this bad!!
Steve
#14
My team spent a combined total of 14 personnel months researching the codebase by tracing through how all aspects of the engine worked to the best of our ability before we even tried to implement any serious functionality.
there are over 1600 pages of documentation, not to include a complete visual inheritence tree that at least marks every single class method in the code. Sure, some of them don't have exact details of what they accomplish and why, but that's what source code is for--look at the function in the source files, and figure out what it does.
Edit: Something tells me that you haven't ever looked at this: Graphical Class Heirarchy/Inheritance Tree.
12/23/2004 (3:01 pm)
Then SEARCH for them man. They are in the code. You have the code base itself, and torque is just not designed to be it's most effective for people that simply want to cherry pick this and that function.My team spent a combined total of 14 personnel months researching the codebase by tracing through how all aspects of the engine worked to the best of our ability before we even tried to implement any serious functionality.
there are over 1600 pages of documentation, not to include a complete visual inheritence tree that at least marks every single class method in the code. Sure, some of them don't have exact details of what they accomplish and why, but that's what source code is for--look at the function in the source files, and figure out what it does.
Edit: Something tells me that you haven't ever looked at this: Graphical Class Heirarchy/Inheritance Tree.
#15
'and why, but that\\\'s what source code is for--look at the function in the
source files, and figure out what it does.'
No your wrong. What people dont seem to get here - okay torque is a pro based engine - but one that is sold via this website to anyone and anybody who wants to attempt at learning how to make a game.
Its not just for the elite - and so no way..... we shouldnt have to 'just' look through all the code to understand how something works. Granted i do, do that, and its very beneficial to do so -but not the grounding for how an engine like this should be presented to the user. There should be a good guide... Time and time again i here people saying , look, look at the engine - but a new user needs more than that!!. Should a new user, not aproach torque then?
I ask u this..... which is basically the same analogy. Should we buy complex rpg games like everquest, morrowind, never winter nights etc - without the manuals??? Should it just be so, that we have to wade through the game in the dark looking for how to do this, how to do that.....
Completally difernt matter i know, but the same reasoning as what ur describing.
Steve
This is prooving a nice healthy debate... so far!
12/23/2004 (3:10 pm)
Stephen, i am surprised - with this comment'and why, but that\\\'s what source code is for--look at the function in the
source files, and figure out what it does.'
No your wrong. What people dont seem to get here - okay torque is a pro based engine - but one that is sold via this website to anyone and anybody who wants to attempt at learning how to make a game.
Its not just for the elite - and so no way..... we shouldnt have to 'just' look through all the code to understand how something works. Granted i do, do that, and its very beneficial to do so -but not the grounding for how an engine like this should be presented to the user. There should be a good guide... Time and time again i here people saying , look, look at the engine - but a new user needs more than that!!. Should a new user, not aproach torque then?
I ask u this..... which is basically the same analogy. Should we buy complex rpg games like everquest, morrowind, never winter nights etc - without the manuals??? Should it just be so, that we have to wade through the game in the dark looking for how to do this, how to do that.....
Completally difernt matter i know, but the same reasoning as what ur describing.
Steve
This is prooving a nice healthy debate... so far!
#16
What's frustrating for me from my perspective is that many people are told exactly where to look, what to trace, how to understand what happens, yet they continue to ask for it in a format that is different from the information that is already provided.
Show me one complex game, or even one other engine that provides 1600+ pages of documentation, not to mention almost 5 years of examples, resources, techniques, and demonstrations.
12/23/2004 (3:13 pm)
Have you even looked at the link I gave?What's frustrating for me from my perspective is that many people are told exactly where to look, what to trace, how to understand what happens, yet they continue to ask for it in a format that is different from the information that is already provided.
Quote:
I ask u this..... which is basically the same analogy. Should we buy complex rpg games like everquest, morrowind, never winter nights etc - without the manuals??? Should it just be so, that we have to wade through the game in the dark looking for how to do this, how to do that.....
Show me one complex game, or even one other engine that provides 1600+ pages of documentation, not to mention almost 5 years of examples, resources, techniques, and demonstrations.
#17
Are you willing to pay the (hypothetical number, I have no idea how much it would really cost just to break even for GG) extra $1,000 per user for that?
12/23/2004 (3:15 pm)
P.S.: It would take nearly 3 more man-years to provide the level of script/code documentation detail that you are asking for, in the format you are asking for.Are you willing to pay the (hypothetical number, I have no idea how much it would really cost just to break even for GG) extra $1,000 per user for that?
#18
3 years.... so the blitz guide or db pro guide took 3 years... What do u think i am asking for.
I have the db pro guide right in front of me. It is only 200 approx pages long. But contains a full listing of all commands - and a brief outline of its use and vars it needs to be used.
Wht would that take 3 years. I aint asking for a complete program for each script listing
12/23/2004 (3:20 pm)
Man - why are u getting so defencive again... i thought we had got over this!3 years.... so the blitz guide or db pro guide took 3 years... What do u think i am asking for.
I have the db pro guide right in front of me. It is only 200 approx pages long. But contains a full listing of all commands - and a brief outline of its use and vars it needs to be used.
Wht would that take 3 years. I aint asking for a complete program for each script listing
#19
Fixing the website is a far more reasonable goal though.
1)Have you tried the various search bars on this website? They return a list of results, but the results have no relation to what you asked for.
2)My profile says I have recommended (link) 6 resources. Seems like a nice feature, keeping track of my favorite resources. Clicking on the link shows me a list of resources that I never indicated an interest in. Shouldn't it show the 6 that I rated highly?
3)I don't think the forums have a search feature at all.
As for a comprehensive guide and making Torque user friendly for people that are totally new to game programming... no. That's what beginner languages like Blitz and GameStudio are for. New game developers can get their feet wet with those and come to Torque when they're ready. Torque caters to developers who have learned the basics and are ready for something more powerful. You can't do everything, so let the newbie engines cater to the newbies.
Quote: This is proving a nice healthy debate... so far!
I disagree. The topic interests me. I think everyone involved is offering interesting ideas. On the other hand, I get the impression that Stephen is starting to get a bit angry. Also, we have strayed from the original topic of camera motion. I will not be posting to this thread again.
12/23/2004 (3:38 pm)
Providing the same detail and organization of documentation that Blitz has would take a huge (and unreasonable) amount of effort because Torque has a lot more stuff that would need documenting.Fixing the website is a far more reasonable goal though.
1)Have you tried the various search bars on this website? They return a list of results, but the results have no relation to what you asked for.
2)My profile says I have recommended (link) 6 resources. Seems like a nice feature, keeping track of my favorite resources. Clicking on the link shows me a list of resources that I never indicated an interest in. Shouldn't it show the 6 that I rated highly?
3)I don't think the forums have a search feature at all.
As for a comprehensive guide and making Torque user friendly for people that are totally new to game programming... no. That's what beginner languages like Blitz and GameStudio are for. New game developers can get their feet wet with those and come to Torque when they're ready. Torque caters to developers who have learned the basics and are ready for something more powerful. You can't do everything, so let the newbie engines cater to the newbies.
Quote: This is proving a nice healthy debate... so far!
I disagree. The topic interests me. I think everyone involved is offering interesting ideas. On the other hand, I get the impression that Stephen is starting to get a bit angry. Also, we have strayed from the original topic of camera motion. I will not be posting to this thread again.
#20
12/27/2004 (1:25 pm)
The forums have a quite nice search feature 
Torque Owner Eric Lavigne