(the numbers don't always match up) 1. I'd like to see the skinning system overhauled. Now it is overly complicated for no real reason. Imho a skin should be just a folder where you can drop any kind of skin files and the game then automatically uses all those bits for the car. The veh file should be used to select upgrades and identify the skin as text (all the things there are now). Also forget wildcard textures. That is just unnecessary complication. So basically you have teams folder and under it you have folder for each skin. In that folder is the veh file. So for example we have a a car with these textures: tire.dds tire_specmap.dds tire_normalmap.dds wheel.dds wheel_specmap.dds wheel_normalmap.dds wing1.dds wing1_specmap.dds wing2.dds wing2_specmap.dds bumper1.dds bumper1_specmap.dds carbody.dds carbody_specmap.dds carbody_damage_normalmap.dds carbody_dirt.dds carbody_mixmap.dds cubemap.dds littlebits1.dds littlebits1_specmap.dds littlebits1_normalmap.dds littlebits2.dds littlebits2_normalmap.dds morelittlebits.dds And some more. So let's imagine with this folder system I want to create a skin for certain configuration of this car (base car + wing1). So to do that I just put all the files I want into the skin folder. ANY FILE I WANT. So for example I want to create carbon matte skin with wing1 texture and also I want to make the dash red and purple matte wheels. So I add these files to the folder: carbody_mixmap.dds carbody.dds carbody_specmap.dds wing1.dds wing1_specmap.dds littlebits1.dds wheel.dds wheel_specmap.dds The game then automatically replaces each texture from the car mod where identical skin name is found in the skin folder. The rest which are not in the skin folder come from the car maps folder. Skin makers just use the same texture names as the modder used. No need for some special hard to understand prefixes thrown into one folder with hundreds or thousands of files. It is how Ac does skinning and it easy, flexible and combined with the veh files in rf2 it is also very powerful system. To make this work with upgrades textures should be available to be chosen directly by name via veh files, in upgrades ini and with genstrings. 2. Fix/remove or at least document the way files need to be named to avoid conflicts between content packages - rf2 has tons and tons of requirements how to name or not to name gmts, textures, upgrades and materials. To figure these out is a massive pain in the ass for modders and takes months sometimes to troubleshoot - as many as possible of these limitations should be removed and be handled by the game internally. For example of two totally separate mods have same material name it should never result in conflicts, crashes and graphical glitches. The game should internally rename all the bits of the cars and tracks for example to guarantee these kind of issues can't occur. This should be high priority for modding platform. - Here is a list of some things I've noticed: Wildcard names can not be used as gmt names. Driver gmt names (all gmts???) need to be named differently for all content. Material names need to be individual as well. Even two skins can not share the same number. Instance names probably interfer with materials and gmts as well. All this should not happen. - this issue means people need to have several rf2 installations just to guarantee mods don't interfer - fixing these issues would allow all content to follow one good naming scheme. Not only would this make things better because modders don't need to spend months sarching for totally weird mismatches that are not even errors in their mod but just conflicts with other content... but it would also help 397 when all content would follow the same naming scheme. This would make it far easier to handle multiple pieces of content without having to worry about conflicts and mismatches 3. Make upgrades work from setup screen. Upgrades are extremely powerful system for managing car configurations but sometimes you need to use the upgrades for items that should be in car setup. The way I see it all the upgrades should be available in the setup that don't move the car from one class to other. This can be things such as different rear wings and aero configurations (unless certain type is specified), ackerman steering configurations, solid rear axle panhard bar locations, upper link chassis and axle side mountings. I'd really like this being pushed as far as it can go. One way to do this is to just create another tab for these upgrades and then allow modders define what upgrades are available in setup screen. 4. Try to get rid of menus that are only accessible through keyboard shortcuts. Forget driving aids in function buttons (F1 through F12). Use those numbers for basic stuff like going through menus, turning things on or off. And also in each menu that you can toggle while driving it should have a text that shows what button controls that small menu. For example fps hud that shpws your fps should have text ctrl-F near it that shows up when you hover your mouse over it. Same with virtual mirrors or whatever. Iracing does this really well. The user is given the information so he can focus on the job at hand instead of focusing trying to remember some obscure keyboard shortcut keys he last used month ago but now needs so he can finish the race. Ideally this could be a little control panel placed on the bottom left or right of the screen which contains buttons to open up these special windows. It makes the game much more accessible and better to use if you don't need to reconfigure and remember tens of keyboard shortcuts you only need rarely. 5. In devmode in the materials list all the materials should be listed alphabetically. Now they are in random order with track materials first and cars materials after that. Unnecessarily annoying trying to find that material you want to adjust. The materials should also be in two groups. One for track and one for car. Not everything in one big mess. Devmode also should load a car even if there is a problem with texture or gmt. Just ignore those gmts and textures and don't load them instead showing an error message and then loading the clio-thingy. Just give an error message about it and move on. And if there are several error messages then instead of barraging the user with tons of popups create a txt file where all the errors are listed if there are more than 3 errors for example. 6. Separate graphics options for replays. When I drive I want fps and smoothness. When watching replays I want it to look as good as it can. This is used when watching replay files. 7. Better cockpitinfo.ini: 6.1. More in-car lcd display options: Deltabar, delta numbers, last lap, best lap, optimal lap, toggleable lcd screens, g lat/long numbers, wheel locking indicator.... 6.1. Being able to use ttf fonts directly is amazing. But you can't change color (always white) and positioning seems to work differently than with bmp. At the very least being able to adjust font color would be nice. Although it would be nice if the bold, italic and underline where available too. 6.1. Rework the lcd text system slightly so text is not tied to shader's tga file nor that you need a small rectangle mesh for it. Better idea is to use the nulls or empties in 3d program for initial positioning. 6.2. Font positioning. There should be a way to finetune the position of the font from the ini file. Just like you can adjust the needle center points for analogic gauges. It should not require exporting the same mesh over and over until you get it right. It is much easier and faster to adjust it from ini file. This is also more economical way to do it as everybody can adjust a ini file but only very few can adjust it in 3d program (3dsmax, blender, 3dsimed). Also allow aligment for fonts. Left, right, up, down, center. Could look like this: SpeedFont=comicsans.ttf SpeedBackground=spd123 SpeedScale=(5.0,5.0) Color=ffffff Alignment: (left,center) //left/right/center laterally, up/center/down vertically. Positioning: (0.01, 0.0, -0.02, 5, 0) //(x,y,z,rotation around x, rotation around z) 6.3 More finer control. - It would be nice if we could adjust precision too. For example some cars use digital rpm lcd displays which show the rpms in 100s. For example 5500rpm is displayed as 550. It would also be nice if you could turn off or on whether empty numbers are shows (" 20"kmh or "20"kmh, notice the empty spot) 6.4 Allow more than one display per type. For example multiple analogic tachs.
part2: 8.3. Allow fonts to be used to write text. For example lcd dash could look like this: Code: FUEL: 5 L SPEED: 126 KMH RPM: 4555 LAP: 1:26.444 To create this in rf2 you now need to write all the text in the texture. It would be far simpler and look better too if you could just write and place all those pieces either as prefixes and suffixes or just as free text. Could work like this: Prefix/suffix style: SpeedFont=comicsans.ttf SpeedBackground=spd123 //mesh to use SpeedScale=(5.0,5.0) Color=ffffff Alignment=(left,center) //left/right/center laterally, up/center/down vertically. Positioning=(0.01, 0.0, -0.02, 5, 0) //(x,y,z,rotation around x, rotation around z) Prefix="SPEED " //adds text speed before the number value. Notice the empty space. Suffix=" KMH" //adds text KMH after the number value. Notice the empty space. Free positioning: Text01Font=comicsans.ttf Text01Background=spd123 //mesh to use Text01Scale=(5.0,5.0) Text01Color=ffffff Text01Alignment=(left,center) //left/right/center laterally, up/center/down vertically. Text01Positioning=(0.01, 0.0, -0.02, 5, 0) //(x,y,z,rotation around x, rotation around z) Text01="Kmh" You can add more of these Text02, Text03 and so forth. 6.4. Allow mipbias to be adjusted from ini file for lcd meshes so you don't need to export several times to get it right (slow and tedious). 6.5. Allow use of 3d models for gauge needles 9. Texture animations could be simplified a lot. It would be better if the numerical values were added in cockpitinfo for example (delays, type) and only shader-critical options are inside the gmt. For example brake lights could be defined mostly in gen file for example (isbrakelight=true, animstages=3) and then the user could simply create brakelight textures by adding 00, 01 and 02 after the texture name. A lot easier to adjust too when you can simply edit a text file instead of going through the whole process from 3dsoftware to edit, then export, then open and export from 3dsimed or gjed. 10. Make mirrors and brakelights damageable so they can drop off. Also add option for parts to hang on on the car after damage instead of just either being on the car or dropping off. A hood for example could open just slightly from a contact and needs a bigger impact before totally breaking away. 9. When driving if you press ESC the ffb should turn off and the game should pause if it is in single player. In online game the ffb at least should go away. 10. More options to create very specific faults or features in the car. These events would use a list of telemetry options as triggers and could then be assigned to control any part of the car. For example you could use lateral Gs to increase the gear ratios (an extreme idea!), create electronic diff or adjust torque vectoring based on Glat, Glon and rotation, wheelspeeds or dynamic wings that change position based on speed. Or create electric motor by adjusting power output based on gear. While this may sound unrealistic at first its flexibility allows huge potential to create any kind of car in rf2. From fully movable wings, active suspension electric hybrid drivetrain F1/lemans cars to baja truggies or rock crawlers with hydraulic suspension. Or cars with different gearboxes like koeniggsegg gearboxless drivetrain wtih torque converter, triptronics with unique characteristics, sexuental dogbox boxes, sequental syncromesh boxes). Cars where you can turn on or off awd, different driving modes for dampers and electronic aids...Headlight animations, dash animations... On text a simple feature could look like this: trigger -> effect and event=effect { // your functions go here } For example let's make a car with electronic dampers (just a simple example). Code: If latG>1.06<1.10; change1 event=change1 { GEN=<LATLIGHT>=latglight1.gmt // sport mode light turns on in cockpit(or off) HDVd=DamperBumpF=(1.22) // Front damper is changed dunamically with 1.1 multiplier HDVr=DamperBumpFRange=(4500,5800) // damper min and max range HDVd=DamperReboundF=(1.23) // Front damper is changed dunamically with 1.1 multiplier HDVr=DamperBumReboundFRange=(6500,9800) // damper min and max range HDVs=RideHeightF=60 //rideheight reduced HDVs=RideHeightR=80 //rideheight reduced } So at latG 1.06 the event is triggered. At this point all static values(HDVs) are changed to what is listed above. Static values is basically binary values. One or the other. Never betweeen the two. So this line basically means: If latG>1.06<1.10; change1 = when latG goes above 1.06 the trigger is triggered. So your rideheight is instantly changed to 60mm at front and 80mm rear. Realistically you'd probably want to use dynamic value for this though. Dynamic values(HDVd) come on linearly starting at 1.06g (1.0 multiplier) and are maxed at 1.10 (1.22 and 1.23 multipliers). So at 1.06g the front damper bump is at its default value and at 1.10g or higher the value is 1.22 x the default value AND within 4500-5800 range. The range is used to control the min and max values so even if you add tons of multipliers to single value that value will never go below or above the min and max limits. Obviously these limits need to be the same everywhere or mentioned just once. Also the first line below means that a light is turned on (.gmt mesh called <LATLIGHT> in .gen file is replaced) in the cockpit when latG is above 1.06. So in this case the suspension goes automatically into a sport mode when lateral Gs exceed 1.06 and so dampers are adjusted and a light turns on in cockpit. This also works with multiple triggers affecting few things. These are defined with HDVr. All these override other values. These could be expanded to time based events so a car for example goes into safe mode after hard impacts: Code: If latG>2.0<20; change1 if lonG>2.0<20; change1 if verG>2.0<20; change1 // we don't need the max value so we just put 20 there. In this case all three if clauses trigger the same event. event=change1 { GEN=<swarning>=safemode_light.gmt // car safe mode light turns on in cockpit(or off) HDVs=ThrottleRange=(0,0.5) // throttle pedal is limited for 0-50% travel to slow the car down TIMER=20 // timer function which basically means the effect stays on this long, 20 seconds in this case }
Other ideas like TIMER: - TOGGLE=action1 // rf2 could allow 10 buttons to be labelled as action0 to action9 which modders can use for whatever they want. Pressing this button triggers an event. This can be used to turn off things like car safemode or it can be used to turn on/off things like different suspension modes, turn wings to on or off, etc... - REFRESH=4 // give some control how often the if-loop needs to be run. For active suspension you want higher number and for other things you are happy with slower responce. This value is in hertz. So in this case it is 4 hertz so the loop is run 4 times per second. The purpose is to save fps and in some cases this allows to use same refresh rate as the real system you are simulating. - STEPS=4 // This allows you to use steps instead of linear multipliers. For example in the damper examples you could use STEPS=4 which means the HDVd value is changed in steps - TURNOFF=(SpringLF,0) // this is a trigger to permanently turn off a feature of the car. In this case front left spring of the car is turned off (broken). The 0 means the broken spring does not lock the system. If you used 1 the spring would not allow movement. - TURNON=(change1) // just like with turnoff but now you can turn on things. For example you can use this to turn on traction control at certain speeds. Only TURNON can turn on things that are turned off by turnoff. - BUFFER=(buffer1,0,100) // allows you to define a buffer that can be used for battery size for example. 0 is the minimum value and 100 is max. You can define these from buffer0 to buffer9 so you can simulate kers system with battery and capacitor. - READ=(change1) //make certain events readable so they can be used for lcd screens in cockpitinfo.ini - TABLE // as defined below. When you need finer control for HDVd you can use lookup tables. In the following cases you have input value,output value. So if your input is 1.1 then output is 1.02. Code: TABLE=table1 { 1.0,1; 1.05,1.01; 1.1,1.02; 1.15,1.05; 1.2,1.1; 1.25,1.3 } This kind of system could also be used for things like lcd displays. For example if you want the dash lcd screen to go into different mode when you turn pitlane limiter on you could do something like this: Code: If pitlimiter=1; change1 event=change1 { HDVs=Cockpitinfo=carx_Cockpitinfo_pitlimiter.ini } That loads separate pitlimiter cockpitinfo file which is configured for that. In reality that would be of course written differently in upgrades.ini but it is the idea that counts here. 12. Gjed 12.1. Allow user to choose which texture uses which uvmap. Or at least show which uvmap (show uvmap name or number: 0,1,2 or 3 for example) is used for which texture. This can lead to some performance benefit too if you can use just two different sized uvmap instead of 4 out of which 3 are identical. 12.2 Also allow users to define their own names for all UVs. Gjed can rename them on export for rf2 so no changes for rf2 engine is needed. For example for one material I'd want to use 3 uv maps: diffuse_nm, shine and tiled. From the names I can instantly see what they are for and can then assign them in gjed for correct textures. This of course assumes the shaders and gjed allow us to choose the uvmaps for each texture slot. Also this system should be optional. 0, 1, 2, 3 should be the default. And it should be automatic. Uvmaps should be always used in alphabetical order by default. So 0 is before 1 and "diffuse" is before "normalmap". 12.3 Grey out shader numbers/options that are not used in that shader. 12.4. Tooltips. Now you need to google almost every setting in gjed to know what it does. And in 70% cases you don't find any answers. Simple phrases for each and EVERY option should be provided. 12.5. Some numbers can be mathematically calculated. So make gjed calculate these numbers for you and show them next to the value you are editing. That way users can either choose to use that number or use something else they like. No need to do it manually. 12.6 Some parts of the gjed are buggy. Animations are pain to set up because gjed crashes a lot. Refreshing (reloading) a tga texture removes the texture from the shader instead of reloading it. Reloading a dds texture from a shader sometimes removes it from ALL shaders that use that texture. 12.7. Same rules for everything. Some things like lodin/lodout are sometimes set in gjed but for others those are set in gen files. Make it that lodin/lodout are always set in gjed. 12.8. Make .gmenv plaintext so it is editable with notedpad. Easier to make batch changes for example. Like changing some value for all meshes or materials is easy to do in notepad by using "replace" tool. In gjed you'd need to manually adjust them for each mesh. 12.9. Introduce new shaders with dx11. There are things that rf2 does very poorly that makes it look bad. Creating new shaders for dx11 for things like glass and environmental mapping would help a lot while maintaining backwards compatibility. Users can use old content which uses old shaders or they can update their content to use the newer shaders. 12.10 Created preset version of the shaders. This would basically create variations of the same shader with different starting values. You for example have T1xT2 Bump Spec Map. Now create duplicates of that shader like: - T1xT2 Bump Spec Map plastic - T1xT2 Bump Spec Map painted metal - T1xT2 Bump Spec Map rubber It is still the same shader but the shader basically starts with values that are suitable for plastic, metal or rubber material. 12.11. Fix the shader names so they all follow the same naming system. Now the naming is all over the place. 12.12 Write a guide to explain what the shader name stuff means. This stuff is not explained anywhere once again and google finds 0 nothing. What does add mean? What does mul mean? Vertex alpha, No shadows, stamp, alpha reflect, color reflect, greyscale reflect, lerp, mix, swap. 12.13 When changing from one shader to another gjed hides what the different texture slots are meant for (cubemap, bump, specularity, t1, t2 etc???). Different shaders also want different textures for different slots. Only way to know what kind of texture that shader wants is to exit gjed and open new project and select that same shader for a material that has no shader set for it. Super annoying when extremely crucial information like this is hidden away. And not only that but this information should be available all the time. Each slot should clearly say what is it for (spec map, bump map etc.) and what uvmap it uses. 12.14 Gjed needs to be restarted all the time to see some of the shader changes you are making. Maybe add "refresh scene" button that simply reloads the shaders without having to restart gjed? 12.15. Create simple track scene for cars in gjed which you can turn on/off to check environmental reflections when the car is sitting on piece of pavement 12.16. Not directly gjed related but make more of the shader settings changeable in devmode 12.17. Create a way to momentarily visually turn on and off instances in gjed. This would make it easier to set up lods in the beginning of the project when all objects are yet undefined (no lods or shaders set for example) and all are drawn on top of each other. By being able to turn on/off instances you can easily focus on working certain parts of the car without other parts being in the way. 12.18. It would be great if the .gmenv file would keep its mesh/object settings when using same gmenv for multiple fbx files. Now you need to setup things like turning decals on, lods and shadow settings each time from scratch when you load a different file. 12.19. It would be nice if 397 could share a sample .gmenv file with some basic material settings. Also if gmenv file worked better people could share them. 13. Create benchmarking tool in rf2. That way we can compare pc parts. And modders can compare their mod fps against 397/isi content. For example if you are getting less fps then your mod is heavier to run. It is also simple and fast and easy way to check you are on the ballpark with your mod. For this users need to be able to choose car mod and track and weather and have some kind of output that shows things like average fps, min/max fps etc... 14. Spinner screen: 14.1 Allow modders to remove class packages from being shown in the spinner options. As far as I understand these packages are generally meant for ai drivers so offering them to user is odd. 14.2 Some materials look different in spinner and in-game. This is a problem because some parts like glass in some cases for example need to be made separately (different shader settings) for spinner and in-game so both look the same. 13.3 Allow modders to create different spinner screens as mods. Make them selectable from the game menus or from the spinner. And give some documentation how it is done. 13.4 make devtools that are used to adjust shaders/weather/time of day/etc. available in the spinner. 13.5 In devmode the spinner should always reload the full car when you enter into the spinner ("tuning menu"). Full car being the spinner.gen, upgrades.ini, textures, shaders, meshes etc.. Now the spinner only loads it once and then reuses that until you load a different car and then load your car again. Or restart rf2. This (always reloading the model) would make it easier and faster to change textures and see how it looks in spinner inside the game
15. Skin viewer This doesn't mean a separate program. But if the spinner in the devmode had a way to reload textures it would work pretty well in windowed mode. Ideally it would have two buttons for reloading textures: - one button to reload all textures - one button to reload just wildcard textures (a lot faster) This way it would be easy and fast to create quality skins. The worse the preview feature for skins is in rf2 the more it restricts artistic freedom. For complex graphical skins a preview program is a must and would improve the graphical quality of rf2. 16. Car colliders 16.1 first 397 needs to make a tutorial how to make a collider. There is 0 information about this anywhere. An experienced modeller can make a collider because it seems to work the same as in ac for example. But a new player will have no idea (uvmaps, materials, amount of tris, triangulated or quads, special texture, what shader, what other settings, what gen parameters...). 16.2 it would be nice if cars could have colliders that you can turn off. For example if a formula car has a nosecone or front wing that can come off then the collider should change. You can try using the engine cover (lodef/high def engine) for this but it doesn't really work. The collider acts wonky. - other option is to have multiple separate colliders for each part. Currently in rf2 this creates a problem too because a separate nosecone collider for example doesn't work correctly. - an ideal system would be such where colliders can be turned off or switched so noseconeless car has its collider switched to noseconeless collider - the game should be improved so separate smaller colliders could be used for bumpers, nose cones etc.. 11. Move some of the basic animation stuff from 3d programs to ini files. Things like shift lights, brake lights and etc should not need anything in 3d software. The game should automatically turn things on like makerendertarget for these meshes. Again this would be more economical because everybody can edit ini files but very few can edit the models in 3d software. So if the 3d modeller is really busy he can leave this part for the person who does textures for example. For example shift lights should be simple couple of lines in cockpitinfo. Like this for example: Code: ShiftLight=shift_mesh //name of the mesh Brightness=50 //scale from 0-100 or 0-255 Color=ed2828 //color coding Blinking=7200,10 //at which rpm does it start to blink, at which frequency does it blink. The game can manually find the textures for these functions. For example if the shift_mesh has texture shiftlight_supergt.dds used for it then the shiftlight is naturally shiftlight_supergt01.dds. For brakelights you could have brakes_diffuse.dds and then for light 1 you have brakes_diffuse01.dds and for actual brakelights brakes_diffuse02.dds. Simpler that way. Let the machine do the tedious work for you. 17. Get rid of the gen files (for cars at least, I can't comment about tracks) - the gen files are unnecessary. All the numbers (lods, reflects, collides) in those files can be baked into the gmt files in gjed. And most already are... - parameters to add support for: lod levels (max, high, low etc), lodin/out, spinner-only.. all gen file parameters - upgrades are not an issue either because the user knows from the way the 3d model is built how and what the upgrade mesh gmt names are. - basically the system works like this. You set up all parameters of mesh and gen files in gjed. Then you export it. Gjed exports a folder or mas file that contains all the gmt files and a gen file. Same gen file is used for both spinner and game even though user has option to include/exclude certain parts to spinner view only. A car be multiple gen files so you can export your car in multiple parts from gjed. You just link all the gen files in your tech-veh. Basically if you wanted every gmt could have its own gen file. Not a sensical approach but why not. If combining multiple gen files slows down rf2 then make the devmode combined the gens automatically into a "master gen" named gen_full00.mas for example and write that into the tech-veh file. That file is then always check first when rf2 loads the car and if it doesn't exist then the individual gen files are used. When modders ship their mod they'll probably want to remove the individual gens and use the master gen instead but having the individual gens available during development is easier. - set up genstrings in gjed. Just add text the functionality for gjed to bake in gen strings names. A simple cell where you write the genstring is already enough for each gmt: genstring: [a] means the name of the gmt will be objecta.gmt which will respond to object<a>.gmt. - sadly gens can not be fully removed. You still need the searchpaths although this could be fixed with default folder structure or simply add the feature in gjed to define the paths - instances can be done in two ways. You either use nulls/empties in your 3d software and parent all the meshes under the correct nulls/empties. Or you create a simple topdown selection list in gjed where instances can be defined. Again there is a big boost in usability of the software when the game does the heavy lifting for you. No need to mess around with gen files at all! - veh files can use genstrings as they do now. - instead of bunch of gmt files gjed would now output mas files directly. After than the user only needs to create a small gen file which only defines the folder structure. It lists all the mas files and that's it. And each folder can have several of these small gen files. 18. Rework the veh files, file structure and checksum for better modding support 18.1 Separate veh files into two files and create editable folder structure to make skinning easier, simpler, faster and better - replace veh files with 2 files: tech-veh file and skin-veh file - tech-veh file contains the class list and upgrade info that changes the performance and graphics of the car classes. This file is placed with the physics files - there is one tech-veh file and each skin has their own skin-veh file - tech-veh defines all classes. Essentially tech-veh is a veh file without the skin specific parameters: driver names, numbers, genstrings. Skin genstrings are genstrings that are editable for skin-vehs. Tech genstring is the genstring for that class. - a tech veh basically reads like this: class: carA category: "carmod,carA" gen: genA.mas cockpitinfo: cockpitinfoA.ini cameras, hdv, sounds, headphysics, rcd listed here tech genstring: gax skin genstrings: 56 class: carB category: "carmod,carB" gen: genB.mas cockpitinfo: cockpitinfoA.ini cameras, hdv, sounds, headphysics, rcd listed here tech genstring: gbx skin genstrings: 45 - in this example we have two car classes. carA and carB. Each one gets its own folder for skins. - skin-veh is a file skin designers use for their skin. It has the car number, driver name, basic driver rcd info, team info, skin genstrings and class name - each skin is its own folder - each car should have skins folder where skins can be placed by just dragging and dropping. There should be no need to do anything inside the game for the skins to show up - car creator provides a basic skin-veh with all possible classes listed. Skin makers then copy this file into their skin folder and edit this file to add the driver names, numbers etc. - preferrably there would be a folder structure where one class of cars go in one folder and each skin is a sub folder there. That way it is clear for the skin designer as he can just drop the skin in the folder based on what class of car he wants to make a skin for without having to edit the skin-veh file manually to choose a class. 18.2 checksum - remove all but certain files from checksum testing. The car should only have one file called physics.mas which is checked. But a lot of the text files should not be in this file by default. SFX file should not be in it (to allow people to create sound mods), cam file should not be in it and rcd file should not be either so people can create ai mods as well. Also none of the gmt, dds or any 3d only files should not be tested for checksum unless those files are placed inside the physics.mas. - move car sound files and folders in the car folder. All cars should be self contained and simply removing the car folder should remove all car material from a computer. - physics.mas is my proposed default file naming system and by default the only file that is checksum tested. When making a mod users should have option to create additional physics files (physics00.mas, 01, 02 etc.) to avoid possible issues multicar mods using single folder. Mod creators can choose what files they want inside this file. It can be left empty or it can include all the files. - remove the limitation of only having one number is only once. If someone wants to create a mod with tens of skins with the number 13 for example then just let him. If user wants to have duplicate skin numbers then let him have it. If the user wants to limit it he can do it if he wants to as well.
