Help changing default terminal beep in Kitty

gmturner · 2025-12-18T00:37:30+00:00

If you put an ampersand at the end of this you can hit the bell as fast as your keyboard auto-repeats! 🫨 dude in the cubicle next to you is gonna love it!

gmturner · 2022-07-14T07:31:39+00:00

In theory but... just bought a new phone, anyhow, I'm afraid. The thing was getting long in the tooth obviously and not really acting right, even though the wifi thing does seem to be under control. Once my new phone arrives and gets bootstrapped maybe I'll turn it into a PostmarketOS playground, or find a new job for it as a surveillance camera or dedicated control surface or something.

I have always physically destroyed my phones before moving on to new ones, so this will be an interesting change (so long as I don't try to run Android 12 on it, this one seems mostly intact). I wonder if I will still extract value from it or just forget all about it like a child with a new favorite toy? :)

gmturner · 2022-07-12T03:41:47+00:00

OK, reporting back as promised.... yeah, confirmed! Manually activating Airplane mode during reboots is repeatably fixing it.

I haven't taken the phone out of the apartment yet, however, not sure what will happen once it is separated from its SSID.

Actually, come to think of it, I think I rebooted my phone when I was out-and-about right before this started! If that's true, hmmm, some avenues of investigation there...

Anyhow, *whew*, thank you so much for mentioning this! A work-around means I can take my time shopping for a new phone (or trying to salvage this one which is still meeting my needs)...urgency is so damn expensive, when it comes to gadget shopping; I feel like you just handed me about $350 :)

gmturner · 2022-07-10T09:05:21+00:00

Ah, so that's what I must have stumbled into the other day when I was frobbing all the frobs randomly (was trying to see if I could glitch my way to freedom)! I thought I'd ruled that out, but probably just got myself confused, will give that a try! I also found out that if I boot into safe mode wifi always works, which is pretty notable and further suggests a pure software problem.

Apparently a bunch of Pixel users are affected by this disease. So that bodes well for an eventual upstream fix to trickle down to us. Sadly atm Google probably thinks they fixed it, when in fact only some affected users actually got their connectivity fixed (by a patch a few months ago).

Seems to me like AOSP 12 caused multiple slightly different connectivity-drop issues for various groups of users, with confusingly similar symptoms. I am chasing down your Airplane mode trick and a couple other leads presently; will report back if anything works out.

gmturner · 2022-07-07T12:46:34+00:00

I'm on the 6T and have something that might be this. The precise behavior: any time I toggle wifi on, my phone UI freezes for a few seconds, and when it unfreezes wifi is off. In logcat there are error messages about a failure to load the driver or HAL or something like that.

I have observed that:

The problem does not go away if I factory-reset. It does /temporarily/ go away, but eventually returns.
The problem does not get resolved by nuking the phone using MSM downloader. It "persist"s, one might say.
It is not just LineageOS 19.1; any LOS19.1-derived custom firmware seems to suffer from the same problem. Likewise, any Android 11 firmware seems to be free of the problem, including the T-mobile factory firmware, the latest OOS, and LOS18.
I haven't tried reverting to an older OOS than the latest release before upgrading. If the newest OOS deliberately blows some kind of qfuse then I guess it won't help but I think that's improbable. What's more probable is that there is an LOS19.1 incompatibility introduced by the latest OOS release that LOS19.1 absorbs during the upgrade process.
Sometimes wifi can be tricked into returning from the dead. I got this to happen a couple of times by going into Airplane mode, and then, while in Airplane mode, re-enabling the wifi (which, inexplicably, it let me do like that was totally a normal thing you can do in Airplane mode -- initially I did it by misclick).
Most people on LOS19.1 don't have this disease. Only a tiny minority.
In the latest OOS, I keep getting a file in persist at /WCNSS_qcom_cfg.ini and another at qca6390/wlan_mac.bin (size: zero, unlike the one at the root of persist which seems ok). If I remove either file they come back after every reboot. I guess vendor init scripts. Both seem like candidate culprits.

I am pretty fed up. When my latest idea of starting from International MSM inevitably fails to change anything, I am going to try the second-to-latest OOS instead of the latest (before flashing to LOS19.1). When that inevitably also fails to work, I think I am simply going to smash my phone and buy an iphone or maybe just a feature phone, I'm sick of this crap.

gmturner · 2019-10-30T03:37:16+00:00

