Both owned_ and to adopt new ones (mask the id so no one can cheat).

Well there are better ways to prevent cheating. You may consider using session, as a user cannot go back to the page(as they may have bookmarked) if the session expires. I do not really recommend using non_numeric ids though, it creates all kinds of problems with other scripts and is essentially impossible to upgrade.

All right, I'll see about session and random for the adopts. Eh, I didn't know that. I'll see what else I can figure out. ;3

Well yeah, actually since Mys v1.2.3 it is already impossible to cheat with multi-adoption, thanks to Fadillzzz. In Mys v1.3.2 a new way of defining and accessing session will be available, which I shall illustrate in the development thread later. Mys v1.3.2 makes dramatic changes to Mys v1.3.1, as you will see soon.

Ooh... Shiny... *waits patiently in dev staff section*

It's not impossible to upgrade using letter codes. I do it everytime. It might be a slight pain but I love it and my members love it. They love getting codes that spell things out. And when I release a new adopt I make the codes relate to what type of dragon it is. Such as my Cow Dragon, his code was Moooo ;)

I may try it later, too late tonight, and I've a long early day tomorrow. Ugh, retail...

Nobackseat posted an updated mini-review of the script.

http://www.virtualpetlist.com/showth...s-Review/page2

It points out a few things, so I thought you might be interested. It's at the bottom of that page. ^

Well actually I am revising the user system including user registration now. The plan was to have Nobackseat review it after Mys v1.3.2 release, but nvm. He has some good point and it is clear that the user registration system does need an overhaul immediately. You will see this in next release, which I promise. The remaining superglobals are gone too in Mys v1.3.2, just incase you are wondering. In a few occasions I will use global keyword in functions or classes, but no more superglobals like $GLOBALS.

I do not quite agree with what he said about password encryption being messy, I personally see no problem in it. You may wonder why the password is md5'd at first, it was done to compensate old users trying to upgrade. The old encryption method is md5 without salting, and I can redesign a new function called updatepass() which accepts md5'd passwords and update them to new and secured version. If the encryption method is altered without using md5 initially, old Mys sites will have to force all of their members to reset passwords after upgrading. This is not what I wanted, not sure what you think. Also I dont understand what he means by 'Guys, are ya sure that's the final password...' though. Not secured enough? If so I will improve it.

Hey,

Wow didn't realize my post had been noted here so fast.

I realize I got increasingly sarcastic throughout the post, but I was being honest on my view of it, and I had listed plenty of examples.

I also, like before, realize that some of these issues aren't your fault, but after all they are being released under your name. I'm glad to hear you're working on them for the next release.

In my strong opinion, globals often mean that code was designed 'wrong'. There's always a better way to achieve what you want without using globals. I can understand if the way the code is setup makes it hard to transition from globals, but it's still being released with them and I was asked to give an honest review.

The jab at the encryption was mostly at how dramatic it was. There's easier ways to obtain equally secure encryption. I would call that secure, but how you encrypted it is just odd, not common at all, which just might make it more secure overall anyway.

Good luck, I'll keep checking it out every few releases.

NBS