impactdevelopment / clientapi Goto Github PK

When Camera and ESP are active at the same time (and chat is not enabled) the ESP will render on the main screen, but using the camera's position.

It should be possible to test ClientAPI by running the example Client without having to setup the CDK with a dev build.

Attempting to run the client using the client-api_test module results in this uncaught exception: ClientInitException: Unable to locate the Client.json.

Please see the full crash log and run config.

src/test should include unit tests for each public class of clientapi. These should try to test that the API performs as expected and should be runable without minecraft being open.

This should be as simple as creating a test class for each class to be tested and using the JUnit API to test it performs as expected.

A new source set could be created for running the example client, which if set up correctly will probably fix #15

Currently dependencies and most other stuff is hardcoded into the cdk build.gradle. It would be nice if we could copy sections of the main build.gradle into the cdk template at buildtime, or alternatively use a gradle dependency object to get the values we need to inject.

How would I go about settings this up? Readme says instructions to be posted and yet there are none in any of the associated repos.
thanks

https://github.com/ImpactDevelopment/ClientAPI/tree/master/src/main/java/clientapi/load (near the bottom of the README for the Tweaker class information) doesn't exist anymore and just 404's (probably due to multiple branches existing now), valve pls fix

At least in single player, EntityDeathEvent isn't fired when EntityPlayerSP dies.

This may be because EntityPlayerSP is not ticked when it is dead, but since I've not looked into this that is pure speculation.

Tested against 2.1

In #9 We started implementing @Accessor and @Invoker mixins. Because it (appeared to) use less boilerplate, we added them to the wrapper interfaces (e.g. ICPacketPlayer) which works well, until you need non-accessor members on the interface, e.g. to add new methods.

Instead of using accessor interfaces where we can and wrapper interfaces where we must, we should instead be consistent and move all mixin stuff (including accessors) into the main mixin class, and simply expose them via the interface.

In order to remove Feather from this repo, we should distribute it on the Impact maven and simply list it in our build.gradle as a dependency.

ClientAPI should setup Continuous Integration (e.g. TravisCI, Jenkins, etc) to test commits/PRs and automatically deploy artefacts to a maven repo and GitHub releases.

It probably also makes sense to use a "proper" maven repo that can integrate nicely with CI artefact deployment.

I don't have any suggestions for a maven provider, but I know there are free ones available for OSS that use worldwide CDNs to speed up download.

This will go well with #17 as the CDK zip along with release jars would be automatically uploaded to a GH Release as soon as a commit is tagged.

LEFT is -1 and RIGHT is +1, which is inverted. This is demonstrated in Impact's HUD alignment, where right-aligned widgets like mod list and coords are initiated with LEFT alignment

Spotless is a cool code formatting util that can be easily integrated into build.gradle and configured for custom code formatting of different file types.

This will be usable as gradle tasks to check and fix formatting. I may also look into adding git hooks so the tasks are run when making a git commit.

If you want to be able to run the client from a notch obfuscated state, you will need to save a mapping for fields as well.

Raw MCP names are used in this example:
https://github.com/ZeroMemes/ClientAPI/tree/master/src/main/java/me/zero/client/load/transformer/defaults/TRenderManager.java#L32

You should probably store fields here:
https://github.com/ZeroMemes/ClientAPI/blob/master/src/main/java/me/zero/client/load/transformer/reference/obfuscation/MCMappings.java