Octarine

2 seconds .. what did you do? Stop and make a cup of tea midway? :P Oh and BTW, you missed at least one other problem :D - - - Updated - - - 2 seconds .. what did you do? Stop and make a cup of tea midway? :P Oh and BTW, you missed at least one other problem :D

Four years ago or so, this was done and dealt with creating a simple expression evaluator that handled basic operators, constants and even functions. It's not difficult to write, it's safe and secure and it works regardless of whether a hosting environment as disabled the eval() function or not.

Yet again, the error message makes it obvious: ` Unknown modifier '=' ` You cannot use the primary delimiters, in this case / within the expression itself. Anything after the second one is assumed to be a modifier.. in this case '=' if (!preg_match("/^(([A-Za-z0-9!#$%&'*+/=?^_`{|}~-][A-Za-z0-9!#$%&'*+/=?^_`{|}~\.-]{0,63})|(\"[^(\\|\")]{0,62}\"))$/", $local_array[$i])) { At a guess I'd say your expression needs simplifying - [!-~]{1,63} perhaps -- just make sure you escape it (mysql_real_escape_string etc) going into the database and escape it (htmlentities etc) going out to the screen.

No, it means exactly what it says Which clearly indicates that the $q is a boolean (as you correctly pointed out), however it needs to be a query resource which in turn indicates that the mysql_query statement itself failed. Defensive programming suggests that you first define a variable to contain the sql statement, then pass that into mysql_query, and finally check the result ie: // Preparation - makes the query below cleaner $pay = $ir['jrPAY']; $strength = $ir['strength']; $labour = $ir['labour']; $iq = $ir['IQ']; $job = $ir['job']; // Define the query $sql = <<<SQL SELECT * FROM jobranks WHERE jrPAY > $pay AND jrSTRN <= $strength AND jrLABOURN <= $labour AND jrIQN <= $iq AND jrJOB = $job ORDER BY jrPAY DESC LIMIT 1 SQL; // Send the query top MySQL and retrieve the result (as a resource handle) $q = mysql_query($sql); // Check the result if (!is_resource($q)) { // If you are debugging, or running on a devlopment box, this is fine to // leave in, but its not wise on production boxes. echo 'MySQL query failed around line ' . __LINE__ . ' of ' . __FILE__ . '<br>'; echo 'Query was:<br>'; echo '<pre>' . $sql . '</pre>'; echo 'MySQL reports: ' . mysql_error(); exit; } // Now .. carry on as per normal. Long winded? Yes, to an extent, but it will nail the bug in double quick time, it also helps if you are using a decent debugging tool like PHPStorm as you can clearly see which lines you can set a breakpoint on and examine the variables at that stage. Code should be designed to help the debugging and testing process after all its *you* how are going to have to read it and fix it when it breaks.

You mean you don't know when somebody is mugged? Oh well, this type of trick works in any number of situations, and I've still to see the need for any in-game crons on any McCode's based system. Server-side crons doing garbage collection, reporting, etc I'll accept, as that is pretty much standard across the board, but another field in the users table and another query to run at some often arbitrary midnight? Now those simple unnecessary imo.

A handy addition, but why bother overloading an already greatly over-used users table, and indeed why even bother with a cron? In authenticate.php, a simple check prior to updating the last_login field would be to check that field against time(). If it is greater than 3 days ago, update the user's job & jobrank fields accordingly and proceed with the normal login process. The same trick can be used for a myriad of things if you look carefully.

Oh I'm so going to have to steal that one .. nice imagery.

include_once('globals.php'); include(__DIR__ . "/globals.php");   What can I say, line 3 and already a problem.   As for the sprintfs' -- Irrelevant. You have failed to understand the reason for using them which while considered a useful trait a few years ago, has mostly been superceeded by cleaner code. -- sprintf('%d', <value>) has proved a useful albeit lightweight mechanism, however sprintf('%s', <value>) is very dangerous when it comes to queries and should be avoided like the plague. -- Since Guest has taken the time to know the underlying database structure - at least data-type wise, and is sensible enough to type-check correctly incoming POST data, there is really no need for sprintf in this instance - which as any good programmer will know is a very expensive function. I would agree at separating the pulling the SQL statements into variables rather than calling mysql_query("...") or $db->query("...") first as it certainly helps if you are forced to run the code through a debugger.   e&oa

I'm sure I should say something really off-color here, but I've known Guest for a good few years, and indeed had the pleasure of his company over a good few libations; all I can say is he's not a bad lad. His code is safe, clean and well written, his knowledge certainly exceeds many on this board and while he may wish to take the lazy way out from time to time, generally sides with common sense, with perhaps a little nudge from shall we say older more experienced individuals. I'm sure the retort will be colorful at least ;)

