Alan

Depends on what sort of mod it is, what sort of timescale is involved, what type of interface it needs (Heavy AJAX, graphics, database use etc.), and to an extent whether it interests me sufficiently. If a game owner shows some foresight in planning a project and has what I think may be a viable project for at least some time, I've been known to simple drop the mod in gratis.

As there are at least 50 languages with ""OOP"" features, more if you consider prototyping languages and the more esoteric languages found lurking more in the hidden depths of research laboratories, plus non-OOP languages which can be made OOPs like without too much work (C being a perfect example) should the question not be more along the lines of: or ie. Pick the best tool for the job. Bjarne Stroustrup's C++ book is good, though the earlier editions missed a lot of the features of well known C++ variants, commercially I use C++ a fair bit but in relatively small doses; for example extensions to operating systems, to database engines and to an extent other languages. Whether there is a large call for commercial C++ code I really cannot say, though I'm confident it will be around for a while. Python on the other hand is a simpler language to learn offers a fairly decent set of OOPs features and is stable enough to warrant being taken very seriously in application development. There is a wealth of excellent documentation and libraries readily available around the 'net, making this a pleasant albeit lightweight OOPs language. It is certainly commercially viable, and I've no doubt it will outlive me in one form or another. Or you could have a bit of fun and look at what is really a teaching language and to an extent the father of many OOPs languages in use today. Smalltalk is not one I've seen in production, though I have seen some cracking applications written in it. It's possibly not a mainstream language, but it can teach you a great deal about computer languages in general and certainly object orientated programming.

$prep = $db->prepare('INSERT INTO `table` (`column1`, `column2`,`column3`) VALUES(?, ?, ?)'); $prep->bind_param('sss', $_GET['column1'], $_GET['column2'], $_GET['column3']); $prep->execute(); $prep->close(); Yet with PDO it is *still* possible to leave yourself open to SQL injection; there are multiple instances where you cannot bind dynamic data - consider ORDER BY $expr LIMIT $offset, $count; you cannot IIRC bind those variables potentially leaving a nice hole as too often people assume that PDO is safe.

SRB/G/... has long been a pleasant person to work with; his views while perhaps strong have brought a smile to many faces both here and elsewhere, his willingness to help outside of these hallowed (or should that be hollow?) walls speaks well of him both as a person and as a talented programmer; many here would do well to heed his advice and pay more attention to people like him instead of falling headlong into the same old mire that appears to have beset this place. G: you know where I am - the door is always open (assuming somebody gets around to fixing the comms!)

Sure about that? No war needed; it's a legitimate question. Assume if you will that $_POST['number'] is a string; with basic checks your expression returns either the number, or 0 (zero is not really ideal here, however that complexity is probably left for elsewhere). But what happens if some enterprising "hacker" (for want of a better term) injects an array here...? PHP Fatal error: Unsupported operand types in /var/www/vhosts/alantest/httpdocs/test.php on line # *THAT* is a perfect bit of information disclosure; from that I know the path to the document root, I have a good idea that the local username is (in this case) alantest though that is hosting dependent etc. It also gives me a clue to the version of PHP in use and indeed to the type of server setup. The point here is that you *need* to check the type of data coming in from GET/POST/COOKIE structures before considering that they actually contain otherwise it is possible to give a vital clues out that can eventually compromise your system. Think "well I can't bothered to do that"? Fair enough, go the old fashioned way, forget at type checking, range checking etc. But if you ask me for assistance, the answer will be no. There are people here who are perfectly capable of helping you out but I'm not one of them; I'm simply not interested. The so called pen-testers that occasionally pop-up here seldom spot things like this as they often rely on programs written by people with no understanding of the language or the protocol itself. Those how profess to understand the problem, seldom understand it when it is rephrased; for example (and referencing this particular problem) intval/cast to int fails differently on 32/64 bit machines; which may seem obvious, but there are remarkably a large number of functions that perform differently between the two. This has major headaches between development and production systems and has been known to cause problems when people run code in distributed cloud systems - something thankfully I suspect is above the bar for most here, but nevertheless something that should be taken into consideration. However if you think "okay, I think I can make that work but can you check"? I'll be more than happy to run through it with you and point out any omissions. That's not to say that what I write is perfect; far from it; however unlike far too many people here I've actually read the manual, I understand the protocol itself and I take the time to try and improve upon it as the language itself grows. Long gone (hopefully) are the days of such posts as the hilarious "How to secure your script from all known exploits", yet people still fail to understand the basics of the language. Look at the protocol definition; it essentially declares that all GET/POST (and COOKIE) data is string, however PHP mangles this in certain cases to produce arrays; given everything that is coming in through those vectors is therefore a string or an array, how do you go about ensuring that the data is what you expected?

