In case of dispute, these terms apply.

How the "Red October" Workshops support housing ...and other simple building extensions	DISCLAIMERS Any experimentation in conjunction with the content of this domain should be conducted in an extra, dedicated installation of RR Tycoon 3, easily created by pasting an existing one into any available permanent or removable drive. Experiments will undoubtedly and frequently cause this extra installation to crash until you figure out what went wrong, so keep one working, untouched version always on disk. To avoid additional obstacles, unexpected behaviours and miscelaneous trouble, never put RR Tycoon (or anything else for that matter) under the “C:\Program Files” or “C:\Program Files (x86)” folder and the like, no matter if prompted to.

How the "Red October" Workshops support housing
...and other simple building extensions

DISCLAIMERS

Any experimentation in conjunction with the content of this domain should be conducted in an extra, dedicated installation of RR Tycoon 3, easily created by pasting an existing one into any available permanent or removable drive. Experiments will undoubtedly and frequently cause this extra installation to crash until you figure out what went wrong, so keep one working, untouched version always on disk.

To avoid additional obstacles, unexpected behaviours and miscelaneous trouble, never put RR Tycoon (or anything else for that matter) under the “C:\Program Files” or “C:\Program Files (x86)” folder and the like, no matter if prompted to.

A step-by-step walkthrough of another 3D-modelling attempt for RR Tycoon stuff

Abstract

This article describes how to enhance existing RR Tycoon buildings with support foundations/retaining walls, as well as other addons and extensions.
The basic software tools for the job are:

the Watto Game Extractor for extracting 3D model files and bitmap skins from the relevant RR Tycoon data folders

a 3d model viewer/converter to explore geometries and check out any modifications you make

a good hex editor to modify the vertex and bitmap coordinates for your 3d addons
Pre-requisite skills:

Full familiarity with RR Tycoon3 mapmaking

Many dozens of hours of user experience running RR Tycoon3 to guarantee understanding of what it is all about

Elementary analytical stereometry (especially manipulating coordinates of solids in 3D space)

Basic understanding of binary file structures, datatypes and hex-editing

Huge patience

Advanced users need only read the white-lettered parts.

Preface

An outrageous visual harassment ever since the original release of RR Tycoon3 in 2003 has been the placement of buildings on anything else than flat terrain. Even on slightly-sloped hillsides, you can end up with fully levitating houses as depicted, by as much as an entire floor height!

Despite the immediate obviousness of this drawback, the programmers did nothing to address it. Given the behaviour of the ground in the virtual 3D-world, the obvious professionally correct remedy would have been to release free-of-charge a linear extension of each building's superstructure(s) downwards, which would become visible and convincing once the earth below for some reason failed to reach the building's relative 0 level. This omission is accounted for as a major consumer disrespect, typical for the plutocracy.

Given the attitude of the so-called "intellectual proprietors", the next feasible step for the average user with limited modelling tools and skills would be to place support(s) under parts of each building specifying negative relative altitudes for the base of the understructure, that is negative Z coordinates. This will simulate a credible foundation of an otherwise superelevated (or super-levitating!) structure.

Some elementary technical information

All 3-dimensional objects in RR Tycoon III are defined through a probably unique "3DP" format. In short, this format:

defines the coordinates of a 3D model's vertices
then it defines which of these vertices (in groups of 3) are connected by "faces" (triangular ones, needless to say). The set of all "faces" of every 3DP file constitutes the outer surface(s) of the respective 3-dimensional object.
finally, it defines the so called "UV-mapping", i.e. which part of the object's bitmap skin will cover each one of the "faces" so that the final, "painted" view of the object is produced.

First useful conclusions drawn from basic geometry principles

Curved stuff, such as cylindrical surfaces and spheres, have to be approximated in a rudimentary way, as series of polyhedral surfaces. So, unlike serious 3D modelling applications like professional C.A.D. (Computer-Aided-Design), a huge lot of individual vertice coordinate sets -and hence filesize- are necessary even for a mediocre representation quality (not to mention a decent one). This makes manual hex editing of such objects practically impossible.
The simplest possible 3DP object is understandably a sole triangle
The second simplest one will have 4 vertices allright, which may be configured in various ways:
- if coplanar, they will define a Quadrilateral, either simple or self-intersecting, either convex or concave.
- if not, they will define a pyramid (or some sides of it, if not all 4 possible triangular "faces" are explicitly specified in the file).
With 5 vertices we get a bi-pyramid
With 8 vertices we can have a cuboid (or some sides of it) and so on.

We shall be working a lot with the above, simple geometric shapes, since a combination of them can produce more complex geometries to form important additions to numerous 3D objects. Complicated 3DP files are a headache to work with by painstakingly hex-editing vertice coordinates and texturing parameters.

