Interactive Userlist

[Spudinski]

Last prune... I promise.

Interactive userlist, is just that.

It is fully ajax, and includes a search feature.

Upon click of a entry within the userlist, a dialog(inline) will apear, holding basic info of the user.

It uses jQuery, and that loads from Google, so don't worry.

I'm far too lazy for screenshots, I already had enough trouble just getting the thing on my linux box.

Installation:

1. Upload and replace the file "userlist.php".

2. Upload files "unknown_female.png", "unknown_male.png" and "pagination.txt".

Download: http://www.mediafire.com/?4hbbjsqqaksmjed

All important license: http://creativecommons.org/licenses/by-sa/3.0/

Problems should be mailed to spudinski[]gmail.com

Discussion should be done in this thread.

Edited August 27, 2011 by Spudinski
Updated to work on all versions.

[jay-dogg2009]

i seem to be having issues with this now i have chnage it to this most of the errors have gone

 

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

 

but still gettting this

Fatal error: Cannot redeclare get_mine() (previously declared in /home/*****/public_html/global_func.php:9) in /home/****/public_html/global_func.php on line 27

but once i take it out it keeps going down the list lol

[Spudinski]

That error is not related to this mod, in any way.

Please post "previous errors".

[Glasses]

I am having issues i get this

 

 

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

[Anonymous]

There are so many bad-practices used this extension, I can understand your frustration - however in your case

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

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?

[Glasses]

There are so many bad-practices used this extension, I can understand your frustration - however in your case

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

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?

Yes i included config.php and yes they are fine

[Spudinski]

I am having issues i get this

 

 

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

What version are you currently using? I have re-uploaded a script for all versions.

Please download it again.

 

There are so many bad-practices used this extension, I can understand your frustration - however in your case

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

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?

I'd very much appreciate if you could point out those "many bad-practices" I used in this script.

[Glasses]

I am currently using version 2

[Glasses]

I now just get a white screen lol

[rulerofzu]

Dont include the config you only need to refer to the globals.php file.

[Uridium]

Ive got it to work but its putting a page within a page

Edited August 27, 2011 by illusions

[rulerofzu]

Indeed it does I stripped out the header and menu to have a look at it properly.

[Spudinski]

All above problems mentioned, are now sorted.

Please re-download.

[Anonymous]

I'd very much appreciate if you could point out those "many bad-practices" I used in this script.

#1 Retrieving unnecessary data:

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

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.

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

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):

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

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:

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

Of course, any condition needs to be carefully constructed to ensure it matches the exact prefix of your index.

#3 What? No cache?

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

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.

[Uridium]

spud i suggest changing max-width and max-height to just width and height it dont seem to work on IE

[Spudinski]

As for unnecessary data:

I completely agree, but I also didn't intend this to be used by >10k users. One would think they would have programmers to create these things.

Nonetheless, it could be optimized with relation to that.

Caching:

I thought I did turn on chaching client-side, guess not.

As for server-side caching, I agree that one could cache certain data. I've seen this being used by larger games.

But I didn't think it would be needed for the audience of this addon.

.txt extension:

It's GPL, so I thought best to include instead and avoid confusion.

And also, I've used that class for some time, and I feel it's worth the extra load.

jQuery version:

As said, this was created over a year ago.

Thank you for your input, although I won't change this addon to accommodate those suggestions, I will keep it in mind.

[Anonymous]

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.

[Jaaaacccckkk]

( CENSORED )

For once can't you appreciate others work, instead of being so far up your own anal passage?

All i've seen you do is slate other people's work, and make naive comments about irrelevant things.

Edited August 27, 2011 by illusions

[Spudinski]

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.

My script isn't of poor quality. I dare you to go look at other addons available on this forum. I do consider that a main factor when developing - quality.

If you want to bash me on that, you are way out of line. I take that personally.

Restrictive: I don't see the restrictive side of this, other than it not being able to deal with large systems. But even the base won't handle that.

Until you personally remake the entire base to be optimized to handle large quantities of data, I will hold this script as is. It's useless trying to effectively optimize one script in an entire application(engine) that isn't - somewhere you have to draw the line.

Design: I do believe that this script is designed in a way that complements it's function - to search through a paginated set of users. It does that extremely well.

When keeping in mind said above, it is designed to be effective within the extent of the engine's capabilities.

Marketplace: If you know me by any nature at all, you would know that I offer my help for free when selling an addon. I'm willing to help and alter the script to the clients exact needs; if there are faults, I repair them. But, I released this as "free", as a commodity for others. Everything here is out of my own generosity.

The main subject here is the creators of MCCodes, not the developers that extend it. You can't blame me for their mistakes, and you certainly can blame me for not doing something that the application isn't capable of in the first place.

[Anonymous]

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.

 

it is designed to be effective within the extent of the engine's capabilities.

You have me there. I can't add anything to that.

You also state that

It's useless trying to effectively optimize one script in an entire application(engine) that isn't - somewhere you have to draw the line.

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.

[Spudinski]

Hackers(the correct definition) are the reason why most applications continue to be more secure and better than ever, with that I agree. And I do appreciate the input you've given, as said.

My main point of focus is that:

a) every past script/addon I have released, is done to the best I can and the best the platform enables, and if more is required I provide it,

b) optimizing one script wouldn't be worth the effort when compared to the whole of the likes of MCCodes (agreed), like training one soldier in an army of a thousand - useless.

I acknowledge that you did not directly say that I should change the script, but you made it pretty clear what you thought of the idea that I would not alter this script to improve it.

[Anonymous]

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.

[gurpreet]

Nice mod, very neat and helpful :)

[Mystical]

Looks and works well but does anyone who uses this know how to change the name of crystals to something else? I do not use crystals on my game. It does say DO NOT EDIT BEYOND THIS LINE in the script... I can figure out most stuff but this script is like looking at formulas for the Nasa Space Shuttle......

[Spudinski]

Looks and works well but does anyone who uses this know how to change the name of crystals to something else? I do not use crystals on my game. It does say DO NOT EDIT BEYOND THIS LINE in the script... I can figure out most stuff but this script is like looking at formulas for the Nasa Space Shuttle......

Look for this line:

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

 

And just change "crystals" to something else.

Edit:

Technical info:

The script will use the CSV to add extra fields to the output, but please remember that if the row you want to display is outside of the `users` table, you will need to use a JOIN method to include the table and rows wanted into the original query to the database.

Edited February 7, 2012 by Spudinski