RicePigeon

Do water guns count? If so...

Sorry for the lack of activity but here are the November UUbers tier shift update:

The following Pokemon are now allowed in UUbers:

The following Pokemon are now banned from UUbers:

A few tier shifts:
: B -> A+
Now with White Kyurem gone, Reshiram is back to its former glory.
: Added to B
Basically Blissey 2.0

: B -> C
Now that Chansey is allowed, there's really no reason to use this thing other than its "slightly" better offense presence (which is still pretty bad by UUbers standards).

I like to believe that Clownpiece isn't mocking Americans, per se, but rather is ZUN's attempt at political commentary towards the American government, especially when you take into consideration the mass surveillance programs that have been going on and the fact that Clowpiece is Hecatia's servant, who is the goddess of Hell (Illuminati confirmed lol).
Or I'm just overthinking things :p

Flandre released.

Flandre released.

I wasn't referring to this collection, I was referring to the Pokemon sub section under the Gaming/Nintendo section

Stay on topic, please

Stay on topic, please

This topic suddenly reminded me of this:

Hard to believe this thing was made 8 years ago

This topic suddenly reminded me of this:

Hard to believe this thing was made 8 years ago

Link: http://ricepigeon.webs.com
Sakuya Changelog:

Link: http://ricepigeon.webs.com
Sakuya Changelog:

Link: http://ricepigeon.webs.com
Sakuya Changelog:

Because they're not Sega, Namco-Bandai, or Capcom characters and would require substantial licensing fees.

Because they're not Sega, Namco-Bandai, or Capcom characters and would require substantial licensing fees.

Because they're not Sega, Namco-Bandai, or Capcom characters and would require substantial licensing fees.

So after looking at various AI tutorial and code, I've noticed a major flaw in almost all of them that remains unaddressed.
 
For anyone who knows Mugen code, you should know that Mugen processes states in a top-down fashion. What this essentially means is that for each state controller in a character's state, for every tick that character is in that state, Mugen will process each and every state controller in order. Take for example the following code snippet;
 

 In this case, the Changestate controller is always processed before the Varadd controller, even if the Changestate controller doesn't actually change the character's state. Therefore, once the character reaches time 20 in state number 200, assuming that var(19) is initiated to 0 at the beginning of the state, Var(19) will be set to 19 by the time the character exits state 200 (the Varadd controller will never activate at time = 20 since the character will have already left the state by then. Note that there exists a bug in WinMugen where the Varadd controller will still be processed at time=20, even though the character will have already left the state by then.).
 
This processing order applies to all states, including the negative states -1, -2, and -3. Now let's take a look at an AI code snippet with this in mind.
 

 

Considering the identical conditions, we look at both controllers and see that when the conditions are right, and see that both have a 50% chance of sending the player into either state, at least thats what it looks like on the surface. Remember the top-down processing order I mentioned before? With that in mind, lets follow the code again. Lets assume the conditions are right. We see that Shoryuken has a 50% chance of occuring on the first possible tick. But what about that other 50%? That other 50%, we check for the Hard Punch, which itself has a 50% chance of occuring. This means that we have a 50% chance of using our Shoryuken, a 25% chance of the Hard Punch, or nothing at all.

If we want the AI to give the illusion of a human player, we want those odds to be roughly equal, so as to keep our opponent guessing like they would against a human player, as opposed to a predictable scripted AI. While it's impossible to make an AI that performs exactly as a human player would, we can at least remove the above problem from the equation. To do this, we need to take advantage of State Trees.

For those of you who aren't computer science geeks, a state tree is basically a graph of all states that a state machine, such as a mugen character can be in, and all possible outcomes or paths that machine can take. In our example, since we want to script our AI so as to not be so predictable, we want our AI to be able to perform several different options when conditions are right. For example, say the conditions are right for us to use an antiair attack, such as when an opponent is jumping in, we want to be able to do one of the following;
Shoryuken Hard Punch Dash backward Roll forward Jump up If we followed the pattern of the AI code snippet above, these five different actions would each have a split of 50% - 25% - 12.5% - 6.25% - 3.125% in that respective order. Ideally, each of these should have a 20% chance. Thats where this code comes in;

