Wind Shadow Methods

This article discusses the various methods of implementing wind shadow for sailboats in Second Life. There are currently three approaches…

  • Inter-boat chat.
  • Sensors.
  • Dedicated server.

Inter-boat chat

In inter-boat chat, each boat broadcasts its position and related data on a chat channel, and listens on that channel for similar broadcasts from other boats. The main advantage of this method is that it is self-contained. The chat is impemented in LSL and there is no dependence on third-party objects or code, whether in-world or external.

There are, however, several disadvantages…

  • It is constrained by the distance limits inherent in chat.
  • Simulator load increases exponentially as more boats are added.
  • There are limits to how many chat messages a boat can process in a given time.
  • Updating the shadow model entails updating all boats that use it.

Chat Range

Since chat has a fixed range over which objects can ‘hear’ each other, this method is neccessarily limited to that range. For chat broadcast using the llSay function, the range is 20m, and llShout is limited to 96m. For a universal system, where all boats can shadow all other boats, the 20m range of llSay is arguably inadequate. There are many examples of large boats in SL whose sailplan in real life would shadow much further away than 20m. On the other hand, there are few boats that would affect other craft as far away as 96m. (Some might have a slight effect at 96m, but not a significant one.)

Simulator Load

The more boats there are within chat range, the more processing each boat has to do in each timeslice. Since every boat listens to every other boat, and since all boats are actually ‘run’ by the region simulator, the chat processing handled by the simulator increases exponentially. In very extreme cases (ie, in a simulator that already has a lot of chat traffic), chat messages can be dropped from the simulator’s chat queue, with the result that some boats do not receive all of the information that they should.

Broadcast Reception Limits

An object can only process so many chat messages in a given time period. To test this, an object was created that simulated a simple boat using inter-boat chat for wind shadow. The object sent some text on channel -1234 once every second, and listened for broadcasts on the same channel from other objects of the same type. In the listen event, the object only incremented a counter – it counted the number of chat ‘hits’ that it received, but did no other processing. On each 1-second timer event, the object displayed the number of hits it had receievd in floating text, and then reset the counter (as well as broadcasting its own text).

Copies of the object were made, and the number of hits received by each was seen to update as more objects appeared in chat range. So, for two objects, each received one hit; for three objects, two hits, etc. (The number of hits is one less than the number of objects because objects cannot hear their own chat.) At 23 objects, the number of hits was 22. At 24 objects, the number of hits remained at 22, and stayed at 22 as more and more objects were added.

The timer frequency was then reduced to 0.5 seconds. This time, the objects could only register a maximum of 11 hits. With the timer set to 2 seconds, the maximum was 45 hits. In this last case, all of the objects (there were 25 in total) except one were selected simultaneously and deleted. It took over 5 seconds for the remaining object to update its display to show zero hits. This was presumably because the server’s chat queue was still being emptied, indicating that, in busy situations, there is a delay between a boat broadcasting its data packet, and other boats receiving that packet. In other words, a boat could find itself being shadowed by another boat that is no longer in the position that the shadowed boat thinks it is – shadowed by the upwind boat’s ‘ghost’.

The significance of this is that there is a practical limit to the number of boats that can be within shadow range of each other, and that this is directly affected by the frequency at which each boat broadcasts its information. Clearly, using the longer 96m chat range increases the likelihood of more boats being within chat range of each other, meaning that the consequent effects of too many chat messages increase.


As with all in-world scripting, updates are done by issuing new objects by a number of means. For a shaow implementation that is only used by a single product, or products from a single maker, this is relatively straightforward, although there is a possibility of legacy boats using a previous implementation (and possibly not working properly with updated boats). For a universal system, updates can be much harder to synchronise – all makers must release the updates at more-or-less the same time.



In Second Life, sensors are used to detect objects and avatars. When there is a successful detection, a sensor event is triggered, and other functions can be used to get information about the object or avatar that the sensor detected. Sensors are implemented in LSL, meaning that boats using sensor wind shadow have no dependence on external objects, but are also subject to the same issues with updates as those that use inter-boat chat.

There are two types of sensor command which can be used to detect other objects or avatars. llSensor triggers a sensor scan once, and llSensorRepeat triggers scans at fixed intervals. llSensor cannot scan across region boundaries, and is of little use for wind shadow – a boat that’s a few metres upwind, but in the sim next door, would not shadow the downwind boat because the latter can’t detect it. llSensorRepeat can scan across region boundaries, but is limited in how often it can do this. Successful inter-region scans happen at a rate of about 5 seconds, and attempts to scan at a higher frequency result in no_sensor events being triggered. The success of llSensorRepeat is also influenced by the repeat rate – the faster the rate, the fewer times the scan returns useful results.

The sensor method is limited by the number of objects that it can gather information about during a scan – the maximum is 16. It is also at risk of detecting false positives. Depending on what it has been set up to detect (for example, avatars or active objects), the sensor could detect a spectator or other passing avatar, a wind setter or start line, and calculate wind shadow based on that avatar’s or object’s position. The results can be further filtered by the boat’s script. For example active objects could be reduced to those that are physical, or the object names could be examined to provide a basis for inferring whether an object is a legitimate one. These methods may be more or less successful, but can mean that the ‘real’ number of detections  is less than the maximum of 16.



Dedicated server

The dedicated server method uses the HTTP services in LSL to communicate with a web server that is external to Second Life. Each boat sends a data packet to the server, the server processes the data, and then sends an HTTP response to the requesting boat, containing current wind information.

Unlike chat and sensors, this method cannot work if the server is unavailable – the server represents a single point of failure. The boats also experience a delay between the HTTP request and response, due to network latency – the ping time between the simulator and the external server. In the current implementation (Windmaster), this ping time is around 0.25 seconds.

The server method does not use chat at all, so is not limited to chat range, and cannot overload the simulator’s chat queue. Rather than an exponential increase in server load, the server’s HTTP traffic increases linearly – one transaction per boat, per timer cycle. 

It uses global coordinates, meaning it has no issues with region boundaries - there is no impact on the number of successful hits, as found with sensors. The risk of false positives is extremely low – the server only deals with information sent by the boats, meaning it can only ‘see’ valid objects. The server keeps a note of when each boat last transmitted a data packet. If a data packet has not been received from a boat within 10 seconds, it is deemed to have moored, been deleted, or otherwise lost, and is ignored when calculating the shadow effects on other boats.

Moving all of the calculation onto a separate server gives the programmer far more scope to develop the wind shadow model. There is freedom from LSL limitations like script memory, and the need for boats to parse variable amounts of incoming data. Moreover, additional data can be added to the system, such as terrain shapes and representations of buildings, and this can be used to model further effects like land shadow. There is also scope for non-boat objects to use the data, such as representing race boats on a race course.

 A key advantage of this method compared to chat and sensors is the ability to update the calculation models without having to update the boats that use the system. Wind shadow can be refined, additional wind effects can be added, and new client objects can be created and put to use, all without having to issue new boats to end users.



Comments are closed.