requinix

Remember this? expected profit = bet * odds of losing / odds of winningLet's revise that a little bit to be more clear what it means. (It was late night when I wrote that and it made sense to me.) expected profit = bet * (odds of not winning - house edge) / odds of winningIf you predict 88 then your high roll must be within 89-99 to win. That's 99 - 88 = 11 out of 100 (or 100% - 88% - 1% = 11%). Not winning would thus be 89%. If you wager 5 and the house gets 0.96% then expected profit = 5 * (89 - 0.96) / 11 = 40.01818Look familiar? I imagine that logic is buried somewhere in the Javascript, though it looks like they're using an alternative form that calculates gross and not net winnings. Same difference.

Well then, good luck. I'm sure you'll eventually arrive at the formula I told you. [edit] Maybe you're getting thrown off because your numbers are wrong? When I enter 5/88 on their site I get 40/0.625. Not the 40.01818/0.62727 in your screenshot. I don't know how you got those but they're wrong. It's also possible you didn't notice that the random number range is 0-99 and your choice must be 1-98; that's where the house advantage comes in. [edit 2] And one more thing: the odds of winning/losing in the formula do not include the... I don't know what it's called, but they don't include the number that you automatically lose with. Since you always lose only on your own number, odds of winning + odds of losing = 99%. Yeah, math.

Those aren't the numbers I'm seeing. It should be basic gambling math: expected profit = bet * odds of losing / odds of winning.

That's only partial so "/???/SHOP/SHOPITEM/PRICE_VAT" $???->SHOPITEM->PRICE_VAT

You can also do plain -> and loops on SimpleXMLElement objects. Exactly what you do depends on the structure of the XML.

Well yeah: you're only grouping the data per employee. If you want it broken down by week then you'll need to group by the week too.

Ungreedy will help but it will still crash on large enough inputs (that is, a long enough distance between the BEGIN and END). The problem is you're putting the quantifier on a capturing group, and the PCRE library will smash the stack trying to remember everything. 1. If you don't need to capture what's in there, don't use a capturing group. 2. Alternating .|\n is like using the /s flag but worse. '/(?

You need PHP 5.4+ for short array syntax. Upgrade. 5.3 is dead. 5.4 is dead. Even 5.5 will be dead in a couple weeks.

Then penalty.php can get the value from $_POST by itself. Like you're doing in whatever that file you posted is. You don't need to do this "send a php variable" stuff.

Making the href span multiple lines like that is not a good idea. Could cause problems. Where is $angle supposed to be coming from? Either it's set in this script, or if it comes from POST data then your script doesn't do anything and just keeps that form (and penalty.php gets the value from $_POST).

What's your HTML?

PHP executes in the order you tell it to. If you want the output to appear on a certain spot on the page then you need code at that spot which causes the output. Could simply be a matter of moving the include statement, but like benanamen said you should post your code.

This code has absolutely nothing to do with databases or PDO.

I suspect doing that will try to interpret existing data as YYYYMMDDHHMMSS strings, not as Unix timestamps. Will definitely work: add the created_at column, UPDATE it using FROM_UNIXTIME(user_date), then drop user_date. Three statements.

Still doesn't help. 1. Where does the transaction processing happen? Does it happen earlier and set $payment? It has to or else you can't use $payment. 2. According to the earlier code, isApproved is a function that you need to call. Not a simple property. 3. Are you actually storing credit card information in your database like that? Do you know what kinds of laws you're breaking? I hope this payment stuff means you don't have to do that anymore, and that once it's deployed you'll purge all data in those two database tables. And lastly, 4. Have you tried executing any of this? (If so, any specific problems or errors you're trying to address?) Or are you still working on writing the code?

Syntactically it's correct. But you've only posted a couple chunks of code with no context. Where is the first code located? When is it executing? Where is the second and when does it execute? It's impossible to tell whether the code is correct without that kind of information. How about posting the entirety of edit.php?

As the output shows the first layer of the "JSON" is an array with a numeric key. That suggests it could contain more than one element. Is that possible? If so, what will you do with the multiple items in the array? Ultimately you will have the second array. From there it's either ->name or ->live->stream->name. Assuming you are still decoding as an object, as the output shows it using arrays instead.

What do you mean by that? I don't see anything triangular.

You aren't repeating that character set at the end. As for the format, [0] will always be the full match. Best you can get is "i" as [1] and the identifier as [2] by using what you have now with the PREG_SET_ORDER flag.

Plain HTML does not support submitting forms using links. You have two options: a) Use a form button ( or ) and style it like the way you want. It is possible and not much more work to do since you have the appearance already working for a link. b) Put an onclick handler on the link and cause it to submit the form. This isn't AJAX but it does require Javascript. The first option is much better than the second.

If that $Variable thing was your actual problem then I would say If that's not your actual problem, what is?

Working on it.

As far as we knew it was down for good. It just happened that there were things going on we weren't aware of that gave it a second life.

We can't really share what's been told to us about any plans for the site. Regardless, consider that all this transition stuff only just recently happened and we're still getting back on our feet.

Have you tried looking at the documentation? Dates and times don't even have lengths. The string values do, sure, but the data type itself doesn't. Lengths only matter on field types that (can) have variable length data. Like strings and numbers: for VARCHARs it is the maximum character length stored, while for *INTs it is only the display width.