Track howto video

[NaN]

Atm the objects.txt is meant to replace list.txt(list.txt is ignored). I will add objects.txt generation to the importer/exporter soon. The include functionality is missing atm.

The list.txt is only there to stay compatible with the track editor.

[zimluura]

oh, i see.

you sure that it's best to have it not keep both? i had thought static track geometry would be in one file and shared/dynamic objects in another would be a good way to do it.

[bunny]

@NaN- I created my track again .Now No darkness.everything is ok.

[NaN]

@bunny: You don't have the old one anymore? There still has to be a bug somewhere.

@zimluura: Having to deal with two files with differing format per track? objects.txt already supports static objects. Half of the code in the loader duplicates this functionality for list.txt. Or do you mean you would prefer to have a separate file for shared objects generally?

[zimluura]

@nan: yeah, a separate file for the shared objects in general. i didn't know they were in different formats at the moment. i can see how you wouldn't want that.

my reasoning is: the static track geometry is generated from a script, while the shared objects must be typed in manually. i know it may not always be like that, but having that separation could still be useful in a couple of ways i can think of: shared objects could optionally be turned off to help debugging or to get a performance improvement on lower end machines. then again, i was thinking about using them for houses in the garage neighborhood which may be a bad idea.

[joevenzon]

the static track geometry is generated from a script, while the shared objects must be typed in manually.

I'm a little out of the loop on the most recent track development workflow, so take this comment with a grain of salt, but: wouldn't it be better to be able to have the shared objects also generated from a track editor / in-game editor / blender? Maybe that's already the plan, I dunno.

having that separation could still be useful in a couple of ways i can think of: shared objects could optionally be turned off to help debugging or to get a performance improvement on lower end machines.

Having them in the same file doesn't preclude doing debugging/LOD.

[bunny]

@NaN-sry for delay to reply .I hv saved my new track over the old track. :x

[zimluura]

@ joe, you're right. if everything can be placed in blender easily, through (append or link -> link) then it shouldn't really matter. but i'm still not 100% convinced that will be the best way to handle shared objects. it may increase the need to download large blend files full of the shared data to build a track or to import every object you want to use in your track, which can have the side affect of making shared objects less quick/easy to add to your track. so i'm not too much in favor of that approach.

the track_editor/in-game_editor maybe a good idea. but keeping them in a separate file could still be good for dealing with the blender export script. that way broader revisions could be done on the track geometry. perhaps building a large height-mapped country-side to replace the mountains in the skybox. without affecting the additions you've manually typed in the objects file. a smarter export script could work around it. but i would guess it would be easier to have it load from multiple files. bear in mind that almost all my programming experience is in c, so i'm mis-trustful of blender scripts because they're in pyth...some language that's not c.

[zimluura]

so, i've got a much better looking garage now on my system. but svn is being difficult. last thing i tried was: deleting my local garage/.svn
then: svn rm garage/ --force
then: svn add garage/

which seemed to give me some console text that looked like the new textures were getting added.

but when i try to check in i get this:
svn: Server sent unexpected return value (405 Method Not Allowed) in response to MKCOL request for '/svnroot/vdrift/!svn/wrk/87ed2879-eb37-4759-92ee-e1e65775174f/vdrift-data/tracks/garage'

hopefully i haven't broken anything.

[joevenzon]

Doh, I hate it when SVN gets all confused. The server seems fine, though. You probably shouldn't have manually removed the .svn folder. Can you try svn rm garage --force again, then update, then check in, THEN try to add?

[zimluura]

tried that, but i still get an error:

Server sent unexpected return value (405 Method Not Allowed) in response to MKCOL request for '/svnroot/vdrift/!svn/wrk/82e8249d-8293-43dd-a6a9-1f2962734ce0/vdrift-data/tracks/garage'

i'm glad i at least didn't mess up the network version.

hmmm, is there anyway to for me to force my data to be in perfect sync (i had thought svn up was supposed to do that) with the network copy? if i can copy the track to a different directory, and then get 100% re-synched i might be able to then add it and sucessfully (one file at a time maybe?).

i guess i could locally destroy the whole tracks directory and then re-download it. but that sounds like a waste of bandwidth.

perhaps there are pending server changes to the track directory garage/ and i should rename this to garage_residential/ ??
[/quote]

[zimluura]

saw that garage wasn't deleted from the trunk server. but it wasn't getting re-downloaded for me. nixed the tracks directory and re-downloaded them 2.8gb later i have it again. copied the garage files over and uploaded them.

[bunny]

width of the track depends on the width of Curve .But i see when we increase the width of the curve(DimX) , it mess up the mesh.So how can i increase the width of the track ?

[NaN]

Not sure what you mean. The width of the track depends on the length of the bevel curve/object used, in the video at least.