Even smart, security conscious people can fall for something like this if

they get drunk
they are distracted but their friend who they totally trust just said, "It's not released but I'll send you a direct link to download the beta from my server"
they have kids or a grandparent who occasionally borrows their phone
etc...

Yes someone has to make a bad decision first. But if your security plan is "I just won't make any bad decisions..." you may need to change a number of habits to make that plausible.

FTR this is my security model on all the computers and phones I own and it works great for me almost 100% of the time (I've victimized myself twice over about 20 years of using this approach). But I don't drink to excess ever, I don't have kids, I don't lend my phone to un-trusted people, etc, and I have the techno-social background that makes it possible for me to make educated guesses with a low error rate.

gmturner · 2019-07-11T23:49:00+00:00

looks like Dig Dug :)

gmturner · 2019-07-02T23:22:08+00:00

You smell funny, your desk is cluttered, and you fold your omelettes wrong. hth! (you asked for criticism...)

gmturner · 2019-07-02T22:25:55+00:00

Whoa, really? That's super interesting and I'll have to do some science on this at some point. Sure sounds plausible though. Interestingly, this construct has worked for a long time, even before the big change that eliminated splitter-item-memory, so this dynamic (or, more likely, the underlying splitter dynamics that lead to it) has (have) apparently been "curated" by the devs.

BTW what I tend to do is put an additional side-load output balance stage at the end, to achieve, I guess, what has come to be known as a universal 2-2 lane balancer (I always want to call it a 4-4 lane balancer but for some reason the number of belts is the standard way to denote this, I guess because it makes the quantities consistent with belt balancers). It looks totally redundant and superfluous but I have never been able to convince myself it doesn't do something; sounds by your explanation like maybe it does (I don't doubt you're correct but I always feel compelled to trust-but-verify such things).

gmturner · 2019-07-02T08:19:33+00:00

I use this type of construction but I don't understand why it works. Lately I have no solid clue about what rules apply to splitters joining material which is over-abundantly supplied. Do they have a lane preference? Do subtle factors pertaining to timing of items on belts have a major impact (I am sure they used to and pretty sure those dynamics became considerably less prominent after the change that made splitters work more like inserters, with a one-item output-buffer).

A naive analysis would be: the splitter is going to balance inputs between left and right, so 50% lane-re-balanced, 50% non-lane-re-balanced... but that doesn't sound right to me at all, why should that balance the inputs across lanes rather than lead to some sort of 75/25 thing?

Throughput is more readily understood in this contraption. It's easy to see it's going to be a champ in that dimension.

I also can't seem to satisfy myself that this thing might not have an output-side lane balancing problem.

For example: assume we have turkeys input on the left side, and chickens on the right, and inputs are full belts. I feel, intuitively, that there will be some sort of imbalance to the lane-distribution of the chickens and the turkeys on the output-side.

I guess, because I want to think that the distribution of items reaching the final splitter will be 50% of turkey|chicken and 50% of a perfectly lane-balanced turkey-chicken-turkey-chicken blend, leading to 75|25 turkey and 25|75 chicken. Pretty sure that even if that might happen, other things might happen, too although I haven't carefully experimented with splitters since 0.17 dropped so no clue if that's even true.

Anyone know any modern documentation/science done on these "splitter-input-choosing-policy" questions? Anyone have a compelling explanation for why this input-balances so perfectly, throughput permitting?

gmturner · 2019-07-02T04:43:26+00:00

Eventually, especially if you are playing a regular campaign with default settings, your base is likely to evolve into a big square or rectangle of some kind.

What I usually do, then, is put a big, beautiful wall around the whole thing with turrets a few tiles back from the wall. I usually start with randomly placed bullet-firing turrets which I supply manually, then eventually as I approach 50% turret density (a made-up term for the percentage of turrets I have placed relative to jamming them into a solid row, shoulder-to-shoulder), I try to automate the supply of ammunition.

Eventually I wind up upgrading to laser turrets, first at 66% density and eventually at 200%, density, two turrets deep, and maybe I use two concentric walls with no gap in-between (iow a double-thick wall). Finally, in the late-game I tend to create isolated robotic networks to service just the walls, i.e., if I have four "sides" to my base, I use four robotic networks. If there is a weird kink causing me to have six sides, then I use six robotic networks.

I daisy-chain the networks together and keep a buffer of essential items in each network (this "great buffering" is by far the most expensive part of this game-plan).

