Recent posts

#41

Openbve Development / Re: How do I merge routes?

Last post by E-man-25 - Apr 23, 2021, 10:07 PM

To merge a route you need to have already a good understanding of how routes work and how to code the CSV route , first choose the csv route which you will be using to convert to a merged route , then a secondary route csv which you will copy code from to add to the merged route csv. Inside your primary route csv file find the section you want to keep and erase the rest , here is a boring , and i mean very very boring process of converting the secondary code's positions to connect to where the section you kept in your primary csv file ends by subtracting each position instruction until it transitions correctly, then here is another very very very long and even more boring process of converting the secondary csv file's object indexes to not conflict with the primary route's indexes (this is usually done by adding '100' in front of each object index from the secondary file, then updating the code in each specification of the secondary objects to match with the newly converted object indexes. This is NOT recommended if: 1. You are a beginner in route development , 2. you are easily bored or are already bored and hope to 'have fun' with this 3. you are not patient!

#42

Openbve Development / Re: How do I merge routes?

Last post by Supreme DripLord Doggo - Apr 23, 2021, 05:32 PM

it's almost been a month since you haven't responded. Is everything alright?

[Common File Types]

#43

Development Classes / File Types and Progression Map

Last post by E-man-25 - Apr 22, 2021, 10:28 AM

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.

[To be a certified dispatcher you must complete 2 forms of training!]

#44

[OSCA] Rail Control Center News / [OSCA] Dispatchers Training fo...

Last post by Trainkidkris - Apr 19, 2021, 01:00 AM

[OSCA]OpenBVE School Car Academy: The OBND Coordination staff is recruiting new dispatchers today to help assist the current team in moving trains quickly and efficiently. As a dispatcher in our virtual multiplayer academy, you will be trained and certified to dispatch our members and supervise those operators who move trains in all divisions of the virtual subway system.

To be a certified dispatcher you must complete 2 forms of training!

Training 1: You will learn about the OBND School Car Rules n Regulations, this book is governing all operators in OBND Multiplayer sessions. You will be required to learn the basic rules for operating and procedures that are necessary under roleplay. 

Training 2: You will learn about the OBND Dispatchers Rules n Regulations, this book governs all dispatchers for guiding trains through OBND Multiplayer sessions. All dispatchers will use this training to keep ensure that runs are performed to their highest ability.


Training will be hosted on Teamspeak 3 from April-June 2021 5pm-7pm

Please visit the OBND Teamspeak 3 Server for the classes!

Teamspeak 3: www.teamspeak.com
Teamspeak 3 Server IP: ts.openbvenews.com


We hope to see you there!

#45

Openbve Development / Re: How to add PACIS Signage

Last post by Supreme DripLord Doggo - Apr 17, 2021, 10:21 PM

So on the Dwtn 1 to South Ferry there is a PACIS Signage, by that I mean this thing https://youtu.be/Mlg3kl4alOk

#46

Openbve Development / Re: How to add PACIS Signage

Last post by Trainkidkris - Apr 17, 2021, 09:52 PM

?

#47

Openbve Development / Re: How to add PACIS Signage

Last post by Supreme DripLord Doggo - Apr 17, 2021, 01:11 PM

aka Bernie Wagenblast announcer thing

[Understanding performance rules and guidance on handling fps yields on objects]

#48

Development Classes / Fundamentals of OpenBVE Develo...

Last post by E-man-25 - Apr 17, 2021, 12:42 PM

Understanding performance rules and guidance on handling fps yields on objects

-Key fundamental before developing anything is always having your performance rules in mind , openBVE is not unlimited , in fact , there are a fair amount of limits that you dont want to have to try risking... the following is an ordered list with scattered demanding and non-demanding Characteristics:

    *Texture Sizes and Count: textures must follow the power of 2 rule in pixel sizes (e.g 64 x 64 , 128 x 64 , 512 x 64 , 1024 x 64 , 256 x 1024) , this is due to the way BVE interprets it internally , in the words of one of the main program devs , Christopher Lees or Chris Lees , "The biggest killer by far is number and size of textures, and there's not a lot that can be done easily engine-side for this problem.