$brain_file=array(); $brain_file="globals.php"; include_once $brain_file; vs. include "globals.php"; Rocket science its not. Code should be cruft-free, clean, indented, and ideally elegant. (I'll assuming working is a priority), however even this replacement is not safe. include_once(__DIR__ . '/globals.php'); would be a wiser alternative assuming an up-to-date PHP version (5.3.0+)

It may well be going down the tubes, however I for one am happy to to still be working with certain individuals I've met through here - and enjoy supporting some of the younger people by providing services with or without their knowledge, for development, hosting, and simply someone to come to when a problem arises. The ban hammer seldom if ever worked here as more than a few will testify to, neither it appears does the clue bat given some of the recent posts I've read. The owners seem disinclined to take a hand in the organisation of the forum, the administrators equally so, and older posts it seems are rapidly deteriorating as a succession of forum changes have corrupted so many topics. There was a day when the place genuinely flourished, but that being said, there are still some good things coming from it. I see active projects being developed for and by people here with some nice ideas. Clean code, well thought out ideas, standards compliant markup etc., seems almost a shame to tar their release on the same forum as certain recent "ripped" topics. C'est la vie

I cannot help but wonder what the purpose of such a tool is. Code is after all, meant to be read by humans, obfuscating it serves but one purpose - to piss people off. No code is safe from a <strike>truly talented developer</strike> country bumpkin, and as all it takes is one person to de-obfuscate, safety is obviously not a major concern. Correct me if I'm wrong, but didn't that young upstart Ravan use something similar albeit with a callback for his McCodes clone? eval + base64 + gzip - hardly the stuff I'd expect from a web gaming forum.

Impressive

It never fails to amaze me the ability of certain members here to completely fail to understand what is at heart a very basic and extremely powerful concept. For years, we have been have been using multiple connections - application (game) servers each utilize at least two connections to the database cluster which provides read-write splitting, improving ensuring that for example, SELECT statements are handled by read-only database nodes, freeing that load from the primary database. With a very simple replication setup of two database servers; A (master), B (read-only slave); an application could utilize dual connections; $connA for INSERT/DELETE/UPDATE etc, $connB for SELECT etc. Proxies can be positioned easily between the application server(s) and the database cluster extending this concept further and reducing the read load considerably, which can be a stumbling point once games reach a certain size. With careful planning, you can split write load as well. There are other solutions which work on a single connection, but the experience gained from multiple connections is excellent and will hopefully warrant the time spent in developing the ideas. @guest: I swear I've seen that code somewhere else

As a piece of code, it cannot be relied upon for a multitude of reasons, but it served a purpose in its days. Perhaps however, it would be wise to understand the underlying principal of the code, rather than relying on third party (ie MTG) so called "claimants". With some engineering, it can be made to work passably well, assuming you ignore the fact the IP's are not a decent mechanism for detecting multi's - consider for example the small country pub with wifi... "A" likes the game, takes his phone out to the pub, shows "B", "B" registers, instant ban... Why? The solution is relatively simple, and in fact has been deployed in a number of projects including the venerable McCodes, and more recently in an NWE project. Look at a) how you are detecting the IP address, I can almost certainly guarantee you are doing it incorrectly, b) how you store the address, again, it's almost bound to be wrong, and c) how you examine the database for duplicates; that is unfortunately very wrong. It has merit as a bit of code, it does work, up to a point, but making to work properly is a challenge that few have mastered.