Some alternatives:

1. Video game convention - use a shift or control key that toggles run while held down.
2. Internet convention - (what I prefer) - left-clicking the ground should default to "go here" (rather than right-click, pie-menu), and double-left clicking the ground should default to "run here".

Instead, this feature should be a client option and should not be enabled by default.

Edit: Also, many games use double tap to run, so this isn't a completely non-standard implementation (battlefield, unreal, as two high profile examples)

> I have altered the title of this Jira. You should not petition for total removal of a feature if some will find it useful (and some will).

Mr Thorne, I will petition for what I damn well feel like.

It seems to me for a lsl script to recognize arrow key imput it must request access to your controls. This gives us a point where we could turn off doubletap and other potentially content breaking extended behaviors. Scripts could then treat control inputs in the standard way without worrying about new behaviors. Releasing controls would re-enable the new behavior.

This allows scripts which take control input to handle doubletap and other such behaviors without interference from the client interpretation of keys. A new lsl flag to re-enable doubletap (and other potential extended movement behaviors) could be implemented should the scripter wish to re-enable doubletap to run.

Doubletap to run should be enableable/disableable via a flag in prefs.

So the logic would be:
User has no scripts requesting control input: doubletap on.
User has scripts which have taken controls; doubletap off.
ALL user scripts which have taken controls have re-enabled doubletap; doubletap on.

I think that covers it - would hopefuly not break content by ensuring content is more likely to break the new behavior.

I may well be wrong in this.

People who use such scripts (phazing, katana, etc) will loose the ability to run unless Ctrl-R is kept

People who only learn to run with double tap will loose the ability to run once they start using an established device, or they will need to relearn. Making people relearn what is a fundamental movement for some groups of residents is a bad thing (tm)

Switching a feature/keystroke that has been in use for years is just an insanely bad idea, and I am astounded that it is even being considered.

Someone above mentioned that Unreal uses double tapping to run, and I know that to be inaccurate. It uses double tapping to dodge much like in the way C:SI works.

I vote against adding this feature and recommend either adding a new key for running or leaving it the way it is.

Seriously.

edit And since I found out that it was already implemented.. ugh Please change this. While my previous statement may have stretched it a little bit, its still damaging. To put it simple enough I'm opposed to this change due to the problems it will probably cause for developers and because there are way more important functions needed to be implemented involving the keymap.

Double tap wouldn't work (if any of the lindens have used SL outside of the office they would see the lag before avatar moves, SL has chosen not to include adequate hardware delegation to sims and therefore any form of double action won't work even if it's client side, how can a user correctly interpret what is happening client-side if movement changes in-world don't occur until the damn network&sim responds to requests made 10+ seconds ago)

The only reason I can see for this change, is slightly more "ease of use" and slightly more "intuitive" in theory but not in practice.
The people that would benifit from this wouldn't even know it's implemented and would use it by mistake, where as those aware of the change are against it. Not to mention every type of movement mini-game and most keyboard driven physics programming will instantly brake (over a million different products).

And if CTRL-R is removed (it seems to currently still work), then it could cause even bigger problems.

I'm sure that there are implications I'm not yet seeing, the fundamental point being that LL has decided to implement a key combination that is already in very common usage.

emDash by Cheshyr Pontchartrain http://slurl.com/secondlife/Gallifrey/128/163/567
Omniphaze by Ryozu Kojima http://slurl.com/secondlife/Hwaryeo/106/161/58
Ashes Jin-Geom by Esprite Xavier http://slurl.com/secondlife/Samurai%20Island/178/48/25

just for a start.

This is far more than "theoretically-broken" items, this is a real issue.

Working on features, like properly implementing keymapping, or simply fixing other problems and bugs would be something I would hope would be higher on the priority list. I think thats the main point here. But then again, if anyone has some facts, stats and or proof for the man please provide it for him like seany did, it wouldn't hurt!

Wouldnt know about that, but I do know that there.com uses the doubletap to run.