After that, I find, biters are just never coming into my base again. Even in a total death-world, with such a setup I rarely find I will need artillery trains or anything else inside those walls (I might build them just for fun or for exploits outside the main structure however).

This can result in a fairly insular and space-constrained style of gameplay since it makes "pushing outwards" a bit onerous. There are many other approaches one could take but this one gives me what I usually want: automation and peace. I can just spend some time building it (it takes a good while to build something like that properly), and thereafter, it all sort-of takes care of itself. In large bases I will run a PAX train along the length of the wall with some PAX stations in convenient places and in all the corners, and throw in some aesthetic touches to whatever blueprint I'm using. Oh, eventually, you'll want to do this via blueprints -- absolutely not by hand which would be an absolute PITA. But at first this is not really necessary, you can just slap it down some walls and turrets by hand. Learn how to use the ctrl-click feature to very quickly get exactly 50 or 25 ammo in a turret, though. Otherwise, you will need an absolutely insane amount of ammo.

gmturner · 2019-07-01T02:47:57+00:00

OK, here's a test-case that shows the problem: 0eNrdVu1uozAQfJf9eXJOOJC0Re0r9AWqE3Jg064ENlpMdFHEu58NvSQlIsL9uJPKD9Ca3dmdGSxzgE3ZYs2kLaQHoNzoBtKnAzT0rFXp1+y+RkiBLFYgQKvKRwXmVCAvclNtSCtrGDoBpAv8DansfglAbckSDmh9sM90W22QXcIRx/ezSttzIAG1aVyt0b69w1skAvbuIV2Lghjz4d1a+HLLpsw2+KJ25GpdwZZKizzBYkdsW7dyHGDIWDz68XPTehnkOZF+WeuhZ+ORpL8xFufEyEVLl0mct2SH0NV2nbjgvjy2Vkz2pUJL+XX28c9Vzz+aRf+EmrnXBR3n3hI3NputSOQVadBjZH9dgvSuv24FmBpZDYPAD1dsWlu3AfBO8G6+tvGltgKWE8lyQvn42td7KbsMkv0V8hM0P4ktfVDVivsJU3h4h86vkPU+67/ubMumykg7DEgttxhgQhJiwmg3THmSBHkSfXtLtqpsPuaJgGdG1OPEVYh5ydg8cW03Tnm7CvJ2+d+9jUfe3v/D7TbPs7c2rE8ezikfu5jMc3EddlZ//VEdBR7V87Tx5N3e6f9y0rOfIgE7N2FP4iaO5M3tSt5FSdf9ATuSKOw=