Where are -and should be- the 3DP files located?

When saying "stored in various ways" we mean that groups of 3DP model files can be either lie loose in the mentioned folders or packed together inside a specially compressed archive called a PK4 file. So, a look inside an untouched ..\Data\3D subfolder will reveal no 3DP files, only few huge PK4 archives.

TIP: Preferably unpack immediately with Game Extractor all existing 3DP files from the PK4 archives in ..\Data\3D to a dedicated repository outside ..\Data in order to fetch various objects easily to ..\Data\UserExtraContent for experimenting without the nuissance of running Game Extractor over and over again. Disk space isn't so expensive after all. You better paste the target directory location directly in Game Extractor's relevant field at the lower right of its dashboard.

RR Tycoon III reads the databases of all its assets immediately on startup. These assets can be stored in various ways inside the following subfolders of the DATA folder. During startup RR Tycoon III looks for 3DP models succesively in:

the ..\Data\3D subfolder
the ..\Data\PopTopExtraContent subfolder
the ..\Data\UserExtraContent subfolder

Due to this hierarchy, the ..\Data\PopTopExtraContent overrides the default 3D models sold together with the original program while ..\Data\UserExtraContent overrides everything else. This way, users can permanently or temporarily substitute/override selected default 3D models and bitmap skins with their preferred versions of the same name merely by placing the latter in one of the last 2 subfolders, no deletions required. The program will undig all 3DPs in these 3 subfolders, regardless whether packed inside a PK4 or loose.

In addition to the user-defined substitutions mentioned, these are also the folders where completely new additional 3D components of existing stuff or totally new objects should better be placed. It is good to leave the ..\Data\3D subfolder alone in order to avoid accidental damage to the basic Tycoon configuration, in case things are totally messed up in the other 2 directories.

Surplus/orphan 3D objects and bitmap skins -such as the model of a meanwhile eliminated building type- happenning to be left over inside relevant folders DO NOT cause RR Tycoon to crash (unlike other assets, such as surplus commodities in the ..\Data\CargoTypes subfolder or surplus BCA/BTY files). On the contrary, existing building types and categories lacking their allocated 3D model -or having its filename misspelt- WILL cause crashing.

Bitmap skins

are located by default inside PK4 archives in the ..\Data\2D subfolder. The default preferred format is DDS for filesize and computing speed reasons, but TGA can be used as well. For flexibility, the format and the name extension of a model's Bitmap texture is not fixed in its definition files, only the main part of the filename. Thus, a XYZ.TGA skin in the ..\Data\PopTopExtraContent will override smoothly a XYZ.DDS one from the PK4 archives in the ..\Data\2D subfolder once the user decides to place it there. JPG is mentioned too at places as a possible format, yet it sounds kind of useless since it doesnt support transparency.

Let's examine some bodies closely!

At this stage, it is appropriate to take a closer look at 3DP files, beginning with opening them in hex-editor NEO. The exact file structure is described here. You did follow the TIP

above, right? So, go to the directory where you unpacked that 3DP lot and arrange the contents by size! Ignore all filenames at the bottom which comprise "light", "smoke", "LengthPoint"s, "TrackPoint"s and look at the files referring to "Bogie"s! These are the simplest ones, defining simple triangles and squares. Mind you that these "Bogies" are actually wheels, one of many misnomers exposing PopTop's lack of rail culture, but anyway let's get to the points (literally)! Let us open "ReddevilL_Drivewheel2.3dp" in the hex editor, to pay our respects to our friend David Wardale too, and see what evidence we can collect examining it! It will look like this once displayed columns are set to 12 (undock the browser tab to a new window to study it more comfortably). 12 is the total byte length of a point's X, Y and Z co-ordinates, so they stay vertically ordered, each point exactly under the previous one. It would be nice to have each point in 1 row too, but we can't have everything! Obviously these co-ordinates refer to the object's own intended axes, not the global map co-ordinate system. When we select a set of bytes guided by that 3DP file structure mapping the "Data inspector" tab to the left displays in human-friendly terms the information hidden in these uncomprehensible characters. E.g. selecting these 4 bytes which according to the 3DP guide represent a "floating" decimal number, we see a "float" value of 2.8192. Incidentally, we observe this is the X-value for all 4 points of this 3DP model, which reveals that the rectangle in question is a vertically upright one, quite expectable for a locomotive wheel (a rectangular wheel is not so expectable, but this is remedied through a circular Bitmap skin covering it). Furthermore, it reveals that the track axis coincides with the Y-axis of rolling stock (instead of the X, which would be more expectable) and constitutes a cause of errors when working with rolling stock, but we'll survive... Finally it implies a track gauge of 2.8192 x 2 = 5.6384 ! Yeah, right, if Wardale was to export his brainchild to Spain! Anyway, we get a first idea of the information we can draw by examining these files.

