The question is not whether Andi posts, but whether he has something to say when he posts!
Regarding randomisation, you already mentioned the only choice - scripted scenery. My experiments on how much of a child gets operational are dated, so better repeat them now, using TS2014. Just make a scripted scenery item child of a gantry post. Script would be something like:
- Code: Select all
function Initialise()
Print "It works!"
end
If "It works!" shows up on LogMate, you won.
In that case, I would make different versions of the stanchion named objects inside one IGS, so the script can switch them on and off like lights in a signal, using ActivateNode. Only showing one of them raises hope that there will be only one draw call per post. Showing a decal certainly leads to a second draw call.
Entering ID data will not work since you depend on the world editor to show the input field in the properties box (right-hand fly-out).
I would not try abusing mileposts or signals just to have proper data on the plate.
If you can go with random numbers, you could try to find out if texture sets work with scripted scenery. Just look at some speed sign that is known to work, make a scripted scenario item with exactly the same setup (primary texture set, GeoPcDx) and use SetText to show some value of your choice, just for testing.
- Code: Select all
Call ( "SetText", "30", 0 ) -- show 30 using primary texture set
In case that works, you will can start developing the IGS. But remember that these digits might use one draw call per digit, so a performance comparison might tell you after you succeeded that you better call that off. But then again, you only show them for the nearest LOD, so the effect may well be negligible.
Since stanchions cannot ask their neighbour about its number, you would generally end up with a meaningless mess on these plates. However, if your route runs somewhat straight and does not change direction anywhere significantly, you can get the global location using
- Code: Select all
x,y,z = Call("getNearPosition")
and divide that by some factor to get the mileage, using the remainder as a proxy to the running number. E.g., if the route runs east-west, dividing x by 1609 would give the mileage. The remainder divided by the typical stanchion distance would provide the running stanchion number for that mile. Of course, some numbers will show double and some will be skipped. But it is possible that people don't follow these figures close enough to notice. At least, there would be some coherence, i.e., the mile figure should continuously increase as you travel along, incrementing by 1 for every mile +/- 50%.
You see that this part of the script is route-specific. So you need to clone the .bin and .lua file for each new route, like you do it often for signals. Also remember to add a suitable number to the coordinates to make sure you get positive figures. On tiles with negative tile number, the location value is negative, of course.
For routes heading to north-east, multiply the coordinate by 1.4 (square root of two) to get an estimate of the location along the route.