Such a script noob

[LordHappycat]

Okay, there's this ring toss game I've built for use for a pub I attend at and I want to make it a good gift for them. But, I have no idea how to go about it's scripting process.

Like, I'd want to be able to make it so you toss this ring to several of these pegged hooks and register the corresponding points and all that. Moreso, to even throw the ring six times to try and score with. It's one of those old-fashioned Irish Ring Toss games where you toss rings at a fixed wall board and your goal is to get to 100 points.

So, I figure I'd have to script each individual peg, I assume? and I'd like for it to have it's own scoreboard and everything.

Help, please?

[Rolig Loon]

You'd certainly have to script peg, although you could do with a single script and address each peg as a link in the linkset.  The real challenges come in figuring out how to toss a ring and how to tell when it has landed on a peg.  Neither is going to be easy. The only way to toss anything is to make it physical.  I'd suggest using llCastRay to make it possible to identify a target in mouselook (with an approriate random error so that it's not dead simple to hit the target).  Getting it to end up around the peg instead of hitting it and bouncing off will be a nice challenge for the player, and then figuring out how to detect that it is around the peg is a bigger one for you, the scripter.

[steph Arnott]

To create a game like that based on skill and physical effort judgement is impossible in SL.

[Madelaine McMasters]

The scripting may seem difficult because you haven't yet encountered the difficulty of the physics. Have you tossed a ring at some pegs yet (start with the freebie snowball thrower script)? If yes, then bravo! If no, worry about that first.

Presuming you get that working...

Drop a script in the ring to report when and where it lands. I don't imagine a tossed ring takes all that long to settle, so you could just have a timer expire a few seconds after the ring is rezzed (tossed), and then use llGetPos() to figure out where landed. If you don't want to use a fixed timer, you could check once a second until two consecutive llGetPos() calls report the same position, suggesting it has come to rest. Then you report the ring's position on a chat channel and the pegboard receives it. From there it's just a matter of comparing the ring position to some acceptance box around the center of each peg. If the ring came to rest within the box, you score the points. A few seconds later, the ring self destructs.

Because I leave thinking until the last possible moment, I'd probably write a simple root prim script that listens for ring messages, repeats them to all child prims (pegs) via llMessageLinked(), and then tallies any replies it gets from the child pegs. I'd then write a little peg script that locates itself on rez via llGetPos(), and responds to any link message from the root by comparing the forwarded ring position with some acceptance box around the script's position (as obtained from that llGetPos() call on rez). If the ring is within the box, you reply with a message indicating the points scored. Each peg script would be identical, except for the point value, which you could store directly in the script, or in the peg's description field. The root prim would listen for link messages for a second or so after forwarding the ring position, then close the listen channel, tally any received points, then listen for the next ring.

By putting a script in each peg, you avoid writing the logic for a root prim to scan the linkset for pegs, building a list of their positions and points. In exchange, you have multiple scripts and listen handlers running. The latter method is, I think, easier and faster to code and debug. Once you get that working to your satisfaction and determine if the game is any fun to play, you rejigger the code to improve efficiency.

Good luck, have fun, stay Happy, Lord Cat!

[BrownBoxStudio]

Don't fret about potential physics issues, they do exist but can be "beaten". As someone who just finished programming a perfectly working skeeball game the only issue that I have now is lag. Physics work fine. Although I do have a high LI physics mesh until I get something better.

You shouldn't need to script the pegs, at least not if you have a base. In my skeeball game, which hole the ball goes in is figured out by one script in the root prim. A good way to figure out where a ring is and if it has scored, albeit not an easy way, is to get the center location of the thrown object and teh center location of it's scoring position. In this case you'd grab the center of the ring position on a timer and check that against a position by the peg. If the ring center gets within X distance then count as a score. You can do testing to see which distance is best so that non-scores do not count. Rolig was the one who made this suggestion to me for my skeeball game. This would even work to see if the ring stays still as you could use a timer to see how long the ring stays within the distance limit or check if the ring has stopped moving within X time. 

The way I go about not having to script each score prim is to have the thrown object report back which position it was closest too. This means the thrown object is given the position of each score spot when it is rezzed and then it tracks which score it is closest too. When the distance limit is met it "scores" and sends which score it got too the base. Then the base add new score to total score. 

There is really a lot more too it but maybe that can give you an idea of what to look into. Timers, getting positions, and sending information over channels are very useful in these types of games. If you have any questions, since I've made something that uses the same ideas, feel free to message me in world. I'd be willing to help out. 

 

Edit: Just noticed that Madelaine suggested practically the same approach as I did. I'll just agree and say that I've tested this and use it in my own applications. It works well, is fast enough, and the only issue is lag maybe messing up the messages being sent.