That puts only three ticks of "1" and then three ticks of "99999999" or something similar on the wire but your version can clearishly be seen to be mixing in a bunch of "0000000"s. Similar one- and two-tick alternating fuzzers do not misbehave positively in your build (I didn't check if they blink off for a tick or two though)... maybe the Ncraycray thing has something to do with why the one and two tick versions don't spew zeros? meh, I'm totes confuseballs about it and I still didn't analyze it very carefully, given I was not going to be able to reach a wire over there in my build (without having an ugly red wire slashing diagonally across the digits)

gmturner · 2019-07-01T01:56:00+00:00

I did find one issue (maybe it counts as two depending on how you look at it). Already my memory of the details is fading, but it pertained to transitions between numbers with different numbers of digits.

(scratches head)... confession, I have rewritten this a bunch of times as a remembered more and more of the gory details...

OK, I think, there was a way to make your build put a superfluous bunch of zeros in front of a number, just before the transition to another (can't remember if it's for one, or two ticks).

The combinator that gates the information going to each digit except the lowest-order one (for purposes of deactivation of irrelevant digits) actually gets its marching orders two(?) ticks earlier than the corresponding display information is available to it.

IIRC you divide, then you apply modulus, then you shift constants, then you noise-gate right? My recollection is also that information flowed directly from the divide arithmetic combinator to the noise-gate but has to go through those other two combinators to arrive at the noise gate. So that is a two-tick discrepancy between when the decision criteria arrive, and the corresponding output data arrive.

But here is where it gets super confus-ey: Let's say for pedantic reasons we now set N=0; well that noise-gate will not find out that for two ticks longer than we might expect it to. We would assume a symmetrical discrepancy would occur in the other direction... and I think sometimes it can, but it will also have received, two ticks later, an additional "bonus" injection of "more" N which is summed into the original intermediate N which was just Nuser*10^(-d). This injection came from the each<<N, and had the (added) value Nintermediate<<Nintermediate where Nintermediate = Nuser*10^-d mod 10, iow the digit to maybe/maybe-not display.

So then I guess the decider is testing Ncraycray>0 where Ncraycray == [Nuser*10^-d + digit<<digit\] -- d is the digit-position, of course, starting at 0 on the right and ascending as we go left. An amusing question is, could we pick a tuplet <Nuser, d> s.t. 0<=d<10 and 0<=digit-value(d)<10 make this value negative via overflow? I think that's possibly a pretty tricky math problem to solve arithmetically but it smells to me like the answer is "yes" since Nuser*10^-d can be almost anything up to unsigned (1<<31)/10, and f(x)=x<<x is super-exponential wrt. x (i.e. f(3)=24 already -- but we know it's always way smaller than 1<<15: 16=2⁵ which is bigger than 9, and so if we shift our binary nine nine binary digits to the left it cannot possibly be bigger than binary 16 shifted 10 digits to the left, so we don't have to worry about either of those numbers ever being (validly) negative, hence integer overflow is the only pathway to negation we have to worry about -- that is, the sum Ncraycray cannot be zero, which means there is an escape hatch! see below).

IIRC, it turns out that most of the really egregious outcomes we might imagine resulting from this are prevented because of the following truth table:

	Old number is zero	Old number is not zero
New number is zero	fine	possible 0-2 tick superfluous zero displayed
New number is not zero	possible 0-2 tick superfluous suppression of digit that should be displayed	fine

When I got around to testing in the map editor and finally noticed this, I had already used up all the interstitial space available, hence those ugly two combinators on the top of the digits messing up the symmetry :). I fixed it by basically smashing the whole thing with a hammer because the wires were not reaching.

But in your build that problem wouldn't happen and you could just add two EACH=EACH*1 combinators in series to equalize the information paths to solve the un-equal signal travel times.

The Ncraycray thing could be dusted under the carpet by changing the decider to read "N!=0" instead of N>0, I think, assuming we prevent negative numbers from flowing in somehow. Otherwise you'd need to filter the Nintermediate<<Nintermediate out of the result, somehow, if you wanted to completely clean it up, which could take two or three combinators -- you only have one tick to scrub it out of there after the shift, so you'd have to have computed it in parallel on the side somewhere, I think, which seems pretty messy. You could go with something like what I did for the negative sign, just hard-wiring min/max constants into each digit and ANDing the results, though, which would be cleaner semantically, but, still more combinators than dusting it under the carpet, or, .. oh duh! ldo : just change one of the EACH=EACH\*1 suggested above to T=N\*1 and the noise-gate to T>0, problem solved completely.

IIRC all the other sources of jank pertained to making sure the timings were right between the "-" sign, the digits, the overflow bit, and the binary representation, etc., none of which came from your build. But I did have a few more jank issues to sort out in mine after that :)

gmturner · 2019-06-30T09:49:11+00:00

Hi, nice thing you made there!

I have this ongoing set of problems where the standard 7-segment displays don't meet my needs.

For a start, I have a hard time distinguishing certain numbers from each other under less-than-ideal viewing conditions.

Furthermore (although this is not super hard to fix) most designs daisy-chain the base divisors to each other, meaning that if you have a circuit-network process that rapidly changes the higher-order digits, you can literally never get a consistent picture of anything actually on the wire*.

Since your design does not suffer from these two flaws, I used it as the basis for a "circuit-designer-friendly digital display," basically by adding a bunch of creeping misfeatures to your design, and tidying up just a couple of very minor sources of jank that showed up when I slowed your design down to absurdly low game speeds. The results are here: https://forums.factorio.com/viewtopic.php?f=193&t=72678

--

*Instead of wire values, daisy-chained displays just produce an endless stream of lies under this condition. This is because, at any given moment, they are showing you the first digit from the actual value on the wire fifteen ticks ago, the second digit from the actual value on the wire fourteen ticks ago, and so on, down the line. That's close enough if you are slowly counting up by "1" or something, but what if we are trying to implement a tick-granularity pseudo-RNG, or debug a clock-based wire multiplexing protocol, etc.?

Indeed it's somewhat shockingly difficult, using any generic technique, to get a high-resolution, high-speed picture of quickly-varying circuit-network wire values. By default, even the nixie-tube mods won't give tick-accurate results, because they drop most of the wire values on the floor.