The slowest OpenGL / Direct3D operation is changing texture by a massive margin. This is exponential based upon the size of the texture too, as stuff has to be passed over the memory bus to the appropriate shaders etc.
That's why essentially every commercial game engine uses texture atlasing heavily: https://en.wikipedia.org/wiki/Texture_atlas
Far too much stuff also forgets the power of 2 rule, which is another total killer.
The next (possible) step I suppose would be for the engine to implement an internal texture atlas, but that's going to be a massive amount of work, and utterly pointless with some of the 2048px plus sized textures in the most egregious stuff.
Fundamentally, some of the content authors need to take a long hard look at the size and number of textures they're using, relative to the actual size they appear on a player's monitor."

-Pro tip: Try to create textures of power of 2 that wrap around objects by using texture coordinates appropriately. This will reduce or eliminate the need to change the texture when rendering, which is expensive.

    *Geometry: Avoid overly complex geometry where the end results are hardly noticeable. Avoid using Cube and Cylinder commands (B3D/CSV) if parts of the cube/cylinder will not be visible. Do not create cylinder caps unless they are likely to be visible. Avoid using external modelling programs unless absolutely necessary, it may seem as the faces count are good in the raw count but certain exporting methods may be a lethal mistake. The following is a considerable judgement system you can guide yourself with:

Face Count | Demand
~ 0 - 50 | Nearly Unaffected
~ 50 - 500 | Very Low
~ 500 - 1000| Low
~ 1000 - 5000 | Moderate
~ 5000 - 7000 | High
~ 7000 - 12k | Very High
~ 12k+ | Insane

-Recommendation: A face count fitting under Moderate demand should offer just enough user experience and features without going too high on the normals

-Pro tip: To get smoothly curved objects, use custom normals with fewer faces instead of no custom normals with many faces.
   
    *Face vs Face2: Just ... use face , period

    *Transparencies: For best visual quality, every transparency has its overhead. Avoid using transparency at all if there are alternatives of similar implementational and geometric complexity.
Use color-key transparency whenever possible. Avoid using alpha channels in textures or using Color (B3D) or SetColor (CSV) commands with an alpha setting at all costs.
When it is necessary to use alpha, bear in mind that depth sorting will be used to determine the rendering order. There is no perfect real-time depth sorting algorithm, thus artifacts cannot be completely avoided.
When using alpha, keep polygons parallel to each other, which will always render correctly. The worst case scenario is perpendicular faces. When such faces overlap on-screen, the rendering order might be erratic. Use perpendicular alpha faces only if they are unlikely to overlap on-screen.

    *Animated Functions: This ties up to all of the above , the execution of an idea regarding functionality should be planned out carefully , thoughtfully and smart. Not every method is optimal. There are certain kinds of animation which are less expensive, and others which are more. Also, the underlying object plays a significant role. If you want to design your animated objects with as best performance as possible for future releases of openBVE, take a look at the following performance table:(Source: Official OpenBVE Documentation)

Animation   Object                           Performance
State changes   Has only opaque faces           Good
State changes   Has partially transparent faces   Moderate
Translation   Has only opaque faces           Good
Translation   Has partially transparent faces   Moderate
Rotation   Has only opaque faces           Good
Rotation   Has partially transparent faces   Bad
Texture shifts   Has only opaque faces           Bad
Texture shifts   Has partially transparent faces   Bad

Performance is generally better if the result of a function only infrequently changes. So, even if you set the RefreshRate parameter to zero, performance is generally better if the outcome of your formula is constant over longer periods of time. On the other hand, if it changes every frame, performance is generally worse.

Generally, you should avoid using animation with partially transparent faces and stick to opaque faces when possible. Also, try to avoid texture shifts, and consider using state changes or translation where possible.