The best part, this "float" value shown in the "Data inspector" tab is directly editable! If you double-click that "2.8192", you can select and replace it with any value you want. No more tortuous "Little Endian" conversions!

Now, wouldn't it be nice to LOOK at 3DP objects to obtain an even better idea about them? So, lets download this baby and install it! Associate the 3DP extension with this program, so that the models will display at once when doubleclicked. Play with it a bit and continue reading! We'll get back to it later on.

Peculiarities of the RR Tycoon's handling and behaviour of 3DP objects (the worst pain in the ...)

Unlike other simulations, objects in RR Tycoon's world can only be placed under very weird and inflexible rules.

Apart from vegetation and railtrack, every fixed object must be designated as a BUILDING, which means it must have a BCA (Building Category) and at least one BTY (Building Type) file allocated to it in the ..\Data\BuildingTypes subfolder (a broader BCA Building Category can have many variants, i.e. different looking edifices for the sake of visual variety which functionally perform the same job). The 3DP stuff and the bitmap skin to be used for each one of these variants is defined at specific byte addresses of the corresponding BTY file (see here the BTY file structure)
Technically, it is not necessary to have any compatibility between the filenames of the 3DP base model (the "body"), the Bitmap skin, the BCA and the BTY. For example, you can download and examine here one of our Workshop's addons, the "favela", where the broader category is "House.BCA", the specific Building variant is "favela.BTY", the 3D model is "FarmRubber" and the Bitmap texture is "Oilwell" !
This verifies that one can "borrow" e.g. the skin of the Oil well and the 3D "skeleton" of the Rubber Plantation to produce a Building that functions as a residence! In other words, some existing graphic files CAN BE SHARED IN AN UNORTHODOX WAY (with a bit of luck to match!) between the most different Building Types without being renamed. However bear in mind that in this case, any change you perform on a shared asset will affect all Buildings using it. In some instances you will want this to happen, in some others not. In the latter cases, you will have to clone the desired asset under a different, unique filename and use/modify it under exclusive use for the chosen Building Type.
The basic structure of every Building is contained in one and only 3DP of the so-called "body". Its filename must consist of the prefix specified at byte address 64 of the BTY file, an underscore and the suffix "body", like "XYZ_body.3DP".
To further make things suck, only 1 bitmap skin file can be attached to each Building, namely the one specified at byte address 124 of the BTY file
The most serious consequence of the above is that objects cannot be composed utilising libraries of standardized, yet customizable components. Every part is supposed to be coded over and over again in the base 3DP of each object intended to make use of it.

So, is it hopeless? Can't further elements (like the underground foundations/supports mentioned in the beginning) be superimposed to our houses without painstaking extensions on the ***_body.3DP's themselves? Not quite! PopTop left a backdoor unlocked. In order to animate buildings (like the sawmill for example), the animations are stored in extra 3DP's because they cannot be incorporated to the static "bodies" (just like rolling stock wheels and other moving parts, which require separate 3DP's). Each animation have to be stored in a separate 3DP file with the same prefix as the "body" files and a consecutively numbered suffix "_Anim1", "_Anim2", "_Anim3" and so on. E.g. the first animation for "XYZ_body.3DP" shall be "XYZ_Anim1.3DP". Caution, the first missing number in the series will cause the rest of the animations to be rejected. Apart from the numbered "_AnimX" 3DP files, an additional "XYZ_Anim.3DP" (without a number) must be provided, otherwise the numbered ones won't load with the building.

The interesting fact is that any properly named 3DP file will superimposed on its namesake building "body", regardless if really animated or not. BINGO! That's our Trojan horse for invading the stubborn Tycoon structure! No need for painstaking modifications of complex body files. With a series of simple triangles, quadrilaterals and/or cubes disguised as fake animations, various patchings can be effected upon most buildings.

Construction begins!

So far we have gathered all the tools and theory necessary for our venture. We choose to support the No. 4 "Victorian House" as our pilot job. A look into our 3DP repository reveals that its group of 3DP files (actually the one and only body file so far) has the prefix "VictorianHouse04". First and foremost, we create its generic, unnumbered ""VictorianHouse04_Anim.3DP". This is done by cloning and renaming any of the ***_Anim.3DP files from a random animated building, doesn't matter which one. Then, the tricky part begins: we have to look for a 3d shape that will form a reasonable underbody foundation, while looking right dressed in the compulsory bitmap texture of the "Victorian Houses" group.

