-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathTODO.txt
86 lines (59 loc) · 4.69 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
DONE - create a way to auto-generate a javadoc for methods based on param comments
DONE - bspkrs - add undo/redo commands for all members
- The top group (currently admin) should ONLY be defineable in the config file. As of now, it is not possible to have an admin group that can't run dangerous commands like sqlrequest.
- better concurrency for throttling... seems like if multiple people are getting throttled messages it blocks the bot from sending messages to others
DONE - add nickserv auth success detection and move channel join to there (unless nspass is not set)
DONE - commit workflow
- info commands
- DONE - unnamed members in a class
- DONE - change history
- DONE - staged field view
- DONE - staged method view
- DONE - staged param view
- DONE - automatic export of CSVs periodically
- STARTED - create wiki pages for new bot:
- naming conventions* we really need this
- how new commands differ from old bot
-
- DONE - commands to list class members: listf listm?
- DONE - set params should warn when there is a field with the same name within scope
- DONE - set params should prevent names that can conflict with JAD-style naming of local fields
IN PROGRESS - web interface (started on a Django project)
- provide a way to view staged changes
- possibly allow editing using some sort of bot-generated session URL
DONE - cache long lists of results per user and add a command to display more of the list (!more)
- a class summary command (cs) that would list all methods/fields in summarized format
^ this is now possible using the new find functionality
- find something by date
<LexManos> !gf enableEverythingIsScrewedUpMode 20140930 20141130
<Cazzar> search by mapping I asssume?
* Rankine has quit (Read error: Connection reset by peer)
* Quetzi is now known as Quetzi|off
<LexManos> ya, search for the new name of something that changed mapping between the two specified snapshots
suggestions from xaero:
Feature #1) Migration helper
I wrote a python script that helped me to migrate mappings and comments from 1.6->1.7. It would take two arguments, new 1.7 srg name, and old 1.6 mcp name, and it would prepare a set of 'set' commands to migrate mappings. I would manually clean up any comment formatting before pasting into an MCPBot dcc chat. Can the bot streamline this somewhat?
USE CASE #1) No problems with the old name/comment
> migrate do newsrg oldmcp oldversion
USE CASE #2) There was a typo/problem
> migrate show newsrg oldmcp oldversion
- 1) the bot shows the necessary set command -
scf newsrg oldmcpname oldmcpcomment
- 2) the user makes changes
- 3) the user submits the command
> scf newsrg oldmcpname_revised oldmcpcomment_revised
You can of course specify the grammar however.
Feature #2) Changelog
I wrote a bash script that would generate a changelog of changed fields/methods from MCPTest every time I ran the script, in the dual-column format of `diff -y --suppress-common-lines old.csv new.csv`. The old MCPBot has 'getlog' but the output isn't ordered, nor can you restrict it. It would be nice to specify a range, e.g. last 30 changes, or all changes within the last 3 days, or a combination thereof.
Feature #3) Not yet migrated MCP mappings
Another script of mine generated a diff of mcp names that were in 1.6, but not in 1.7 latest. This should be much simpler with the data in a DB (exclusive left outer join).
Feature #4) Not yet migrated comments
Sometimes people set the correct MCP name, but 'forget' the comment from the previous version. This command would be semi-automated, allowing the reviewer to correct any javadoc mistakes before committing (like feature #1 perhaps).
Feature #5) SRGs without MCP names
I planned to make something that would make a report of what classes were yet to be mapped, and ranked by percentage. This is to help decide what to deobfuscate. This might be more appropriate for your MMV than the bot, but it'd be nice for the bot to do it all.
In a similar vein, maybe a dumbed down version where you can list the fields/methods for a class, with output ordered.
Feature #6) Synchronize client/server - NOT NEEDED
Feature #7) In-demand MCP names that don't exist
This is to direct deobfuscation efforts to SRG fields that are in-demand, and do not yet have MCP names. Currently, the only way I can think to implement this is to log all of the get queries (anonymously, of course), and generate reports.
Feature #8) Conflict resolution
Already discussed on IRC, but it bears repeating. Fields/methods, as well as classes. If precedent rules, at least log the attempt (this might not be appropriate for the bot though).