-Pro tips:(Source: Official OpenBVE Documentation for animated functions)
~Generally speaking, try to keep the complexity of functions as low as possible. This is not the most critical aspect, though, as most of the performance impact will result from applying the results of a function, e.g. rotating the object, and not evaluating the function.

~Use the RefreshRate parameter when possible to optimize performance. Usually, you can use this parameter when you don't need a smooth animation, or when you deliberately want the functions to only update in intervals.

~Don't use functions which always evaluate to the same constant. For example, don't use RotateXFunction = 3.14159, but rotate the underlying CSV/B3D/X object directly.

~State changes are very cheap as long as the state doesn't actually change in between two executions of the StateFunction. If a change occurs, this is a relatively expensive operation, though.

~Try to optimize out if conditions. Especially try to avoid nested if functions. Often, there is an elegant mathematical solution.

~Certain functions, e.g. Exp, Sin, Cos, etc., are relatively expensive. Use them only if absolutely necessary for an effect. Don't include unnecessary operations. For example, the result of StateFunction is automatically rounded toward the nearest integer, so don't apply an additional explicit Round.

~When working with car objects, bear in mind that some variables have an optional car index. You should use this index if you want to query the state of a particular car (that is, not necessarily the one the object is attached to). If, however, you just want to query the value of the particular car the object is attached to, use the variable without the index. For scenery objects, you should not generally use car indices as you can't be sure how many cars the queried train has.


Appropiate Texture Work and Object Specifications

-When Working on textures , apart from keeping in mind the performance rules , textures should be able to imitate correct lighting and shading fitting to the surroundings (e.g If the object is located near a light source , create appropiate illuminations on the textures and/or if the object recieves only partial light , cast shadows on the textures, others also apply like reflections , texture quality and more... This process has proper terminology called texture baking or "render to texture" :
https://www.igi-global.com/dictionary/giving-form-to absence/56563#:~:text=Texture%20Baking%20is%20any%20process%20aimed%20at%20generating,associated%20with%20the%20information%20describing%20the%203D%20model.

-When undergoing object creations , i personally treat this as a must.. you should consider using EmissiveColor 255,255,255 , this is due to the various advantages this offers:
   1: Seamless Smooth Blending between 2 or more components
   2: Uses 100% of the texture's illumination at all times (hence the reason why it makes the seamless blend)
   3: You can specify your nighttime textures in the 'load' parameter,after specifying your default texture with 'load texturename.extension' put a comma and define your nighttime texture to use for the component right after.

-Avoid using post-transformation commands like 'translate , rotate , translateALL , rotateALL , scaleALL, etc...' because in the long run when making additional components you would have to mathematically calculate the actually coordinates of a vertex or placement of a component.

Organization

-The more you keep your assets organized , the better the efficiency of your development process and post-development process, consider structurizing your folders and internal code as sectioned as possible , in the internal code use comments appropiately (thats the reason they exist) , if you want to add on to your internal code dont just write it in a random place or at the very bottom, locate your sections and place them strategically.

-Always plan your start from beginning to end , keep backup plans if the original plan doesnt work out, but NEVER work on the fly , an appropiate planification should have milestones , goals , to-dos, procedure steps , features you wish to add , visions for the future , crew members with respective roles (if applicable) , never estimate 'time for release' if you're developing for the public, instead take all the time you need to work and it is up to your planifications if you want to leave your package as-is or to have separate releases for different features or add-ons.

#49

Openbve Development / How to add PACIS Signage

Last post by Supreme DripLord Doggo - Apr 16, 2021, 05:40 PM

Noticed most routes have PACIS Signage on their route. How can I add them to a route?

#50

Development Classes / Re: Basic Object Building

Last post by Supreme DripLord Doggo - Apr 16, 2021, 03:45 PM

Mad respect. Thank you so much, I am learning how to start making routes so this forum will come in handy.