Not to mention that I never run in SL, and I know of no one who does.
If movement needs to be speedy, I just fly.

In C:SI duelling, we are not allowed to fly, only running and jumping (and double-tap do dash) to try to move faster than the opponent. If a young fighter keeps on simply walking, he get sliced in less than 5 seconds.

Please Lindens, at least make this feature "enable/disable" in the pref just like we (CSI player) are able to disable "flying by holding UP button".

Thanx for reading

I'm also quite against this change without a means of turning it off if I want to. I'll often times tap forward to reposition myself while talking to people, this could prove quite annoying if I were to sudden take off for no apparent reason, or worse run into someone whom I'm trying to line up with.

C:SI currently has more than sixteen thousand customers, and is growing by approximately a thousand customers a month. Without having any way to know for certain, I'd speculate that the majority of those are not hard-core enthusiasts who fight on a daily basis, and probably aren't exposed to the "common wisdom" of the C:SI community on how to get around some of SL's quirks to get the most out of a C:SI product. That majority will (extrapolating to newer future customers) likely think that C:SI developers were stupid to have chosen a key combination for dash that they could otherwise use to run, therefore making it so that you cannot run using C:SI products

I understand that you probably are not terribly interested in sword combat in SL, and probably will not be motivated to try it out long enough to really get a feel for how many things LL has recently done adversely affect the system, but rather than ask you to go to a vendor I'll send you a weapon in-world so that you can see what I mean.

If for some reason you prefer to receive a weapon from a vendor, I have several vendor locations listed in my picks, but will also send you a landmark.

(On a personal note, not being a weapons-user, I absolutely love the double-tap run).

To the subject at hand, emDash and similar devices won't be broken by this, but they will have to be changed to chording behavior (i.e., hold another key while moving to dash.)

It will, however, break any older objects who's creators are no longer around to fix them. And also, as I've experienced numerous times while working on emDash, will cause major confusion with users. SL is laggy, buggy and unreliable in many ways. Double-tapping is constantly being triggered accidentally by users because their connection is slow, their computer too slow, or the sim they're in hiccuped.

A feature which I WOULD vote for is the ability to capture double-taps at the client end. This might alleviate the lag issues I mentioned, and would most definitely eliminate the hacks we have to go through to emulate it. For instance, add CONTROL_DOUBLE_UP|LEFT|RIGHT, etc to the list of usable keys.

I would rather have shift-forward/back (which is as yet unused) for run.

Ideally, of course VWR-6250.

Obviously LL expects to win the battle of "who gets the keystrokes", forcing content creators to either endure the customer support issues or redesign their products, never mind who implemented it first

Perhaps Tofu could tell us scripters on how to do that. The problem is that there aren't many keys available already :
http://lslwiki.net/lslwiki/wakka.php?wakka=llTakeControls
You have to remove the four arrows, turn left and turn right because of their effect, so you're left with the only two mouse buttons... which make no sense at all for dashing. LL could have used Shift+arrows, Ctrl+arrows or Alt+arrows, but us scripters don't have that option. And even if we had, double tap is still what makes the most sense for dashing when you want to both be able to run and dash.

Robby, at this point do you not think compromising to an optional setting would be enough? If LL intends to win then I believe they will win. I do believe though that a compromise needs to be made so developers, customers, and other residents can be happy. I do not believe at this point LL will take the function out of the Second Life no matter how much we want it to be removed.

Tofu, as a member of the C:SI community myself I can say that I did expect this to cripple the C:SI system and I am definitely relieved it did not, but you can see that there is a large number of customers who will be negatively effected by this new function. Is this function becoming optional a possibility?

Also note how the new double-tap to run system works. It's NOT a double tap, it's a tap, tap-hold, in order to run. In order to dash with the C:SI system you have to tap-tap, which only gently moves the avatar forward. If anything, when trying to use the new run in the release client, you DASH first, then run.

