CI on grill.php

[SSCBryce]

Some autism. Improve speed, efficiency, tidiness and ease of scaling for grill loading. Adding a new grill is drap and drop + tick up proper variable. Updated array_rand to superior mt_rand which is, according to multiple sources both un and official, more random and at least 4 times faster (mersenne twister). Also added a new grill, 1.png, to prevent obvious empty array spot with new grill.php code.

These changes are tested working on my clone, at least.

[ghost]

Sorry to be rude, but it's bad. Branching is also messed up in this merge request. I doubt you have rights to distribute the new grill anyway, baka.

04:40:37 WubTheCaptain | CI on grill.php by Farfie · Pull Request #47 · nokonoko/Pomf · GitHub https://github.com/nokonoko/Pomf/pull/47
04:40:41 WubTheCaptain | Why can't people use Git right
04:51:35        ewhal4 | >+$waifus = 10;
04:51:37        ewhal4 | +$aWaifus = 0;
04:51:39        ewhal4 | +$images = array();
04:51:41        ewhal4 | jesus fuck
04:51:55        ewhal4 | can't you just length the array?

I am glad grill.php is no longer a feature in pantsu/pomf, the only mostly maintained and clean development branch of Pomf.

I almost wish I didn't reply, this repository is dead.

[SSCBryce]

I don't really think you're being rude. I was just tinkering with a clone and did this change to make adding waifus easier, I had no idea if it was more efficient code wise or what not. And yeah it was also my first time trying to use Git at all, heh. I'll just close it since you've confirmed it's worthless.

[SEAPUNK]

I'd (mostly) ignore Wub's comment, since it's not really that constructive.

While there are better ways of doing this PR, it's a start. With practice, you'll get better. :)

Your PR does many things, which could be split up into their own PR, or omitted entirely, in my opinion:

• The README change completely changes who the contact of the repo is, and what the support matrix is. Unless you're the maintainer or the new owner (and have agreed with the original owner that this change is OK), it's best if you keep that change to your personal fork.
• Your PR adds a new image. Other than licensing(?) rights (which I don't think is really relevant here), it adds clutter to your original PR: to improve grill.php, and how it loads/determines the image. If I were the owner of this repo, I'd have preferred that the image addition was done in a separate PR as well.
• Your PR adds $aWaifus, supposedly for animated waifus. Again, this should be separated to another PR, preferably sometime after the original change, because the original repo doesn't have .gif waifus, so it's mostly a feature request, instead of the original enhancement. Not to mention, it adds clutter to the file, since $aWaifus is 0: it's not being used.
• What I would think is the original purpose of the PR: Use mt_rand() and a number system instead of having a (potentially) long image list and a slower and less random array_rand. And past that, it was either having the start number of mt_rand be 2, or renaming one of the images (preferably 10.png) to 1.png so the code didn't break on 1.png. I'd choose the renaming step, because it's generally cleaner, and makes more sense.

So generally, I'd have this PR be just the change in grill.php, sans the $aWaifus addition, and then create separate PRs for the rest of the bullet points.

Considering how you're a beginner at git, a tip: for PRs, it's preferred that you create separate branches for each enhancement or feature addition and not master, because as soon as you add another commit to master, it automatically gets added to the PR.

Read this tutorial to get a better idea on how to do a PR correctly: https://yangsu.github.io/pull-request-tutorial/

Have fun!