Anonymous

How, for the love of god is this even remotely useful? Sheesh JSON? I mean seriously? for cron jobs? What fracking planet did you think this would be useful on? Then there is a laughabale loop that .. wait for it ... requires_once the job.. which will only execute once..   <?php /* y.php */ require_once('x.php'); require_once('x.php'); <?php /* x.php */ echo "me!\n"; $ php -f y.php me!   Do you not actually do testing Spud? Try reading the manual next time, or at least paying attention.

Love the logo

Apparently yes - MWG AKA "Pendants are us" :D

There's an image I really need to erase from my mind   Please explain...

Nope, you managed that all by yourself. W3C's HTML Validation service clearly states: W3C HTML Reference Documentation -- Objects, Images, and Applets in HTML documents States equally clearly that the ALT tag is mandatory. Is there perhaps some part of this you fail to comprehend? or shall I speak more slowly and use smaller words next time?

Bollocks . How you can even state that it isn't basic shows a serious lack of knowledge of the protocols involved not to mention the client applications in general use today.

Surely, you mean<img src="path-to-images/{$itmid['itmid']}.jpg" style="width:70px;height:70px;" alt="..." /> I don't remember HTML having a size attribute after all and AFAIK, the ALT attribute is mandatory.

And who determines what the quality is? Haven't you ever heard of open source or even just sharing? Some of us are quite happy providing code free-gratis, and publishing it for all to benefit from - yet you seem determined to keep your so-called "secrets" under wraps for only those that meet some self serving criteria. I can quite happily conclude from this that you have in fact no "development secrets" at all. Of course, I could be wrong, but then having painted yourself into a corner, you will find it hard to extract yourself. Meanwhile, a few of the rest of us will happily share our knowledge and resources without limit - via IRC rather than MSN. Yes, strangely enough, there are people who don't have MSN, IRC may be an older medium, but its used by a lot more "devs" than MSN.

hehe .

Rather pointless then

I'm with SRB on that one.

So you ignore the type? Tsk Tsk, I'm sure I taught you better than that :D isset / is_string / ctype_digit - then range check :P /me ducks ;)

What you read into my generalized comments about the state of the genre is entirely up to you. I know from my own experience that developing a user list module is in theory straight forward, however with the restrictions placed upon a system in my case by the use of a large dataset; finding highly optimal solutions is an uphill struggle. The method I've personally hit upon displays little similarity to yours however you could say that is a function of the engine I employ. It does however rely on similar abilities inasmuch as retrieving a subset of users whether searched for or within a particular range of values, display them in response to ajax requests.

You are right however - I can't blame you for their (the creators of MCCodes) mistakes. I'm not sure how that relates to me pointing out to the forum users at large that the code as provided exhibits some of the same pitfalls that the base "engine" does and as such would need to be modified at a later stage once (or if) the game garners more support. I have looked in depth at a number of mods presented here - a few quite fun ones, a lot of dreadful ones and surprisingly, there are a few authors who have presented some exceptional code; though I can't but help wondering which authors code is still in use given the age of the posts. Yes, you have released a number of mods, but I don't remember that being relevant whilst discussing the merits good or bad of COUNT(field), caching, or the benefits of using a WHERE clause and LIMIT count versus the much slower LIMIT offset. Does # of mods/posts actually improve query execution speed? I wish it did. I can't really comment on design outside of stating the simple fact that a couple of minor change are all that is needed to gain a large boost in speed and reduce table locking (more so than can be found in any other module of this type presented here) dramatically.   You have me there. I can't add anything to that. You also state that So where do you start? For one, I don't actually remember telling you or even asking you to change the code, I merely pointed out that you were using bad practices. You have done this very same thing yourself so I'm hardly unusual in that respect. I agree however it is difficult to optimize one script in an application which is designed as this one is, however that does not preclude the ability for members of the forum the ability to speak up and point out that there are better ways do perform even the simplest of tasks. Were everybody to take something from this, it would not be long until a few decent high speed applications arrived on the block. Does it not stand that improved workflow, improved practices, and an improve design would assist the overall product(s)? If everybody stays mum and blindly accepts what is presented in front of them - free or otherwise - rather than question everything then what hope have future users have? It is only by discussion, experimentation, careful examination and questioning every single line of code be it PHP, SQL, C, ... in detail that programmers can learn and improve their abilities. I can point to a number of forums posts where users have questioned certain aspects of code which have then been incorporated thus improving the base code. Hardly rocket-science. For what it's worth; while I question the actual implementation; the overall concept of this particular mod itself is good. Using Ajax to fetch data "on-the-fly" is becoming much more prevalent these days, and while it can be over-used, it's useful to learn the basic techniques. @Jaaaacccckkk Go drink your milk, there's a good boy, let the grown ups play now.

