RicePigeon

I'm pretty sure this is classified as warez, which isn't allowed in this section.

Mamo and Mandibuzz are still usable in OU (Mamo is still like A- rank iirc) so its not like they're gone from the tier. Though the consensus seems to be that Mamoswine is really good in UU so far, I wouldn't be surprised if it ends up getting suspect tested.

Except Mega Gallade isnt OU, its BL, which means it can only be used in the OU metagame anyway.

Singles OU Update: Doubles OU Update:

No homo?

Mega Gallade is still good in OU, it just has competition from the other megas, which is why its usage decreased. The decision to drop regular Gallade from UU to RU was based on regular Gallade alone, since Mega Gallade is banned from all tiers except OU and regular Gallade pretty much sucks in UU. Its the same situation with Politoed, except replace the Mega Stone with Drizzle. If it wasn't for Drizzle being banned in all tiers except OU and Ubers, Politoed would be sitting in UU or possibly BL right now.

For the Gallade fans, they decided to quickdrop Gallade down to RU; Source: https://www.facebook.com/SmogonU/posts/10153275935247390

Screw that, I'll give you Koakuma without the Ko;

Fun or not, it was uncalled for, especially considering you were using it in a demeaning manner, or at least came off across as such. Not to mention I'm pretty sure I warned you in the past for doing the same thing before (i.e.: calling Wlanmania an infidel). Just because another user is annoying or makes bad characters does not give you the right to start flaming them, whether its in the shit thread or not. This goes for everyone on the forums. Do I make myself clear?

Singles UU Update Additions Added to Not Yet Ranked: Added to C: Rises : A+ -> S : A+ -> S : A -> A+ : B+ -> A- : B+ -> A- : B- -> B+ : B- -> B : B- -> B : C -> B- Drops : S -> A+ : A+ -> A : A+ -> A : A -> A- : A- -> B+ : B -> B- Removals Removed from C: Removed from D:

Jfc now you're just grasping at straws.

What the fuck? Even if something like that did exist (which it doesnt), why would you even need it? Just don't click the damn thing (its not like you can anyway, it'll just give you an error message stating you were banned), how difficult is that? Who's holding a gun to your head telling you to click the chat button or else?

Depends on which metagame Salamence is being used in. In OU its outclassed as a sweeper yet in UU and Ubers it can run either offensive or defense equally well.

