-
Resolved
dice rolling script imbedded in post
I saw this on another gaming site (sorry…she didn’t mean anything to me, and I broke it off right away…) you have the ability to embed a Vcode right in your post so a die roll will occur as soon as you click Post Message and it will show up in your post, so for example if I were to write “Lupo is tired of the talky talky humans, takes out sword and chops [dice] die type: d20+6[/dice] at the biggest one’s head” the post would look something like this: “Lupo is tired of the talky talky humans, takes out sword and chops “23” at the biggest one’s head” . Don’t quote me on the actual code, that doesn’t look right, and I’m not looking it up, but I could get the specs if you want. I’m sure you know more about it than I. It’s an option some folks might want.
-
Assigning for work.
- Assignment jendor added.
-
Ok, so here’s an idea on how to handle this. we create 2 tags, [dice] and [idice] idice would be for inline dice rolls, dice would be for full graphical dice display.
Now, any time either tag is use in a post or in a preview, an entry is created in a new database table, that stores information such as user, board, Topic, post, number of dice, type of dice, modifier and unique key. The key would need to be unique and md5 hashed. the hashed key would be put into the post in place of the die type. for example.
User types in [dice]8d6+8[/dice] and clicks preview, after thier preview shows on the screen, the text for the post shows [dice]55j535j3i9fmnafa5nldf34925252[dice] and that is what is stored in the database. Then when the page is actually viewed, we pull the information using the key to show in the post. This would prevent dice tampering.
- Assignment Donboy added.
-
- Status changed from New to Assigned.
-
Its possible I dont fully understand. But I think there might be a problem. I dont know how to decode a MD5 hash. As far as I know, its a one-way process. So you can string together a bunch of characters and then generate the MD5 from it which results in a unique string of characters like what you showed. But in order to check the validity of the code, you’d have to take the same string of characters, generate another MD5 and compare the output strings to be sure they are the same. This is how most password systems work. Your password is a MD5 encoded hash of whatever plain-text you submitted. So when you try to login, the system just encodes whatever you put into the form and compares the two hashes to see if they match. If they do, then you are allowed in. Otherwise, it says password is incorrect.
But maybe that’s not what you mean. Here’s how I thought it could work:
The user types in the dice code like you described: [dice]8d6+8[/dice] Then when they press the Post Message button, several things happen. The dice roll result is computed. It gets stored to the table you described, along with a hash that is unique. (This is another issue we will have to address in a minute). The posted message gets stored in the “posts” table, but instead of the dice code like I mentioned earlier, it is the hash you described. So if you were to edit the table and look, instead of the dice code, you’d see a hash, like this: [dice]55j535j3i9fmnafa5nldf34925252[dice].
Now the user will never see this code. In the emails that are sent out, we will put the actual dice roll results. But when the user views the posted message, the message board system will take the hash and use it to look in the table and find the dice roll that is associated with it, and display the roll results instead of the hashed value. So the only reason I’m using the hash is for linking purposes.
As for tampering with the rolls, the only way I can imagine is during a edit of their post. I imagine its possible they could post somewhere else with another dice roll that is the same. Then edit THAT post and see what the magical hash key happens to be. Then edit their original post and replace the hash key and they are in business.
-
Obviously this is a little complicated. One way to avoid all this is by putting all the rolls at the bottom of each post instead of trying to embed the dice roll inside the message text. As long as we are trying to embed the dice roll directly into the message body, there is a chance that someone could edit their post and alter it.
If we just associated a dice roll (or rolls) with a posted message, then that would be much less prone to tampering.
-
I was not suggesting the md5 has to be undone just using it as the unique key for the table in the database. for example before the post is submitted, we take the board,topic,post and combine them into a string them md5 hash it, that becomes the unique key for that dice roll. Then we put that has in the post, and when the post is looked up to be displayed we just do a select * from dicerolls where key = hash and then show the results as the post is generated. I suppose we could get round it by just using some other key, my concern was lets say we use just standard incrementing numbers, so we have [dice]3592[/dice] they could just put in 3593 or 3595 to show a different roll, now we could put in logic to make sure the board and topic and post match, then if they dont we put that in the post results like (This dice roll does not match the post) or something.
-
Ok, I see. But didn’t you want to have multiple dice rolls in a single post? In that case, your “salt” has to be more unique for the keygen. Board, Topic and Post would only give you a key that allows enough uniqueness for a single dice roll per post.
I guess we could add 1, 2, 3 as a suffix in the salt that is used to generate the key.
And I think the “dice rolls” table needs to have those other attributes broken out into columns so I can quickly select them when someone views a post in messagethread.pl. I can put indexes on those so its a faster select. But the MD5 could be the primary/unique key.
-
Ok making some good progress with this, single dice rolls are posting and displaying just fine, both inline and full graphics. Multidice is working inline, but graphic displays are breaking during submit. once I have both working, ill be doing inline and graphical displays for the new EOTE roller.
-
To properly handle in post dice for the d6 roller going to have to add the option to add the wild die. There are a few different ways of handling this.
First would be to add additional dice flags such as [dice] [dice=] [idice] [idice=] [wdice] [wdice=]
The other option would be to place the wild die flag in the die roll itself, such as 4D6W or 4W6 or just 4W or 8W. -
Im leaning towards the second option of having them add a W into the roll itself, probably replacing the W.
-
I am also thinking with how complicated this in post dice roller is becoming, it might be a good idea to have a popup window provide a graphical interface. So when creating the post they hit a button, a page similar to the exiting dice roller appears, they choose all their dice options and click “OK” and then the correctly formatted code is inserted into the post.
-
Alright, I believe the D6 roller is working correctly now.
Left to do:
EOTE inline dice.
Web Interface for Inline Rollers. -
EOTE die roller is complete for Table and Inline entries, I also modified the D6 roller to support more standard notation (leaving out the D6 portion), 5D, 5D+3, and then 5W and 5W+3 for Wild Die inclusion.
Still need the Web Interface.
Also remembered, need to handle the Digest, and Email formatting. -
Code completed and launched.
- Status changed from Assigned to Closed.
-
- Status changed from Closed to Resolved.
Highest Rated
- Mobile Browser
(5.00 out of 5) - dice rolling script imbedded in post (5.00 out of 5)
- Custom Board Backgrounds/CSS (5.00 out of 5)
- Custom Sigs Not Working
(4.00 out of 5)
- Mobile Browser