Raise the (flight) limit!

Update April 2012: The flight limit has been raised to 5,000m. 

Nalates Urriah keeps her finger on the pulse where all things server and scripting are concerned, as well as keeping an eye on other technical aspects of SL. Today she reports on server scripting, and carries an interesting little nugget on flight limits.

Apparently the Lab is considering whether or not to raise the current flight “ceiling” for unassisted avatars. As we’re all aware, if you fly without any kind of scripted  / client-side assistance, you’ll start slowing down from around 165m onwards, and come to a complete halt at about 180-190m. To go any further, scripted / Viewer assistance is required.

I’ve no idea why this limit was set – there has to be some solid reasoning for it in the depths of time. However, for as long as I’ve been involved in SL, build height has (I think, my memory is getting fuzzy in some areas) always been at least 768m (prior to being raised to the current 4096m), so the brake-point at 180-190 to “natural” flight does seem rather arbitrary.

Simon Linden apparently puts forward an argument that raising the limit will shoot people using flight assistance systems into orbit. I’m not entirely sure I follow his logic. There is a plethora of flight assistance alternatives available across SL, from the ubiquitous Flight Feather or Flight Ring of old, through to fancy backpack attachments to options built-in to a range of tools such as Em Dash and Mystitool. Many of these include accelerators which allow the rate of vertical ascent to be adjusted by the user – some of them quite ridiculously so. Yet none, so far as I’m aware, have resulted in people ending up in orbit on the click of a button / key, even when employed at altitude. So would the removal of the current limit suddenly cause these tools to behave any differently?

It’s not even as if flight assistance tools are required, either. Firestorm bypasses the current limit by adding flight assistance to the LSL bridge. Milkshake (prior to being withdrawn from public use) demonstrated that it is possible to override the flight limit directly from within the Viewer without even resorting to any form of bridge attachment. Both of these capabilities tend to make the current limit somewhat pointless.

As it stands, and with maximum build height sitting at 4096m, it would make sense for LL to lift the limit to that altitude (as I’m sure they are only too aware). This would not only make mobility at altitude easier for all (especially around the more expansive higher-altitude builds where flying is allowed), it might even lessen people’s dependency on attachments, be they wearable or HUDs (not that this is a critical issue, given the threatened script limits project is now apparently shelved).

It’s not what I’d call a priority in any way shape or form, but it would potentially make people lives a little bit easier in-world; so if LL are considering the move – I for one say, “go for it – and push it to 4096!”

With thanks to Nalates Urriah

