Floydian

Re: Query Optimization   When did I say that? Now if you've got 50- fields and you need 49 of them, maybe it doesn't make any difference if you use * or name each field explicitly.

Re: Need help MySQL/PHP You're welcome, glad that worked out ;)

Re: Another problem need help with Now you gotta make sure your inventory is quantized....

Re: Query Optimization   Care to present some benchmarks proving that? Without some sort of evidence, I'm not inclined to just take your word for it. That doesn't mean that I necessarily think you're wrong though. I merely challenge you to back up your fact. As for the rest of codestyke's post, I think it depends on the point of view. To the players of the game, getting pages that load even 0.1 seconds faster makes a difference. Amazon did a study where adding 0.1 seconds to page load time actually reduced sales by 1%. To look at it another way, Bill Gates might think my yearly income trivial, but to me, and my family, it means all the world.

Re: Another problem need help with Using the code you have, and assuming your query is working properly, you'd take the var $items, and put it in an if.   if ($items < the number of items required) { // you don't have the required items... } else { // you do have the required items... }

Re: Another problem need help with   Killah is on the right track here. You had a missmatched set of parens. The only other thing I see that's a problem is your in() function takes a CSV, but you've enclosed your entire CSV in quotes. in(%s) is the way you wanna do that, and not in('%s')   The key there, is using %s does not always require quotes. You're outputting a CSV composed entirely of numbers. If you had strings, you still wouldn't use quotes around the %s because you would need quotes around each entry: in('a', 'b', 'c') Does that make sense?

Re: Query Optimization If you have 150 fields in the users table, you'd prolly want to consider splitting that table into a few more tables...

Re: Need help MySQL/PHP First, looking over that sql, you'd definitely need to use that group by clause: select (sum(t1.power) + t2.bonus) as total, t1.Clan from table_2 as t2 left join table_1 as t1 on t2.Clan = t1.Clan group by t2.Clan   Yes, and using that group by clause it then sums up each individual clan's power.   um?? lol   You're selecting from table 1 and table 2. You have "from table 2" but to select from table 1 as well, you need to join that table to take 2. Somehow the table 2 in the from clause and the table 1 in the join clause must share somthing in common for which you will use to join them "on". In this case, they share clan names. Hope that helps. You should try to run the query. Can't hurt running a select query, even if it doesn't work. ;)   EDIT: I had the sum(t1.power) part mistakenly labeled as t2.power. Kinda confusing to me labeling the tables t1 and t2... lol

Re: Query Optimization I think you missed my point, because you're making it for me in your last post. My point was, writing out all those column names isn't yielding you much "optimization" over doing u.* So, the corollary to my point is that removing as many column names as is possible makes the optimization more worth while. Does that make sense?   In fact, I wouldn't be surprised if naming 50 columns out of 60 or whatever it is, is actually worse than doing u.*. Just think of the time mysql has to spend deciding which column matches, when it could just get em all without having to match em up. I obviously haven't benchmarked your query on your game, so without doing that, no one will know for sure. It would be ironic is naming all those columns actual penalized ya on performance. lol

Re: Query Optimization along with staff notes, user notepad, signedup, and duties no doubt... lol

Re: Need help MySQL/PHP select (sum(t2.power) + t2.bonus) as total, t1.Clan from table_2 as t2 left join table_1 as t1 on t2.Clan = t1.Clan   t1 (table 1) is the table with the username in it t2 (table 2) is the other table you may need to put in a ---> group by t2.Clan <--- try it without that first, and see if it works, if you get a "mixing of group" type error, toss in the group by that should do ya

Re: Query Optimization user_notepad,signature,gender,signedup, email,display_pic,duties,staffnotes   That's just a few columns I picked out that, IMHO, shouldn't be needed on every page load.   staffnotes? email? eh, If you say you're using those on every page on your site, then great, good luck ;)

Re: Query Optimization is that really yielding an improvement?   that's one of those situations where the improvement might not be worth writing out all those column names. I counted about 50 columns listed there. now if you can reduce that to 25, that'd be outstanding ;)

