IllegalPigeon

And PSR standards...which should be adhered to.

The problem with that, braces don't adhere to PSR-2 standards. Also, casting to an (int) is a lot faster. Plus, braces are ugly.

Yes, and that was what I was referencing. But, when you stated it, you said "if you have a script that you have thats good". Which suggests you're looking for 1 or the other, either something custom built or something pre-made. I'm simply saying, with your budget, you'd be lucky to find something pre-built. You could always used McCodes, but, I don't know how much customisation you'd get for your budget.

You're not going to get a custom project done for this price. You will not find a competent developer for this price. You *may* find someone with a pre-built script that will customise theirs for you.

The best way to do it, which I should have done originally, would be: WHERE playerid = " . (int) $wj['playerid']; Also, you don't need to keep ending the query like you are: WHERE playerid = " . intval($wj['playerid']) . ""; There's no point. You can just end it with : " . $blah; - 'tis neater.

Might help if you posted your budget.

What I'm saying is that you're using mysql_real_escapestring() on numbers. Notice the "STRING" at the end of that function name. A number is NOT a string. Example: WHERE playerid = '" . mysql_real_escape_string($wj['playerid']) . "'"; , that looks like a number to me, you're using MRES() on it AND quoting it. It's a number. But, I don't know your system, you could be referencing a players name in the "playerid" field. I just don't know...I didn't make it. WHERE playerid = " . $wj['playerid']; Would be a better usage. Or, if you're unsure what the contents of $wj['playerid'] is going to be and you want to force it, then you'd use: WHERE playerid = " . intval($wj['playerid']); But, in reality, you should even be using the MySQL extension.

You're using mysql_real_escape_string() to escape numbers. That's not what it's meant to be used for. The hint is in the name...string. You're also still quoting numbers. If you were running out of resources, then, that's not helping. It forces MySQL to typecast/conversion, which, on a script that's already haemorrhaging resources is not helping. That's not why your script isn't running, though. It's down to whatever query you have that is throwing an error. We'd need to see that query.

I feel like I've adequately expressed my feelings towards this forum and it's use of back-ticks. If I have to discuss it again, I'll cry.

Can't really help unless you try to debug it a bit and give us the errors. Also, why are you quoting numbers in your queries? Number != string. I won't comment on the plethora of issues within that file, just the number thing...as it's sticking out.

That's just down to preference, though. If they all do the same thing but you prefer one, default to it. If one thing does something that you need that your default one doesn't, then use that one. Personally I prefer Bootstrap over Zurb and Sass over Less. So I default to Bootstrap and Sass all the time. I've never been in a situation where I've NEEDED to use one over the other. Although, mdl is pretty epic.

I'd go with Bootstrap. You can use media queries to specifically change what something looks like on a mobile, too. Even show/hide elements.

This forum is obsessed with using back ticks on table and column names. It's bad practice to use back ticks on everything, you only need to use back ticks for reserved MySQL words.