I guess that explains why MMCodes/Ravans will never grow up to become a product capable of truly competing alongside bigger products. People - even those who are considered competent by their peers - simply aren't interested in taking the design of the code and data to a level which is necessary in the marketplace today. Poor quality code, restrictive practices, seem to be the order of the day and rather than develop something that is worthwhile, that brings value to an ailing genre, people re-iterate the same poor designs and ideas with not even a glance at usability, or good practices. The few products out there that survive with a decent active user base have learned that the key to keeping the users around is not just new material, fresh ideas, and brilliant designs, but also the attention to detail in the lower reaches of the so-called engine itself; and ensuring that the core game, its restrictions, its foibles and downright stupidities are hidden from the user - who, after all, are the people that the owners strive to please.

#1 Retrieving unnecessary data: $num_query = mysql_query('SELECT `userid` FROM `users`'); $num_users = mysql_num_rows($num_query); $pagination->setTotalRecords($num_users); This is unfortunately context dependent and will not always return the correct number of rows even without considering the obvious race-condition problem. If you consider that the database engine has to construct the entire recordset, this is not overly dissimilar to a full row-scan; something I'm sure you;ll appreciate is far from optimal. SELECT COUNT(userid) FROM users; Would at first glance to be optimal - it is after all heavily optimized in the core [MySQL] engine code, however even this is considered bad practice in this context but I'll leave that one open for debate. Either way, the need to display the last page # or # of records is to me rather pointless. If its used to predict the First/Previous/Next/Last links, then there are cleaner methods such as lookahead or tracking the last seen rows - basically extending the number of rows returned per page and ignoring a couple, or extending the WHERE clause to identify exactly which row was last seen by the user. #2 Retrieving unnecessary data (part deux): $query_txt = 'SELECT `userid`, `username`, `laston`, `money`, `level`, `display_pic`, `gender`'; foreach(explode(',', $extra_fields) as $field) $query_txt .= ', `' . $field . '`'; $query_txt .= ' FROM `users` ORDER BY `userid` ASC ' . $pagination->getLimitSql(); $query = mysql_query($query_txt); LIMIT # is fine, LIMIT #,# is not. The sweet point can be seen around page 6 assuming a records-per-page limit of 20 or so. The key point is here is that using LIMIT A,B means that the DB engine will actually read and discard A rows, then return B rows. At first glance this seems exactly what you need, but when you consider that it is actually reading A rows into (paged) memory - this becomes a bottleneck. The solution is to use a WHERE condition to specify WHERE in the index to start from. For example: SELECT userid, username FROM users WHERE userid > 20 ORDER BY userid LIMIT 20 Of course, any condition needs to be carefully constructed to ensure it matches the exact prefix of your index. #3 What? No cache? $num_query = mysql_query('SELECT `userid` FROM `users`'); $num_users = mysql_num_rows($num_query); $pagination->setTotalRecords($num_users); $query_txt = 'SELECT `userid`, `username`, `laston`, `money`, `level`, `display_pic`, `gender`'; foreach(explode(',', $extra_fields) as $field) $query_txt .= ', `' . $field . '`'; $query_txt .= ' FROM `users` ORDER BY `userid` ASC ' . $pagination->getLimitSql(); Every Ajax request. As the MyISAM engine locks the entire table during SELECT, you have two separate full table locks per request per user. Multiple this by say 100-200 odd active users and you will quickly discover a database response time that can be compared to cold molasses. Using the InnoDB engine would help a little were you not filling the cache up with useless data from the initial SELECT userid FROM users; however with the apparent and unfounded dislike for InnoDB these forums have, there are still better solutions using plain MyISAM tables. The user count can at the very least be cached, repeatedly fetching this is simply a waste of time. Users are not going to be interested in knowing that while they were viewing page 1/6564, another 10 users registered. Sure, if there are < 100 users I've no doubt the young admin/owners would be eager to count every user as the come in, but for a budding Torn programmer - pointless. Caching a page full of data keyed with the userid making the request and the actual page # would help a long way into reducing the load requirements, global caching would marginally more complex, but would provide much superior response times as every user would be sharing a common cache. Yes, you lose a little accuracy in respect of things like "last seen" timestamps - who cares. Losing that versus annoying users who simply want access to data is a no-brainer. #4 Other problems of note? PHP includes with a .txt extension? Not every web server likes that idea. Not sure why it needs to be included as a separate anyway. Yes reusable code yada yada, but it's not doing anything that can't be done in one or two lines at most in the main code. JQuery version 1.4 served from an HTTP link? Somewhat old, Google's CDN (and others) have been providing 1.6.2 for some time now from HTTPS links.