The original fear of many people was the complete and outright breaking of certain products (and a great many of them), we now realize that's not the case. However, that doesn't change the simple truth that features like this just don't need to be implemented. Linden Labs is asking the users of the game now to use a double tap for run. Instead of simply toggling run on or off with ctrl+r as it has been done for years now. This is just an unneeded control change, to a system that people are already used to, in a game that is already riddled with UI and key and control problems.

The gaming industry is notorious for releasing games out onto the market with poorly designed default keymaps and movement controls. The primary difference here, is that the majority of those games out were at least smart enough to build in client and UI remapping. Now remapping really isn't the point here, but I'm using this as an example. Users need the ability to feel comfortable with their controls, and their surroundings. If a company was to do the same thing with a control or movement feature in most other games it wouldn't be as large of a problem, *because* of remapping. However, here we don't have remapping, we have custom build products, and hundreds maybe even thousands of scripts that may need to be altered if this change is made. A change, I remind you, that really does not need to be made in the first place. Why is Linden Labs making the change? Did they ask feedback from the user base on this issue? Where did the idea for this new feature come from? These are things that should be asked when something like this comes up. And so I've come full circle, bottom line here is this is a bad idea.

My complaint is NOT that this issue prevents dash, it is that it is confusing because it is a conflict of key mapping!!!

If they remove CTRL-R and move to only using the double-tap to run, the current C:SI code will actually prevent running, because the user will dash instead (or maybe first, as you mentioned).

You've been around C:SI long enough to know how people HATE dashing unintentionally, it was for a while one of the most frequently-voiced complaints, and many users were asking for dash to be completely removed because of it

Archanox intentionally worked to make dash less sensitive (/me confirms via the patch log), so that our users would be happy. Now there's another problem where dash can be unintentional, and this time it's caused by a Linden Lab decision made without community feedback.

I can't help but think that there's a better compromise to be made, like using SHIFT to run, that could not possibly have any conflict with ANY in-world product already in existence, whether C:SI or not. Am I missing something here?

.

In Counterstrike as an example that was done.

I would argue that it could even be kept, if the default was that double-tap to run was not the default, so that users to whom it didn't matter could enable it, and as long as an alternative (such as CTRL-R "always run") were available.

But the current default "conflicts" with current content, even if it doesn't "actually" break it as so snidely mentioned above.

The fact that this is conflicting with many products that have existed for quite some time really makes me surprised that LL wants to push this through.

Yes, having an intuitive way to run might make some of the user base happy, but messing with the preexisting control setup that people have grown accustomed to using and scripting around does not seem like the logical choice considering there are so many unused keys on the keyboard.

Alt?

Alt would mess up focus.

I believe Ctrl-Shift-Arrow would be a free keystroke for running in any direction, but then it's not a standard and there is the similarity to camera controls that could cause you to run when you really wanted to move your camera.

How about a toggle. Maybe Ctrl-R as a mnemonic for run?

Seriously though, with the movement (and camera) display now put on screen by default to help the new players why not add run into that and leave Ctrl-R as a toggle for everyone that actually has spent more than 20 hours in world.

That is a relief, and I'm very glad to hear that.

Tofu : "I'll talk to some folks here about what to do with tap-tap-hold, based on the feedback."

Thank you, that is very much appreciated.

I read here that some MMO has it, I assume they mean MMORPG. I can understand it in that kind of environment, where you run and follow a lot. The whole game is designed with moving that way in mind.

The Second Life environment is very different, running is something you only want to do in very little cases, and even then for most users running isn't a optimal experience, because of lag, either clientside or serverside. Double tap might even then happen accidentally, and be a nuisance most of the time.

For what kind of users is this intended to be more intuitive? If i think about SL users, I picture people who predominatly don't come from a MMORPG background and/or don't expect it to behave like that. Because you know, SL at its base isn't a game. (it can have some) Where there requests or complaints for this?

Now this addition could be harmless and not or breaking very little content. Looking only at this thread, it is hard to say either way, but at least these products might have some added side effects. I worry that a script that overrides the double-tap run will be too slow and you do run for a bit at first.