The process behind splitting up tables is called normalization. It's not necessarily faster OR slower, it is extremely unlikely you'll ever be handling enough data to ever see a JOIN become a hindrance. Plus, with correct indexing and query performance, you won't run in to the issues either. Normalising also reduces data redundancy. But, by far the BIGGEST and best thing about normalization is the maintenance. It's so much cleaner and easy to maintain. Also, no one is going to look at your normalised tables and say "that's inefficient and going to slow your site down" (unless you've split one table into something ridiculous like 15, of course). Relational Models are standard and encouraged. You don't need to split every table, but, things like separating user account info from user stats and user items is a good call!

I thought the idea of this was to have the ability to change the name of "energy"? E.g you have key_name | key_value stat1 | energy I'd store the users "energy" and "max_energy" in a user stats table, that is related to a user table. For example; Table users: id | username | password Table user_stats user_id (foreign key references users) | stat1| max_stat1| money Then, if you created a model implementation to fetch the data from the related tables, you could have something like: echo 'You have ' . $user->stat1. ' out of ' . $user->max_stat1. ' ' . config('stat1'); Which would translate roughly to: "You have 50 out of 150 energy". See what I mean? Obviously, my above code is assuming you have some sort of model to fetch related data and, a function named "config" that would fetch config variables. You can do it however you want, though!

Personally, I don't think changing the name of commonly used stats is a good idea. You create a game where people can use "energy" but then you change it half way through? Sounds like a good way to confuse people! However, there is equally nothing wrong with storing these settings in the database if you did want to change them later. You could even store them in a configuration file, if you really wanted. Just define the names of said items, If you want to use a database, I'd do something like this; CREATE TABLE `settings` ( `key_name` varchar(50) DEFAULT NULL, `key_value` mediumtext, UNIQUE KEY `key_name` (`key_name`) ) ENGINE=InnoDB This method will be a lot easier than storing in files, especially if you want to add more configurable settings later.

I called you out on sessions, I didn't *think* you said anything, I took what you *actually* said and corrected you. I also do not *think* you said that your Framework performs faster than Laravel, I was just pointing out to the OP that just because something is overkill and has a lot of features, doesn't mean it's any less great. I am not accusing you of saying Laravel is not great, I'm not accusing you of saying Google is ****, I'm not accusing you of calling my mother fat, I'm not accusing you of anything at all. Do you think the developer of CI would be replying to me accusing me of attacking him if you said something like "I'm using CI because Laravel is overkill" and I did a benchmark? Nope. I could have used CI in the example, but I just went with Laravel. It was the most accessible to me at the time. In the future, if I post any code, please do feel free to benchmark it, slate it, tell me I'm wrong. I will provide a counter-argument, we can discuss all night and then maybe someone will learn; "Hey, I didn't know sessions don't actually use memory when being written". See, it helped you out. Ergo, my comments in the aforementioned thread weren't malicious, were they? They were helpful!

I was simply pointing out that, just because a Framework is (in your words) "overkill", doesn't mean it's going to under-perform. I have nothing against you, if it was someone else, I'd do the benchmark for them. I believe that your problem is that you don't like being told your wrong. I don't see why you can't just say "yeah, you're right" and accept the information being given to you. None of my comments have been said with malicious intent and are informative. Now OP can look at this and say "Hey, Laravel is pretty ****ing quick. I might take a look at it". When he does take a look at it, he'll be in awe because Laravel is amazing, and adhering to L5's coding standards and practices will intern make you learna lot more. Don't feel like I'm attacking you, you're the only person I've seen in the last 2 days providing incorrect information, I was simply correcting you. When you argued with me over the sessions thing, I just carried on proving more data to prove to you that your information is incorrect, you're the one that started crying. Don't comment on things if you don't like the thought of someone saying "hey, actually, you're a bit wrong there..." Edit: This is neither here nor there. I have never once mentioned your abilities or tried to insult your abilities. I am again only providing information based on some incorrect information you are providing people. This forum is quite inactive. If I see someone else post something that I feel is wrong, I will happily tell them about it. You're taking offence to someone correcting you when you should be soaking up the information. I do not care for your coding abilities. If you're telling other people incorrect information, though, then I'll simply tell you that you're wrong and provide reasons or examples where needed. Chill, bro.

I've been a Laravel developer since Laravel was starting out, I love it. When they announced Lumen, I was so happy. Lumen is fantastic for creating API's. But, even still, Lumen isn't HUGELY faster than Laravel anyway because Laravel is quick in itself. See, you say this, but I've just created to instances on homestead. One using your Chaoticframe Framework, one using Laravel. Both just returned a view with "Hello world". Even your MASSIVELY smaller Framework cannot compete with Laravel, and this was without caching too. I've proved screenshots of both tests. ChaoticFrame code: [ATTACH=CONFIG]2175[/ATTACH] Laravel: [ATTACH=CONFIG]2176[/ATTACH] Edit: I'd just like to add, Laravel wasn't installed during the first test, on just the Chaoticframe code. I did multiple tests, took the average one, then installed Laravel after removing the original code. The directory name is just the same. I also did page load times, and, Laravel won again. But, as it's calculated in microseconds, it really wasn't worth screenshotting.

Yeah, or that. Lol

But that wasn't MY argument. I don't need to learn about sessions, I'm fully aware that reading the data will use a little bit of memory. I don't need to Google how to use sessions or find an answer to prove someone wrong. So yes, I am 100% right and you are 100% wrong with your original argument. I don't know why you're even bothering to say "well sessions use memory when you read them", because in the beginning you said "STORING" data in sessions will use memory. The memory being used was the for loop that produces 1,000,000 results on the page, not the sessions being stored, so again you're still wrong. Oh, and of course I wouldn't store data in a session if I wasn't going to use it again. That's neither here nor there, though, the fact of the matter is that storing session data does not use memory. The OP asked about storing a lot of data in a session, you provided an inaccurate answer and I corrected you. Even if he was to store huge data in sessions and call them again later, it STILL doesn't matter because fetching from a session, the database or cache is ALWAYS gonna use memory. So your comment is immediately null. Also, when we go back to this: You clearly think you're right. I provided code that proves otherwise. In the above example, you're again suggesting that running that code which STORES sessions will not run because of the memory usage when in reality it will run if your browser could render 3 billion results (if you're patient enough). There's no harm in admitting you're wrong. By trying to make out "oh well, I'm only 90% wrong because someone on Stackoverflow said this" is just stupid. Take it on the chin.

Yeah, so, like I said...memory is BARELY touched. And that's to be expected with 1,000,000 sessions. But you see my point! Sessions won't affect the memory. Calling 1,000,000 sessions will, but, same for calling 1,000,000 cache entries and 1,000,000 database entries!

Yeah, but, what was the starting memory? The very first number ;) rendering in the browser will take a couple of seconds, but that's your browser and that's obvious if you're rendering 1 million numbers!

Yeah, so, the link you just gave completely agrees with me. It's as simple as that. Your example is completely redundant, too, because you're going to run into ANY of those issues running ANYTHING for 3 billion iterations. I just ran your code on a machine with 512MB RAM, I only did 1,000,000 iterations though because the problem now is rendering it in the browser, it'll take too long. Oh, what a surprise, I'm right. Run this. Tell me the results, the memory is pretty much exactly the same. <?php echo memory_get_usage() . '<br />'; for($_SESSION['iterator'] = 0; $_SESSION['iterator'] < 1000000; $_SESSION['iterator']++){ echo $_SESSION['iterator'] . '<br />'; } echo 'Memory: ' . memory_get_usage(); ?> Your original comment was "if you want to store them in $_SESSION, be my guest, it'll take up memory though.", which I pointed out is WRONG. It is wrong. Storing stuff in a session won't cause any issues at all. However, if for some reason, you're reading 3,000,000,000 session files per page load, then yeah, you've got a problem. Also, your last comment assumes that the OP is loading EVERY stored session data for every page load. Why would you do that? Just like a query, you fetch the data you want. So, store 3,000,000,000 sessions files if your filesystem can handle it if you really want. But the fact is, I'm still right. Your original comment was "STORING" data in a session, not reading AND writing/best methods to fetch the data. Also, the fact that you had to Google the answer and still get it wrong shows me that you have little understanding of sessions.

Lol, what. So, you're saying, if I set too many variables, I'm going to run out of memory? PHP sessions do not use memory. So, yes, exactly. You do know how sessions work, right?