CSM stuff (brain goes boom)

Posted by ZaZ 
CSM stuff (brain goes boom)
Date: June 30, 2005 08:24AM
Posted by: ZaZ
Additions to the advanced docs of 1.25:

First let me start by saying that this doesn't work with build 31
It will work from next version, which will probably be build 35 (or higher if i find bugs)

What has changed?
Well, a lot :) But I'll start with the files.
The core of csm has seperated from the GUI.
Which means the the interface is a seperate program and people with little programming knowledge can write their own little tools to control CSM.
The core is now a console program and the output can be called with the use of pipes.
Next version will have the 'old' GUI as seen in build 31 because I couldn't find the time to finish the entire new GUI, but that will probably happen in the future :P
If someone wants to create a new GUI and needs some help, I'll be happy to answer questions :)

So what's changed underneath that isn't in the advanced docs?
I warn you... If you are done reading this, you probably grew a long beard.

I won't bother you with stuff like: "it's more safe", "has a better log" etc.. etc..
I have no idea in which order to tell it, so I'll just start whatever comes to mind first and then continue from there on. Most likely I'll forget to tell some things, too.

Inside the .CSM file:
Under the [General] section, these are undocumented keys.
This sets the title of a subset, instead of simply using the name of the file itself.
This overrides the default steering wheel picture. Simply point it to a new picture just like the preview picture of the mod.
It's not very useful, unless you include a steering wheel yourself, without letting the users choose for themselves.
Leave this key alone... CSM creates unique ID's for each subset and mod, which could be useful for automatic installation of mod upgrades, without having the user to choose the mod.
Leave this alone, too :P
Only erase this line when you are sure you have the right version/build of CSM and the mod is telling you you need a newer version.
A boolean setting to add a spacer in the subset list.
So it's possible to get something like


.... etc. in your subset list, when using multiple subsets.

There's a new [F1gstate] section.
For now it only supports to select a certain track when you load the mod.
use this key:
then simply add a number of the track you want to select.

In the [Files] section there are some new things as well.
Executes a file before the carset is loaded
Executes a file after the carset is loaded.
Executes a file before the carset is restored.
Executes a file after the carset is restored.

This can be useful when you want to extend CSM with your own stuff.
CSM will wait for the executed process to finish and then continues.

Pumps a DLL file into Gp4 so it can fully control gp4 from within. Like a file which makes certain new tweaks possible as: cars getting dirtier, tyres visually get worn, new faillures etc.

Points to a plain text file ("Settings\MergeINI.lst" by default) to temporarily merge ini files into other ini files
the format can be used like this:
<source ini file>,<destination ini file>
The base path of the source will be the data folder, and the base path of the destination file will be gp4's root folder.
Remember this is not an ini file. If you want to use several ini's to be merged, just add new lines in this file

It can be used to point to an unpacked anim.wad file (with original structure)
Not all files have to be in there btw. only the ones which should be updated into the anim.wad.
But there are other ways to acclompish this.

This one is not new, but has some new features.
Now it can point to multiple directories and/or ini files (comma seperated). And in those ini files don't have to contain info of all cars.
It's useful when you want to override some settings.
When pointed to a dir, it will automatically search for a file named "config.ini"
I'll try to get a little bit more specific how it works:
For example you have a config.ini with
and in another subset there's only 1 car different. Then you don't have to copy the whole file.
But just add something like
This prevents mod builders to make the same changes many times when maintaining their mods.
And if you are a creative person, you can do many more with this ;-) (like per-car ini's)
It will also automatically take care of GpXPatch settings when you use trackspecific mods.
And it can use the user variable system (again... I will describe it later)

See cars...

Still works like it did before, but has some extra stuff..
If the cockpit dir contains a subdirectory called "Cockpit", it will place those files into the cars/cockpits folder inside the wad
If the dir contrains a subdir called "Cars", it will place those files into the cars/ folder inside the wad.
This may help keeping your mod structured when it is necessary to place some files into certain folders. And you don't have to manually add those files through ini's
You can use this in combination with some new .cap (autopatch) files:
"DisableCockpitFolder.cap" to completely disable gp4 to use the cars/cockpits/ folder inside the wad.
then gp4 will search for those files inside the cars/ folder. but it will break the steering wheel selection inside CSM, because CSM will place some files in the cars/cockpits/ folder
Does the exactly same thing as described above, except it will still use the cars/cockpits/ folder for the steering wheel, thus keeping the CSM stwheel selection working.
Forces gp4 to use the cars/cockpits/ folder for all cockpit related files

Still works just like before, except you can point it to multiple dirs to combine parts of settings.
This one also works comma seperated.

Also comma seperated to use multiple paths.

See loadingscreens.

Idem dito

Idem dito

Idem dito and, CSM supports mp3. not all formats, but it should tell you what is wrong with your mp3 file when it doesn't work.
this only is interesting when you want to release a mod of your own. because CSM will convert the mp3 into a gp4-readable format and then the mp3 won't be there anymore.
the only reason i added this, is because it can reduce the size of a mod by many MB's

This can also point to multiple dirs and/or files. It will look for config.ini by default.
If no ini is specified then it will try to swap all gpi files keeping their original names.
If an ini is specified, it will do the exact same thing, and then start to read from the ini.
The structure of the ini is like this:
File1 to File22
File1 to File11
File1 to File11

There are also some minor things different in the [Settings] section

Also uses comma seperated files to support multiple swap files to be combined


Specify your global variables file ("Settings\Globalvars.ini" by default)
*I will describe global variables later

Leave this alone ;)

