Official Mys v1.4.0 Ideas & Suggestions Thread

[Pear]

I just thought of another idea that probably wouldn't be that hard to code. c: It is the ability to be able to adopt all the allowed pets at one time. So for instance, if one were to adopt a pet, but it had multiple outcomes so they wanted to adopt more than one. Let's say the cap is at 5 of that pet, so they could go on the adopt page and there could be a little bar thing (I don't know how to explain it..Kind of like the links at the top of the site where you hover over them and it drops down a list.) that is numbered up to the amount of that adopt that they are able to get. c: Exept have it individual for each adoptable. So if they only wanted 4 out of the 6 of one adoptable, but reach the cap on the next, they can adopt them all at once instead of having to go back to the adopt page 5 million times. x))

(Also, did you happen to say if you were going to introduce pet groupings? If you are thinking about not doing it, I'd say that it would be a very valuable function to have in all sites and I would greatly recommend reconsidering. I cannot think of a site that wouldn't use it. c: There could also be a little checkmark that says "Allow users to create any amount of groups?" and if the admin checks it then they can create however many they need. Below it has a different checkmark that says "Specify how many groups a user may have?" and then have a blank box where the admin can enter in the max number of groups a user may have.)

[squiggler]

Lori had a great idea about lineages and I wanted to know if it was possible with the future stats system. It still has some kinks but here it is:
You can assign a value called "generation" to each adopt as it is created. For bred adopts, it's +1 the higher of the parents. So if the father is a 7-gen and the mother is a 13-gen, it's a 14-gen.
The parents get assigned a second value called "parentGen." (This only happens if they don't already have one.) This value is written as the child's ID + D or M (or if not numbers, 0 for dads and 1 for moms).
Example: Child's ID is 102. The dad's parentGen stat is 102D or 1020.
When you go to the lineage page, the grid has slots up to 14 and places the dragons according to their IDs.

Am I making any sense? XD

[parayna]

Squiggler, would this maybe enable you to click on a button on your pets profiles (for example) and see the past generations? I would kinda like that implemented as well... It would be a nice add on to have, and it would definitely mean that people would enjoy the breeding aspect more as they could keep track of the past generations and, I don't know... breed 'pure blooded' pets. (Whatever that would entail on your site, either breeding with only that one colour or type... whatever )

[squiggler]

I love the achievements and personality ideas. Not sure what the personality would do unless it affected how they grew stats.

The competition idea would be fun. It could be based on who has the best stats. I think it would be cool if it ran once a week, and members would pay an entrance fee for the chance of winning either money or an item or an adoptable.

Originally Posted by parayna

Squiggler, would this maybe enable you to click on a button on your pets profiles (for example) and see the past generations? I would kinda like that implemented as well... It would be a nice add on to have, and it would definitely mean that people would enjoy the breeding aspect more as they could keep track of the past generations and, I don't know... breed 'pure blooded' pets. (Whatever that would entail on your site, either breeding with only that one colour or type... whatever )

Yup, that's exactly what I had in mind. For example, like DragCave: http://dragcave.net/lineage/r8uSR

And you can click each adoptable's image to go to their stats page.

This would probably only work if the adoptables have public stats pages though... otherwise it'd be kind of pointless. The personality would be displayed on the adoptable's stats page or box.

IntoRain was able to do that for me- you might want to ask them how they did it. Example.

[parayna]

Does anyone know if there has been something like a 'crafting' feature suggested? Like, if I wanted to create the item, 'Sushi,' I could go to a page and then use up the ingredients (fish, seaweed, rice) from my inventory and then come away with a sushi item?

I don't know if it has been suggested yet, but I would love that feature XD (Sorry if it has, I sometimes skim over bits when pages become too long XD)

[Hall of Famer]

You may want to check out the alchemy mod I made for Mys v1.3.4, its very similar to the feature you are requesting. In Mys v1.4.0 the alchemy/craft system will still come out as a plugin/mod rather than bundled with the official package.

[parayna]

OK! Thank you! :D (Can't wait for the next script to come out :P)

[Kyttias]

For v1.4.0, I'd like to see some database optimization done. Some of the VARCHAR values could easily be held as CHAR values.

There are trade-offs, both with their benefits. VARCHAR values take up less disk space, because while they hold a maximum value, they store the contents dynamically. But it's because of this reason exactly that they query slower. CHAR values will always take up the exact amount of space you allocate, whether they are filled or not. But because they are predictable in this fashion, queries through them run up to 20% faster. On the downside, again, is that they are storing the full length of the max you set, regardless of how much of it is filled.

For values that will barely change in length, useralternates in the owned_adoptables table, for example, CHAR(3) may be a better fit, given it will only ever hold yes/no values (and at that rate, rewrite the code to handle it in binary, perchance?), or gender, as a better example, it only holds one character, easily could be CHAR1 instead of VARCHAR10. I think the entire database could use a look over before release, trim up some absurd lengths here and there, etc.

It comes down to size on disk versus query speed. Some more reading here?

But if there's going to be any importing from previous versions, there could be conflicts... =/

[IntoRain]

Originally Posted by Kyttias

For v1.4.0, I'd like to see some database optimization done. Some of the VARCHAR values could easily be held as CHAR values.

There are trade-offs, both with their benefits. VARCHAR values take up less disk space, because while they hold a maximum value, they store the contents dynamically. But it's because of this reason exactly that they query slower. CHAR values will always take up the exact amount of space you allocate, whether they are filled or not. But because they are predictable in this fashion, queries through them run up to 20% faster. On the downside, again, is that they are storing the full length of the max you set, regardless of how much of it is filled.

For values that will barely change in length, useralternates in the owned_adoptables table, for example, CHAR(3) may be a better fit, given it will only ever hold yes/no values (and at that rate, rewrite the code to handle it in binary, perchance?), or gender, as a better example, it only holds one character, easily could be CHAR1 instead of VARCHAR10. I think the entire database could use a look over before release, trim up some absurd lengths here and there, etc.

It comes down to size on disk versus query speed. Some more reading here?

But if there's going to be any importing from previous versions, there could be conflicts... =/

There isn't really that much of a difference in terms of speed, it's pretty neglectible honestly. I believe the char/varchar query differences are actually if you manually create the indexes based on those columns. Database optimization would fall into the very boring subject of normalization xD I agree the yes/no/true/false columns should be changed to boolean (int if database doesn't support it or even enum('true', 'false')). And the gender also, that one deserves to be a char

But I'm not really into databases, normalizing them and stuff has never been my thing, just talking out of personal opinion

---

Having Mysidia on git would really help. People who like this framework could contribute with bug fixes and aditional features, etc. SourceTree is a good interface that supports git, so you don't need to use the command line if you feel uncomfortable with it

[Kyttias]

^^; Will it still be negligible at 6,000 users?

Originally Posted by IntoRain

Having Mysidia on git would really help. People who like this framework could contribute with bug fixes and aditional features, etc. SourceTree is a good interface that supports git, so you don't need to use the command line if you feel uncomfortable with it

Definitely. There are a lot of little things I've long since fixed that were almost too minor to mention, but I feel bad for the less php-savvy.