First, in your -2 state, make sure to add the following controller;
 
 


This will spawn a helper that will make all AI based decisions for us. The idea is that we are going to have the helper look at all possible conditions, look at a list of all possible states our character can go in to, randomly choose one and pass it back to the player. Now, inside our helper, we'll have the following code. We'll go over each one step by step and explain what they do.
 
 

This section contains the required Statedef for our helper state, and makes it so that the helper is always bound to the player and facing the player's direction. This way, we can simply call certain triggers without the need for redirection, such as p2dist x, pos y, and so forth.
 

Our helper's RNG. Basically, our Helper will be producing a constant stream of random numbers each tick to be used for state selection. The reason we don't simply call random in each instance is because random reinitializes itself every time it is called. If you don't understand yet, don't worry, as this will make more sense later on.
 


This is the meat of our AI decision making:
<conditions>: refers to the set of triggers you would normally put in your AI's state controllers, such as p2dist x, statetype !=A, and so on. <number of outcomes>: refers to the total number of possible outcomes you want for your set of conditions. In our above example, we have a total of 5 outcomes, so this would be set to five. <stateno of outcome #X>: this is the stateno for each of your possible outcomes In this case, var(0) is the random number that we stored earlier. Var(1) stores the state number that we wish to pass back to the root. Var(2) is merely a flag for when we want our AI tree to decide which state to go to next, and dictates how long to hold that value for before we regenerate another outcome. We dont want to generate a stateno if we already have one generated. In this setup, higher AI levels generate outcomes more frequently, providing for quicker reaction times. Here is an example of this block of code in action;
 

 
 


In this above example, we have five possible states that our AI controlled player can go into when the following conditions are true:

    player 2 is lying down
    player 1 is not attacking
    player 1 is not in the air

For each set of conditions, such as antiair, a certain distance between p1 and p2 is reached, etc, you will repeat this process for each set of states. Let us continue.
 
 


This piece of code is what allows the helper to pass the stateno back to player 1 once the meat of the work is done.
 
 


This piece of code counts down Var(2), which doubles as a buffer. Once Var(2) reaches 0, we can generate another stateno for our root player. When this happens, we tell our root player that we do not currently have a state generated by setting the value to 0 (or any other sentinel value of your choosing).
 
 


This destroys the helper if the player is not under the control of AI, since the helper is no longer necessary.

We're almost done. Go back to your CMD file, and under each Changestate controller where you would normally add your AI code, change each one to include the following:
 
 


Basically your global conditions, such as statetype, cancel ability, power requirements, etc should be moved to triggerall. Your trigger1s should be everything related to human control. For the AI control, remember Var(58), which we used to pass the stateno value back to player 1? This tells the player to change to that state ONLY when Var(58) is the same stateno value as the one in the controller here. In this case, this tells player 1 to only change to state 220 if the AI helper tells us to. You would repeat this for every single changestate in your CMD file.

http://i.imgur.com/gaWR2Rp.pnghttp://i.imgur.com/pCwU2aK.png
 
link: https://ricepigeon.neocities.org/

It had to be done

I put "Ayy Lmao" as my name on MEGA over 5 years ago and I haven't had any problems as of yet

I put "Ayy Lmao" as my name on MEGA over 5 years ago and I haven't had any problems as of yet

I knew something was up when loading this character in Fighter Factory 3 caused it to crash, turns out the issue was because, despite being a 1.0 character, it had palettes assigned as whitespace (ironically, a certain Pachirisu by "another" author had the exact same issue).
Anyway, the character has a mess of issues, including no damage dampening, resulting in meterless combos that can easily deal over half the opponent's health, and supers that can hit opponents during superpause. Considering the last part of the previous paragraph, I'm not sure if it's worth delving deeper into this character.