brainstorming idea for displaying dice number

[Xander Lopez]

I own a sim where everyone wears a hud created by me. And this hud has a dice button that displays a random integer in between 1-100 in the local chat when pressed.

The local message would say something like this:

[04:17] DiceHUD: Xander (xander.lopez) rolled 9.

Now, here is the issue.  Anyone could just make a random object. And they could slap a code in the object that will fake the dice message.

This allows people to cheat so they can win a prize for any dice event.

I am trying to find a brilliant idea that can prevent people from cheating by letting people identify they are pressing the legit dice button on the HUD.

The problem is, our sim is already laggy and don't want to add another llRegionSayTo() to the hud to communicate with some kind of central server prim.

Is there anyway we can display the dice in local chat without other people faking the message?

 

 

 

 

[Profaitchikenz Haiku]

I remember discussing this with somebody ages ago, possibly the medieval Dee RP sim, they had realised the same thing. We couldn't think of an easy solution.

My only suggestion is of a cheat monitor.

Assuming everybody wears the hud, and when the hud is pressed by a user, it outputs the message in the form you give.

If the Hud keeps track of the times and numbers when it issues such a dice roll but also monitors channel 0 for messages of the form "Dice Hud :  (wearer name) rolled..." and hears such a message that it has no record of issuing that message, it announces that It didn't say that and that the roll is invalid.

Klutzy, I know, and potentially a bit laggy with the listen on channel 0.

Going back to your other point about sim lag and regionSayTo, I have no practical observations that reegionSayto is in any way lag-inducing. It is very reliable, in a recent test where I was looking for events and communications that might get upset by region-idling, I saw no missed messages at all in the regionSayto or regionsay messages that were sent at 15-second intervals. Not a single one got dropped, and there was no obvious change to region performance. Try it as aa solution.

[Quistess Alpha]

My suggestion would be to have the hud llSay() (or llWhisper or llShout) on a specific channel, that all the HUDs know but the players don't. then any other huds in chat-distance relay the dice roll back to their users. if you (a user of the HUD) get a dice roll from an object that isn't your own HUD then you know it isn't legit.

[Mollymews]

 

6 hours ago, Xander Lopez said:

The problem is, our sim is already laggy and don't want to add another llRegionSayTo() to the hud to communicate with some kind of central server prim.

Is there anyway we can display the dice in local chat without other people faking the message?

 

3 hours ago, Profaitchikenz Haiku said:

Going back to your other point about sim lag and regionSayTo, I have no practical observations that reegionSayto is in any way lag-inducing. It is very reliable, in a recent test where I was looking for events and communications that might get upset by region-idling, I saw no missed messages at all in the regionSayto or regionsay messages that were sent at 15-second intervals. Not a single one got dropped, and there was no obvious change to region performance. Try it as aa solution.

^^ do it this way

any kind of game mechanic which can't be validated is inviting trouble

if was me then do it the safe way

player clicks HUD. llRegionSayTo relay server "roll,9" on some negative channel. Server validates the sender, the HUD (OBJECT_OWNER + OBJECT_CREATOR + OBJECT_CREATION_TIME). When valid, relay shouts it to the region on channel 0: OBJECT_OWNER + " rolled 9!" and gives out winning prizes/points/etc

this might be not what you envisage, but when all of the dice huds are shouting on channel 0 then there has to be a way for prize/points/etc to be awarded to a winner yes ? Which means that there is some prizegiving script listening for winner/loser messages already yes ?

[bobsknief Orsini]

Add a encrypted hash to the message and validate it.

[Quistess Alpha]

35 minutes ago, bobsknief Orsini said:

Add a encrypted hash to the message and validate it.

That would cause a lot of lag. maybe for some very specific things that happen rarely (IDK, 'going up a level' perhaps) it might be ok, but but I think for most things on SL that don't involve large amounts of money and such, 'security through obscurity' (only the HUD creator knows which out of 4 billion+ private channels is being used) is sufficient.

[bobsknief Orsini]

13 hours ago, Quistess Alpha said:

That would cause a lot of lag. maybe for some very specific things that happen rarely (IDK, 'going up a level' perhaps) it might be ok, but but I think for most things on SL that don't involve large amounts of money and such, 'security through obscurity' (only the HUD creator knows which out of 4 billion+ private channels is being used) is sufficient.

A proper implementation of encryption barely causes any overhead. But anyways, agree that a region say would probably be the best implementation.
Or one could completely forget about the HUD and just rez a box that people can click.

[Quistess Alpha]

5 hours ago, bobsknief Orsini said:

A proper implementation of encryption barely causes any overhead.

in LSL? I don't see how a 'propper implementation' is possible; although it might be slightly more so now with llOrd and llChar and llHash.

[Rider Linden]

21 minutes ago, Quistess Alpha said:

in LSL? I don't see how a 'propper implementation' is possible; although it might be slightly more so now with llOrd and llChar and llHash.

For general purposes llHash() would probably serve your needs.

An option for the original question, I believe that the sender key in the listen event should be the UUID of the HUD that sent the message.  (Verify this to see if I'm misremembering.)  Take that UUID, pass it to llGetObjectDetails() and ask for OBJECT_CREATOR.   If it is you then you can be reasonably sure that HUD is not a forgery. 

[bobsknief Orsini]

2 hours ago, Quistess Alpha said:

in LSL? I don't see how a 'propper implementation' is possible; although it might be slightly more so now with llOrd and llChar and llHash.

Neither of those are needed. The point of a encrypted hash is that you cant decrypt it, nor would you want to. You create a hash with for example llSHA1String that is always different, pick your parameters. Then ones the other object gets this hash you let it create a hash using the same parameters and simple see if its the same. In addition to that you also want to "salt" your hash.

You would do the same if you validate a password on a website or if you want to validate (token) a sensitive web form. Those same techniques you would use in for example web development and are not to complicated to implement in LSL with some workarounds.

[Mollymews]

when we validate the sender (the HUD) and the HUD is No-Modify then the integrity of the game is maintained

it doesn't matter if the game players know the channel or even if they listen in on the channel using their own scripts

with sender validation then it doesn't matter either if the message is transmitted in plain text

[Coffee Pancake]

On 7/19/2021 at 7:22 AM, Xander Lopez said:

I own a sim where everyone wears a hud created by me. And this hud has a dice button that displays a random integer in between 1-100 in the local chat when pressed.

The local message would say something like this:

[04:17] DiceHUD: Xander (xander.lopez) rolled 9.

Now, here is the issue.  Anyone could just make a random object. And they could slap a code in the object that will fake the dice message.

This allows people to cheat so they can win a prize for any dice event.

I am trying to find a brilliant idea that can prevent people from cheating by letting people identify they are pressing the legit dice button on the HUD.

The problem is, our sim is already laggy and don't want to add another llRegionSayTo() to the hud to communicate with some kind of central server prim.

Is there anyway we can display the dice in local chat without other people faking the message?

HUD broadcast dice rolls on a channel.

Nearby HUDS pick that up, decode / validate the message and pass it to the wearer via llOwnerSay

This has the added advantage that dice rolls will be shown in a brighter 'yellow' text rather than the usual green. So unless someone manages to guess your broadcast channel AND your quick and dirty hash/CRC code, their fake rolls will also be in a different color.

Use an experience to attach the latest dice HUD and you're golden.

It's not local chat, but as a side bnonus does mean people can easily opt out of dice chatter if they don't care for it.

Don't worry about the lag - this entire mess is lighter than that one random person who just wandered over with body & face & clothing huds on.