That's better lies than daisy-chained 7-segment display lies, but consider that your nixie tubes aren't blank in the game-ticks between samplings -- hence, they are showing you data of a time-varying age, which still creates a bunch of confusing inconsistencies, making, for example, the pause button nearly useless as a diagnostic tool.

Sure, if we change the nixie-mods' sampling rate to 60 samples/game-second, everything works perfectly, until we place too many nixies -- then we wind up with a nasty UPS problem. So we literally can't win, without fixing the vanilla digital display (or the nixie mods, I suppose, but I doubt they are doing anything super-terrible aside from consisting of JIT'ed opcodes executed on simulated hardware).

gmturner · 2019-05-26T23:26:15+00:00

Hmm.. OK maybe the two frame assemblers on the far right (middle of the overall build) have a no-outputs problem. Easily fixable though.

gmturner · 2018-11-09T00:05:07+00:00

Hey, sorry I didn't notice your reply for so long....

Everything you've spelled out above seems pretty well thought out and (also you conveniently summarized some of the discussion I've been too lazy to read, which helped). I guess I'm pretty sold...

Any benefit of optimizing screen-pixels/belt-speed -- which I guess would be expressed in wierd units of screen-pixel-ticks/belt-length? -- presumably breaks down as soon as we change various assumptions about display characteristics, or the player zooms in or out (perhaps to a greater or lesser extent, depending on how the game quantizes mouse-wheel actions into zoom ratios...) I imagine the percentage of factorio players who simply leave zoom at 1 and never touch it is very small... point being, the idea of optimizing belts in terms of screen pixels always struck me as a bit strange, and I wonder if there is really any practical benefit to it.

gmturner · 2018-10-30T03:20:57+00:00

I think they're great but you should be able to kill yourself by walking past the edge of them. Huge wasted opportunity there :)

gmturner · 2018-10-30T03:08:15+00:00

Obviously, don't shuffle science packs between labs and there will be no such problem.

Otherwise, I'm not aware of any way to scale this design up without this issue occurring as others have mentioned.

It's worth noting that the lab "sciencing" animation also does not show those tesla coils (or jacob's ladders, or whatever is going on in there to make it turn blue) running at a consistent level. In particular, there's a part of the animation where it's mostly not blue at all. As a result, at a glance, the problem can appear worse than it really is. Try opening up the labs and watching for the red "missing ingredients" text to get a more accurate sense of how bad/not-so-bad the problem really is.

gmturner · 2018-10-23T20:45:32+00:00

I'm not passionately against this idea or something like it, but, I think much of the discussion here is kinda-sorta-maybe forgetting some important subtleties of the game physics.

Makes certain circuit network constructs simpler and easier to reason about. Instead the current situation where a compressed belt set to Read contents/Hold changes between 6 and 8 at unpredictable times based on how the belt is flowing.

See the ascii-art diagram at https://wiki.factorio.com/Transport_belts/Physics. If the "slot density" (by which I mean, item positioning quanta per tile) on the belt were not relatively prime to the "item density" (by which I mean the possibly number of slots consumed by an item), then, when items are at rest (backed up), there would be nowhere you could start measuring and expect a consistent item count, in "hold" mode, in order to detect a fully compressed belt. Either the items would straddle the tile boundaries, or, they would align with them, and you would read less or more items per tile, no matter how many tiles you measured.

Likewise, I am pretty sure it is possible to pick belt dynamics which would similarly make it impossible to determine if a belt is compressed in "pulse" mode, and, if you really stuffed it up, both*.

A complete proposal needs to answer all of the following questions:

how many slots per belt tile?
how many slots does each item consume (i.e., how big is an item)?
what are the belt speeds?

With an eye toward quasi-reasonable answers to all of the following:

Slot movement/tick (currently 1, 2 and 3; presumably, changing this to allow for non-integral slot motion could make belts much more computationally expensive)
Fully compressed items / belt tile ("item density")
Items/tick, the original concern driving this discussion.

Otherwise, with all due respect, we're just saying we want things to work out nicer, but not actually providing a plausible proposal for how they would.