I don't believe I used the word "hack", I pointed out that failure to correctly identify the type of an incoming variable results in an information disclosure exploit - which were you to use something like phpIDS would be quickly spotted. I also stated that converting to an integer is not safe using a typecast or explicit conversion function. By not safe as surely somebody with your skills would attest to, it is not architecture agnostic, nor can it handle large numbers. I don't see either of those points as being unnecessarily harder than what it is required. Seems to me that any sensible programmer would look at the above and write some sort of small wrapper to encapsulate all the different types of data with range checking that they are liable to encounter resulting in an altogether more efficient, architecture agnostic and secure mechanism. Of course, if you look back to before even your time here, you will find those very points alongside stable working code however if you wish to belabour the point that abs(intval(..)) is superior, that is of course within your rights. If these forums are meant to assist people with lightweight projects from gaming onwards, then isn't it better to occasionally think outside the McCodes ""security"" modal, and try to improve peoples skills rather than waste time defending outdated methods that would or at least should earn a slap around the head for carelessness?

I can't help but wonder what part of that is related to security (outside of the possible information disclosure exploit). Not only is it bad practice, it is making a number of key errors which are easy to circumvent with careful programming. if (!array_key_exists('number', $_POST) || !ctype_digit($_POST['number'])) { // Assuming you had a form with an <input name="number" ...> field, // then reaching here means that somebody has bypassed the usual // submission method. // Respond with a 400 but no clues. header('HTTP/1.1 400 Bad Request'); exit; } // At this point abs() is pointless as the value contains ONLY 0-9 // Question.. is this safe? (The answer btw is no) $value = intval($_POST['number']); // Or how about this? $value = (int)$value; // But do you actually need it to be an integer? After all, MySQL // as with HTTP operates with strings.

To offer a different opinion, yes it is an excellent language to learn. Portability springs to mind unlike a lot of languages; it can run both client and server side (see the excellent node.js), supports event driven, multi-threading, classes; it is a good cruft free language, syntactically elegant, and is widely supported. Web side of things, certainly a tremendous amount of sites use some form of javascript so it is fast becoming a key "must have" skill for any type of web development, and with the addition of server-side, is rapidly becoming an ideal prototyping tool all the way up to credible applications. There are huge number of libraries out there for it, like all languages - some good, some bad; there are languages written that produce javascript that provide a different some would say simpler way of writing javascript (for example CoffeeScript), user-interface tools are too innumerable to mention outside of JQuery and friends. Or perhaps you need a solid reference such as Mozilla's JavaScript reference (one of the best imo). The only other point I'll make is that is under very active development. The language as a whole is being continually refined, libraries are being produced daily to cover almost every topic under the sun, new features are carefully introduced to language with a lot of discussion with the industry as a whole.

I cannot help but wonder what type of ""optimization"" is going to be applied to ... Notwithstanding small ""optimizations"", reducing the number for queries from 40K to a few 10's per hour I'd consider key to solving this problem.

Donald Knuth.

The inner loop can be compressed to one while statement - something along the lines of $x=$db->query("SELECT * FROM buildings WHERE userid={$r['userid']}"); while($y=$db->fetch_row($x)) { $gold_gain = rand(100, 100) * $y['goldmine'] * $y['goldmineworkers']; $food_gain = rand(100, 100) * $y['farm'] * $y['farmworkers']; $wood_gain = rand(100, 100) * $y['sawmill'] * $y['sawmillworkers']; $db->query("UPDATE users SET gold=gold+$gold_gain, food=food+$food_gain, wood=wood+$gain"); } However with say 1,000 users and maybe 5-10 buildings per users, that's 5,000-10,000 queries every fifteen minutes - 20,000-40,000 per hour which I know a lot of smaller hosting providers will not be very tolerant of. Not to mention the fact that given an McCodes base, you will be locking the entire users table for the duration the cron runs which will introduce an element of lag you may have trouble getting rid of in the future. Thankfully there are far better ways of doing this, a timestamp would work which could reduce this potential ~40,000 Q/hr down to quite possibly 2 figures or less even if you have an active player base; it may even be possible to rewrite the entire set of queries as one by careful use of joins although I'm not in favor of UPDATE with JOIN statements. Try a timestamp route; your players probably only need be aware of their own stocks, therefore no need to update everybody en-masse. Just update the current player as and when.

Had to lol at the comments on the demo account ...

There's hope for the boy yet

And in English?

It is mind-blowing that people cannot debug the most simplest of problems; worse that they write non-defensive code which makes debugging hard. Consider: mysql_query('INSERT INTO table VALUES (1, 2, "three")') vs $sql = 'INSERT INTO TABLE (field1, field2, field3) VALUES (1, 2, "three")'; if (array_key_exists('debug', $_GET)) { echo $sql . "<br>"; } $rs = mysql_query($sql); if ($rs === false) { echo __FILE__ . ':' . __LINE__ . ' -- ' . mysql_error() . '<br>' . $sql; } Not an elegant way of displaying error messages I admit, but it does: a) Define the SQL statement prior to using it - helpful during debugging, especially if you use something like PHP Storm b) Define each field - In case you change the table structure at a later date. c) Displays the SQL statement if debugging - No elegantly, but this is more about defensive programming than style. d) Checks the result of the query e) Displays an error message if the query failed - Again, not pretty, but you get the point. Yes, there is more code to type; but in its defence, if a problem does arise, you will be able to see the exact error message, where it is being output and the actual query that caused the problem. Obviously you would need something more secure than simply passing ?debug to the script, but again that's not the point here. Write your code so that you can easily debug it; any complex variable that gets generated over several lines of code and/or is populated with data from a variety of insecure sources (ie user input) should have something that enables you to quickly show its value *PRIOR* to using it.