PFFFF! Now I need to smoke... just give me a sec.

Okidoki, all done :)

.Cmu updates
cmu updates can also use an install.script (which is a plain text file) and it should be located into the root folder of the mod.
It executes after the update is installed
It can use commands like:
copydir <source> <destination> (copies a dir)
movedir <source> <destination> (moves a dir)
removedir <source>[,<source>,<source>..] (removes a directory or multiple directories)
createdir <source>[,<source>,<source>..] (creates a directory or multiple directories)
copy <source>[,<source>,<source>..] <destination>[,<destination>,<destination>..] (copies a file or multiple files)
move <source>[,<source>,<source>..] <destination>[,<destination>,<destination>..] (moves a file or multiple files)
delete <source>[,<source>,<source>..] <destination>[,<destination>,<destination>..] deletes a file or multiple files)
extract <wadfile> <filetoextract>[,<filetoextract>,<filetoextract>..] <destination>[,<destination>,<destination>..] (extracts file(s) from a wad)
exec <file> (executes an executable file. can be useful in combination with a .bat file)

User variables
Finally :) This can make things look a bit complicated at first, but it's very powerful
Some people who looked at Tony's 2005 mod may have noticed this, but probably didn't fully understand.
So now I'm here trying to explain it.
It's possible to declare your own variables, which you can use in every ini file in the mod.
There are 2 kinds of variables. Global and Local.
Local overrule the Global variables if specified.

I'll take my time trying to explain this, because at first.. it will probably be a little bit confusing.
Imagine having a mod which should give you two options to switch between two different cars in the last slot.
then you can make an entire new subset by copying another one, or you can use variables for this.
So lets say you have a cars config file which looks like this:


and in the other subset you'll have this


Well now you can do it all with one config.
Add a section in your ini file called [vars]
And add something under that section called "MyFantasyCar" and give it the value "Prost", so it looks like this:
then change the 11th Dir to call a user variable. User variables are embraced by percentage characters btw.
It should look something like this:



So what happens?
Well, CSM finds that the mod calls a variable.
Then at first it will check if it is a local variable (always located in the file CSM is currently reading from)
If it can't find the declared variable then it will look if it is a global variable (located in your global ini file, and works exacly the same as a local ini file)
CSM finds your declared variable called "MyFantasyCar" and it contains the value "Prost"
So in simple; it will simply replace

You can even use it combined with 'hard' folders and files.
Imagine you want to be able to only set the resolution of a car.
You have the shape of your Prost car located in "Prost\" and a set of Hi-res textures in "Prost\hi\" and a set of low res textures in "Prost\lo\"
Take a look at this:



In this example it takes all files from the Prost folder (in this example the shape) and then looks what resolution textures it should be using (which is high)

Still with me? Lets take it a bit further..
We have 2 fantasy teams with both low res and hi res textures, and we want to have options to choose between both teams and both resolutions.
Then we can have a file looking like this



Now when you change the MyFantasyCar variable or the Resolution variable in the [Vars] section, it will change the car or texture-res.
If you want to achieve the exact same thing by using multiple subsets, you'll end up with 4 subsets for just this.
Imaging adding more customizations without user variables and you'll have to include an insame ammount of subsets.
Fortunatly, this is not necessary anymore :)
Local variables (as used above) are only useful for the mod creator. It can help you to easily maintain your files (think about a generic pitstands piece of code)
However, global vars can be accessed from the user.
To do that you'll have to Put the [vars] section with all variables into your global variable ini file.
Then create a new section in your global ini with the same name as the variable itself. This holds the variable's settings, and can contain the following keys:

A boolean setting which decides if a variable if configurable though the config menu.
The name the variable has in the config menu
The number of options for the variable
The variable itself
The name of the value of the variable in the config menu
A picture of a file to preview the variable
Comma seperated to tell it which other variables it should modify as well.
So if you switch this variable to it's second value, it will set those variables to its second value also.

