The changes have not yet been merged to the client's master branch, but are available in the "res-override" branch for you to preview. Unless there are any damning objections, I'll merge them to mainline shortly, and you can merge them from there.
Fundamentally, not much has changed, but there are three main additions to client (the third one of which may be slightly controversial).
1. A tool to fetch resource source code
Since a while back, resources with code also contain their source code, but this has never been documented or supported in any way. The client now contains a command-line tool that can be invoked to fetch the source code of a resource. Again, please see the documentation linked above for the details, but briefly, you can run something like this to fetch the source code for a resource:
- Code: Select all
java -cp bin/hafen.jar haven.Resource get-code ui/tt/name
That will put the source code in the src directory along with all the rest of the client source code, in the subdirectory appropriate for the package name the code uses, and as such, that code will compile along with the rest of the source code. Since the fetched code lives along with the rest of the client code (in the same classpath, as far as Java and JavaC are concerned), there should be no issues referring back and forth between it and the ordinary code without needing any reflection.
Note that there may exist some resources that don't contain source code (in which case the above command will complain). Such resources are simply historical artifacts of the fact that I may not have recompiled them since I added the ability for resources to contain their source code, rather than being intentional. If you happen to come across any, just report them and I'll recompile them.
2. A tool to check for updates
When you use the get-code command to fetch resource code, it will annotate the classes thus fetched with a FromResource annotation, containing the name and version of the resource it was fetched from. Along with get-code, there is also a find-updates command that scans all source files for such annotations, and checks the corresponding resources for newer versions. It would usually be invoked without any arguments:
- Code: Select all
java -cp bin/hafen.jar haven.Resource find-updates
It will simply list the resources which have newer versions, without actually doing any updates. That is simply so that you can check for updates without worrying about anything being overwritten. Just use get-code again to actually fetch the updates.
3. A mechanism to automatically let newer resources override local code
The resource classloader also uses the annotations to make it so that, if there is a newer version of a resource than that which the local code was compiled from, the code from the new resource overrides the local code. I realize this may be somewhat controversial, but the idea is to make custom clients more crash-resistant, if you will bear with me. The reason is because resource updates are sometimes incompatible with previously fetched local code, and as we've seen many times already, if the client is left un-updated, it may simply crash. Allowing newer resources to override local code should allow the client to continue running, albeit with degraded functionality, until its author will come around to update it. I do realize that there are also many resource updates that are not incompatible and will thus degrade client functionality unnecessarily, but I should think that occasional degraded functionality is better than outright crashes when incompatible changes do come around.
It should be noted that this override mechanism will also override local classes that simply don't have the FromResource annotation, as would obviously be the case with current extracted code that doesn't come via get-code. If you don't want to, you don't have to use get-code just to add the FromResource annotation; whenever this happens, the client will emit a warning (to standard error) which contains the name and version of the resource that is being used to override local code, so you can simply use the information from that warning to add annotations yourself.
Again, I do realize that this may be a bit controversial, and if you really hate it, there are ways to turn it off, both globally and more selectively (also desribed in the above linked documentation), but please consider that keeping this behavior probably makes your client more crash-resistant in the face of incompatible resource changes.
Also, inb4
How 'bout you just put all the code in Git and spare us the pleasure of your custom tools, ya doofus?
There are many reasons to keep the resource-code system. Some of them are purely for my own convenience, but the idea is that it's also for your sakes. If resource-code were simply part of the rest of the client code, then any time we push an update that incorporates new code, then all clients would just crash all around until they're updated. If you stop and think about it a wee bit, I think even you may come to agree that it's better that I can push some simple tooltip or harmless sprite or something without every custom client breaking until their authors get around to update them.
It should also be noted, that if you just want to use Git to manage merges and conflicts with resource code, there is a way to do so. It is described in the above linked documentation, so refer to that in case you're interested.
At the very least, I hope these tools will lessen the frustration a bit. I'm sure you'll let me know if you have any opinions about them.