Linden road group for better roads.

I would like to see the roads to be more useful. I envision a system where instead of having to steer the vehicle, you would instead select the lane.

To accomplish this I propose the following.

1. The road blocks be unlinked, named a unique name and have a description that includes more information for scripts to tell what road section they are to follow.

2. I propose that the linden road land is deeded to a “Linden road building group” This would allow residents to update and improve the roads.

3. I also propose that people can deed land to the road group for future roads. The group permissions would not let them take back the parcel, but LL could resell the parcel if it feels that that section is not needed. This would be intended for larger land owners that already have a plan for a road and not for people to just drop land into protected space.

Edits: merged 1 to 3 and moved details.

Scripting discussion
/54/fe/143237/1.html

Details see wiki http://www.lslwiki.com/lslwiki/wakka.php?wakka=Autobahn

I don't use road but that sound interesting!

Roads? Where we're going we don't need roads.

http://pics.livejournal.com/anyaristow/pic/0000bs24/g1

Sorry, couldn't resist...

I would love to see a proof of concept of the system.

I've realized something really cool about this concept.
The road can be any direction. Even upside down

I’ve started building a test road in Charissa (5, 5)

It’s going to arc upwards and then go up for about 600m before looping upside down before coming down. Since the vehicle will have to do the rotation math anyway it can track the blocks in any orientation as long as the block’s rotation is well defined.

I’ll play with slope and cut options before making an exact rotation definition since I want to use the least number of prims possible for a 14m wide road with optional sloping sides.

I renamed the block name to "PublicRoadSection" sine I can envision people making public roads across there private property in order to direct traffic into there malls.

I'll stop by YadNie's and see if I can find a low prim +mod vehicle to use for testing the script. I’ll be replacing all the scripts so all I want is a full perm shell.

I'll also have to make a lsl wiki page with the protocol definition and sample vehicle script.

edit: lets define rotation <0,0,0> in editor as pointing east and upright.
Edit that rotation doesn't work good for curves.

I am going to move the techical details to the scripting forum and create a vote pointing to the different topics and the wiki.

Since this concept includes overpasses and bridges I think we should call it the Autobahn.

*Sigh*....I wish I were a talented builder or scripter.....as a rl civil engineer in the highway/bridge business, I would LOVE to be involved with something like this!

Well if someone else had the basic script, all a road-team member would need to do is place the road sections and adjust the values in each script as required. While the rotation might be a bit confusing at times it can be made fairly easy.

I'm not 100% sure how you're trying to do this Grumble, but might I suggest an alternative implimentation for the roads? This is instead of sensors, it's more difficult to set-up (not by much, just needs more care) but ought to be much faster:
Basically, each road section would keep a list of object IDs for other key road sections, and lane numbers. On a given channel, a vehicle would broadcast the last road section it visited (by transmitting its key) and the lane it wishes to travel in. If a road-section receives this broadcast, it checks to see if the key is one that leads to it, and looks up the lane number to find out which object is next. It then replies to the vehicle, telling the vehicle which object to look for next, and how to travel toward it.

So say I have a road that looks like this:

    | 1 || 2 |
    |   ||   |
    |   ||   |
    |   ||   |
a   | * || * |
    |   ||   |
    |   ||   |
    |   ||   |
b   | * || * |
    |   ||   |
    |   ||   |
    |   ||   |
c   | * || * |

In the 'diagram' the numbers indicate the lanes, 1 is the south-bound lane (assuming right-hand driving) and 2 is north-bound. The stars indicate 'key-points' in the road. In this case the key-points are simply on a straight line, but the road is so long that they are in fact quite far apart (perhaps as much as a full sim-width apart, the closer they are the slower vehicles would have to travel to follow the path accurately).
A vehicle is moving in lane one and just visited key-point a, and it broadcasts a message such as:
1@<Object ID of a>@<channel to reply to>
All key-points with range of this broadcast will receive this communication on that channel, and will look first to see if they have information relevant to route 1, and if so, if they have an entry for that object id.
Key-point b will have an entry for 'a' and lane 1, since it is a step along that route. It's entry will tell it that the next step to go to is key-point 'c'. The reply it gives on the channel the vehicle chose could be something like:
<Object ID of c>@<pos>@<gradient>
Now the vehicle knows where the next object is (so can now move towards it) and what it's object ID is (so that it can filter out invalid replies on the channel the vehicle is using for listening).
<pos> of course is the position of the next key-point, while <gradient> is the curve to the road. This might be a rotation, but vehicles would have to decide for themselves how fast to turn in order to achieve the correct curve at their speed so a float could suffice. Most likely this would require key-points to be placed at the beginning and end of an arc type curve.
Anyway, this might be confusing, but I think it could be more efficient than the sensor method, and may respond faster, since the vehicle only needs to begin broadcasting when it thinks it is in range of the new key-point. The key-point receives the message, does a quick look-up in its list of data and outputs the values on the channel being used by that vehicle. The vehicle (which is listening for messages on that channel, and from that key-point's object ID) will then take that info and work out how to continue.
I might give some example scripts later, as it may be a better system (would need some testing to be sure).

The problem with chat messages is that it takes the same sim time as a sensor. They both have to create a list of items within a distance and that requires the sim to do a search.

The method I am putting together names the road sections so that they include the segment number. This means the vehicle won't even see the other lane.

The description then lists the next segment number, but since the vehicle may skip prims the vehicle script will have to scan for both prim names during a transition.

This has the advantage that it can deal with very complex intersections like cloverleaf’s.

I am also worried about script time in that the script has very little time to decide which block to use. A scanner can be set to only look forward at the maximum desired distance and then the script can simply use the farthest prim.

Making the road with less waypoint prims would make it harder to rez a vehicle and get on to the road. I envision people adding on and off ramps.

Edit: I also do NOT want to leave a script in every road prim as every script, even empty ones, adds script time due to the scheduler. The current road script is designed to be removed via a chat message after the road section is adjusted as needed.

Mmm...that started to sound good I can imagine automate superhighway in SL already ^^

Hmm.. This is a very interesting issue and I am going to look into it to do my own R&D.

I have some test road sections in Charissa (5, 5) .

Please focus on the vehicle side as that is where the complexity and where the money will be made. We of course also have to make sure everyone builds to the same standard or the system won’t work. So let me know if you see anything wrong or might be better.

I chose the prim rotation so that it could be twisted and tapered.

I'll set a box there on the ground to give away a full perm road section.
you just have to place, unlink and adjust as needed.

PS: It looks like the new definition I have now works, I just need to replace about 600m of road I did earlier.

See the wiki for updates.
http://www.lslwiki.com/lslwiki/wakka.php?wakka=Autobahn

Edit: fixed rotation. full perm blocks are now avalible.

description fields are now separated by colon ":" symbols.

''Note: pipe symbols don't work in the description field''