All settings are optional and don't have to be used.
Now lets continue with the Prost/Arrows example..
Imagine having a nice picture of your prost car, and a nice picture of your Arrows car.
Then in your global ini file place this:


Name=Fantasy car
VarName1=Select prost
VarName2=Select Arrows


then in your cars config file you only have to have this:


Now the user can select which car to use and which resolution from the config, and you don't have to include subsets for each combination!
If you combine this with multiple car/helmet ini's you can do A LOT with it. Yet, it still could use something extra.
There's also a thing such as 'combined variables'
It can be quite confusing, but there's no excuse for more flexibility ;-)
I take you back to an earlier example, and demonstrate something which is totally useless:



Pay attention to the Dir10 line.
What it does, is that it resolves both variables, and because they are embraced by parenthesises, it will treat the 2 variables as a new variable.
The "Myfantasycar" variable contains Prost and the "Resolution" variable contains hi
So on the Dir10 line it resolves "Prosthi" and treats that as a variable itself! then it resolves that into "Ferrari"
Still with me? probably not. You might want to fiddle with it and read this 10 times over again.
And it gets even more complex :)
You now can add loops to keep your ini's as compact as possible
Loops are embraced by number signs.
Again... I will show an example which is useles, but i think a bit easier to understand



This will add MyFantasyCar (alias prost) and then adds Prost\Extrastuff (which is a loop from 1 to 3)
so CSM resolves it like this:
I can almost hear you think "when will this be useful?!"
Well, imagine keeping the current track number in a variable, and the Tracknames in other variables.



And you have a line like
then it will add the subdirs Melbourne to Hockenheim (hockenheim being boss)



And you have a line like
then it will add the subdirs Imola to Hockenheim (hockenheim being boss)

Last thing I can think of right now are the reserved variables. Don't worry... it's not hard and doesn't require much explanation
just a short list
%CarsetPath% (returns the carsetpath)
%CurCarsetPath% (returns the carsetpath of the current mod)
%Gp4Path% (returns the path where Gp4 is installed)
%DataPath% (returns the data path of the mod)
%BackupPath% (returns the path where all temp backup files will be stored)
%SettingsPath% (returns the settings path of the mod)
%Gp4Exe% (returns the path and filename of the users gp4 exe file)
%CSMPath% (returns the path where CSM is installed)

Don't get scared about CSM getting too complex. Users don't have to deal with this, and mod builders don't have to fully understand or use everything as well.
It's just when you need all this power, it's there :) else, don't use it.
In fact; CSM should be more user friendly in the future.
But that's up to the GUI.
And I wanted to write it down somewhere so i can look it up again if necessary :P

I'd rather have a bottle in front of me than a frontal lobotomy
Re: CSM stuff (brain goes boom)
Date: June 30, 2005 08:43AM
Posted by: Guimengo
I am left undone and separated :(
Re: CSM stuff (brain goes boom)
Date: June 30, 2005 08:57AM
Posted by: chet
Guimengo Wrote:
> I am left undone and separated


"Trulli was slowing down like he wanted to have a picnic" LOL
Re: CSM stuff (brain goes boom)
Date: June 30, 2005 09:11AM
Posted by: b-tone
super stuff ZaZ :):o:)

whens the exam - i got a feeling i can pass this one ;)


Re: CSM stuff (brain goes boom)
Date: June 30, 2005 08:06PM
Posted by: gpxcartworld
The Incredible Ronald is BACK!!! WOOOOOHOOOO!!!! :)
Impressive stuff, Ron! Yay! :)

Re: CSM stuff (brain goes boom)
Date: July 01, 2005 10:57AM
Posted by: Guimengo
So, am I done yet? ;)
Re: CSM stuff (brain goes boom)
Date: July 01, 2005 06:42PM
Posted by: _Erix_
OMG, am I supposed to read all this stuff to make a mod? ;)

Great work again Zazzie!

[1991] [2003] [2004] [gp2 world series]
Re: CSM stuff (brain goes boom)
Date: July 05, 2005 10:32PM
Posted by: Mini Maestro
will read this all later but thanks
Re: CSM stuff (brain goes boom)
Date: July 06, 2005 05:07AM
Posted by: Jagdpanzer
Has the new version been released yet?

"There are some pikeys there at Turn 10 putting tarmac down - what do you think of that?" - Martin Brundle
Re: CSM stuff (brain goes boom)
Date: July 09, 2005 06:17PM
Posted by: jonny
any news Zaz?

Sorry, only registered users may post in this forum.

Click here to login

Maintainer: mortal, stephan | Design: stephan, Lo2k | Moderatoren: mortal, Vader, stephan | Downloads: Lo2k | Supported by: Atlassian Experts Berlin | Forum Rules | Policy