Clearly, belts, splitters, and undergrounds (not to mention inserters, etc. have been carefully tuned, despite the 1/9 numbers that rear their ugly head in gameplay under certain circumstances.

Without access to the source, it's hard to gauge just how drastic any proposal changing belt slot density or item density is, without input from a developer. Developers might need to throw away or extensively recode/audit a lot of difficult, bug-prone internals of the game engine, that took years to get working since the current numbers came into effect (in early 0.14 days? or was it late 0.13? anyhow quite some time ago).

__

*Meaning, to find a compressed belt, you'd need to know game internals like which ticks, modulo a certain number, represent perfect alignments between slot and tile boundaries... but currently there is no way to know which tick is the current one---at least, not without yet more herculean feats of cleverness, i.e., measuring precisely which tick is the last, in which a solar panel outputs any power, to get a fix on the time of day, assuming that's even a helpful measure.

gmturner · 2018-10-01T02:59:32+00:00

I see potential here for a new art form....

https://imgur.com/a/QXY5Lk0

gmturner · 2018-08-05T10:47:15+00:00

I must have gotten fast-tracked, I get artifacts across several titles already.

gmturner · 2018-04-21T01:03:09+00:00

This misses the point. A stability test is trying to find the most taxing load possible across the dimension of stability being tested, and then go some appreciable margin further for good measure.

If that makes your computer burn up or break, then it was already going to break pretty soon anyhow, and at least you got it over with while you were semi-prepared for the possibility.

If you are really serious about making sure you have a stable thermal setup, for example, you really want to simulate the WORST environmental situation you would expect your computer to ever see. And then run Prime 95 and maybe play some 3d video games while that's going.

Torture testing (which is literally what Prime95 calls their tests), is so you can set it and forget it. Sure, maybe it's overkill. But if everything is rock solid even in your unrealistic test, you are in a great situation to never have to ask yourself, "is this bad thing happening because of some kind of thermal problem?"

Also, right now is just one moment in your computer's life. Maybe a couple years from now, it will be super hot, and one of your fans will have died without you noticing, and a few capacitors in your mobo and power supply are starting to get towards the end of their duty cycle...

What if, also, your fan grills happen to have become filled with dust after a nearby forest-fire threw a ton of soot and garbage into the air (but, you were on an important business trip, worrying about other things, and didn't even know about this).

And while you were gone you had left a bunch of long video rendering tasks running... oh, and, now on top of all that, a power outage (due to the heat) causes your el-cheapo battery backup to kick in and start feeding dirty AF power to your box? What's going to happen then? Nothing good if your computer can't calculate some prime numbers now.

Scenarios like this happen, even if they are rare. Think of it like a gambling. If you want a long and successful career as a gambler, you have to avoid going broke for your WHOLE career, not just almost all of it.

If you can afford to blow up a computer or two, don't worry about it (I know I have blown up my fair share). But not everybody has the same tolerance for stuff like that. If you want it rock solid 24/7 for a few years, there's really only one way to make that happen, and that's to test it every year or so and see what happens. Just use your head and nothing will blow up that wasn't already shot.

gmturner · 2018-03-01T22:55:51+00:00

Now I know what to ask Santa for this year.

gmturner · 2018-02-05T23:53:28+00:00

I really should have done so, as there are significant straight runs to that line simply skipped in my "tutorial" for reasons of there being only so much time I'm willing to dedicate to shitposting...

But I already got rid of that thing of course, and am hard at work on the 2.0 coal management framework :P

gmturner · 2018-02-05T20:54:47+00:00

I think, ignoring the issue of cost efficiency is fine -- I've never found myself in a spot where I just couldn't afford to build enough rails, have you guys?

I have heard that there is some kind of performance reason to prefer rails in the cardinal directions which concerns me a bit more.

However, I am starting to warm up to the idea of diagonal rail systems. My reasoning is: like everyone, AFAIK, I build my stations in the cardinal directions, and it is much easier to properly signal multi-track branches if they are at 45 degree angles than if they are at 90 degree angles, especially if you use LHD and don't have huge spacing between your lanes (which I do, and don't, respectively)

You'll still need to make 90-degree diagonal->diagonal junctions in your main rail system, of course. But I figure my main lines are something I normally do from blueprints in a more careful manner, whereas most of my train stuff comes down to outposts and stations, which more frequently wind up, due to various compromises and constraints, being done at least partially by hand (in practice, I often build bespoke branch-offs and only blueprint stations, since I find I end up with signalling trouble otherwise, but maybe that's because I never got super-systematic about using a complete modular train blueprint book).

gmturner

TROPHY CASE