krballard94

Because that's the way Eloquent is intended to be used. However for example, if it would update on each reference... What if you wanted to do more than one adjustment? That could be multiple queries! So why do more, when less is good?

I did actually toy with that idea just before I previously posted, but i decided against it. I believe the method names are more clear and concise.

I want to keep my view files as clean and with minimal logic inside them so I disagree with this (And I'm not a fan of blade, but I am using it). However, as I'm going along I'm slowing documenting what I add. Personally for me, I know that I'll be using accessors in this project so I know that the getOrignal function will return the raw output. I've since added some methods to my logic in the model, and in my opinion it will make it easier update stats and currency in mods.   // Within UserStat model public function decreaseStat($stat, $value) { return $this->attributes[$stat] = parent::getOriginal($stat) - $value; } public function increaseStat($stat, $value) { return $this->attributes[$stat] = parent::getOriginal($stat) + $value; } //Examples $user->stats->increaseStat('endurance', 10.10); $user->stats->decreaseStat('currency', .50); $user->stats->save();   So now, upon displaying the information it is still formatted but overall the editting of the stats are done with ease.

I think it's very good to! I might even create a GitHub repo after I have the basics so the source is easily accessible.. Then people will also be able to fork it and make adjustments to make the whole engine better.

Refer to my previous post.

Eloquent has a function to output the original state before the accessor touched it. $user->stats->currency // output: 1,234.56 $user->stats->getOriginal('currency') // output: 1234.56

The best thing about this, is Laravel ships with this.   I'm open to suggestions on ideas through out. I don't plan on making a specific genre because it gets way to boring. So if you have any ideas, please let me know! To even avoid every game having the same currency, I've simply put currency and special and in the settings table I've made fields called game_currency, game_currency_sign and game_special. I even made it so when you reference the currency column all the formatting has been done already with the help of accessors from Eloquent $user->stats->currency // output: £1,234.56

I've been using it quite a bit since I've come back to development and I think it is very good!   Laravel encourages people to extend the framework to how they see fit!   I believe that MVC is a good approach and we should start using it as it gives us great ability to separate our application logic.

Straight away, this will not be a game out of the box. To be able to make a game out of it, development will be needed. I'm looking at creating a basic open-source engine developed on the Laravel framework but first I'm wondering what the general opinion would be.

I wouldn't do it this way at all personally, I'm not going into the code as I don't have McCodes. Also I think its just badly built. I'd create a new table e.g password_resets (email, token, timestamp) first of all. Next I'd let the use create a new row in that table by making them fill out a forgot password form - generally just an email field, maybe a captcha if you want. Do some validation on the email, and then I'd insert the email, a generated token and the timestamp for this. The user will receive an email with a link to the file with the query string for the token appended there and then allow them to change password. The timestamp is just an extra field, but I'd use it to make the token valid for around an hour. Just my two cents!

I updated my post, I meant to write permission_user for the second pivot table. As for the pivot tables, as I mentioned I am working with Laravel which is using Eloquent and these allow me to access them the easier. http://laravel.com/docs/5.0/eloquent#working-with-pivot-tables

I'm currently using Laravel 5 and I'm making a open source game engine for people to develop further upon (not a complete game without further development) however I'm looking at a few ideas for user roles and permission based access. I'm completely impartial to several ideas and I would like to ask you would think about doing it. For example I want a user to have a particular role, but if that user doesn't have access to a permission because of the role, I want to be able to give that user the permission while still not changing his role. Currently I'm looking at having a users, roles, permissions, role_user (pivot table), permission_role (pivot table) and permission_user (pivot table). I'm also looking into the idea of having a meta field in the users table and encoding it in JSON. Any tips would be appreciated.

PDO - Just purely on the fact its easy to change databases and all you have to edit is the DSN string. Just remember, it's only an data abstraction layer which uses the same methods regardless of whatever database you use. It's not a database abstraction layer.

Well as I said in my first post, I'm not going to mention the code as I have just returned to development. I was just voicing my personal opinion.   I do understand you here but, I do not believe I am undervalue the work. I was saying that compared to another script which gets updates from the author, customisable and boasts more functionality it was expensive.

I do understand where you are coming from, however I still don't agree with the price personally for what it is. People can feel free to have their opinion, but for a login and register, I believe its overpriced in my opinion. I wouldn't agree to pay that being a client.

I'm not going to get into the code and slate it off (as I've just returned to development) and quite frankly, I could never be bothered with JavaScript and AJAX requests. However I definitely do recommend thinking about your pricing! I found Ajax'd PHP Login, User Management & Site Security on CodeCanyon which boasts a lot of features. Price comparison is quite remarkable here, your script is a staggering 430% more expensive (after currency conversion)!