Dino's Guide To: Mysidia 1.3.6

[Dinocanid]

(Note to HoF if you're reading this: Mysidia really needs official documentation. People would be much more willing to use it if there was.)

In my journey to update all of my mods to the latest version, I'm making a guide of sorts on google docs to hopefully help those moving from 1.3.4 to 1.3.6.

Dino's Guide To: Mysidia 1.3.6

docs.google.com

The guide is very incomplete, but I'll be updating it as I go along like I said. I'm only just beginning to understand the changes, and I haven't been able to discover them all as of yet. I hope to make it less of a list of random references, and more of an organized guide in the future (like a "getting started" section, etc.)

 

[Hall of Famer]

Again, exactly why it was broken up like this is beyond me.

The code has been criticized for being behind the time so I decided to modernize it for PHP 7/8 standard. The classes are organized by packages/namespaces, instead of inside one big folder. Eventually all classes will have namespaces, so its something that has to be done for Mys v1.4.0 anyway. Also this is the logical step to take as the number of classes increases, it wont be easy to browse 200+ files in one folder.

 

[Dinocanid]

If I can give some criticism: the modern way appears to be just typing HTML directly into the respective view file, versus using something like $document and lang files to determine the text for the website's pages. (While not virtual pet specific, I'm using things like Laravel and CakePHP as examples here)

Not that I'm against using $document but the thing going on with it is part of why I have "Classes from 1.3.4 have also basically been scattered all over the place". Everything that can be used with $document isn't located in the document folder of resource/gui (forms and formbuilders use resource/gui too but it could potentially cause less confusion nonetheless). Plus even then, there doesn't appear to be one line or two you can include to access it since it's not accessible "natively" anymore. You have to include each, individual, piece.

Made more difficult by the lack of any sort of guide to say "these files moved to X and were renamed Y". Where exactly they ended up isn't even all that predictable. "ownedadoptable" has been split into two separate models for a reason I just can't figure out, adding to the "why" factor. I could just move everything back into ownedadoptable and delete ownedadoptableview (which I'll probably do tbh), but.

I hope I'm explaining this right, but what I'm basically trying to say is that it's the sort of thing where you have to stumble around in the dark a lot to figure out what does what and what's connected to where, and from there you have to experiment to see what works. It has to be frustrating to provide support for every single thing, and it's frustrating on the end of the developers using the script as well.

 

[Hall of Famer]

Actually in Mys v1.3.6, you can already use just html/tpl for views. I wrote a post explaining this:

What is new in Mys v1.3.6: Custom Smarty Templates

We are near the end of the July, and the first beta release of Mys v1.3.6 is coming closer. About 2 weeks ago I managed to get PHP 7/8 compatibility working, and now I am ready to introduce another new QoL update for the new version. This one is...

forums.mysidiaadoptables.com

So if you wish to just write HTML, you have a way now. Though it seems the 'modern way' is to write JS components for views, but thats a different topic. By Mys v1.4.0, both PHP and HTML views will be available for you to choose. The advantage of PHP view is only relevant in future when we have built-in AJAX feature, and you can attach an AJAX event listener to a GUI component(which cannot be done with HTML templating). I have this planned for Mys v1.5.0 though, so you aint likely to see this for a while.

 

[Kesstryl]

I came here hoping to find documentation for 1.3.6 and unfortunately this one was incomplete, probably due to Dinocanid hitting walls and losing interest. Hall of Famer, I have to agree with Dinocanid that the "modern" way, which might be great for a professional php dev, is not going to be intuitive for your target audience which is self taught devs and artists. We do need some kind of documentation to find our way around the code in the hugely fragmented MVC (now HMVC?) structure that many of us are getting lost in. I'm noticing the community has been falling off and less active since the code began to become more complex.

I remember some of the criticisms you got on VirtualPetList, and I largely disagreed with some of them. Security criticisms I agreed with, but the rest I felt was a bit snobbish from their devs who also were devs for a living, considering you created this script for those who don't have the ability or don't want to write their own complete framework but do have some php and modding experience.

I know it's difficult to stay motivated, especially when it seems like interest has tapered off, but documentation will help those of us who have stuck with this, and will help new people who discover this script and want to make their own sites. That will help keep the community engaged and not frustrated.

 

[Dinocanid]

I still hope to fill it with more info, but that takes time and isn't high on my priority list. I also don't want the expectation to be on me, when at the end of the day I would be making the guide as a hobby, and how things work is only based on the knowledge I slowly gain through working with the framework. It'd be more apt for the developer to have a guide, since that's pretty standard for "products" (or whatever you want to call MAS) and deters people from using said script if the learning curve is "idk, poke around and figure things out", no documentation or anything. I've been having to give support through DMs to people trying it out since they've had trouble even hiring devs that haven't specifically worked with MAS, because they don't know how to work it. (Aside from the possibility of paying them to learn I guess)
It's like if someone was downloading, idk, PHPBB and it didn't come with any documentation. You'd just have to stumble around in the code and search through forum posts to find things.

 

[Kesstryl]

I still hope to fill it with more info, but that takes time and isn't high on my priority list. I also don't want the expectation to be on me, when at the end of the day I would be making the guide as a hobby, and how things work is only based on the knowledge I slowly gain through working with the framework. It'd be more apt for the developer to have a guide, since that's pretty standard for "products" (or whatever you want to call MAS) and deters people from using said script if the learning curve is "idk, poke around and figure things out", no documentation or anything. I've been having to give support through DMs to people trying it out since they've had trouble even hiring devs that haven't specifically worked with MAS, because they don't know how to work it. (Aside from the possibility of paying them to learn I guess)
It's like if someone was downloading, idk, PHPBB and it didn't come with any documentation. You'd just have to stumble around in the code and search through forum posts to find things.

Sorry Dinocanid, most of my post was targetted for HoF, didn't mean to imply it was your responsibility. I realize I was unclear with who I was talking to. I will edit it.

 

[Milly Money]

I personally am having tremendous issues being able to wrap my head around the difference in what we had in 1.3.5 and 1.3.6.

it's wonderful to get some sort of basic guide for it, it's so confusing to me.

I used to be able to create mods with only moderate effort, now I am so lost with most of the details of how to do it, I don't have the nerve to try - and when I do it fails miserably.

It's really gotten complex. So glad it isnt just me!

This:

" ...the "modern" way, which might be great for a professional php dev, is not going to be intuitive for your target audience which is self taught devs and artists. We do need some kind of documentation to find our way around the code in the hugely fragmented MVC (now HMVC?) structure that many of us are getting lost in. I'm noticing the community has been falling off and less active since the code began to become more complex... "

Well described.