Official Mys v1.4.0 Ideas & Suggestions Thread

[Hwona]

Originally Posted by IntoRain

I did this system for Infernette's Forest of Mirrors, it's kind of boring and very rarely used I think. Rounds take long to start, since they need to be full before calculating a winner.

Each competition asks for a certain adoptable (Infernette has implemented stats and moods and season/time of day an adoptable was born in) and has a limited number of entries. When it's filled, it calculate the top 3 adoptables with the best stats and distributes rewards (money)

If there's enough interest I can try to ask her if I can make the code public and translate it to 1.3.4, since I plan on doing many mods once my vacations start

Wow, that must be pretty awesome! I'm actually still using v.1.3.3 and have been trying to get an alternative system up since probably as one of the worst coders here, I can't do anything like competitions. XP

[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.

[IntoRain]

Originally Posted by Kyttias

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

Honestly, I've used varchar in most of my projects and queries took no longer than a few seconds with a few thousands auto-generated fake data entries. Query speeds actually depended more on the instruction I was doing (lost of joins, constraints, etc.) and if I had indexes to speed up selects.

I mean if you are only getting a person's gender, yes it will be faster, but in mysidia you usually get the whole row (since you are building objects). If you are getting a row where a column is a char and another is a varchar, you will get no performance improvements
But if you are indexing tables with columns that can be either char/varchar, go with char.


Again, talking on personal opinion about speed difference xD I still agree with you the gender and other columns should be changed anyway

[Hall of Famer]

Yeah I think you make a good point. For certain data field such as password, salt, session, and etc, we can definitely replace varchar by char since each cell in the same column will have identical or similar length(for password, encryption results in 128 characters for all passwords, regardless of the length of unencrypted password).

[Kyttias]

Also, I wouldn't mind a partial-public trade combo, with the poster choosing a winning 'bid'. Some additional thought might need to be put into it, such as everyone's bidding material being locked (so those pets and items don't end up elsewhere by accident) until the auction closes (the non-chosen get their stuff back), and the poster needing to choose a winner within a certain time period, else it auto-closes.

A "wonder trade" like Pokemon could also be interesting.

Really, I'd love an auction house the most but it sounds like quite a lot of effort (even one without bidding, just auto-buys).