The fact that several users products have used double tap as a dash and not run is a sign. Atleast for these content creators and their(happy?) client double-tap dash is what seemed intuitive.

I'm not someone who stands in the way of improvements and actually often petition for features that would break a lot of content. But I think it is important that it is explained fully why a chance happens and what the benefits will be, and if it in the long run will outweigh the short term pains. One pain that would need to be discussed with content creators is if there is a suitable replacement for their double-tap forward dash widgets. It would be a shame to add a extra run option but remove(worsen) the dash users have created.

its no fix - its DISABELING WALKIN IN RUN! by taping

please leave it the way it was, maybe jumpability comes back then too hehehe

I'd also like to see more people using the ability to run. Being hidden away in a menu, or a shortcut key to toggle on and off, means most people never run in SL. So what do people do when they want to cross a crowded, enclosed room in a hurry? They start flying, and plow through everyone in their uncontrolled path. Running actually offers a much greater degree of control when trying to do that, and if people did start using it, then maybe we'd have fewer idiots turning a crowd of avatars into a line of bowling pins.

I like the double tap, I can't seem to understand why so many people don't except in those cases where it maybe breaks content, but if people are that adamant against it I'd at least like to see running mapped to a key. Hold down shift, or Q or something and you'll run when you start moving. Being able to toggle "always run" on and off is useful, too, but just having run more readily available on the fly, something people won't overlook, is something SL would benefit from.

The functionality is great. The command chosen is a problem.

I don't think it should be removed, but could be improved upon.
If any of you have played UT2004, the game has double tap actions,
and has a very good option to change the sensitivity of the double tap exactly for those of us that activate it by accident.

Perhaps a slider in the preferences menu ranging from 25milliseconds to 400ms would solve the problem?

At least if there was an option to disable it, such makers could just tell their customers to go disable it.
As for myself, I'd disable it by default, though.

The problem is that when you tap-tap the emdash or omniphaze to dash you run instead. Maybe 4 times out of 5.

Where in the past you could pgup-pgup-tap-tap-tap-tap-tap-tap-tap-tap to shoot across the sim or just tap-tap to pass through a wall you now fall back to earth and run in the first case or in the second case run into the wall.

many times taptap to run is stealing the key before the omniphaze and emdash can catch it and trigger.

Enabling it as an off-by-default client option that can be enabled through the preferences menu resolves your concerns in entirety by allowing residents to enable it if they want to, yet not breaking any existing content by default.

If you think about it I'm sure you can see that would be a perfectly acceptable option.

Frankly, avatar running does really need to have an easier means of toggling than using a bit of an awkward 2-key combination that (at least for me) forces your hand off of the movement controls in order to enable-disable run. This feature is a reasonable means of offering that, and if presented as an optional feature it does no harm in being implemented.

I appreciate this concern, but the tap-tap is in no way stolen or otherwise masked from scripts. If the scripts aren't responding to the tap-tap then that is most likely a symptom of lag which is agnostic to tap-tap-hold running.

Why is it that LL insists that any shiny new feature has to default to ON?

How dare you doubt that infant wisdom and all around correctness of Linden Labs! Why if it wasn't for them we wouldn't have these awesome fandangled unneeded features of shininess!! /facetiousness

Optional with default to on would be OK, I think. That way you only stop things working if and when they are causing a problem. I love the new run, personally.

Sean- about the phase thinger, are you saying it's a huge problem to run into a wall when the scripted double tap fails to register, but it's ok to stand still?

I think "double-tap to run" should be implemented, but only if it can be disabled easily. Notecards are easier to update than scripts.

• This will default to 'On'
• A persistent 'advanced' option will be added to allow it to be disabled.

The current behaviour isn't tap-tap-hold which to me implies that it's the time between key presses that counts while it's actually the time between the first release and the second tap that's used.

Find a flat sim and start walking forward across the whole sim, after 10-30-60-whatever seconds release the forward key and press it again. You'll be running.

The time-out should be (second tap - first tap) < time-out and not the current (second tap - first release) < time-out.

