Crazy Idea for Light Rail

[sbaros]

OK, as far as I understood I have to edit the main placement coordinates of the loco body 3DP file, which come before the individual vertex definitions, right? Afterwards I'll delete the moving parts, which are anyway useless when embodying the "rail motor's" boiler inside the leading carbody.
Do I need to do anything with the TrackPoint.3DP as well ? In general, I have not understood what exactly this file defines. The LengthPoint.3DP obviously represents the overall length of each vehicle and consequently dicatates the starting point for the next one?

[Gumboots]

OK, as far as I understood I have to edit the main placement coordinates of the loco body 3DP file...

Only if you want to hide cargo cars inside a large "locomotive" like the ships.

Honestly, it's easier to just make the mesh you want in one custom model, rather than trying to merge two separate meshes by screwing around with length points. I'd do this with Blender, but you can also use the trick of calling the body of your second model as a truck of the first model.

The track points define where the model attaches to the track, more or less. It's a weird thing that includes some variation due to the mesh of the model, which is probably an unintended bug that they never noticed (see this post).

[sbaros]

OK, the TrackPoint.3DP seems to be in simple terms the file that will make a vehicle look derailed in case it is screwed up.
As far as my intention is concerned, it's similar to hiding cargo cars inside a locomotive, but vice versa. Actually, the boiler will be partially hidden inside the first car (preferrably an express one) of the consist. Quite similar to a Sentinel or a steam tramcar.

[Gumboots]

Try using Truck*.3dp files: renaming an existing Body.3dp as a truck of the primary model. That's the easiest way to do it if you don't want to merge meshes in Blender (or whatever modelling app you use). But that's mainly useful if you want to put one thing in the middle of another. If you want a longitudinal offset, like half in and half out, you'll probably find that it all ends up being a PITA sometimes. It will probably be ok on straight and level track, but could go weird around corners and over lumps. It may also go weird with era changes, when the pax car model changes, or when there's a different car at the front of the consist.

My 2c, after messing around with things and thinking about it, is that things like railcars and ships really need to have custom express cars that are amenable to being hidden (ie: short, with minimal mesh and a simple transparent DDS). The problem is that conflicts with standard express locos, which you want hauling standard express cars. There's no way to get both running at the same time. You could do a scenario entirely with railcars and steam trams and ships, and no standard express or mixed traffic locos. That could work.

[sbaros]

Well, for a few days I'll be unable to work on the railcar concept, having left the relevant files at home. I do have handy my flatcar cargo 3DPs however in my portable stick installation and I experienced the following related to the matter discussed here:
From the info available, I assumed that the first set of hex-coded coordinates immediately before the "INST" statement refers to the cargo's position in relation to the wagon centre.

So, I tested these fields around a bit in order to see the cargo displaced either longitudinally or vertically off the wagon centre. Well, in vain, since the cargo insisted to be centred on the wagon no matter what.

I am beginning to suspect that the placement coordinates of CargoModel.3DPs are also ignored/locked by the .exe program, just like the negative coordinates for the LengthPoint parameters, regardless of the users' manipulations. If this is true, then one has to painstakingly transpose in parallel the contained vertex coordinates one by one in order to "slide" the cargo sideaways or whatever...
I'll conduct further experimentation with the supposed placement coordinates of other 3DP stuff from buildings and vehicles to see what happens.
Another observation: When arbitrarily reducing the stated quantity of vertices and triangles within the 3DP file, the program crashes; it doesn't simply ignore the omitted stuff. So, editing by hand has to be impossibly careful.

[Gumboots]

Altering the X, Y and Z position (before the INST) should work, but there are a couple of things you need to watch out for.

1/ With locos and cargo cars it is necessary to reload the model before the changes will be visible. You can't just save the game, make a change, then reload your save. If you do that, the old positioning is cached and that's what you will see. With locos, I just buy a new replacement loco. With cargo cars, you have to run the train to a station and get it to reload the consist. I haven't actually tested changing these bytes with cargo models, but my bet is they will work the same way as loco and cargo car components.

2/ Changing the longitudinal position with those bytes may also change behaviour around corners (assuming cargo models work the same way as loco components). So you may find the cargo model wanting to turn to a different angle around corners.

Regarding transposing coordinates: I, and others, have done this before. It's the method we used before we had the Blender export script. Yes, it is really tedious. If you think doing it with a cargo model is fun, try building an entire custom steam locomotive that way. If you want to start moving mesh around it makes a lot more sense to do it in a modelling app, then export the result to a .3dp.