@rockwood Proof? In any case, array_key_exists() is considered the correct solution since isset() fails on certain values: [[email protected] ~]$ cat test.php <?php $array = array( 'a' => false, 'b' => 0, 'c' => null ); echo "isset() ...\n"; echo ' ' . (isset($array['a']) ? 'true ' : 'false') . "\n"; echo ' ' . (isset($array['b']) ? 'true ' : 'false') . "\n"; echo ' ' . (isset($array['c']) ? 'true ' : 'false') . "\n"; echo ' ' . (isset($array['d']) ? 'true ' : 'false') . "\n"; echo "\nvs array_key_exists() ...\n"; echo ' ' . (array_key_exists('a', $array) ? 'true ' : 'false') . "\n"; echo ' ' . (array_key_exists('b', $array) ? 'true ' : 'false') . "\n"; echo ' ' . (array_key_exists('c', $array) ? 'true ' : 'false') . "\n"; echo ' ' . (array_key_exists('d', $array) ? 'true ' : 'false') . "\n"; which when run produces: [[email protected] ~]$ php -f test.php isset() ... true true false <-- isset() fails to spot null values false vs array_key_exists() ... true true true false

Command line suffices surely... for i in {12345..12360}; do curl -o user-$i.html http://mysite.com/user.php?id=$i; done Change start.end & options to suit.

` php -l ` is your friend. For *nix users: find /path/to/root -iname "*.php" -exec php -l {} \; for windows users, get *nix.

MySQL 5.6 supports full-text searching under the InnoDB engine - amongst some other seriously impressive updates that make it well worth your time finding a host that has it installed - or in your case, me I believe! :D

SELECT ... JOIN ... (SUBQUERY ...) -- Slow for many rows, stalls multiple tables. vs SELECT ... ORDER BY RAND() -- Slow for many rows, stalls the table. vs SELECT ... SELECT ... SELECT ... -- Multiple context switches, suffers from race condition. vs CALL ... -- Using the tri-select, works well, fast and doesn't suffer from race conditions Kinda makes you think that there might be a far better solution that is independent of database, of table design, indeed of number of rows.

20K rows .. bless.

Think scale; we know ORDER BY RAND() is not optimal, neither is reading each row into PHP so ... // compute number of rows in table $rs = mysql_query("SELECT COUNT(draw) FROM userstatistics WHERE draw > 0"); $row = mysql_fetch_row($rs); $count = $row[0]; // pick a random number from 0 to $count - 1 $offset = mt_rand(0, $count - 1); // grab the user id from the userstatistics $rs = mysql_query("SELECT userid FROM userstatistics WHERE draw > 0 ORDER BY userid LIMIT $offset, 1"); $row = mysql_fetch_row($rs); $userid = $row[0]; // finally, read the row from the users table $rs = mysql_query("SELECT * FROM users WHERE userid = $userid"); $user = mysql_fetch_assoc($rs); You could probably combine the last two operations with a JOIN, however whether you do or not will be determined by the database engine (MyISAM vs InnoDB) and the number of rows we are looking at it. There is a possible race condition here, however careful checking of each result can mitigate that down to acceptable levels.

Why do you feel like you need to "optimize" their ID's ? What possible gain is there ? The ID's are simple there for the application to be able to track players by something that is utterly unique to them, changing it would mean changing that ID in many tables essentially simultaneously as any interaction part way through could really screw things up. If you delete players, and end up with "holes" in your ID list (1,2,3,6,8,9,10...) there are easy ways to find out the lowest "hole" and use that when registering somebody, but the chances are quite high that some other tables will still have data relating to that ID number (inventory, mail, attack logs etc) that may affect their account. I would ask the question why do you need to show ID's ? Sure, you need something unique to each player to refer to them from urls but outside of that there's no real need to ever display that information.

I started implementing commands in chat in a project here 4+ years ago; both chat and irc were hooked in the project in question and it did help a great deal especially from a staff point of view. As to a game itself, I briefly looked at it purely from an IRC point of view, but hit a few minor stumbling blocks. Saying that, it can work remarkably well. A recent AJAX backed chat script for the venerable McCodes I developed for somebody here recently had a rudimentary command dispatcher that could easily be extended to handle this type of concept. How you make it an interesting side-game that holds the players attention I'd be interested to see - I've long thought that those of us who hang around in IRC for whatever reason could enjoy this as a sideline.

@guest; lend me a buck then :D