Where can I get the GSLR Tug Scripts?

Hi All,

I have a piece of land in Tamsi which has a waterway connection to a large body of Linden water sims. I can even just get from where I am to the southern continent to my great delight.

What I would like to do is run an automated boat tour service through some of this vast area. Not sure at this time whether I want to make it part of the GSLR or anything but that remains a possibility.

To achieve my goals, I would need to get hold of the scripts that operate in the GSLR Tug boat service. I have no objection to paying a reasonable price for them, though obviously free would be great too.

I contacted Qu Qi who is the owner of the GSLR Tug boat via all available means in their profile but to no success so far. Does anyone know if the scripts can be obtained elsewhere? Or anyway of contacting Qu Qi that I have not tried? Does anyone know if Qu Qi still comes to SL regularly even?

Many thanks for any help you can give.

I am not sure this is the same thing, but Yavanna Llanfair does a really good, modifiable Pod Tour system that can be used for tours or transport systems. It can cross sim boundries too.

Thanks for the pointer Elgyfu but I am really wanting one that is specifically written with boats in mind. I did some quite in depth reaserch and most of the tour systems don't deal with boats as a boat vehicle and so they don't move in the way you would expect. They are really great at flying/hovering or land based things but not at floating things.

*bump* Unresolved.

the ferry that ping-pongs between the first and second continent seems to use scripted prims along the way for orientation and communication.

I heard on this forum that other selfmade-shuttles seem to disappear without error messages on linden land if no agent sits on them.
Reelays along the path seem to be essential to keep the script reasonably small to communicate the position of an empty shuttle. but you cant maintain those on linden road easily.

Search this forum and script libraries for "pathfinding". there are some opensource scripts that can find a path across region borders to a target region. Theyre not so good though, the pathfinding is simple and stupid due to the 16k script limit.

I'd be nervous about the shuttle-without-passengers thing, too, on Linden water: not sure what would keep it from getting auto-returned, unless it were pretty reliably quick about crossing a sim and not stay in a "foreign port" for very long. And that could be difficult to ensure for all possible conditions of the sims it traverses.

I don't think it's really a pathfinding problem. It would be easy enough to chart a course for the vessel manually in advance, recording waypoints, and just have the vessel move between them. But the observation is quite correct: even the successful private rail systems seem always to use "beacon" prims for those waypoints instead of just recording them as target coordinates, and I have no idea why. (Maybe somebody can lift the veil?)

There could be a problem maneuvering around temporary obstacles: prims stranded in the vessel's path for the auto-return interval. Well, that and the emergence of ferry-ramming as a competitive sport.