Re: Header.php problam [mccode v2] alrighty, the problem is you have each of those links in it's own div. the divs are overlapping (they're like 300px wide and contain just one link each) they're absolutely positioned which is how they are overlapping each other. I can't just say, "do this" and fix it for ya. You're just going to have to rework how your page is laid out. And try not to let those divs overlap your links.

Re: Header.php problam [mccode v2] If you can post a link to a page that exhibits this problem, I'm sure an answer will follow shortly.

Re: A little snipet (Could be security could be more) lol there is a way to stop people from having two sessions.... try it on a Horizons Game Engine based gamed. You'll find out that every time you load a page on one browser/computer with a different session ID as another browser/computer, your other browser/computer is auto logged out. it'd be nearly impossible to do a dual page load on Horizons just because of that, at least using the multiple browser or multiple computer trick. multiple tabs though would work (naturally we account for that) So, it's pointless to go on and on about this script stopping dual page loads. I'm sure the script does what it's supposed to do, and that's great. Good job killah.   Just a little hint, I'm checking for multiple sessions with the same $_SESSION['userid'] Yes that does involve running a count(*) where userid = blah on every page load to the database sessions table, but eh, the HGE header is highly optimized so adding that one query doesn't impact performance...

Re: Basic Ajax is easy We'll see where Chrome goes... Safari, with all the mac users, has stayed at 2% for a long time. There's nothing to indicate that Chromes 3% share is anything more than novelty at the moment. Then there's Google's proven inability to be successful in the desktop applications (of which Chrome is one of).   So, yeah, it's possible Chrome might take off. I might even switch over to Chrome one day. I did switch from Mozilla, to IE, then Firefox, why not add one more on the end? I'm in the here and now, and where things are now, Chrome isn't that important, and neither was Firefox when it had 3% market share. Certainly not important enough for a one person developer to invest time testing everything they make in a 3% share browser. The big folks are expected to do things like that, but the little guy has to be wise about how they spend their time :)

