clean up train building code, and use that to make it such that we don't place duplicate rail pieces

[ahicks92]

Looking at the train builder, what we actually have is a bunch of lookup tables hardcoded into functions, also including some inventory logic specific to each kind of thing. If we lift these to proper lookup tables we can loop over them and build. Once that's done, we can then easily add a check to that loop to see if there is a matching rail piece already present, and if so, just avoid trying to place it.

I put the LUT in here because in 2.0 we will be at least doubling the number of these that we need. The followup to this issue that is sort of in scope: we should figure out if we can transform (as in transformation matrix/geometry) these so that we don't have to have n lookup tables per corner and can reduce to just one. This part needs to be done by someone sighted.

[LevFendi]

The LUT stuff is big work but it is doable. Simple translation from function args to LUT values does not need sight. Maybe a quick and clever regex solution can be found.

The transforms of LUTs for rotation are not trivial but a rule could perhaps be figured out by experimenting, and that part would need sight.

[ahicks92]

The first step isn't trivial no, but it's manual gruntwork. Time consuming but not hard. I will eventually if you don't.

The rotation stuff--I mean if we can generalize it then I or other blind devs could add new things to the train builder menu maybe. Dunno. If it's too complicated lookup tables aren't the worst thing in the world to have. It'd just be nice to, well, not.

One interesting thing though, if we switched this to something that knows how to lay any of the 3 rail pieces on a given rail end or otherwise then we could just do these as like straight left straight left strait (90 degree turn) and then because we can lay things on top of each other a fork is just adding a turn the other way.

[LevFendi]

I agree with the rest but your latest proposition has a UI problem that has been around since day one: When you drop the left turn, the end rail you had before is no longer an end rail. The player now needs to both find the correct mid rail and declare the appropriate right hand direction on it, as there are two.

One idea is to identify it as a "corner rail" using the fact that it has a curved rail attached on one end and straight on the other. Then it could have a menu option named something like "complete the fork".

[ahicks92]

No I'm not saying we expose that to the player. I'm saying that internally really what we have is just multiple lists of turns from a given start point and maybe that's useful as an internal abstraction, since it doesn't rely on very precise geometry and can be rotated freely as long as the piece that knows how to extend a rail can handle it. Basically we handle the couple cases you can do today with alt+left/right and just build everything from those. Again though, internally. This isn't a proposal for extending the UI.

I suspect we just do the LUT approach though. It's just an interesting maybe fruitful idea.

I have issues with how you can only build turns on end rails but I also am aware that it's not that simple to expose. That's another topic. At this point I don't care how horrible to use it would be as long as it's less horrible than mining pieces, but it's also another discussion entirely. I do have an idea I should write down somewhere though.

[ahicks92]

We like trainstrings. I'm going to close this and open an issue later today with the minimal amount of work we would need to move current mod stuff to trainstrings. Let's not waste a ton of time only to redo all the work again in the near future.