It's because the waypoint (beacons) system is more reliable than a path finding, expecially when the vehicle must be physical and not phantom, it means it must relay with other (possibly) vehicles, with avatars, with the landscape... the possibility to have it stuck into an obstacle are frequent. With the waypoints you have the control of the path (so the vehicles may go outiside his route, but can recover), you have a fixed path (if the objects reset, you don't loose the path since a memory cleaning, for those "learned" path vehicles), you have a fast way to deploy the path, seeing it visually, with the possibility to modify/tweak it on the fly (instead than fill a notecard with a list of coordinate, that will be certain will have an end, and it wouldn't be usable for a very long path...).
In the majority of the cases so a vehicles with waypoints is preferred, while a pathfinder would be ok for some limited purposes (in example: a free roaming pet would look more natural with no predetermined path...).

beacons/rails may have scanners and communication protocols.
those can ensure that there are never too many or too little shuttles in one place.
A p2p, shuttle2shuttle, network as alternative for communication is too fragile, much more complex, much more processing intensive, and it may be larger than the 16k limit per peer/shuttle.

if all shuttles are gone in a large space due to reset or rollback or autoreturn, only a static beacon can notice that (on a separate parcel that wont change its parcel settings).
A lonely shuttle can not maintain a p2p shuttle communication network and it may get stranded and information is lost.
A p2p communication network needs a critical mass of scripts to remain functional. but that mass requires a lot of processing and will cause time dilation.
A script that creates shuttles because it assumes shuttles to be lost may also create too many peers without noticing it, because the shuttles keep gettign lost and stranded somewhere, but not removed.

If parcel settings change into something that wont allow shuttles at some places, only a static beacon could know that and communicate it over region borders.

-
even with static nonscripted beacons (to be less processign intensive) that are being scanned for via their name to find and identify them, like the rails of all railroads, a pathfinder to follow the rail is still very complex, and trains along it can get lost easily.

Just to be clear, I was assuming a waypoint system would be necessary, I was just questioning why those waypoints need to be beacons instead of coordinates recorded on a notecard and read into some memory script. (Note that the 16k limit is per script, not per scripted object. There's a tiny overhead associated with having multiple scripts communicating by link messages, but that's nothing compared to even a single sensor scan.)

So, the only dynamic pathfinding I'd imagine would be maneuvering around temporary obstacles in the predetermined path--pretty much impossible for a railroad, but at least theoretically of some use for a water vessel.

Not sure if I'm getting all the points, but I do see an advantage of a kind of network of primmed waypoints that communicate telemetry back to some control point about the progress of shuttles, since presumably llShout() is a more reliable way of relaying information across sim boundaries than is llEmail() directly from the vessels. And if the beacons run a local sensor scan for things that look like shuttles (or llGetObjectDetails of known shuttles), it might be a more reliable way to discover stranded vessels (or the lack thereof)--again compared to llEmail directly with the vessels.

I have no idea what the logic should be at the "replacement shuttle rezzing station," but I suppose the more reliable its information, the fewer stupid things it would do.

As i said you can record coordinates into a notecard, but it would be then more time expensive to adjust the path (just in case), while a beacon solution offers to you a visually path (that u can turn invisible after deployment) and an instant adjustment for almost nothing: why you want to complicate your life when a single prims (you may end to up to use 20 primitives for an entiere sim... that is nothing) woule make it better?

Manouvering around an obstacle is another matter, you need to implement a AI, the most basic logic (used in robotic) is the "right/left hand rule" (used to escape from a maze in example), so the vehicle turns to his left/right if it identify an obstacle on the current route, while it keeps control of the original route, as soon the route reprise is free (no obstacles between) it turns into it to regain the main route. It's the basic of robotic with sensors.

The "beacon" solution doesn't really need to communicate the waypoints, the vehicle may intercept the beacons by sensors in a certain range (so it would find the corret next waypoint), the logic is: reach the waypoint, as soon you reached it, let's look for another one discarding the current one and the previos one (so it won't turn back!), and go.... if no new waypoints are found, cancel the cache (previous one) so it would turn back (imagine a trolley reaching his last station), if no waypoints are found (scenario: the vehicle goes off of his imagined route for an external event; eg: someone pushed it hardly...), extend the range to trying to regain his route, no waypoint .. extend it again, until it reaches the max distance (96 meters), no waypoints found? It's time to die. :\

The replacement vehicles (to have an autonomous system) may be different. On short routes you just have to use a timeout, assuming that the vehicles must pass *always* for a replacement station in a given amount of time.. if he doesn't pass the network assumes it's ded, so it rez a new one.
On long routes a timeout with local stations won't work, since the route may be completed in hours* (so the network may stay down for hours...), so you gonna use a backend server (external), the vehicles updates his position on the server with the time, the rez station does read this information back, if the information is outdated then it assumes the vehicle is ded and rez a new one (this would works with emails too, *but* since you may need to rez a new "inworld server", you need to update the vehicles each time you do it.. it works, but well it's not so problems proof). The backend solution is also usefull to distribute informations to the stations all around the grid, in example if you would have time tables into the stations (arrivals, ETA arrival), users aboard, and any sort of nice decentralized features.

The "multiple vehicles on the same route" issue (ie: you rezzed multiple vehicles assumed one is ded, while in fact it's not) is easily archived with the highlander rule ..."only one will remains", so with backend server: two informations received? One dies; on the "local station" solution, if a vehicles meets his twin, they will start to fight (in case of boats.. with water bombs) and one will end with a llDie;

Hope this help!

Qu Qi does still come inworld -- I've talked with him recently. I do know dat the ferry from Purple hasd been a bit borked since H4, though -- maybe he's been busy tryin to fix it?

Thanks for all the replies everyone.
To Mari...

Okies I will wait some more and maybe send another IM/Email/Notecard combo in a few weeks

To everyone else...

Great thought provoking posts everyone - thanks very much. What I originally had in mind in my ideal situtation is a fairly simple system that would be based of notecarded waypoints. In fact I already have waypointed one possible route. There would be no telemetry back to base and was not expecting to need any beacons to be put down on Linden land. I had also expected that the boat would do a round trip like a tour and would require at least one person to stay on the boat. If all people got off at any point then it would llEmail the starting dock and de rez. Then a new boat would rez waiting for passengers at the dock but not disembark until someone sat on it.

I was not sure how the GSLR tug operated - obviously it operates a lot differently to how I expected. However I don't mind revising my plans and attempting to get Linden approval for putting down a set of beacons and hooking my route up with purple and operating in the same way. Failing that being an option, I was hoping to see how the scripts worked and modify them to be more like the plans I had originally.

Really I am open to most solutions that try and lean towards simplicity and seem to treat the boat as a vehicle still instead of just an object that needs to be moved.

One of my long-term plans is to run such a ferry service in the S of Corsica - from Nebo to Kuttara, to Eldfell and back.
That's all crossing Linden open water sims.
I have an option to be brave and extend that via the narrow channel through Hengill and Grimsvotn to a parcel in NW Grimsvotn, then on over open Linen water to Dunnylun and Charleville.

I haven't planned anything more complex for navigation apart from a small number of ports ( 3 or 6) with a few intermediate waypoints to pass close to scenery and to access the ends of the narrow channel. The route would be fixed, so no need for dynamic pathfinding.
I don't 'get' the need for beacons.
I'd use email and/or shouting on a channel for coordination where more than one of the boats could be in the same area.
That would happen at the home ports if a docked boat sitting there.
The easiest thing there would be to poof the docked if nobody was sitting on it.
If the docked boat had passengers sitting and waiting for a departure, then pull alongside and get people to tranship before poofing one boat.


A position check on a timer could be useful to check for general borkiness or accidental/deliberate collision with other boats.

It would be interesting to scan for unexpected prims dead ahead and to divert around them.
Two cases here
1) I have come across prims sitting static in open water and channels.
2) Someone(s) could start to play with the thing and try to shepherd it as far as possible off course I think that this would be where the timed position checks would come in.



