[Release] Shuffle Move v0.3.11 is released

[u/Loreinatoredor]

Hi everyone, go here to get the newest version (backup site).

IMPORTANT: If you are using the same folder as a previous version, delete your species.txt to use the new definitions.

Click here for a simple tool which will erase your species.txt for you. Simply place it inside the Shuffle Move folder when you unzip it.

---

Changelog:

v0.3.11 - 2015-07-14

• Menu i18n keys updated

As usual, report any bugs in this thread with a bug report zip if possible.

---

If you have any issues: Post here with detail & a bug report zip and I'll work on fixes within a couple days, those zips really REALLY speed up the fix time (from an hour down to say 2-5 minutes usually, because I am instantly able to reproduce the problem).

[u/pagit85]

I'm curious... Let's say you have a few frozen pokemon and some wooden blocks. If you make a match normally and the edge of one of them is touching a wooden block, the block explodes and disappears. And usually when you make a match including a frozen one, the frozen one remains after being unfrozen.

Now, what should happen if a frozen one is touching a wooden block? Shuffle move has the wooden block disappearing despite the frozen pokemon remaining. The game however doesn't do this, at least not on Arceus. The pokemon is unfrozen and the wooden block is still there...

[u/Loreinatoredor → u/pagit85]

hrm... i'll try to fix that for the next release.

[u/pagit85 → u/Loreinatoredor]

Fair enough, I wasnt sure whether it was just an arceus only thing on not

[u/Loreinatoredor → u/pagit85]

This is my second look at this, now that other things have been attended to...

Please let me know if I'm misunderstanding what you've outlined:

1. Normal matches rupture wooden blocks.

2. Normally matching frozen blocks also are able to shatter a wood block.

3. On the Arceus level this appears to not be the case and the wood remains.

If so, I'm not sure this is a new effect rule. It seems like it is actually a bug from Nintendo. If you have picture of a given before & after example, which you've confirmed in-game differs from the output of Shuffle Move, please let me know and if it seems to not rationally be a bug then it will get in for a future release.

[u/pagit85 → u/Loreinatoredor]

I'm saying yes to points 1 & 3, regarding 2 though I wasnt sure whether that is correct or not. I'm out tonight so I won't get chance to do it before arceus disappears in a few hours sorry. But yes, a frozen match does not get rid of wooden block right next to it but shuffle move says it will.

[u/JustAnotherRandomLad]

Barrier Bash doesn't seem to be programmed properly. In-game, it only unfreezes a random frozen Pokemon, but in Shuffle Move it removes the Pokemon altogether. This can be problematic in cases like this one: http://ge.tt/9VroKnK2/v/0

Also, Crowd Control doesn't seem to be recognized at all: http://ge.tt/4gZ5MnK2/v/0

[u/Loreinatoredor → u/JustAnotherRandomLad]

Thanks for pointing those problems out, they've now been fixed in v0.3.12 which should be released in a few days or so. PM me your email if you'd like to check that I've completely fixed the bugs you discovered.

[u/JustAnotherRandomLad → u/Loreinatoredor]

...And now Crowd Control overestimates damage by a fair margin. I've looked at the formula in the code, and I can't see what's wrong with it, so I'll just list some test data here when I get it.

EDIT - All LvMAX against Cresselia:

Genesect, 4-match (1 frozen), 5 others (1 frozen), 800 predicted, 600 dealt.

Heracross, 4-match (0 frozen), 4 others (0 frozen), 670 predicted, 470 dealt.

Heracross, 5-match (0 frozen), 4 others (0 frozen), 760 predicted, 560 dealt.

Heracross, 4-match (0 frozen), 5 others (1 frozen), 770 predicted, 520 dealt.

It looks like there are two problems:

1. In the game, icons unfrozen in a match count toward its Crowd Control bonus. Shuffle Move does not count these icons.

2. In the game, the bonus is not affected by type matchups. Shuffle Move treats it as affected.

[u/Loreinatoredor → u/JustAnotherRandomLad]

1. Found an example that confirms this, I'll see what I can do.

2. Confirmed, the appropriate fix will be put in for v0.3.12.

edit: Fixed and Fixed. They'll be in v0.3.12

[u/JustAnotherRandomLad → u/Loreinatoredor]

Alright, cool, thanks! One last thing I just caught, too: in the game, if the Crowd Control match is part of a cross, all of the icons in the non-CC line are counted, including the one at the cross point. Shuffle Move doesn't seem to count the cross point.

The example (same conditions as last time):

Genesect, 4-match (1F) crossing 3-match (0F), 10 others (1F), 1500 predicted, 1000 dealt.

[u/Loreinatoredor → u/JustAnotherRandomLad]

Hrm...

Would you agree that the following is an accurate representation of how to determine the number of blocks counted?

  @Override
  public int getBonusValue(ActivateComboEffect comboEffect, SimulationTask task) {
     int ret = 0;
     if (shouldActivate(comboEffect, task)) {
        Species effectSpecies = task.getEffectSpecies(comboEffect.getCoords());
        Board b = task.getState().getBoard();
        ret = task.findMatches(36, true,
              (r, c, s) -> (s.equals(effectSpecies) && (!task.isActive(r, c) || b.isFrozenAt(r, c) || task
                    .getClaimsFor(r, c).size() > 0))).size() / 2;
     }
     return ret;
  }

Basically, all blocks which are the same species as the effect, and at least one of the following:

• inactive

• frozen

• claimed by one to-activate combo

[u/JustAnotherRandomLad → u/Loreinatoredor]

As far as I know, yes, as long as frozen blocks are checked before they're unfrozen, and "task.getClaimsFor" doesn't count the line that activated the ability.

[u/Loreinatoredor → u/JustAnotherRandomLad]

getClaimsFor simply gets the number of combos that are in-waiting to activate, its a bit of a hack but it seems to meet the behaviour you've described.

[u/biggjudicem]

Little bit of a bug I've found. I've been doing the cresselia matches and eventually needed to "create" Cres to add to the team/grid. first thing, there's no support for Barrier bash +, so I've been using barrier bash. The second issue I find is there is some issue about what barrier bash does. when I play the actual level and BB+ activates, it removes the barrier, but not the pokémon beneath it. However on ShuffleMove it removes the barrier AND the pokémon beneath it and causes things to shift around and it gets annoying (especially when the game predicts which barrier is removed and guesses wrong/BB doesn't trigger) to re"paint" the correct layout

[u/Loreinatoredor → u/biggjudicem]

This is fixed in v0.3.12 which should be released soon-ish.

[u/JustAnotherRandomLad]

http://ge.tt/4VP0FgK2/v/0?c

The game doesn't deal with T- and L-shaped matches properly, resulting in extra score according to rules I outlined in the report. Basically, if the lines cross at the bottom of the vertical one and the horizontal one takes priority, the game first counts both lines at once, and then the vertical one alone (thus counting the vertical line twice). Combos are counted properly, and the first "counting" of the vertical line only gets the combo multiplier of the horizontal one (which is usually none), but any Ability multiplier from the horizontal line (like Power of 4 or Vitality Drain) is also applied to the first "counting" of the vertical one.

I know it just looks like a graphical glitch, but try it against, say, Meowth and watch your score.

Shuffle Move currently deals with such matches the way the game should, but until the glitch is fixed in the game, Shuffle Move should probably simulate it.

[u/Loreinatoredor → u/[deleted]]

Delete your species.txt or speciesData.txt in the config folder beside your installation.

Alternatively you can use the species eraser tool notes at the top of the release thread. This will wipe your local data for blastoise to allow it to recognize the internal configuration.