This includes the special elevated rail layer from the Elevated Rails mod. Placing the rail supports DOES work.

Rails are a tricky special case, I ended up using the revive() method to build them and deducted the item cost from the player manually.

Here are all of the entity types from the API, and how many rails it should cost to place them:

Cost 1
straight-rail
elevated-straight-rail

Cost 2
half-diagonal-rail
elevated-half-diagonal-rail

Cost 3
curved-rail-a
curved-rail-b
elevated-curved-rail-a
elevated-curved-rail-b

I'm not sure if I can add this feature for more than just the basic straight rail (which just works with build_from_cursor), because while this sort of logic could work with just vanilla, I don't believe it would work with mod-added rails, made of their own materials, without creating a specific patch for each and every mod-added rail.

Upon further inspection, all of the train mods I thought added their own rails, did not actually add new rails. I could have sworn that space trains and electric locomotives had unique rails, but I guess not.

Added the requested functionality to v1.0.7, should work exactly as written (while also respecting quality)

Building intersection blueprints will be much easier now!

Upgrading rails to a different quality doesn't work (disregarding the bug with build_from_cursor on normal entities), and I suspect upgrading to a different kind of rail doesn't either. I don't much care for the functionality, but I'll note it for posterity.

I don't suppose you know of a good mod to test upgrading a rail to a different kind? Space Exploration had space rails, but you could only build those in space so they don't really work.

Holding rail ramps in the cursor causes ghost rails to be revived.

Right, that was one thing I forgot to note, in-place quality upgrades not working on rails. I believe this is because you can't fast-replace rails with different qualities, since I tried using the same logic as the rest, but nothing happened. It probably isn't important, so yeah, I wasn't gonna spend any time figuring out how to make that work.

As for that last bit, very interesting.. the current logic checks if the player is holding a "rail-planner" type entity in their cursor while hovering over ghost rails, and then performs the ghost revive if matching quality. It's quite odd that the ramp would be considered a "rail-planner", since it doesn't really function like one. I suppose I could add some logic to prevent that from happening, but maybe we can call it a feature and not a bug? :D The numbers were probably not being processed correctly, possibly consuming the wrong item when in cursor.

Rail ramps reviving ghost rails fixed in v1.0.8

Also added that holding rails can also revive rail-ramps and rail-supports, so you don't have to swap between the different rail types (that was pretty annoying during my testing, especially with elevated rails)

I like that rails will affect ramps and supports now, it feels quite natural to build out blueprints with it.

This got me thinking about whether entities could revive in "groups". For example, holding belts would also revive splitters and undergrounds. Holding inserters would revive other kinds of inserters. Pipes would do underground pipes.

Would that be too easy? The reason I'm using Picker Extended instead of Mouse-over Construction is because that mod does literally everything for you the moment you walk into range, whereas having to hold the right item still gives building a manual feel.

How do you feel about respecting player.build_distance (and in general, how powerful do you think Picker should be, harkening back to the Chest Copy debate)? The way you implemented rail building means that you can build them all the way to the edge of the camera. The same is true of module insertion (when you press Q on a building that wants modules).

Building anything that uses build_from_cursor() DOES respect player.build_distance. So there's an inconsistency: building a rail blueprint at a large distance means I can place the rails, but not the signals.

I'll note also that using the rail planner in vanilla does work at a greater distance (about 2.5x normal, don't know what it's called in code).

That functionality would actually be pretty useful, especially when blueprinting belt balancers (which I often use with belt brush).

I also hadn't even considered that ghost rail revival was technically outside of the player's normal build reach, but that does make sense. For rails, I think it's fine, especially if the vanilla rail planner already exceeds that build distance, and given the backup constraint of the camera's maximum zoom. (I also don't know what value they are using anyways, since there was nothing in the docs I could find related to rail planner build reach)

For the theoretical pipe and belt ghost revival groups though, I would definitely want to include build_distance as a restriction. Ideally, it should function exactly the same way build_from_cursor does. So thanks for reporting that, I'll be keeping it in mind for the next update

(also will probably just add signals to the list of rail entities to be revived when holding rails, even if that technically breaks the rules regarding player build reach and wouldn't normally be revivable when holding the signal itself)