11 thoughts on “Raise the (flight) limit!

  1. I am so glad that Linden Lab are concentrating on such important features of Second Life, unlike things that would be considered a mere frivolity like .. oh I don’t know … creating a native 64bit client. 😉


  2. Gosh, I’ve lived with a flight assist so long I hardly think about it any more. It’d be nice if newbies didn’t need them, and to be informed that they need them, but it’s a pretty trivial change. I’d rather see them address things like chat lag, inventory loss, and low frame rates. There aren’t any “assist” gadgets for those problems!


    1. They are.

      It amazes me how small, potentially popular fixes that LL toss out for consideration immediately get bashed as indicating the company isn’t focused on “bigger issues”. Things aren’t mutually exclusive. Recent releases of the Viewer have tended to give a general improvements for many – not all, admittedly, but many. Which is not bad, considering so much about the Viewer is more dependent upon the hardware / environment in which is runs, rather than anything intrinsic LL themselves can do. As you’ve noted yourself, I actually enjoy a potentially “better” SL experience than you, when my hardware is older and my net connection “poorer” than yours.

      This should be a trivial fix, as you say…one unlikely to take time and effort away from other, longer-term and more complex issues that are being dealt with, so why not?


      1. This.
        Small things count too.

        Just because there are starving people in Africa doesn’t mean you shouldn’t feed your dog. One doesn’t prevent the other.

        (lets just ignore the global resources and geo-political arguments for a second that prove that one might actually in fact prevent the other… and take the old fashioned analogy for the analogy it is… 😀 )


  3. A higher flight ceiling would be nice, especially if that would mean that people start to understand that you can have skyboxes above 512 meters. or beter 1024 meters. so you can fly lower , without sytange fly manouveres to avoid collisions. I think reason now is why people dont build higher. because the cant reach it with flying. or are just lazy.

    Anyway a shame so many dont care for the serrounding look


  4. “Simon Linden apparently puts forward an argument that raising the limit will shoot people using flight assistance systems into orbit. I’m not entirely sure I follow his logic.”

    Oh hai guyz, we iz not to raise limz and make scripts uneeded, cuz den folks wit scripts will find dem uneeded. We know it wud be grate if folks dun needz script no maor, but that would hurt folks cauz dey wud not needz doz script no maor.

    We can just paint a big circle on this one with an arrow inside, going round and round.


  5. ps: back in the day there used to videos of people flying up into the sky to heights of a million or so… and showing that the higher they got, the more their avatars ‘decayed’
    Prims would fall off visibility, scripts would break down, and eventually the avatar mesh itself seemed to almost melt…

    I have no idea how a database could be coded to cause a bug like that… or even if those videos were even accurate… but if so, it might explain the limits we see. It might very well be that in week one of the alpha of SL, the mesh would melt at 200m up… so somebody put a bandaid over the code, and nobody ever went back to peel it off after the ‘wound had healed.’

    It could even relate to sims being 256 by 255. Maybe originally, before even beta, they thought they would be 256 by 256 by 256, and didn’t know what to do about the 257th meter… As in: not even a spot in memory allocated for a floating-point number above 256 (if you code in a language like K&R C, this actually can matter – if you allocate a variable to one size, and then put in a value above it, you get problems).
    – And again, insert my comment about ‘not peeling back the bandaid’ after the problem was moot (hey guyz, we iz haz database that haz room for big numbers, like 11. /holds-up-10-fingers).


  6. I believe that flight assists work by applying a strong upward force to your avatar. Perhaps Simon’s reasoning is that if there were no height limit, this upward force would still be applied to any av wearing a flight assist, who would then be propelled upwards much more rapidly than they’d like. Think of a newbie on the day the limit’s removed, trying to fly around their skybox like they did yesterday and ending up on the ceiling.

    Removing this limit could go against the Lab’s principle of not breaking content, or at least necessitate some kind of widepsread publicity: “on , but not before, you will need to remove any flight assists you’re wearing. For full instructions on how to tell if you’re wearing one, and how to remove it if you are, click here. Mystitool users consult their documentation, etc etc”.

    Yeah, it could get messy.


    1. The height limit would still be there – just at a higher altitude; ergo, I’m not seeing any “braking” issue when using scripted tools.

      As to breaking (of the other kind) content – I don’t see that either. The current limitation can be disabled through the viewer without imacting / breaking content in terms of flight assist tools. Not clear on why it should impact things if made server-side.

      It’s true that the client-side disabling had some issues when used in conjunction with a flight assist (using both the Firestorm Bridge assist and a flight assist attachment can lead to unpredictable behaviour, for example); but dealing with this is actually quite straight-forward, as the Firestorm team demonstrated by documenting an advisory that flight assist option / tools should be disabled / removed when using the Bridge function. Certainly, no content (to my knowledge) was broken.

      As to referring to documentation on tools like Mysti – again, not sure that’s a major issue. By default, the flight assist in such tools is OFF, and requires explicit activation via the menu – so turning it off shouldn’t be that hard for people to get their heads around.

      But you’re right, the fact that the limit has been raised – if it does in fact get raised – will need proper promotion by LL.


  7. @foneco, Flight cannot really be be turned off at the estate level, nor can scripts. There is always a way around them. Any viewer can enable flight by requesting the Admin Option, or clicking the checkbox in the viewer prefs for some viewers like Phoenix.

    I think its a non-issue – let them fly higher. If there is a problem, just take of that laggy flight band or ditch the Mystitool. Mystitool is the script hog, with script time in milliseconds, not microseconds as any good script should be. I’ve seen it take up 10% of a sim’s script time.


Comments are closed.