MAA Special Operation 30

Not much, but on the GroupBoss, you can lower the 5% requirement for a LB.  (This is helpful if you're having trouble breaking 5%, if your GB starts with 5% or less, or if your Hero  - ie: QS - is doing too much damage to get the LB reward).

  > In client, search for Dracula, make sure to find the GB one (should be around line 8000).  Change from 5 to 1.

Here's what I've tried so far on the GB and lockboxes.  If anyone can come up with alternate methods, I'm happy to collaborate.

1. Changed drops to guaranteed U-ISO.
     Result: Success (see previous posts from other users).
2. Increased GB's total health to return a crapload of silver.
     Result:  Success (see previous posts/threads).
3. Increased Hero damage to defeat GB quickly.
     Result:  Success (see previous posts/threads).
4. Decreased 5% Milestone to 1% (see above).
     Result:  Success.
5. Changed 5% Milestone reward from 1 LB to: 3-50 LB.
     Result: Fail. (Temporary success, but doesn't stay after refresh).
6. Changed drops to guaranteed: LB, comic cover
     Result: Drops successful, but ends up as a Fail (CVE).
7. Changed LB map rewards from 10LB/1LB to 3-50 LB.
     Result: Fail (does not recognize change, still returns 10/1).
8. Changed Victory loot table to return 5 LB every time (instead of 1 or 3)
     Result: Fail (does not recognize change, still returns random amount).
9. Changed the random loot when redeeming 1 LB to return a guaranteed unique cover (this would have allowed you to collect the LB Hero by opening a max of 8 LBs).
     Result: Fail (does not recognize change, still returns random loot).
10. Changed weights in various tables to return a guaranteed item (LB, cover, etc.)
      Result: Fail (does not recognize change, still returns random items).
11. Change comic cover IDs in the comic cover loot table to return a specific cover (this would have allowed you to collect the LB Hero by opening a max of 80 LBs - 10 at a time).
      Result:  Untested. I may try this after the Spec Ops is over and I start to get desparate; I didn't want to waste gold on a theory because it requires editing items0.xml, and those changes don't seem to get recognized.

What other methods have you guys tried?

I tried these methods, including the one mentioned Jarly, The only problem is that we are concentrating on the client.xml

I know, but that (and the missions) seem to be the only ones that register changes in the game.

Here's a thought, and I'm just thinking out loud here...  I took a look at the ab.xml, and saw a whole lot of "abTest" entries, which included "static" labels.  I've also seen "static" labels attached to many of the currencies.  I wonder if "static" is used to flag currencies to make sure their attributes don't get changed, and maybe ab.xml is used to A-B compare the client.xml (or items0.xml?) to make sure it's the same before and after.  Because when we make a change, it seems to register okay (ie: CPs or LBs drop in battle), but after the battle I think the game compares the results to the ab.xml file (or uses the ab file to compare to the server?), and if anything doesn't match, it returns a CVE.

Not sure that's really how it works, but like I said, thinking out loud here.  At this point, I'm in over my head, because I can't figure out how they're connected.
 

That's an excellent theory, actually. Sounds very plausible.

I fear, though, that even if this is the case, then the client side ab.xml is probably just a mirror of the server sided one and not actually useful to us.

If we go back to the early early days of the game, the few hacks around were very powerful because PD hadn't put much resource (if any) into security measures. Back then, you could make Command Points drop during battle, and we all know of the original Force Drop that could drop any item. PD have been gradually shutting down these hacks by (I assume) adding more and more game mechanics to server-sided validation after they got aware of the game's popularity and the hacking community behind it.

ab.xml may have been editable back then, since PD probably hadn't considered it necessary to tie server validation on it, just like it was the case with many other things. But can't hurt to try.

As a tip, you need to SEND "valid" information. It's possible to write a rule for Charles which will change all errors to 0 and all successes to True. This doesn't make anything count, it just stops the forced refresh. The server; however, will record incorrect information, and not save anything.

I believe you're correct, and to augment that, we need to find out how to forcibly validate the information.

True.  But I wonder why they still load ab.xml on the client-side if it doesn't do anything.  (Same for items1 and items0).  Maybe it's loaded on our end as a preliminary check, so that the game isn't constantly checking back to the server for every little thing?

 

Aye, there's the rub.  I suspect, that on some of the ID swaps, we're simply not updating the code correctly.  What I mean is, each item has: an <itemID>, an <itemCollectionID>, and a <rewardID>.  I think somehow we're not changing everything completely and the game returns an error (much like if we forgot to close a tag).  Is there another reference that needs to be updated (or that can be updated on our end)?  I wonder how much of our efforts are actually being stopped by PD's security measures, and how much is us missing something...