MikeShinodaSLR:

---

to the vertex/mesh snap option like

Snapping the control points to vertices or faces of the track wont help, it is quite hard to approximate the shape of the track (as you also pointed out) even with unconstrained movement of the control points introducing a new limitation will make it even harder (even if it doesnt seem that way) (I mainly used the height of the control points to make the example trc passable, and minimize the number places where the cars were floating or intersecting the ground) and would probably lead to people making splines with an overwhelming amount of control points (as to make even the linear approximation feasible and disregard the curved nature of the spline) which would make it all but impossible to adjust the "density" of a spline and hence make the traffic travel the spline at a near constant velocity, which again must be done by hand.. (I researched the problem and confirmed my vague memories about splines (in particular Bézier splines (but even curves) that arc length parameterization is not viable in the given context (would need a pre-transformation on the parameter which slrr doesnt use as far as I know) and the whole thing becomes a general iterative method on the given "length" parameters of the slrr spline construct with only a guess on the use of the params being optimised... frankly I dont want to deal with that)

Defining splines for the track after the fact (I'm pretty sure the basis-model of Valocity was generated in regards to the splines used as the trc data and not vice versa) is as easy as I could make it in reasonable time (generating the Navigator lanes, enforcing the constraints on continuity, generating adjacencies, translating the relations from indices and back and so on)

If however there is a way to save (continuous) splines of this kind (list of Cubic Bézier curves) in any other program I would be alright with implementing a way to import these files (if the file structure is known)

MikeShinodaSLR:

---

scaling the mesh by all 3 axes [..] Or you could just share the sources

I would like to point you to the link mentioned just above (LINK) you are looking for the ScxV3Constructable and ScxV4Constructable classes after constructing one of those the problem becomes trivial, I would be glad if you or anyone else for that matter dove into the sources and utilised it, it has some great potential, and as battered as I am regarding modding slrr it would be good for some other people to start using a, I think well written enough, library to access and modify the data files of slrr.
But the source for the small dialog I added using the "model" linked is here for you, it is quite trivial really.

MikeShinodaSLR:

---

regardless of the drawing distance.

If you mean the ingame option I know for a fact that that is not possible from the rpk side of things, also there is a limit on the number of vertices that can be in a POLY entry in an rpk, but you can try and trick the spatial data structure of the rpk (floating an entry high up the hierarchy) to show the given POLY entry even when far away. Even then the draw distance will cut it though so the best you could do is construct a proper octree and bias some objects to be high in the hierarchy in the meantime setting the draw distance to a very high value and leaving the keeping of the number of objects rendered low to the spatial partitioning. But this is a complex problem (with the sources linked above it is possible but there are points in there which I'm not sure about so it would need experimentation)