File Types and Progression Map

[E-man-25]

Common File Types

    *The CSV Type: also known as comma-separated values, works as an object and route file , its use as an object is optional
    *The CFG Type: a 'configuration' file or short for CFG works as 2 image-displayed 2D cab types specifically named 'panel.cfg' and 'panel2.cfg' (panel is an outdated type use panel2 instead) , 1 sound type specifically named 'sound.cfg' and 1 "train-assembling" file specifically named 'extensions.cfg'

Unique File Types

    *The B3D Type: B3D is the equivalent of the object CSV file type , however , the syntax of B3D is simpler and has easier readability than the CSV file type.
    *The ANIMATED Type: The ANIMATED type is a one-of-a-kind object file with the role of adding functionality to your creations with very high freedom , ANIMATED has very strong potential to totally revolutionize openBVE's limitations in functionality
    *The DAT Type: DAT or "Train Data" Files allow you to set or define a train's physics , default motor sounds and other characteristics, Train Data Files only work if specifically named "train.dat"
    *The TE Type: Intermediate 'TE' Files are only used to store train data to be used with TrainEditor2.

Special File Types

    *The XML Type: Extensible Markup Language 'XML' files are currently working as 1 Image-Displayed 2D Cab type specifically named 'panel.xml', 1 sound type specifically named 'sound.xml' , and various other secondary features . It is not recommended to work with XML as a beginner, please refer to the default CFG cab and sound types.

    *Directly Supported foreign object types: .s , .x , .l3dobj , .obj

Progression Map

-The progression map allows you to visualize how to start, execute and finish it! now that you have acknowledged some of the pre-development process, this is a basic idea of development progression throughout as a whole:

Pre-Development Process
1. Brainstorming: What do you want to create? is it fictional? is it based off of real life? is it as a joke or is it serious well-made work? This should be the first thing you need to worry about
2. Developing an order: At this stage , you should be thinking about maing your plans , to-do lists , goals , milestones , agenda , annotations , etc.
3. 'Hunting and Gathering': This phase consists of performing the necessary observations , the making and gathering of textures (NOTE: there is absolutely no problem in making stylized textures froms scratch as long as they are accurate and made appropiately) , obtaining datasheets , scaled drawings,getting crew members and coming to an agreement for the roles, etc.

Development Process
1.Modeling: the first step in the development process is modeling it , construct it from the ground up , then apply the textures, or you can apply the textures as you go , usually applying textures(taken by photo) as you go can give you advantages such as telling you if the object/component is to spec depending on the texture's scaling.
2.Post-Modeling: after the major construction work is done, you have to clean it up and perform revisions , after everything is set according to your judgement , at this stage you can apply the textures you made from scratch(PRO TIP: if you use sketchup for your modeling process, sample the scaled faces which you plan to add textures built from scratch and export them as a texture, build your textures from scratch respectively with the scaled exports).
3.Assembling: assemble your trains with the extensions.cfg and define the correct specs in train.dat & sounds/motors , ready to load up in-game, with routes , you should be assembling with your .csv route file every station , defining the station's positions , curves , total length , placing and defining all your made components and stations (this is is a rather long process depending on the route length).(PRO TIP: it is recommended to assemble your STATIONS with an animated file or a separate route csv file (animated is better in my personal opinion),then assemble your BRANCHES with a separate route csv file or an animated file (only use an animated file in this instance if you have a fully assembled branch directly from a b3d or csv object). Then the final route csv file you're gonna use to load in-game should only be a container consisting of the branches you're going to use all connected , (if a branch is assembled with a separate route csv file , you need to use the $include directive , if a branch is assembled with an animated file , you need to define it as a freeobj and place it in the appropriate position, wether is at the start (position 0) or any intermediate positions before the end of the route. NOTE: you cant include route csv files in an animated file, so if you choose animated for containing and assembling, you'd have to assemble each branch(rails connecting the stations) directly from a csv or b3d object or built in an external modeling program if you originally modeled it.

Post-Development Process
1. Animated: Once youve made your final touch to the model , its time to make the good stuff... If youre building a station , make those countdown clocks work , make the turnstiles work , emergency doors, etc... If youre building a train, make interchangeable route programs, animate those truck components, mid doors , storm door , cab door , windows , etc.. theres always something else to add
2. Testing Period and Setting a Release Date: Schedule a period of time for overviewing what you've created, this is the appropiate time to think about a release date(if its for public use) , make sure it doesnt coincide to right after you finish your testing period as testing it does not always mean you're getting satisfaction, its called a 'TEST' for a reason, you dont have to immediately set a release date when you start testing , just think about it as you move forward in the testing period, once you thought it out , then you set your planned release and advertise it if you'd like (keep in mind you can change your release dates if any inconvenience pops up)
3. Packaging and Uploading: If you planned for a public release , you should be entering this stage days before your release dates, you should be adding 'readme' files and any necessary instructions revolving the use of the package. once set , upload to a convenient service and DONT make a link/ dont make it public without hitting the release date 
4.Further Updates: if you've planned to update your train regularly in features always follow anything applicable from pre-development to post-development in that same order.