| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
The code I wrote worked only for my y-turnout and 3-way variants because
it assumed the variant name == the switching state, which is obviously
wrong for the default sw(l|r)(st|cr) variants. I have added a
'switchprefix' property to address this.
|
| |
|
|
|
|
|
| |
I chose to make three-way turnouts have 5 conns (last one is not used) so
that they can be distinguished from crossings easily without refactoring the
code. Three-ways should have their last entry with {["3"]=0} instead as a sort
of internal mark.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add two new sets of diamond crossings in addition to the current set
of perpendicular crossings. Also cleans up the inside edges on the
perpendicular set models. All of these varieties have their mirror
images, which was previously a problem with the 45/90 crossing.
The naming convention for all of these rail types is this: when facing
east and param2=0, the angle and direction of the two crossing rails is
indicated. So 30l45r means 30 degrees left and 45 degrees right. The
mirror image of that would be 30r45l.
There is a recipe for each set of crossing types and the trackworker can
change geometry within types with left cick, and rotate between two 90
degree rotations with right-click. When left-clicking, the angles move
in an intuitive fashion like rotating rails.
* The perpendicular set (already existing) has rails that cross at 90
degrees.
* The 90+x set has 90 degree (straight, node aligned) rails plus a rail
intersecting that at 30, 45 or 60 degrees.
* The diagonal set has both rails not axis-aligned, for example 30r-45l,
60l60r. The latter is quite useful for scissors crossovers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a set of new models for crossings to make some new track
arrangements possible. This commit adds perpendicular crossigns that can
be rotated at any angle: 30/45/60/90 and 45/90 degree crossings in two
rotations. In future, further crossing types can be added to the blender
file.
Add the blender file in rail_crossings.blend that is the source of these
files and which refers to the texture inside advtrains_train_track.
Add a set of prototypes for rail crossings to advtrains/tracks.lua and
register the new crossings in advtrains_train_track.
|
| |
|
|
| |
Allows defining a suitable substrate for tracks, and liquid pointable tracks
|
| | |
|
| |
|
|
| |
to remove dependency of interlocking on luaautomation
|
| |
|
|
| |
Missing things: signal aspect updating, waiting routes handling, management /info tool
|
| | |
|
| |
|
|
| |
Missing: ATC stuff, yaw problems
|
| |
|
|
| |
See privilege_guide.txt for information
|
| |
|
|
| |
(also fix the output of /at_sync_ndb)
|
| |
|
|
|
|
|
|
|
| |
...to support an arbitrary number of connections for rails, which leads to these new features:
- switches now get recognized by the trackworker correctly
- ability to add real rail crosses
During this, I also rewrote the rail registering system and the conway function (important part of path prediction)
Note, developers: the track preset format changed, you might need to rewrite them according to the presets in tracks.lua if you wrote your own
(possibly breaks advcarts)
|
| |
|
|
|
|
|
| |
Bug was caused by the drives_on table of every train and advtrains.all_tracktypes
sharing the same reference, which caused advtrains.all_tracktypes to become the
intersection of all train drives_on's in the world.
However, this did become empty, causing nothing to work anymore.
|
| |
|
|
|
|
|
| |
nnpref
This finally fixes the need to rotate atc rails and bumpers.
Also prefers rotation that is closer to the player's look dir (placed bumpers will face the player)
|
| |
|
|
|
|
| |
into a library mod
advtrains will keep its own node database code for reasons of crash recovery, with the handicap that improvements to nplib need to be manually backported.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
wagons
|
| |
|
