MAA Special Operation 30
Spec Op 30
RE: MAA Special Operation 30 Posted on: 11/13/2015 5:48am
Quote Post
take it easy
Gillman Posted on: 11/12/2015 11:53am

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 revel in my anonymity. But when I'm at a specific event and gamers are there, they'll recognise me.

RE: MAA Special Operation 30 Posted on: 11/13/2015 3:18pm
Quote Post
Ahssherder Posted on: 11/13/2015 12:48am

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.
 

RE: MAA Special Operation 30 Posted on: 11/13/2015 11:05pm
Quote Post
Gillman Posted on: 11/13/2015 10:18am
Ahssherder Posted on: 11/13/2015 12:48am

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.




 

RE: MAA Special Operation 30 Posted on: 11/15/2015 9:52pm
Quote Post

client2.swf may also do a part in validation of values

RE: MAA Special Operation 30 Posted on: 11/17/2015 5:11pm
Quote Post
A1 to A0 architect.

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.




atdt *67
RE: MAA Special Operation 30 Posted on: 11/18/2015 12:30am
Quote Post

jessica jones is comming spec op 31.. :)

RE: MAA Special Operation 30 Posted on: 11/19/2015 3:14pm
Quote Post
fathead Posted on: 11/13/2015 6:05pm

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.


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?

 

jarly Posted on: 11/17/2015 12:11pm

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.


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...

RE: MAA Special Operation 30 Posted on: 11/19/2015 4:10pm
Quote Post
A1 to A0 architect.
Gillman Posted on: 11/19/2015 10:14am
fathead Posted on: 11/13/2015 6:05pm

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.


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?

 

jarly Posted on: 11/17/2015 12:11pm

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.


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...


In client2.swf, there is a section called "Offbeat". I believe this has something to with issuing errors. Also, nice Hamletting.
 




atdt *67
RE: MAA Special Operation 30 Posted on: 11/19/2015 7:47pm
Quote Post
jarly Posted on: 11/19/2015 11:10am
In client2.swf, there is a section called "Offbeat". I believe this has something to with issuing errors.


I wouldn't think a .swf file would affect the game function.  I thought it just handled animation.  (Though I'm not real familiar with swf code, so I could be wrong).  I'll give it a look and see if I can make heads or tails of it.
 

jarly Posted on: 11/19/2015 11:10am
Also, nice Hamletting.

;)  I've got a thing for a well-placed quote, movie line, etc.  (and by "thing", some might call it "mental issue"!)