Different surfaces?

[joevenzon]

slowDan, if you get to this before I do try to use either the CONFIGFILE class or the functions WriteObjectToFile and LoadObjectFromFileOrCreateDefault in joeserialize.h. The latter set are still a work in progress but will read/write a text format that looks roughly like this:

Code:

section
{
variable1 = value
variable2 = value
}

Although you have to set up the class of any object you want to serialise as a friend of serializer and add a serialize method as seen in the examples in joeserialize.cpp.

[slowDan]

slowDan, if you get to this before I do try to use either the CONFIGFILE class or the functions WriteObjectToFile and LoadObjectFromFileOrCreateDefault in joeserialize.h.

I went for the CONFIGFILE format in the end. Lots of ready made examples already in the code swung it for me!

I've added a surfaces.txt file to Rouen which shows the format so far. The game loads it, reads the values from it, and stores them as a vector of TRACKSURFACE structs.

This is where it gets a little complicated! To use the values in game I had to jump through a few hoops. The sounds and the wheel contact properties are still expecting to see a CARSURFACETYPE. This means that both need to exist until I can switch everything to the new arrangement. Which also means that we need a default surfaces.txt to use if a track doesn't supply one.

For now I wouldn't try adding any new surfaces to other tracks because if the two surface formats don't match strange things are likely to happen.

On the plus side I figure that this means that sound parameters can also be specified in the surfaces file and possibly (in future!) particle graphics as well. Also because its in the Config file format it uses names for each section as well as an ID number. :wink:

[joevenzon]

Did you check in the newer version of your surfaces.txt file? In data repo R426 the surfaces.txt file just says "New surfaces file."

[alex25]

great job with the new surfaces. but can we also get rid of the extraneous parameters in list.txt? there is the five now set in surfaces.txt and the driveable flag that has been dead for so long. this will probably break the other tracks but it will be more of an incentive to fix them as soon as possible. i'll fix my tracks (and the others i guess) once we slim down the list.txt file. i guess we'll need a delete parameter command as well in the track editor.

--alex--

[alex25]

I've added a surfaces.txt file to Rouen which shows the format so far. The game loads it, reads the values from it, and stores them as a vector of TRACKSURFACE structs.

the values you added for rouen don't correspond at all to the old values in list.txt. not only that but, for example there were two different grass surfaces corresponding to fldgrass.bmp.png and grass2a.bmp.png textures respectively. they had completely different parameters but you mapped them to one surface with new arbitrary coefficients. any particular reason for this? if you want to fuck up tracks please don't touch the ones that i worked on.

--alex--

[slowDan]

they had completely different parameters but you mapped them to one surface with new arbitrary coefficients. any particular reason for this?

Yes there is. As I said this is a work in progress so I'm trying lots of stuff out. It helps to have different values so I can easily tell which file the game is getting them from. Its also helpful to have lots of surfaces in one area so I can check that the sounds respond as expected without having to go too far.

There is still more work to be done before you can use this feature in anger, so I wouldn't recommend removing any parameters from the list files yet. When everything is safe to experiment with, I'll let you know.

In the meantime I reverted to the last version of the list file. All the data is still there.

[joevenzon]

Looks good; my only suggestion is instead of having ID=X in the surfaces.txt file and referencing the ID number in list.txt, just reference the surface name (asphalt, grass, etc) directly in the list.txt file.