Narissis

I think what Murdoch is saying is that the problem this design is looking to solve doesn't really exist; the connections between regular pieces of straight track have enough room to flex that the track will naturally form this incline regardless. That being said, I do appreciate the effort to create a piece that avoids any stressing of the track connections and provides a curved transition without the slight 'knuckles' that standard track develops when it's angled relative to adjacent pieces.

Here's a handy article by Michael Gale about cleaning and restoring 12V track. Might be helpful!

I'm not sure about the PCB but I can tackle the other question based on my conversations with Michael last summer at Bricks in the Six. The intent is for the motor bogie to come in two versions. The cheaper version, the 'dumb' motor, will have contacts on two sides. One will be a direct pass-through from the track to the contacts, and the other will be a motor input. There will be a jumper (or perhaps a switch in the final version, as suggested by the drawings) on the motor that bridges these out of the box so it'll work like a standard 9V motor (but supporting up to 12V as implied by the power components illustrated in the update), but if the jumper is removed you will be able to put your choice of control solution between the track output and the motor input on the bogie. That could theoretically be FX's own PFx Brick, a Power Functions IR receiver, or some other third-party solution. The fancier version, the 'smart' motor, will integrate the PFx Brick electronics directly into the motor housing so you'll have that control functionality as a turnkey solution. Obviously this version of the motor will be priced higher. Obviously all that is subject to change as product development continues, but this was the understanding I left that event with. There was also some talk of maybe having standardized DCC support in a future motor project, but I think that's a bit beyond the initial scope. Could become an option on the 'smart' motor, or maybe be added as a third motor variant. Could end up on the cutting room floor. Time will tell!

Looking at the two, it looks like the only substantive difference between the two is that the FX Track R72 is the same size as two TrixBrix R72; if you use the FX Tracks instructions and ballast the TrixBrix rails in assemblies of two, I don't see any reason why it wouldn't work. Alternatively, look at the FX Track instructions and note the repeating pattern; all you'd have to do to ballast the shorter TrixBrix R72 pieces individually would be to replicate each end and then just infill the same pattern in between the ends; it simply wouldn't repeat as many times. Obviously doing it this way would affect the manifest of needed parts, though, so you'd have to suss that out to acquire the pieces.

I think the manual workarounds make it not completely a dealbreaker, however it does mean having to have all parts of the yard within arm's reach, which can be a problem on big layouts. Hopefully the smart motors arrive within the year so we can have an in-system control solution!

Finally a post appeared that made me stop lurking and actually sign up to answer, haha. So, yes, with FX Track switches, all routes are electrically live at all times. This, according to Michael's own writings, is "for our own good," though I personally feel there should be an option to make them work like LEGO 9V switches. That being said, the intent isn't that you use third-party DCC, but rather that the switches be used as part of the larger FX Track ecosystem which will, eventually, include motors that are designed to be more easily compatible with the PFx Brick, or in the case of the 'smart' motors, will have that functionality integrated. The problem, of course, is that presently there is no way to feed power from the rails through a PFx Brick to a PF or PU motor with off-the-shelf parts. I think this is probably one reason why Michael is prioritizing the power pickup axle over the FX Bricks motors in his product roadmap - to enable the use of a PFx Brick with FX Track and a train motor as early as possible. In the meantime, with only 'dumb' 9V motors available and the switches not cutting power from diverging routes, we'll have to make do. For my part, I will probably just lift the motor bogie to the side a bit on any train I have parked. Not ideal, but it'll hold me over until the smart FX Bricks motors arrive. Another option would be to insert one length of plastic track near the front of each siding and nudge the motor onto and off of that. Either way, it does mean employing the 'hand of God' but I've observed at many model railroad shows that this is not exactly verboten since all kinds of model railways occasionally need a little persuasion. :P In the future, there may also be FX Track isolators available, which would provide a means for turning off those diverging routes. But I have yet to hear firm plans from Michael on those, so I wouldn't expect them anytime soon. For my part, my plan is to upgrade to the smart motors when they're available, which should be sooner than whenever we get isolators. One other thing: the jumper isolation, as zephyr pointed out, only works for one rail - that's because it's designed for crossovers, in which case when you remove the jumper from each of the two connected switches, then each one isolates one of the two rails from the connected loop so the ultimate effect is isolating both loops from one another. They're not meant to be used for any feature contained within a single loop; you would still get a circuit conflict if you built a return curve, for instance, even with the jumper removed. In cases like that you would need to insert some other kind of isolation, like including a single piece of S1.6 plastic rail, or taping the contact surface between two rails. In the case of a return loop, this would of course mean the polarity would reverse across that gap so a standard 9V motor would get stuck, but a motor controlled by a PFx Brick or some other kind of controller that doesn't care about polarity would be able to handle it just fine.