• This will default to 'On'
• A persistent 'advanced' option will be added to allow it to be disabled. "

Thanks for giving us a choice on how to 'run' our Second Lives.

Especialy since I already have scripts that work this way...

• This will default to 'On'
• A persistent 'advanced' option will be added to allow it to be disabled.

Ah... yeah.. thanks..I think?

Any reason why CTRL/SHIFT/ALT+forward hasn't been choosen instead?
At least CTRL/SHIFT/ALT can't be detected by LSL, you are 100% sure it won't break anything.

Because Ctrl-Alt-Shift-UpArrow is Camera pan upward
Ctrl-Alt-UpArrow is Camera tilt forward
Alt-UpArrow is Camera Zoom

This is already discussed and proven not workable.

Shift Uparrow is 8
Ctrl-Uparrow is last line of chat history and for straffing Ctrl-Left is Fly on some computers with OS X

I would submit that this is distinction is largely irrelevant. Lag in SL is a given, as ubiquitous as air is in First Life. The UI needs to be able to work with the conditions we have, rather than relying upon distinctions that exist only in the laboratory.

>> "In response to "With 159 votes currently this bug is currently 7th in the most voted list of bugs, 100 of those votes appearing in the first 8 hours." - I do think it's less misleading to point out that the issue was opened - and thus by this assertion most votes cast - several hours before any version of the viewer with this change shipped, and hence try to separate speculative resistance from demonstrable problems."

I would also note that anybody who voted for this before the RC shipped and has since failed to find any demonstrable problems has had plenty of time to withdraw her vote. Let me state for the record that I have tried the RC, that I stand by my vote, and that I find it vexing that it might be discounted simply because I came to the party early.

I have to say that I don't agree with being present with a default-on setting, though it is certainly better than it being untoggleable at all of course. Basically this means that anyone with an existing product using double-tap which is affected by this has to send out instructions to users as to how they must change their options, and will likely still receive a large number of outraged "OMG YOUR GADGET DOESN'T WORK I WILL SUE YOU" IMs even if they manage to do this.

CONTROL_FWD_DOUBLETAP would be a terrific thing to have, and in general I would say that easier access to running would be a good thing, but just because There does something in a certain way does not mean that SL should.