Another observation: When arbitrarily reducing the stated quantity of vertices and triangles within the 3DP file, the program crashes; it doesn't simply ignore the omitted stuff. So, editing by hand has to be impossibly careful.

Yep. The .3dp keeps track of how many vertices and triangles there are for each level of detail (the INST headers define where the LOD's start). The verts are just after the INST and the tris are just after the verts. In your example file, verts are 44 00 00 00 (ie: 68 in decimal) and tris are 58 00 00 00 (ie: 88 in decimal). These have to match what is in all the hex after that, so if you add or delete any verts or tris you also have to change the total at the beginning of that LOD.

You can remove entire LOD's to simplify the file if you like. Just find the second INST and remove everything from there to the end of the file. Then change the 04 00 00 00 that is just after 3DMD in the first row to 01 00 00 00 (this, of course, is the number of LOD's in the file).

[sbaros]

Yes, all tests reported by me since I subscribed here are with freshly started sessions, I found that out quite early in my experimentations. I have a couple of map versions for trials, where I modify port recipes each time so as to get the desired freight cars to appear immédiately.

[sbaros]

Well, this looks as if the Budd Company teamed up with Serpollet or Kittel, huh? Anyway, it seems that in its 18th year, Railroad Tycoon 3 acquires its first recorded genuine self-propelled car (not the pseudo-MU's hitherto featured in known distributions of the program, which are practically ordinary locomotives disguised in fake railcar skins). As of midnight of the 173rd anniversary of the Communist Manifesto by K. Marx & F. Engels, the first presentable prototype left the hex-editing workshops and was steamed up for the inaugural test run through Central Macedonia, 100% loaded with excited passengers. Free beer was served by the railway-owned brewery in the background.
It seems to fit appropriately into any era standard express carbody, without any requirement to employ custom shorter express cars or anything like this. There is no conflict with standard express locos either; loco-hauled trains continue their business as usual alongside.
It took exactly 3 months of preparatory skills acquisition, as can be traced through the history of relevant posts on various projects of gradually increasing difficulty.
The prototype is not distributable yet, it needs cosmetic work such as exhaust steam and deletion of various disturbing texture leftovers, yet the basic concept is more or less done and paves the way for related ones.
Also, it may require a skilful manipulation of its mechanical behaviour datafile, so that it becomes competitive for single-car consists on all gradients and 1 trailer on moderate gradients, yet prohibitively slow for heavier loads.
On the modelling side, playing with the transposed 3DP boiler body coordinates before the "INST" statement worked as colleague Gumboots suggested. However, it revealed an inaccuracy published in the instructions here: Unexpectedly, positive relative Z (+Z) is NOT toward top of loco as stated, but toward BOTTOM of it! The prototype smokestack apparently got somewhat exaggerated with these experimentations, it shall be probably lowered a bit.
To commemorate this occasion, the modern-era steam railmotor is named and will be marketed as "Marx-Engels 173" or "ME173" for short. Electric versions with pantographs for various eras will be rolled out on other anniversaries!

[Gumboots]

It seems to fit appropriately into any era standard express carbody, without any requirement to employ custom shorter express cars or anything like this. There is no conflict with standard express locos either; loco-hauled trains continue their business as usual alongside.

It depends on what you're trying to achieve. My original idea was to make things like the McKeen Railcar and similar units. These are problematic when it comes to consists, as are ships, because the unit you are making is large and has its own distinctive style, but you can't have cargo cars trailing behind it or poking out of it.

If you just want to shift the mesh of a few small components so you can hide them inside a standard express car then sure, you can do that. I did something similar with the H era caboose in my custom set (it looks like a standard modern end of train device, but is a caboose for game purposes). I have also thought of doing the old type of railcar which had a visible cab and boiler on the front of (effectively) a standard express car. I assume you just moved all the bits you wanted to use rearwards and used a zero rear length point. Be aware that it will go a bit funny around tight corners. That's just one of the game's bugs.

Also, it may require a skilful manipulation of its mechanical behaviour datafile, so that it becomes competitive for single-car consists on all gradients and 1 trailer on moderate gradients, yet prohibitively slow for heavier loads.

That's not hard to arrange. I did work out trial stats for a McKeen railcar, so it it would achieve top speed with one express car but was useless with two (ie: no trailers). This is how they ran in real life: they were basically one express car with a petrol engine. That result requires using almost no weight for the locomotive file. That then allows you to use very low values of pulling power and free weight, which lets it haul only one car before performance goes down the tubes.

On the modelling side, playing with the transposed 3DP boiler body coordinates before the "INST" statement worked as colleague Gumboots suggested. However, it revealed an inaccuracy published in the instructions here: Unexpectedly, positive relative Z (+Z) is NOT toward top of loco as stated, but toward BOTTOM of it!

Nope. Positive values are definitely above the tracks. This has been confirmed many times over. You can see it in any Bogie*.3dp file. Wheels centres are always above the track, and always have positive Z values. So do loco boilers and any other component.

[sbaros]

I am not sure, can anybody spare 3 minutes to help verify this? I am attaching the 3DP of the boiler body (stolen from the "Planet"), which I raised by 3' units in order to get the appearance shown in my previous post. I think the highlighted Z-value in the accompanying screenshot shows a negative (-3) amount. When using the perceived opposite, positive one, the bottom was digging into the trackbed. What have I understood wrong?

[Gumboots]

Yes, it does, but that's the "attachment point", not the position of the mesh. You'll find your mesh still has Z coordinates with positive values.

The attachment point* doesn't seem to care about the Z axis. It's only really affected by X and Y, because all components of a loco (or whatever else) always act as if they are one rigid unit on the Z axis. You can see this with things like my H era double container cars: the two trucks (ie: the visible cars) behave like one very long rigid car on the Z axis when traversing any changes in grade. You could set that value to 00 00 00 00 and it wouldn't make any difference. In practice you only ever change the Y value, leaving X and Z at zero.

Short version: For this use case, set all track point and length point values to 0. Set the attachment point to 0 for X and Z. Then change the Y axis value to get it where you want it.

*With trucks, it defines where they pivot relative to the rest of the unit.

Edit: By the way, when working on .3dp files I find it's best to set the display to 12 columns. That way all X, Y and Z values line up down the page. It makes things easier on my brain.

[Gumboots]

I just loaded your file in Blender. All vertices are above track level, as they should be. It looks like a standard Planet body file.

If you are finding the bottom to be dragging along below track level, then you have introduced another problem somewhere. Start by resetting the attachment point Z value to zero. Start the scenario, buy a new railcar unit, see how it looks then.

[sbaros]

Dragging below track level was successfully dealt with from the beginning on, by defining this negative attachment point Z-coordinate. I only reported it for informing members. With this trick, the "railcar" so far behaves as intended, I needn't reset anything. When I find spare time I'll focus on the cosmetic improvements I have mentioned. I guess the least visual nuisance will be achieved when

• the smokestack is placed directly over the bogie pivot,
• the declared length of the virtual "railcar" matches as much as possible that of the host carbody

although it can never be perfect due to that annoying "bumping/buffing" effect between adjacent vehicles. Unavoidably it will be the same with the pantographed electric version. At least for me anyway, it is better than having no self-propelled railcar option at all.

[Gumboots]

It shouldn't drag below track level anyway. I've played around with loco and cargo car models a lot, and I've never seen them drag below track level unless an error of some sort has been introduced. I'm concerned that if people take your advice on this they will create problems for themselves.

I'd like to try the entire railcar unit on one of my installations so I can see how it behaves. Would you mind supplying the EngineTypes files and the complete PK4?

I guess the least visual nuisance will be achieved when

the smokestack is placed directly over the bogie pivot,
the declared length of the virtual "railcar" matches as much as possible that of the host carbody

Probably good guesses, but there's no way to tell without trying it.

...it can never be perfect due to that annoying "bumping" effect between adjacent vehicles. Unavoidably it will be the same with the pantographed electric version.

This is why I was trying to think of ways to hide one express car inside the railcar.

[Gumboots]

I just tried a quick test with the default Planet body file. By changing the attachment point to 0, -12, 0 I was able to shift the mesh 12 units rearwards without touching the Z value, and with the body mesh staying at its usual height above the track.

This was just a quick and rough test, without changing length points or anything else, but it seems to work as expected. I think I can duplicate your Clanet easily enough without needing a negative Z value for the attachment point.

---

Edit: Aha!! I figured out what is happening.

Using a negative Y value for the attachment point creates the same look as shifting the mesh by an equal positive Y amount. IOW, if you were to move a body mesh by +12 units Y inside Blender, before exporting the result as a new .3dp, and while leaving the attachment point at the standard 0 for all three axes, this looks the same as leaving the mesh where it was but changing the attachment point to Y = -12. It may not behave the same around corners or over grades (haven't tested that yet) but it looks the same on straight and level track.

So 0, 0, 0 is the game's internal reference point for asset positioning, and when you change the attachment point to Y = -12 that coordinate is forced to the game's 0, 0, 0. But, this is at -12 relative to the asset mesh, so the asset mesh gets shunted 12 units backwards (positive Y values are to the rear, negative to the front).

This explains why you needed Z = -3 for your Clanet. You wanted to shift the mesh +3 units upwards, so changing the Z value to -3 forces that point to track level, thereby shunting the visible mesh upwards by 3 units. So you were right.

Although honestly, if I just wanted a chimney or a pantograph poking out of an express car I wouldn't use an entire default locomotive body file for that job. I'd just create the chimney or pantograph* in Blender without all the other extra crud, set it at the right Y and Z values, and export that as the railcar body .3dp. Then I'd set length points to zero front and rear**, and use the standard 0, 0, 0 for body attachment point. Track point would be adjusted by trial and error. The front track point is probably going to have to go at Y = 0 anyway (because it would probably be worse if it was out the front of the railcar) so in practice you'd only be tweaking the rear one.

*By stealing one from an existing default model, and setting its .lco file to call the existing default .dds images.

**Length points only affect where the previous and next cars attach to the car in question. They don't have any other effect. For something like the Clanet there's no reason to set them to anything other than zero, because it will never have anything in front of it anyway, and you want to pull the first car in the consist as far forward as possible, so zero for front and rear length points makes the most sense.

---

Edit #2: By the way, attachment points for trucks don't behave like this*. They don't translate the mesh on any axis. What they do is define where the truck pivots relative to the body. I've tested them with positive Z values, and with both positive and negative Y values, and the truck mesh stays at the Z and Y values defined for the vertices in the .3dp.

So it appears this odd behaviour of shunting mesh around when attachment point values are not zero only applies to body files.

*Nor do attachment points for other components like bogies, connecting rods, etc.

[sbaros]

Well, I'm learning littile by little. The main reason I do want to provide a narrower, unobtrusive body underneath a "railcar" pantograph or chimney is for preventing the silly sight of a phantom pantograph or chimney levitating above the track in case the thing has to run "light" for part of its journey.
Also, the reason I avoided a wider railcar body engulphing the leading car of it consist was that this car might contain something else than passengers, thus invalidating the railcar's external appearance when moused over.
Undoubtedly, it will take some effort to provide a railcar "skeleton" somewhat decent in terms of appearance.
I still have no PK4 for this "thing", its components are scattered around (mostly in my UserExtraContent). I may work on it this weekend, when I return home.

[Gumboots]

It could be fun to make it like a steam tram: Baldwin steam tram No.1A, 1879 Although obviously there were diesel railcars as well. Not sure what you'd do for the body of those, or the electrics.

By the way, I don't know if you've ever seen this: World's first solar-powered train. It's a short line not far from where I live, running a set (ie: pair) of ex-NSWGR 600 class railmotors that have been converted from diesel to solar/battery power. Something like that could make a nice unit for the game.

[sbaros]

Not bad at all, and in fact quite attractive to use the 600 class body as the standard passenger car body too. I'd consider it as a project when I learn how to scratch-build 3dp solids in a user-friendly application like Blender. Hex-editing this supersedes my patience by far.

[sbaros]

I am uploading a very rudimentary and clumsy version of an early steam railcar. In addition to a chopped-off Planet boiler, it has also a "cab" around it, so that it doesn't look too bizarre when hauling freight. This "cab" was added by coding it as a "tender" (hence the tender-related files in the attached zip) and uses the TrainMaster's diner carbody. It is only intended as a research & development basis, not as a permanent addition to any motive power roster.
(Not an April fool, but probably close enough).

---

There it is transporting coal. I guess my colleagues will love it. We have at work several similar electrically powered cars for ballast and track stuff, rebuilt in the '80's from passenger trainsets of 1904 vintage.

[sbaros]

Developments so far are as follows:
https://rrtycoon.blogspot.com/2021/05/t ... enger.html
The steam railcar conversion module for open-platform express cars doesn't look to me so unpleasant after all.
I suspect that it could have a more appropriate inscription around tight curves if a set of invisible "bogies" are provided, which will match approximately the average car wheelbase of the corresponding historical era, but before attempting this I'd like to have opinions of more experienced rolling stock creators here.