Let's search for a cubic block to begin with. Looking in the file manager upwards from the smallest filesizes ("bogies" for that matter) we encounter something promising with 8 vertices. We preview it in 3D Object Converter and voila! We hit a promising-looking cuboid.

Now, what kind of a cuboid is that? We don't want to examine its dimensions through these weird hexadecimal characters, do we? So, while in 3D Object Converter, we save as format "3dPoints (txt)". After opening what we saved, we see this:

↓

MIRACLE! The Converter translated that hated gibberish into comprehensible decimal vertex coordinates in the same order as they come in the original 3DP. Now, it is a piece of cake (literally) to realise that our cuboid has its lower level at approximately 95 length units below ground and its upper one a little below 0.
We thought of the following improvements, to begin with:

The upper level should better flush with the building bottom, that is level 0. So we shall correct all Z-Values around -1.1968 to 0
The foundation bottom may come unnecessarily deep at about -95 and deform the bitmap texture too heavily. Therefore, we shall choose to try with a more reasonable -25 for a start.

So, we clone that "BallastStone_Section.3dp" into ..\Data\UserExtraContent and rename it to "VictorianHouse04_Anim1.3dp". Then, we change all Z coordinates with the hex editor as proposed above (they will reside at the leftmost 4 bytes of each row once we columnize our view to 12). In order to test the result, we load a map in editor mode and we choose a steep mountainside to "plant" our VictorianHouse04 (don't use ...Holland to test your building foundations!). The foundation sides seem sufficiently decent, like downward extensions of the conventional side walls. However, the top pavement looks totally unconvincing and has to be fully concealed under the superstructure (see arrows below).

Unlike rolling stock, whose orientation is obvious through the track, there is no way to tell from the beginning which is a building's X-axis, Y-axis and their positive and negative directions other that trial-and-error. When a building is placed down, either manually by a mapmaker or automatically by the program, it may be facing at any random direction. So, it can take a few false moves in calibrating a building's addons before the right directions are determined. Such was the case of the above house, and after 2 trials & errors playing with the X & Y coordinates we came up with the following:

It looks more like it, although there is still a slight, disturbing imperfection left uncovered in front of the oblique veranda, marked in red above. So, the idea that came up was to cover it with a triangular patch in order to get the texture oblique like the veranda itself. We took one of several available triangles -namely a "wheel"- and we converted it from equilateral and vertical to right and horizontal by nullifying its Z-coordinates (not exactly nullifying, we set it slightly over 0 to ensure coverage) and aligning its 2 vertical sides with the corner in question. We saved the triangle as "VictorianHouse04_Anim1.3dp". This was the final step in achieving an acceptable, curb-like appearance:

We suggest downloading and unzipping this demo in your ..\Data\UserExtraContent folder to examine it on your own and modify it at will.

CAUTION!

In case the building in question is already supplied with animations, your homemade ***_AnimX.3DP files will override the original animated parts and therefore deactivate them. To avoid this, you must check how many "out-of-the-box" animations accompany the building and start your own extensions' numbering sequence upwards from the last one. If the building is supplied for example with 2 animations (as in the case of the Coal Mine), yours must start from ***_Anim3.3DP upwards. The default animations usually show up in the PK4 packages containing the building in question, unless it is a solitary building that you downloaded separately, in which case the animations are lying loose wherever you stored the whole thing (..\Data\PopTopExtraContent or ..\Data\UserExtraContent).

Download here some of our ready-made creations!

Epilogue

The effort is continuing at the time of publication with enhancing supports for a variety of buildings. We think the visual result, even when not perfect, is far more convincing and preferable to the miserable effect depicted on top and much worth the effort.

Credits

Actually, there is very little prototypical research work and innovation from the part of "Red October Works" in the above. For the most part it is knowledge hitherto scattered around put together. Almost everything is based on the contributions of far more skillful members of the Hawk & Badger Railroad Forum, notably milo, Pjay, bombardiere, Blackhawk, Gumboots, Michael Rountree, Chris Derksen, NedFumpkin and others (please message us in the forum or send us Email to remedy any omissions). Any appreciation is mainly attributable to Them.

Usines Ferroviaires "Octobre Rouge"

Search This Blog

How the "Red October" Workshops support housing
...and other simple building extensions

...and other simple building extensions

DISCLAIMERS

Some elementary technical information

Where are -and should be- the 3DP files located?

Bitmap skins

Let's examine some bodies closely!

Comments

Post a Comment

How the "Red October" Workshops support housing ...and other simple building extensions

...and other simple building extensions

DISCLAIMERS

Some elementary technical information

Where are -and should be- the 3DP files located?

Bitmap skins

Let's examine some bodies closely!

Comments

Post a Comment

How the "Red October" Workshops support housing
...and other simple building extensions