Minitram Review by Blockhead
2022-06-23
Introduction
Doxydoxy's mini tram is a mod that adds a narrow-gauge compressed-down version
of the ubiquitous Polish tram the Konstal 105N as a wagon for AdvTrains. It is
feature-packed and technically good, if not 100% user friendly. This tram is
well overlooked and deserves a good review by now.
Installation
I installed through git by cloning from doxy's git hoster site "KDE Invent". I
can't speak for the ContentDB experience.
I installed the doxy_mini_tram and display attachment offset patch separately,
but then had to remove the attachment offset mods from the minitram mod
otherwise Minetest wouldn't load the world due to a mod name conflict.
I would like to see multi_component_liveries and visual_line_number_displays
moved into separate mods too just like the attachment offset mods. Perhaps
bundle them all into something like advtrains_lib_doxy or something. It's
encouraging to see what developments might make it into more advtrains wagon
mods thanks to the development of the tram. Some of it might make it into the
core.
Visuals
The overall effect just doesn't quite fit the usual block game aesthetic for me.
The thin strips of rubber around the windows and doors, the rounded edges and
thin strips around the driver's cabin all make the overall aesthetic sit more
into a 'realistic shapes' art style that isn't typical in Minetest.
That might all sound nitpicky but other train mods have usually fit into the
block game aesthetic better, while still managing to look quite good. For
instance, while I can appreciate the effort that went into make a physically
accurate pantograph, I can't help but feel like the JRE-E231 MoHa wagon had a
better looking pantograph for the block game aesthetic, even if its texture is a
bit too flat. Another example is the moretrains 'Old German Diesel' which has
windows that obey the normal pixel size and the curvature/angle of the window of
that locomotive is drawn into the texture instead of what appears as polygons in
the Minitram
The wheels approximately sit on the rails correctly, which is always a good
sign, however given the detail paid to the pantograph I would at least expect a
flange, but it seems the polygon budget went on the suspension of the bogie. The
way that the bogies and wheelset don't attract the eye but do look quite
accurate upon further inspection is quite good, similar to the real experience
of look at a tram's bogie - something only the enthusiasts will do.
The door animation is smooth and nice, and much better than having no animation
or no doors.
Crafting
I'm left wondering why are the minitram recipes a mod instead of a config option
to enable/disable them? Dependency 'clean'liness?
At a glance, there seems to be a reasonable balance of complexity and costs in
the recipes, without evaluating them in-depth. What can I say? I'm not an expert
at survival Minetest but I very much appreciate survival mode recipes even
though I usually play advtrains in more of a creative mode way.
The onboard experience
Another bug sadly detracts from the onboard experience, and I think this one is
pretty frustrating. I am using Minetst 5.5.1 in this review, and you literally
can't rotate the camera when the tram/train is in motion in singleplayer.
Attachment offset patch doesn't hinder or help. Obviously this is a Minetest
engine or advtrains bug, but I did have to mention it because looking around
seems to be an important part of what is billed as a tram for enjoying the
scenery.
Maybe the left and right seats are too far towards the window - the player model
head is actually slightly outside the body of the tram, as seen from viewing
from the side.
Painting
The painting bugs first:
A bike painter with no metadata (never used formspec) will crash the server if
you try to paint the tram with it. The same thing on a bike won't crash the
server, just generate warnings from the bike having a bad texture modifier.
Saving and loading liveries works just fine, but I would very much like to see
persistence added since making a livery is hard work. Now, you might have a
wagon with the livery you want to copy nearby every time you are painting
wagons, but then again you might not, so persistence is really quite a good
future goal.
Painting is done with the bike painter. Painting is unintuitive in many ways,
mostly due to poor UI rather than poor design I think. The bike painter is a
poor tool for the job, due in part to the facts that (1) the RGBA sliders move
in increments of 2 or 3 by default (2) not everybody knows how to perform
arithmetic in hexadecimal to set exact values, and those who do would still
rather not have to. (3) the alpha channel has no effect on the tram, it's just
there for the 'meta colours'.
I also really think the body of the tram visually lacks any texture at all,
which makes it less fun to paint. It's actually pretty fun if you do work it out
though - I managed to make an passable interpretation of Melbourne's PTV/Yarra
Trams Livery to make my Konstal look more like a Melbourne A-class, using this
livery:
(layer - component - component name = colour)
1. 1 Side walls = #ffffff
2. 3 Doors = #ffff00
3. 4 Lower skirt = #4d4b4b
4. 8 Window detail = #4ab909
Visual Line Numbers ('destos')
First the bugs again:
Negative line numbers generate errors (don't worry, advtrains_subway has a
similar bug :)
There seems to be no upper bound on the numbers it will accept.. does Lua use
arbitrary precision??
The feature set is impressive, and doxy has achieved in a short time what
advtrains users have wanted for years. That said, I have no idea what kind of
performance impact it costs. I haven't empirically tested anything yet but I was
experiencing some frame drops when painting a wagon that had a destination
display enabled - does this same experience occur when creating each tram entity
that appears? That would be cause for concern.
Adding to my fake "Melbourne" tram I approximated an orange dot matrix display,
using the following text:
{text:#ff7122} {background:#222} 109; Box Hill; via Richmond, City
The fact that the 'Outside text' is used is understandable, because the
alternative of actual Line Numbers is not feasible, as that information is used
for automatic train routing.
I've discussed this with doxy directly before, but: Melbourne gunzels call these
"destination displays" rather than "visual line numbers", since after all they
are more than just a line number. "Destination display" gets shortened to just
"desto" as well, as in "That tram has 'City' on its desto" (as many trams in
Melbourne once did and still do). All that to say there's definite room to
shorten the name or at least make it more semantic, which might happen in a
future release.
Coupling
While the mini tram is at the forefront of a lot of advtrains features, it
hasn't added coupler type definitions. Judging by pictures online you should be
able to couple them together, at least to each other; I don't know what coupler
type would be used. If they're only permanently coupled sets then I would make
it a minitram-specific coupler type.
Sound
There is no sound :( If I recall correctly the author doesn't normally play with
sound and has decided to keep it that way. If it were up to me, every tram would
have some nice recorded sounds including bell sounds, but sadly not everybody is
a sound nerd when it comes to rail transport, nor does everybody play with sound
enabled in Minetest.
A list of sounds to include would be:
- Motor sounds at low and high speed, and startup and stop sounds.
- A bell sound for the horn/Aux1.
- Door sounds.
All of which are quite feasible to record for a railfan with a microphone,
(perhaps something a little better than a phone is needed though) and some time
on their hands, and of course physical access to a tram at a quieter time of
day.
Conclusions
Doxydoxy's mini tram and associated libraries are technically impressive and
will hopefully help advtrains as a whole progress. The modpack is technically
impressive although it lacks a good GUI to help non-powerusers, a problem which
is quite feasible to address. Thankfully, it comes with copious amounts of
documentation, in which the author lives up to his name of "doxygen spammer".
However, reading READMEs is quite unfamiliar especially to ContentDB users.
The library mods multi_component_liveries, attachment_offset_patch and
visual_line_number displays highlight gaps in wagon functionality in advtrains,
and I hope to see at the attachment offset patch and some ideas from the livery
functions make it into advtrains core.