Re: B: lol as far as I'm concerned, webkit can either accept gecko or ie's css styles, or it can get lost. With something like 2% market share (comparable to opera's 2%) it just isn't an important renderer IMHO. My contention is that if one is going to target small niche browser markets, why target some and not all? For instance, just with safari, there's the Mac, Windows XP, and Vista flavors, then Chrome and all the os's it runs on, Firefox on Windows XP, Vista, probably a few other versions of windows, Linux, Mac, IE on all of it's relevant versions of Windows, Opera on whichever os's it runs on...   I for one can't be running a Mac, a Windows XP, a Vista, and a Linux computer and testing every one of those permutations of web browsers... Just looking at usage statistics on a couple servers I'm seeing this: tycoonrats.com Firefox: 47% IE: 40% Windows: 94% phphorizons.com Firefox: 75% IE: 19% Windows: 96% samples.phphorizons.com Firefox: 89% IE: 7% Windows: 98% www.w3schools.com Firefox: 44% IE: 46% WinXP------W2000--------Win98-------Vista-------W2003 72.0%------1.8%-----------0.1%--------15.1%------1.6% www.coveofpirates.com Firefox: 29% IE: 61% Windows: 94%   Anyways, that's the market I'd spend most time on. If someone reports a problem in some other browser, and is willing to work with me on the fix (that is if the browser/os combination isn't readily available to me), then I'll toss in something for it, but otherwise, if things look good in ff and ie, I'm satisfied.

Re: Basic Ajax is easy Are you using FireBug? I've found that to make styling YUI much easier than trying to read over the documentation. To be sure though, it can take a lot of work to get styles for widgets. The good thing is, once you have a widget styled to your liking, you can use that widget anywhere on your site with the same styles, so long as your styles just override yui-skin-sam and don't use #id identifiers. And the #id identifiers of course enable page specific styling if needed. I do spend a lot of time styling those widgets though, the first time lol.

Re: Basic Ajax is easy Yeah, using a library makes things a lot easier, especially if you're going to do more than just load up one little thing using ajax. Once you get into building a rich web app with multiple ajax deals, a library is almost a must... As for the page weight of yahoo modules, I'd have to disagree on that one, at least to an extent. Certainly, if one included a bunch of YUI widgets, drag drop, animation, buttons, RTE, and the list goes on and on, the page weight is going to be heavy, but if you're just going for the ajax, the page weight is low. Combine that with YUI's dependency configurator which will allow js files to be combined into one HTTP request, and css files to be combined as well, the page weight goes down a lot. I don't have exact stats on YUI 2.6.0 page weight for just the ajax module, but in YUI 3 beta 2, the configurator shows the exact weight of the inclues which would be: 30kb if you're using the min files/gzipped That's basically one image. And with that you get Dom, Event, IO (ajax), and JSON modules. Dom gives you all the Dom manipulation goodies, Event allows you to add event listeners in a cross browser way effortlessly, and the YUI global object has a bunch of other niceties that you all get for free whenever you use YUI. I don't know the page weights for other libraries, but YUI is pretty good there. And let's not forget the tons of web sites that use YUI as well. Even cpanel makes extensive use of YUI. ;) The Yahoo site itself makes very heavy use of YUI throught. Mail beta is almost entirely YUI, as well. But with that said, for the person that wants the smallest page weight, you'd have to custom write all your js code, then minify it as well. Then you have to host it yourself. And getting all the functionality of YUI 3 beta 2 with the ajax module and it's required dependencies at a page weight of 30kb min/gzipped would be a challenge for sure.

Re: script to prevent users to register or login using proxies lol yup, a missing cookie count is a great way to flag accounts. There's no way to get around cookie tracking using that. You either have the cookie or you don't. Either way, it's trackable...

Re: Is this worth it?   With that code, it looks like you'd be makin a new connection to the database, doing a query, fetching the first row, closing the db connection, on every iteration. If that's the case, it's definitely wrong.

Re: Is this worth it?   Yes, and in the quote above, from your link, you can add the error handling there. Instead of dieing on error, handle it gracefully. The good thing about this is that since you have it all tucked into a class, you can do a lot more, and do it efficiently.   Zeggy, please forget about that stuff you read. It's the wrong way to do it entirely. It's not like it's a little wrong, it's just completely wrong. No offense. Just don't want anyone to implement something that isn't going to work for them. It is a good thought though. I've thought of doing that myself back in the day as well. Auto increments handle themselves. Simply don't insert to the auto increment column. That's it. insert into table (blah, foo, bar) values ('eh', 'oh', 'ah')   where your table has columns: id blah foo bar   And the id is an auto increment. You HAVE to explicitly label the columns you're adding. I know lots of people skip that. Get into the habbit of adding them in. You have to do it, if you want to do things properly.

Re: Is this worth it?   lol, I did feel a little *glossed* over there... No worries though killah, you're doing good there. ;) And Nyna, Nyna, Nyna.... need I say any more? :P Nice add Nyna

Re: Is this worth it?     To answer the question directly, yes it can be worth it.   To provide commentary on what you're doing: #1 You include $h but never use it. #2 You have the variable $SQL and $v. Why two vars for the same thing? #3 You insert a query string into a query. Do you see where this sort of thing could be a problem since you aren't using mysql_real_escape_string() on $SQL or $v? #4 You're logging queries whether you are accessing the page, or someone else is. Why not just display the error if you are loading the page, and log it if it's anyone else? #5 Why insert NULL into an auto increment field? http://dev.mysql.com/doc/refman/5.0/en/ ... ement.html ---- If you take a look on that page, none of the example queries use NULL as an insert value for the auto increment. I would recommend following the examples from the MySQL site rather than deviating from them. #6 Your mysql_query() function isn't using a link identifier. You should include $c and plug that in there. #7 Even better, make a Database class, and do this the right way. ;) That's about all I can think of lol. Good luck with it!