Closed GRAYgoose124 closed 4 years ago
https://github.com/Owyn/PacketsLogger I hope you mean this one with easy to understand packet content visuals (also would be seen which defs are wrong by values or which are missing and needed),
Then try to log a sequence when you successfully dismantle some fishes manually without any interference and try to replicate that with the proxy interactions, then see where it goes different ( with WinMerge or some other synchronized two-tab text scrolling)
And yea, GUI sometimes would just ignore and not display changed stuff or display it wrong because you do it via proxy commands and not your mouse clicks (example: multiple bait crafting)
Problem with adding fish might be related to reworked inventory-pockets system (or not), try adding fish via your mouse and log to see how it's succeeding, and then see how it's done via proxy command and what's different
Owyn, what I noticed is that the server is using, when doing it through normal play, C_REQUESTCONTRACT.2 and S.2. not the .1 def. Looking at defs clearly just renaming except for one int ->uint conv, which for most numbers really shouldn't matter(like contract IDs). I'm just using debug logger and python script to decode the hex after separating by spaces at guesses of what the data might be. also have packet finder but seems I have very few undefined defs (and at least according to debug logger 0 bad defs). maybe I'm getting a contract, but it's not a valid dismantle...but it opens dismantle window and I have a server given ref...
That's a nice logger, will do. Also, just notice you're THAT Owyn. In learning proxy you became famous :)
As I figured. Changing to .2 did nothing. Still opened dismantle(I had to make sure to use 90 instead of 89 since dismantle is different for each contract...Hower the server is using two... Next step, use a real logger like yours instead of manually trying to decode the packets. I may look into the UPDATE_ITEM def too.
Thinking the process is:
'C_REQUEST_CONTRACT (type: 90)
C_RQ_START_SOCIAL_ON_PROGRESS_DECOMPOSITION
C_RQ_ADD_ITEM_TO_DECOMPOSITION_CONTRACT x 20
C_RQ_COMMIT_DECOMPOSITION_CONTRACT
If not, maybe you can tell me if .1/.2 would really matter in this case where it's just a diff in typedef uint/int for something that will never overflow into the negative bit. Edit: did that and also tried converting to .2. .2 did something strange in that it did the same thing (with the right data changes) but server response was much slower each time and I still didn't get the same response that I did when I procc'd the same event myself.
For anyone working on this, here is the dismantle you need to match as of NA97.03.
<---- Hook ENABLED ---->
[7:17:4:667] -> C_REQUEST_CONTRACT (id 34899)
[7:17:4:755] <- S_REQUEST_CONTRACT (id 26994)
[7:17:5:799] -> C_RQ_ADD_ITEM_TO_DECOMPOSITION_CONTRACT (id 64765) x 20
[7:17:5:860] <- S_RP_ADD_ITEM_TO_DECOMPOSITION_CONTRACT (id 44640) x 20
[7:17:7:333] -> C_RQ_COMMIT_DECOMPOSITION_CONTRACT (id 65461)
[7:17:7:333] -> C_RQ_START_SOCIAL_ON_PROGRESS_DECOMPOSITION (id 60518)
[7:17:7:450] <- (id 61968) S_RP_COMMIT_DECOMPOSITION_CONTRACT
[7:17:8:607] -> C_CANCEL_CONTRACT (id 50022)
[7:17:8:676] <- S_CANCEL_CONTRACT (id 56496)
<---- Hook DISABLED ---->
In the original code, for the ADD_ITEM, it uses id, but the new def uses itemid. This was the problem. I do have my code forked for anyone interested, but be warned, it is being re-written for my readability and my usage and you need ops/defs.
If you don't want to fork the project, you could just pull a request with changed code so it'd still be all here (but fixed)
i'm a lone coder so very bad at using git. (Learning the habit! been a programmer for 20 years, but all solo shudders, I mean I know all the basics just merge/rebasing/conflict res takes google-fu) For my purposes, I'm not a programmer for a job, but for personal tests/automation, but I need to work on collaboration skills. In the languages I know fairly well I try to stick to the guidelines, but also I don't forget my code/need comments(they just get in the way even years later I can look at 20k codebase and ~10 minutes be right in the mindset as if I just wrote it, it's how my memory works, good for logic, bad for rote) Which ofc was perfectly fine for lone coding, when only I need to read it, so optimizing formatting for my ingestion makes sense, but I knew it would be a problem that would bite me and it's hard to unlearn.
I tried forking and rebasing(but lke I didn't start committing until merge had no chance, if I had i would have done a pull request... But also I'm not a nodejsdev/good at team collab) Anyways I do have a fork, it's just as you know the code won't help if they dont get the defs/ops themselves...That's why I'm hesitant, I don't wanna be in Lambda's position, I already aptched the code and will keep it maintained for NA, not my probem to deal with ops...
Edit: Check my fork for a working NA97.03 version for anyone interested, but be warned, it is being re-written for my readability and my usage and you stll need ops/defs as usual. In reality, this repo just needs i believe a few struct key updates and a slight modification to the pattern. You also need to disable tera-proxy's blacklisting...Just follow the bugs..
Hi, I've patched and reworked this for current release. Everything works except dismantling, however I get a contract, and I get server response successes for C_RQ_ADD_ITEM_TO_DECOMPOSITION_CONTRACT.
It's opening the disassemble window, showing these thigns are being added to the contract the server provides. However, the window itself nor inventory updates(tbh dunno if it should given we may be bypassing a gui update) but in game, it simple says "This item cannot be dismantled." Which I presume comes from trying to dismantle nothing.
Here's an example of my console logging. Added a bit more since I have refactored the code quite a bit so that it's a little more obvious. this is with 1 slot left so it catches one and immediately goes into decomp pattern. You'll notice it adds 20 fish to the contract it gets from request contract, it commits that contract, but then the total fish remains the same on next iteration. Perhaps there's a hint in that I get S_RP_ADD_ITEM(that's coming from a raw hook just logging all of them...could be from me dismantling one to do the test again... It's up top but none after the actual C_RQ_ADD_ITEMS? This makes me believe i need to do some packet sniffing and it is again the pattern that's the problem.
here are the ops for these anyways:
I'm on tera NA97 I think. As loking i noticed there's an S_RP_UPDATE_DECOMP def, maybe that's part of the new DECOMP pattern?
Still using his code for adding items to decomp contract:
Anyways, anyone have a clue on the disassemble pattern as of now or has fixed it in lmf themself? When I get it working(using debuglogger/alexpf to analyze game generated dismantle sequences) I'll consider forking, but farm bots in the end need to be self-maintained...I couldn't see how it could be the opcode if i'm getting a contract id response, but maybe some probelm with the ADD_ITEM op or def but it's not a bad def(decodes properly) and goes into the dismantle loop instead of the "evil people" loop that Lambda mentioned was indicative of opcode probem.