@Laharl: Actually he did try to appeal to Alexei, who looked into the chat logs to see who was in the wrong. Needless to say, his appeal was denied. Look in the Staff section for the full explanation (since I doubt I'm at liberty to discuss them here).

Delving more into the original scenario to shed some more light, notice how I mentioned that using numbers that are factors of 1000 do not cause these problems. This is due to the fact that these numbers evenly divide into 1000. When we take an arbitrary value, such as 666, which does not divide equally into 1000, we have an incomplete wrap-around when we perform modulo division, so certain numbers appear more frequently than others due to this remainder. Since we know performing modulo division using factors of 1000 will provide an even spread of random numbers no matter what, we can actually combine these two methods; floor(X*(random%Y)/(Y*1.0) That *1.0 part at the end is important. Since (Random%Y) will return an integer value, diving it by another integer will produce an integer result. For the purposes of this RNG, we want to divide by a float value so that we get a float value as our result. Y, obviously, is our factor of 1000 (2, 4, 5, 10, etc). Of course, not all factors of 1000 will be appropriate in certain circumstances; floor(300*(random%10)/10.0) In this example, our RNG will return values ranging from 0-299, but because our actual random number spread is so small (returning values ranging from 0.0 to 0.9 in increments of 0.1), this RNG will only produce 10 values of 0, 30, 60, 90, 120, 150, 180, 210, 240, and 270. Thus, when using an RNG like this, be sure that your factor of 1000 is always greater than the number of values that you're looking for in your range of random numbers. Similarly, this same problem will also occur when attempting to generate a range of random numbers greater than 1000 values; floor(5000*random/1000.0) In this case, even the results of random will be too small to give us an even spread of values. So in cases such as these, try to keep your range below 1000 or seek an alternative PRNG for Mugen.

Posted this on MFG about a year ago, but realized I never posted it here, so here we go. Writing this up out of boredom due to one of my own personal experiences in MUGEN coding... Many times I've seen authors use modulo division to generate a spread of random numbers for whatever purpose (be it for AI triggers, random animations, or whatever). For those who don't know what I'm talking about, I'm referring to pieces of code like this: trigger1 = random%2 = 0 To understand why the above code is inefficient, we have to take a deeper look into the results its producing. For those who don't already know, in MUGEN, random generates a random integer from 0 to 999 (effectively producing 1 of 1000 different values each time random is called), each with an equal probability of being returned by random. With the % operator, such as in expression X%Y, we are dividing value X by value Y and returning only the remainder as a result. 17%10, for example, would return 7 as its value (17/10 = 1 R7). If we were to apply modulo division to random, for instance, we would be generating a random value from 0 to 999 and then dividing this number by an arbitrary value and returning its remainder as a result. By applying modulo division to random, we expect to see results that have an equal probability of being generated, as follows: Random%10 generates: 0 (10% probability) 1 (10% probability) 2 (10% probability) 3 (10% probability) 4 (10% probability) 5 (10% probability) 6 (10% probability) 7 (10% probability) 8 (10% probability) 9 (10% probability) As we can see above, we have a nice even spread of the 10 possible values that random%10 can generate. While this works great for numbers that are factors of 1000 (such as 2, 4, 5, 10, 20, 50, 100, etc), more arbitrary values won't be as neat and organized. As an arbitrary example, instead of 10 values, we try for 666 (which should return an even spread of numbers ranging from 0 to 665). The results are listed below: Random%666 generates: The problem should be immediately clear: the values ranging from 0-333 each have a 0.20% probability, while values ranging from 334-665 each have a 0.10% probability. If this were an even spread, we should expect any value from 0-332 to be generated only 50% of the time, but instead we see that numbers in this range are generated 66.6% of the time! If we were relying on a number being generated from this range, random%666 would be returning these values TWICE as often as the rest of the spread. The solution? Rather than using modulo division, we use the following: floor(X*random/1000.0) What this does is multiply arbitrary value X by random, then divide by 1000, then floor the result to produce an integer value. This results in a spread ranging from 0-X, but in a much more even fashion. Say we revise our above code to the following: floor(666*random/1000.0) generates: While this isnt foolproof, as we still have values that are twice as likely to be returned than the other values, you'll notice that the spread is much more even. Values ranging from 0-332 now have a 50% chance of being generated, as we would expect them to be, as opposed to the 66.6% probability we were generating before.

Gud Koa is best Koa

I didn't delete your thread, Seriously, just calm down before you start jumping to conclusions like this.

There is an ignore function, it's called not pressing the "Post Message" button in the chat. Seriously, nobody is compelling you to respond to every single thing that you see. Also this belongs in the Staff Action feedback thread, so moving...

You've probably heard of the term "Gill Effect" or something similar before if youve ever played any of the SFIII games; a character with an assymetrical color scheme on their body. In Mugen, attempting to replicate this would require a duplicate of every sprite with the reversed palette, but even then custom states cause a problem. With the ReMapPal controller introduced in Mugen 1.0, this can now be done easily with a simple controller. The idea is simple; using the new SFFv2 format, instead of duplicating each sprite, duplicate each palette and then remap the palettes with the new controller depending on the direction the character is facing. While this works in practice, it would seem than executing a ReMapPal controller conflicts with an earlier state controller; PalFx. To get an idea of what I'm talking about, here we have the same attack which puts p2 into a custom state that applies a PalFX controller to simulate being frozen. One is the default Kung Fu Man, while the other is my version of Eirin Yagokoro, who continuously applies a ReMapPal controller in her -2 state in order to simulate the Gill effect; Purely discovered by accident, I was easily able to find a workaround to this by, rather than continuously applying ReMapPal, instead only apply the controller when it needs to be. This can be done with a variable to act as a flag and compare it to the current direction the character is facing. If they do not match, only then should ReMapPal be applied, with the flag set to that facing value to avoid the controller being executed again until needed. This isn't a perfect workaround, however, as custom states that both apply a PalFX controller and repeatedly changing the opponent's facing direction may still cause the PalFX to end prematurely. This is mostly a heads up to anyone attempting to do something similar to this so that they do not make the same error.

To be fair, most programming languages are like that when it comes to their own versions of the random() function. Java & C++'s equivalents behave exactly the same way, its not something that's exclusive to Mugen. Also, for those wondering why I use floor(X*random/1000.0) instead of random%X, I've found that the former gives a much more even random spread than the latter, which tends to favor lower values, but I'll probably go more in-depth about that in another thread. EDIT: and here is

Alexei tempbanned him for a week starting early this morning. I see no reason why an admin would lie about something like that in the Staff section.

You were already on thin ice and you blew it. Kai gave you a warning to cut out the shit you had with NFS and you both ignored it, thus both of you were kicked and banned. Kai was the one who kicked you and the rest of us agreed a ban was necessary. Dont post like this

Small OU Update: Additions None Rises : A+ -> S : B+ -> A- Drops : A -> A- : A -> A- Removals None In addition, I also cleaned up the lower tier viability rankings of the Pokemon that moved up to the tiers above.