Page 1 of 1

Questions about player storefront features & security

Posted: Wed Sep 15, 2010 8:49 pm
by Gheeda
Working on creating some player run shopfronts & its going well. Just curious to know if there is a feature in php that allows for a 'tooltip on hover' effect? I'd like for descriptions of items to appear once a mouse has hovered over the item...

I'm also curious to know if there is still cause for concern giving a user open fields even after a strip_tags.

Re: Questions about player storefront features & security

Posted: Wed Sep 15, 2010 10:37 pm
by Jackolantern
Gheeda wrote:Working on creating some player run shopfronts & its going well. Just curious to know if there is a feature in php that allows for a 'tooltip on hover' effect? I'd like for descriptions of items to appear once a mouse has hovered over the item...
PHP doesn't do that, as that is the domain of Javascript. You can use jQuery to easily add straight-forward effects such as this. Here is the W3Schools tutorial for jQuery. Typically, I don't link to their tutorials since they are too short, but jQuery is so easy to use, it really does the trick for learning the basics. Then just search for a jQuery add-on that does exactly what you want, and add it to your files. There are tons of great features (thousands, actually) and most of them can be used in 1 or 2 lines of code!

As a side note, regular HTML does have a simple tooltip feature. To see it, hover your mouse over the "Members" link in the upper right corner of this forum. That is likely not what you are looking for since it can only show simple text. You probably want something a bit deeper that can show categorized stats and maybe even small item icons. If so, jQuery is what you need!
Gheeda wrote:I'm also curious to know if there is still cause for concern giving a user open fields even after a strip_tags.
Absolutely! strip_tags is only a defense against cross-site scripting (XSS). There are still several other things to worry about. This is a major basis to PHP security, since allowing users to enter text that will be processed is a major security liability. Do some research on PHP data sanitation. Ideally, you will add several different sensitization functions to your code to use in various situations depending on whether you are going to print data to the screen, store it in a session variable, enter it to the database, etc.

Re: Questions about player storefront features & security

Posted: Fri Sep 17, 2010 4:05 am
by Gheeda
Was thinking about something earlier....Two things really.. Is it possible to include Xxx.php IF ? Let me give you an example

Currently trying to make a gambling page that Randomizes for rarity then randomizes once again for an item of the selected rarity. Haven't necessarily been successful getting the second randomization to work with the first but that's not the big issue.

Got a gambling page w/ 4 weapon types to chose from...upon select you're taken to a page that does the randomizing & gives you the result w/ a little pic of the item...I want this within the main gambling page...instead of _GET on a 2nd page. I'd like to have the results page lie dormant in gamble.php and reload to Gamble.php?select=(1,4) to trigger visibility of page as well as dish the result. SO, in short...how is/is it possible to make a page not speak until spoken to...within another page.

Re: Questions about player storefront features & security

Posted: Fri Sep 17, 2010 4:58 am
by Jackolantern
If you mean reload the same page and show completely different content, yes it is possible! When you create a form, or a link, just make the php page it links to the same page you are on. Then have an IF construct that takes a value (such as a GET value if it was a clicked link, or $POST or $SESSION if it was from a form) and branches off to create an entirely different page.

Re: Questions about player storefront features & security

Posted: Fri Sep 17, 2010 3:38 pm
by Gheeda
Nice, so its now sitting quietly...but I'm still having trouble successfully structuring a randomization routine. Like I said in the post before I'm trying to randomize a rarity result...and then with that result...randomize again within the parameters of the rarity to select a random item. Am I gonna have to list all possible items WITHIN my randomization code as results to get it to function properly? Or is there a method to, after querying for an array of a particular rarity, to randomize a second result?

Re: Questions about player storefront features & security

Posted: Fri Sep 17, 2010 5:08 pm
by Jackolantern
You would put all of the rare items (as well as every other item) in a "master item list", which you should do anyway. That way, each item is only spelled out in one place, and has a master item number that can be stored in each player's inventory, and can also be referenced in the game. You could add all of the rare items that are gained in this way one after another so you have a solid, continuous block of numbers that you can randomize to reward the player with the rares.

Here is some psuedo-code to show how it could be done:

Code: Select all

 //get playerid
$playerid = $_SESSION['playerid'];
 //pick the initial rarity tier
$tier = rand(1, 100);