Lost or jammed boats?
Linden autoreturn would take care of boats abandoned and stuck for some reason en route.
Position checks on a timer would detect an unexpected lack of progress in the right path. The thing could simply poof(die) if conditions were not as expected. This could happen whether on Linden water or accidental straying into someone else's parcel.

We have the Gypsy canoe rezzer currently at two locations.
The canoes are set to die a few minutes after they are abandoned, so that they don't clutter up the place. That works very well.




But then.........

I look at the state of the ferries and trams in Bay City.


And I think.......

Maybe not so simple

But it will be fun trying.

Hi Sling,

Thanks for your observations, there is much to mull over on this I think. My own situation is that from Tamsi there is a large body of water that leads over to the Hyles swamp area and as well as a narrow channel that goes down into the main GSLR oeprating area around Purple etc.
I would love to make my boat go from my dock at Tamsi and around the huge bay past Hyles and down to the narrow channel to finally end up at Purple and perhaps use the boat dock there to pick up/drop off - Purple would be more like a port then with 2 services. If I could not get the ability to drop off at Purple then I would make that my round trip point and head back to Tamsi. The waypoints are very simple on my route and I have manually travelled this route lots of times so far and not encountered anything that the boat would need to navigate around. The area is very quiet generally and there is very little water traffic that I have observed.
So that leads me to think that collision avoidance might be overkill. I would simply stop the boat if I detect something in the way and if after a certain time it did not move then I would reverse course and head back to dock at that point.

It is looking likely though unless I somehow get access to the tug scripts, in which case I would attempt to get my system setup the same way, I am going to have to develop something from scratch which will be long and painful. My scripting skills are good but my ability to do things like guidance and movement through the 3D space is still very basic.

At the moment my boat dock has a rezzor for an inflatable boat which the person can use to explore with.