More info on touch

Want more games in-world?

If we could get an <x,y,z> coordinate where a touch occurred, we could make ball games (like a pool table) where skill was a factor.

If the touch event came on mouse-up, then the amount of time the button was down could be provided as well, to be used as a force-factor (or whatever).

From what I understand, we have both of those.

llDetectedPos(0); and llGetTime/llResetTime. Put the Reset in the start, and the get in the end. Voila, a 'time held down' timer. The llDetectedPos tells you where the person is standing, so you can get an angle of attack that way. Just have them 'touch' from first person.

There have been pool tables in SL since beta

Moving your avatar around to position it properly is a pain, even when trying to face someone to chat; using it to adjust the angle of attack for a pool ball must be mostly a matter of luck. If players were able to control the direction and spin of the ball based on the point on the ball where they clicked, it would be more of a game of skill.

Thanks for the tip about touch_start and touch_end; I hadn't realized that these were mouse down and mouse up (but, of course, what else could they be?). Including the interval as a number of milliseconds with the touch_end event would surely provide better resolution, though.

I have heard that the Lindens would like to have world-class games available in SL. So many of the tools we are provided are just barely adequate for that purpose; and this seems like a (relatively) simple step in a direction everyone wants to go.Ooh! Where?

Ultimately, the success or failure of SL will depend on this. What we have currently is merely a start.

At present, SL is almost certainly populated mainly by creative people who enjoy exercising their minds rather than their motor skills. That's a recipe for good beginnings, but not for a viable large-scale future. It creates a population of providers. Where are the consumers?

I have friends who subscribed to SL a few weeks ago, and despite having technical leanings, they're already getting itchy feet and wondering what there is to do here. Please don't answer "Visit my dance club." You know what I mean --- the large-scale, highly interactive attractions don't exist.

Tiger Crossing's exhibit at Burning Man is currently streets ahead of most other SL attractions, yet this needs to be the baseline for gaming areas 20 times larger if we are to attract the game players into SL, not just the creators.

This needs to be remedied, and in the SL scheme of things, that means giving player-developers ever more powerful tools and abilities, and to relax the restrictions on creating powerful attractions. Yes, I know that the restrictions are there because each prim costs LL real money to host, but there's something inherently missing from that view. Attraction providers are not just a cost, they are a benefit for LL too. Without them, there is almost literally "Nothing to do" in SL except create, and that's not a recipe for large-scale success.

---

On the touch front, Almarea, there are several things missing. At the very least we need start and end events for each press and each release of each mouse button, plus setup functions to control which mouse buttons we accept being rebound for gaming, and of course some contrived multi-key combination to rebind them back to the GUI if something goes wrong.

Interactivity must start with pointer input!!! While I and others may be happy as punch controlling vi and emacs with the keyboard, I hope someone in LL recognizes that that's not enough for gaming. Not if you want to attract and retain the new generation of computer users.

Morgaine, you can already detect pressing and releasing the left mouse button. I suppose being able to detect other buttons would be handy, but LL coded LSL with an overzealous emphasis on security, so the last thing they want is for you to not allow people to use the normal pie menus because you remapped the right button presses to something else. I suppose they could just ignore the value of the pass_on parameter for right button presses, and always pass the RMB press to the UI.

Almarea, about a year ago, i used to hang out in Jessie, and there were working pool tables in there. Come to think of it, I may even have a copy of it somewhere... its fairly easy to make a pool table... just build it, make the balls physical, and put llSetBuoyancy(0) on the cues.
Position them using the editing tools.
On touch, make them move forward and then retract. Havok will take care of the rest.
Its crude, but KISS is often a very handy rule in SL =)

As you say Eggy, we can just about get away with it in today's noddy games within SL. I'm casting my view further ahead though, to the ambitious large-scale attractions that SL will require to attract and to hold gamers rather than just the creative folk.

It's actually a different ballgame to what we're used to, but our framework here is capable of dealing with it as long as the facilities set improves to meet the challange.

As it stands now, (L)SL is horrible for anything involved with the adjective "large". The programming model is totally fucked up. As a programmer, I am used to having centralized control over all the data my code needs to handle.
Say that, for instance, you bough a private server, and for whatever reason, you want to know who is connected to it, or what objects exist.
You could use sensors. But the maximum a sensor will do is scan a sphere with a 96m radius. The buildable area of a simulator is 256x256x768.
Why cant I just iterate over a list of clients, or objects? I mean, sensors are a figment of some wacky havok coder's imagination, right?
In reality, there has to be a friggin list of users stored somewhere in the server as a linked list or array, or database table.
It's not like it would be extremely hard to issue a SELECT statement and return the recordset as an LSL list. If its a list or array, it should be even easier.
Most of SL is based on distance, when in reality, distance is an abstraction that is completely irrelevant to most of the games/systems I want to code.
This is in turn, both a legacy of a past SL that was trying to be seen as a flexible, open-ended "game of games", and an inevitability of a current SL that is still made up of a large percentage of technically challenged socializers.
Let us not forget that the main thing holding back serious development is SL's very nature: the streaming paradigm. You have no way to know when a texture has finished loading, or an object has rezzed, or a sound has finished playing. User-controllable client-server coordination issues like these really make it difficult to make anything polished and appealing. Not to mention that the internet is slow as molasses compared to a motherboard or even a hard disk. Especially for us euro peons.
Also, both because of these shortcomings and LL's unwillingness to market SL as a viable and potentially lucrative development platform for RL businesses, we havent really had a professional, motivated team of people working together to try and get the most out of SL. Its nearly impossible to hire someone who will actually work productively for a large amount of time. SL is seen as entertainment, so heavy workloads and overly lengthy projects will turn off just about everyone. Ultimately, we are here to chat, fly around and have fun, so work is always less appealing than everything else.

You're entirely right, Eggy. But I'm not yet losing hope, because these things can be fixed.

You're totally right. But that's just an issue of parametrization. They've got it wrong currently, but it can be fixed. The absolute minimum fix is that a plot owner's sensor range should cover the owner's entire plot, no range limits. It's only for other people who enter the plot that the owner should be able to restrict the sensor range. That's a good basis for many games.

Yes indeed. But LL isn't totally deaf and their heart is probably in the right place, and they know that they won't survive if they don't provide large-scale attractions. So, those who have the ability and desire to develop such things need to bend LL ears about it. It's darn obvious to the most newbie developer that facilities are, er, on the light side.

So request appropriate termination events. But anyway, a lot of the problems in the area of lag are due only to pretty crappy caching. We're dowloading things every few seconds that we should have downloaded only once several months ago, because they haven't changed. That's not an inherent fault caused by SL streaming, it's simply some crappy code. I'm sure LL want to fix it too ... keep bending their ears about it.

You can't blame the Internet. The levelling MMOGs provide an exciting experience for those who enjoy that kind of thing, and even the twitch-gaming FPS's with dedicated servers manage fine, despite Internet lag.

Eeek. Well that sounds bad. But I haven't heard any high-ranking Linden suggest that their vision is so narrow.