if ($tier < 40) {
     //find the actual item to reward
    $item = rand(200, 220)
     //pull the item from the master item db table
    $hItem = mysqli_fetch_assoc(mysqli_query($db, "SELECT itemid FROM masteritem WHERE itemID = '$item'")); 
     //store item ID obtained in a variable
    $rewardItem = $hitem['itemid'];
     //give the item to the player, using the playerInventory table, which stores the player's ID as a foreign key
    $result = mysqli_query($db, "INSERT INTO playerInventory (playerid, itemid) VALUES ('$playerid', '$rewardItem');
     //make sure the query succeeded
    if (!($result)) { 
        echo "Could not reward item<br />";
        exit();
     }
} else if ($tier < 75) {
    $item = rand(221, 250)
    $hItem = mysqli_fetch_assoc(mysqli_query($db, "SELECT itemid FROM masteritem WHERE itemID = '$item'")); 
    $rewardItem = $hitem['itemid'];
    $result = mysqli_query($db, "INSERT INTO playerInventory (playerid, itemid) VALUES ('$playerid', '$rewardItem');
    if (!($result)) { 
        echo "Could not reward item<br />";
        exit();
     }
} else if ($tier < 95) {
    $item = rand(251, 275)
    $hItem = mysqli_fetch_assoc(mysqli_query($db, "SELECT itemid FROM masteritem WHERE itemID = '$item'")); 
    $rewardItem = $hitem['itemid'];
    $result = mysqli_query($db, "INSERT INTO playerInventory (playerid, itemid) VALUES ('$playerid', '$rewardItem');
    if (!($result)) { 
        echo "Could not reward item<br />";
        exit();
     }
} else if ($tier < 101) {
    $item = rand(276, 300)
    $hItem = mysqli_fetch_assoc(mysqli_query($db, "SELECT itemid FROM masteritem WHERE itemID = '$item'")); 
    $rewardItem = $hitem['itemid'];
    $result = mysqli_query($db, "INSERT INTO playerInventory (playerid, itemid) VALUES ('$playerid', '$rewardItem');
    if (!($result)) { 
        echo "Could not reward item<br />";
        exit();
     }
}

Re: Questions about player storefront features & security

Posted: Fri Sep 17, 2010 5:55 pm
by Gheeda
Hmm... So if i were to ever add items to this gamble feature in the future...I would HAVE to remove/move items so it makes the rand block bigger? Probably wouldn't hurt to have a whole item database dedicated to this gambling page if that were the case. Since I wanted the majority of the item rewards available via this function....obtainable ONLY by this function...ill just go that route anyway...

OR....separate item databases based on rarity. Since adding items of varying rarity to a separate gambling db would be just as much a hassle as adding them to a master item db. Unless there's an option when Randomizing to, for example, rand 1-60 & 88-102 excluding 61-87. Would probably get messy before too long though.

I'll think it out. Many thanks as always jack :)

Re: Questions about player storefront features & security

Posted: Fri Sep 17, 2010 7:53 pm
by Jackolantern
Gheeda wrote:Hmm... So if i were to ever add items to this gamble feature in the future...I would HAVE to remove/move items so it makes the rand block bigger?
I'm not sure what you mean. The initial rand(1, 100) is only for determining the tier of rarity, like in WoW how you have white items, green items, blue items, purple items and orange items. You would only have to expand this IF construct if you wanted more than 4 tiers. If you did want more than 4, you would have to expand it out and break up that 1 - 100 result to match the chances of getting the different tiers. For example, as it is written, the chance of getting tier 1 (items with item ID 200 - 220), is 40%. Tier 2 (items with item ID 221 - 250) is 35%, and so on, down to tier 4 (items with item ID 276 - 300) with a chance of 5%. To add more tiers, add another ELSE IF, copy the code from one of the higher tier IF constructs, and then adjust the IF conditions to set up the percent chances you want. Then just add in the range of item IDs from the master item table into the rand() call within the IF construct. Does that make sense?
Gheeda wrote: Probably wouldn't hurt to have a whole item database dedicated to this gambling page if that were the case. Since I wanted the majority of the item rewards available via this function....obtainable ONLY by this function...ill just go that route anyway...
It wouldn't hurt to have a master gambling item table, although it is not necessary. The key is to keep a spreadsheet with all the items in it, and know which ranges are for what. For example, say 1 - 200 is regular mob trash drops. 200 - 220 is rare crafting rewards. 220 - 300 is gambling rewards. 300 - 400 is rare combat drops, etc. Then just be sure to use the ranges you want in the situation most appropriate. Of course, if your master item table starts getting huge, it would offer a tiny performance upgrade to split the master item table down by usage. It could also possibly ease the paper work to keep it organized.
Gheeda wrote:OR....separate item databases based on rarity. Since adding items of varying rarity to a separate gambling db would be just as much a hassle as adding them to a master item db. Unless there's an option when Randomizing to, for example, rand 1-60 & 88-102 excluding 61-87. Would probably get messy before too long though.
In any item database, you must plan it out first before you add it to the db. Otherwise you will have to make messy logic to get the correct items. Make a spreadsheet of the master item database before even adding a single item to the database. You will end up moving a ton of them around before you commit them. Believe me, it will make your life much easier!