There are so many bad-practices used this extension, I can understand your frustration - however in your case Warning: mysql_query() [function.mysql-query]: Access denied for user 'nobody'@'localhost' (using password: NO) in /home/*****/public_html/userlist.php on line 82 would appear to be pretty self evident. You are of course including config.php? And you have checked it contains the correct credentials for the database?

What I presume you mean is that in your limited observations; none of them is actually better, as clearly there are better solutions. To ask a rhetorical question - why use them at all? With nothing to replace them - there is no set of features, there is no feature set most suited to their situation.

I believe we were discussing in-game - or perhaps I misread the form topic. In game I've yet to discover a need for them - there are far better solutions. Externally; I agree there is a case for them; although even again I don't consider it to be as strong as some people may think. I don't for example use a captcha for comments on my blog - there is no need. Software has been deployed which is capable of determining with a high degree of accuracy if a comment is spam or not.

WikiPedia // Mersenne Twister // Advantages // Section #3 rand() does not perform anywhere near as well as mt_rand() hence the obvious suggestion. Looking at the source of ext/standard.c in the PHP sources, does unfortunately suggest a minor possible problem in that unseeded usage may become predictable in both rand() and mt_rand() cases with access to nothing more complex than a timer and the ability to determine the current process ID. Preserving the state of the LCG across calls is probably beyond the capabilities of many here, and can certainly be considered over-engineering especially when one could equally generate a decent random seed by looking in the manual and however I still would not even consider rand() as a viable LCG. There is some suggestion that mt_rand() is in itself predictable, and indeed it is - however I doubt that anyone has the resources necessary to store the lookup table needed or the cpu processing power necessary to compute the next number "on-the-fly". rand() however is in certain cases a lot simpler assuming the OS itself has not switched over to one of the heavier duty LCG algorithms. mt_rand() would thus seem the ideal replacement as it provides a high degree of future-proofing not to mention a stable known algorithm that is free from operating system problems making it cross-platform, cross operating-system safe. As for the use of captcha's themselves, I see absolutely no need. I actually consider it rather insulting in-game being asked to confirm that I am not a bot.

Unfortunately I doubt many if any here have the wit or skills to ascertain their true raison d'être.

Another one where the error clearly states what the problem is and suggest how to cure it: Fatal error Somewhat self explanatory - the parser cannot proceed until action is taken to address this problem. Cannot redeclare microtime_float() Again should be obvious - Once a function had been declared, it cannot be redeclared previously declared in /home/hitmanm1/public_html/header.php:12 That shows you where it is initially declared in /home/hitmanm1/public_html/header.php on line 14 and where the attempt to redeclare it occurs. Apart from a minor discrepancy in line numbers, it's apparent that the header.php file is being included twice. You need to examine closely each file to find out where it is including header.php (or other files which in turn include header.php). From your htdocs (or public_html) folder: grep -ril header.php * will report the names of any files including header.php. (Decent editors often have similar capabilities these days if you are not command-line savvy).

The clue is in the error (although I suspect somebody will no doubt contradict me on this): The key to solving it is to actually read the error/warning message: Warning: Cannot modify header information That is telling you that something as amiss, however it's also stating that it is only a warning, so it's not preventing the rest of the page from working as per normal. It's also a pretty clear indication as to the type of problem. headers already sent by (output started at /home/thedest1/public_html/hooligans-world.com/mysql.php:8) This is telling you that something has started sending headers from somewhere. Look in the specified file, look for anything before <?php or after ?> including but not limited to spaces, newlines, tabs, random characters etc. And finally this is telling you at what point the error was noticed. in /home/thedest1/public_html/hooligans-world.com/authenticate.php on line 45 At a guess, were you to take a close look at this file and line you would see the function session_start() The fix is to make sure that the mysql.php file has nothing prior to the opening <?php tag, and nothing after the closing ?> tag - ideally get rid of the closing tag, it's redundant.

User intervention? Efficiency? - and No, your post doesn't explain the disadvantage of sscp(), as I do not see that as a disadvantage. I suspect were I to look at the relevant RFCs covering cookie use and the source for sscp() itself, PHP would be following those guidelines to the letter (although one can always take bets on that). However I've grown tired of this, I can see a perfect solution which uses sscp(), I'm sorry if you think differently. I formerly retract my original statement as apparently - it's not good enough.

Please do go further.