I have to say I agree plus some.I also find it frustrating and confusing that the linden who looked into the problem seems to have ignore the fact that the jira was not so much a bug, but a petition for the removal of a feature. And a great many people (who even though don't seem to have an issue with the feature as a whole) have voted, and still want it to be removed. I personally, like Samantha still sand by my vote to have the implementation stopped.

Does anyone even know where the idea for this bogus feature came from?

Please, oh please, fix long standing bugs instead of introducing unwanted features!

That is what's going to have the most impact on our customers...

Created a new issue request for this:

https://jira.secondlife.com/browse/VWR-6690, linked above.

I think that this is about normal users' usuability versus scripters' environment and customers. And since there are more normal users than the rest, I doubt LL is going to give an ear to this bug anymore.

I suggest we close it as "won't finish"; it reflects best LL's intention towards the scripters community.

So, if you're a scripter, you might have to patch your scipt because from now on, double tap makes your character change its walking animation and move faster. And pray for LL to not trample underfoot another key combo any time soon!

Ordinal, I give you the final word.

I mean even when they supposedly compromised on the issue, it was a poor compromise in my opinion.

I mean, this being on by default, with an option to turn it off in the "advanced" menu, basically means "it's on". Very few people are even aware of the existence of the Advanced menu. So, the message there is "no, we will not change this".

I would prefer for a Linden to close this as "will not do" to be honest - that seems to be the upshot, but I would prefer an official word on it.

I created a separate article for requesting the option to toggle double-click-run be moved rather than buried:

http://jira.secondlife.com/browse/VWR-6690
Move option for double-tap-run from advanced-character to preferences menu under "input & camera

(linked above)

Bottom line is its a shit feature.

shift-run, same movement keys otherwise as SL (including the letter equivalents).
icon/button/ctrl-somekey run, arrow keys.
shift + both left and right mouse to run (left and right together, without shift, walks).
icon/button/ctrl-somekey run, left and right mouse determine if you are moving.

Which of these is used "often" depends heavily on what effects the mouse is supposed to have. In stand alone games, the mouse buttons are often fire keys. Both Halo and Splinter Cell use them as such, with other keys, like tab, used to select which weapons to use. In MMO like games, Everquest II, for example, the left button, which you have run the damn menu (I can't tell you how fracking annoying that is...), is only used to interact with objects. The right button is to use the menu in them, but only where the menu makes sense. That is, sadly, every place in SL, but in EQ I it was only in very specific cases, but one of those cases was clicking on your fracking character. You learned to either keep the mouse cursor as far from your character as possible, or to always do 90% of everything in what SL calls mouselook, because even though the camera could be "adjusted", and can in EQ2 now, far better, 90% of the time you would open the damn menu on your character while trying to get a better look at something. Its wasn't always "possible" to work in mouselook (the environment was a lot like SL's). SL magnifies the design disaster that EQ1 had with this feature to something 50% bigger, not the least do to the fact that you can zoom the camera in and out, but near as I can tell, the "angle" you look from is fixed, and always looking as your back. EQ2 lets you easily look at yourself, at the landscape, etc. all while in the mode where you "see" yourself (so long as you remain in view), but then *you* turn to face the direction the camera is looking when you move again, and the general "angle" your viewing at stays more or less the same.

Maybe the new client's camera controls give some of this, but its a pain how you have to use them to get any results.

As for other related issues... I second the complaint about function keys. I have tried some of the weapons in this game. I don't get how people use swords here at all. Maybe something in the AO I use to fracking things when used with the game hud, or.. Who knows. But, when you attempt to use arrow keys + clicking, to generate sword actions... Its just a mess. You move when you don't want to, in directions you don't want to, and your limited to a tiny number of moves at that. In EQ2 I have 3 icon bars, assigned to the f1-f10, ctrl-f1-f10, and shift-f1-f10 combinations (I never use the keyboard versions though), plus a 4th that can't be assigned to anything, just for combat skills, plus one bar, which appears/disappears when moused over, to deal with incidentals and some buffs, plus, until a recent change in their crafting system, I also had yet one more I could pop open specific to "those" skills. It sounds to me like people trying to make complex interactions in SL, which could also include ships, vehicles, etc., are either forced to use lag prone huds, or bend the clients limited keyboard support into a pretzel, in an attempt to provide something that shouldn't require something this absurd.

Instead of correcting "that" issue, you adds something that one one wanted, asked for, thinks makes sense to them, or helps things, instead of creating more issues.... WTF? This is like item 9,999,999,995 on the list of features I would, in your place, even be bothering with. With all do respect, it sounds like someone played some game one day, got the silly idea that because it worked in that one ***specific*** context so well, it should in SL, and everyone else either treated this like the basement project, with no existing users, and said, "Ok, great!", or no one objected among the build team, so they just went ahead with it anyway, and everyone is now trying to claim it was "intended". I have difficulty imagining a room of people sitting around and saying, "Ok, here is the list of numerous things we could to do make this feature more intuitive.", and actually picking "this one" out of such a list, well, unless I am actually 100% dead wrong and the closest any one on the team has ever gotten to playing any modern first person, or even second person, style game was Pac Man. Oh wait... No, Street Fighter... That would explain everything. You had two buttons and a joystick and half the shit you did in the game involved tapping the stick left 5 times, up 2, down 3, and hitting kick.... Yeah, its *perfectly* analogous with SL, unlike Halo, Splinter Cell, Myst, Medal of Honor, Thief, or even WoW, EQ, etc., etc. Don't know why I didn't see your genius!!

Seriously, name one game that uses this effectively and I will show you 90 that it would be completely, absolutely and totally worthless in, especially with the limitations that exist for controls we are dealing with.

I mean, prim skirts disappearing, borked buoyancy and hovering, repeated crashes... is something I have to deal with on a daily basis. I mean... double tap to run should have been a low (or null) priority compared to that...

Time for a new petition, maybe?

Double tapping has disconcerting consequences and it's made worse when lag rises, something that is getting worse than better nowadays. There are too many deleterious side-effects with overloading the basic movements. For any events (precision flying, combat, or just adjusting on'es position in a crowd of people) in which repeated movement taps are used to control oneself, having a short walk-movement become a spastic newbie-like bump because it is now converted into a run-movement creates massive discomfort. The avie experience for newbies and experienced people will be diminished. Seriously, this change is plain wrong in virtual kinematics. And, having a feature switch to turn it off is even worse because the feature itself is bad kinematics architecture. So now there will be dead code potentially getting in the way for some future developer to get wrong and more devloper time spent on swtiches and UI changes to the client viewer.

And again I ask and chide, why are the Lindens adding ad-hoc features, tying up developer resources when there are so many serious bugs to be fixed first?

Summary: Doubletap-to-run destroys precision movements in SL. Bad feature, remove it.

Please don't kill this feature. It's fun to run around as a kid AV and this makes it easier than [ctrl]+R to choose between running and walking. (^_)

Take double tap to run out, it is not a good feature mostly because I and many who use the interface the right way will again have to retrain just to do simple things, and that is not fun.

FIX SL FIRST!
thank you

P.S. What would be awesome in the future after all the stuff still wrong is finially fixed, and not before, would be a customizable menu of controls for doing everything related to movement, so that each user can program it to his/her liking seeing as so many games have small differences that each person could just program to be the way they desire and or are used to using. (many games actually do this)(oh and sorry Lefties but you are a minority anyway so of course as always you will have to accomodate either way but no I didn't forget your point of view, its just not practical, and maybe having the customisability would be to your advantage)

What do you think we should do next to mess things up? Make people have to hit " before typing something to say? Lock out the movement keys while you're typing a message? They already TRIED that one, and it took several updates to fix it.

Fundamentally the only "difference" between SL and an FPS, other than you have to "intentionally" go to a CCS, DCS, etc. combat area, is that mouselook works in "both" first person and second person view, so you can look around you in all directions while your AV is "visible" in second person. Its something that has, frankly, driven me nuts to not be able to do since I started. lol

Look, I see it like this. Linden Labs came into this thinking to give us legos. It never occurred to them that one of the defining characteristics of something like that is that when you start of try to make them "do" things, you will run into situations where a lego just can't handle it without way too many parts to make it look/work right. We on the other hand showed up, got a good look, and went, "Oh cool! A real metal shop!", and when it turned out half the stuff we thought "would" work wouldn't, we resorted to using the tools they did provide in ways that added really serious stresses to the system. Instead of IK chain style object linking we have "animation scripts", which take 50 times as much complexity to both move "and" calculate how to move, objects that would take one line of code to move in an IK chain. Why? Because, other than the "base", nothing is connected to anything else, so what should be, "rotate elbow <0,45,0>", becomes, "do until elbow is at location <x,y,z> and rotated to <t,u,v>, do 50 calculations to figure out what this means, then loop to the 'do'". The server has to run this, and its doing 10-50 times what is strictly necessary "to" do that.

Keypads (or even HUDs), instead of making the buttons a texture, then asking "where did I touch", you make 9+ prim buttons, plus textures, plus scripts, then a "plate" which "listens" to these to figure out what happened. Again, the "server" has to make this all work. Everything that doesn't involve either one single axis of rotation around the "base", or needs multiple places to touch, or anything else you can't do with chat or sit, or one "touch" takes 1 extra prim, texture "and" script to manage.

Imagine this was your PC, and all the scripts ran on "your" end for a moment. The people complaining now about crashes and poor performance on systems that worked OK before certain things where added, would be trying to explain to their insurance companies just how a PC caused a six foot flaming crater in the floor of their rooms. Its nuts, and its, at least to some extent, due to simply not realizing this would happen and how people would use it, and why building something out of a dozen prims, which "should have" used a single texture, and a collision -> texture projection, 90% of which is "already" done just to determine if you touched something in the first place, was a really bad thing, which should have been blindingly obvious was going to happen at some point.

We need to reduce how much scripting and the rest is needed to make it all work. Linden knows this, some of us recognize it too, but imho, we recognize that the problem is that you can't, as things stand, do it. The tools are not available to make it work with less, and the existing tools "mandate" doing it the dumbest way possible, in many cases, for the same reason.

Keyboard issues, are just the visible part of the iceberg we are running into. And, like most such things, 80-90% of it is under the surface, where its less obvious what the problem is.

Hmm. Sorry about the rant... lol This issue is an example of things that "limit" what we can do, and, in the process, maybe create unneeded complexity. How much server resources does a "listener" have over a keypress test from the client, if you opt to use "/9 draw", instead of, "F2", for example?

It would be like in IM all the time. You can always tell when I'm in IM, because I STOP MOVING.

SL is so fundamentally different an environment from a combat game that it simply doesn't make sense to draw parallels between them. Yes, I agree, YOU should be able to use it the way YOU want, but that doesn't mean the way YOU want is the natural one that should be taught to new users.

And on a side note, flaming each others opinions and conceptual ideas for solutions does not help the situation. Try and keep things mature here folks.

It CAN currently be disabled. It's in the debug menu. >>Advanced >>Character >>Tap-Tap-Hold to Run.

I admit, that setting CAN be put in an easier place to be found, but you can't deny it's there. Feel free to uncheck it if you don't like it.

I'm a "arrow keys only" type of user because my chat bar is up 100% of the time. I don't do weapons, I don't do combat, and I get woozy in mouselook mode. But, I do scamper, sneak, and run around. Double-tap run makes it all the more fun. (^_)

" Do people come here to post without reading anything, or am I on a mute list of some sort? "

Look who's talking. At least please read the bug description. We've kept it updated so that you don't have to read all the comments. It's content creators that have trouble with this implementation, because when users like you don't like a product, they don't come here to complain.

I personally do not believe that it is impossible for Linden Labs to give us access to more keys via LSL. I think the entire keyboard should be unlocked to LSL scripts. So rather than try to alter the only keys we as the developers of Second Life have at our disposal, I would rather suggest they unlock access to more keys, or at the very least stop trying to fix what is not broken, and breaking things as a result!

I do not believe that adding the double tap to run functionality will offer any improvement in usability for the average user. I think it would be better to offer access to toggling RUN on/off via script and those people who wish to develop around the idea of double tap to run, can implement it in their own projects. I simply do not see that the average user of SL needs a double tap to run feature. Rarely does anyone run in SL to begin with, unless it is in a specialized environment, and then with the suggested scripting option to toggle run, this would make sense.

My two cents,
~Ayame Musashi

I don't care what the command is, but I like being able to break into a run at short notice. It DOES provide an improvement in usability. And, yes, I do run a lot. And walk around. And jump. While I'm talking to people.

And, as my previous comments indicate, I fully agree that scripts need access to more keys and key combinations, and I would be just as happy with shift-forward to run, by analogy with shift-side to strafe.

There is a double tap feature related to something that conflicts somehow with other things that might register double taps. I get that much but it isn't very specific.

Could the summary or description be updated with more detail?

This will never get my vote.

Perhaps the title of this JIRA could be changed, maybe "Select a combination other than 'double tap' for 'start running'"?

IMHO this is poorly implemented functionality and should never have been implemented without proper design. LL make matter worse by defaulting this feature to on and then hiding away the option to turn it off (from the main menu "Advanced" -> "Character" -> "Tap-Tap-Hold To Run").

Please, please get rid of this feature!!!

Tap-tap-hold-to-run by far very is useful, there is no way I want to see it removed. If it messes with scripts, I suggest alternate ways of solving the problem. Tap-tap-hold to run is great.