just remove the type C0FPacketConfirmTransaction then. Since JavaScript is a dynamically typed language, the type is determined at runtime. If the packet is a instance of a C0FPacketConfirmTransaction you can call getWindowId() and getUid() then if it is not, exceptions should be thrown.
//if (event.getPacket() instanceof C0FPacketConfirmTransaction)
packetConfirmTransaction = event.getPacket();
@asd-dsa
hmm actually in some cases (when the arrow is heading to the player's head/foot) it has a big possibility of not triggering it (should be able to fix it by checking intersection between 2 bbox).
Iirc it should have a horizontal speed mode, but it is annoying to lock the view.
The code is spaghetti, but I would try to improve it when I have time. (Probably in a few days)
@Max4K I think the compact part before recognizable code is from Core.lib of CzechHek (start from line 239). Which are just some imports.
Maybe the reason it didn't work was that he forgot to inline some libraries or some cross_version change (just guessing randomly lol).
Btw Hek's Core is licensed under unlicense so it should be fine by using it this way.
Interesting, the new forum seems to be a lot better than the old one. Markdown format, reply as a topic, seem to have a better experience than Luna on mobile, good looking ui, and even rss feed.
@NUMB
Actually u can,
The first step to do is to checkout the cross_version branch. (Default master branch does not contains any cross_version stuff yet)
just cd to the root dir of LB and git checkout cross_version. If u use your fork, you should know how to add a remote for it and how to use.
Look into the setting.gradle and you will see
rootProject.name = 'LiquidBounce'
if (System.getenv()['mcversion'] == "1.12") {
include '1.12.2-Forge'
} else {
include '1.8.9-Forge'
}
// include '1.8.9-Vanilla'
Which means you only have to make the environment variable mcversion equals to 1.12 then you can do gradlew build.
On *nix u need to use mcversion="1.12" bash ./gradlew build, I already forgot how to temporarily set a environment variable on Windows.
The jar will be at 1.12.2-Forge/build/libs/LiquidBounce-B73.jar
However I have not found a way to change environment variable in Intellij idea, because simple modifying setting.gradle takes less energy(still bad tho).
Btw last time when I compiled cross_version stuff I had to modify one import statment to compile, never tested tho(it was at this commit). There seemed to be more frequent commits lately, it might be ready to use in a short period I guess. (Spoiler: there is a new branch for 1.16.2-fabric, however there is no commit yet)
Edit: I tested and crashed when I tired to launch lol.
Edit: Crashing in splash screen does not always happens. I managed to launch once
@asd-dsa
Yes but the challenging part is to make it the blink way. This is definitely fine and good work. blink teleport is kind of holding the movement packets and sending them in a instant, but the current setPosition is more like the clip thing (some ac may flag you for speed).
If you want to have it this way you might have to calculate the positions of the position packets in advance (and probably lower the timer(< 1) after dodging the arrow in case the ac flags you for timer).
btw we can make the tp direction perpendicular to the velocity of the incoming arrow, and see left/right is closer. (This would be easier than blink and already in horizontalSpeed mode). Also left/right variable in that part might not be really left/right, it could be opposite.
Anyway the scripts was originally for trolling only, never thought someone would need it but I am happy to see someone actually used it.
Also +1 for the effort.
I do have one that(Projectlies+.js) is made for arrows and can only tp upwards or blockhit before the arrow hits you. Calculating snowball/egg trajectory might be similar as calculating arrow's. Part of the code is adapted from the Projectiles module from LiquidBounce. If you want one for eggs/snowballs, you can simply change the entity type to eggs/snowballs, and alternate the prediction. And make horizontal teleport. I am just too lazy to do that lol. (Would be grateful if you can make a pull request).
ALSO BEWARE THE CODE IS LICENSED UNDER AGPL-v3, WHICH MEANS YOU CAN'T OBFUSCATE IT BEFORE YOU GIVE IT TO OTHERS. AND IF YOUR WORK USES THE CODE OF IT YOUR WORK MUST BE LICENSED UNDER AGPL-v3 TOO.
ALSO BEWARE THE LICENSE OF LiquidBounce IS GPL-v3.
THOUGH I AM NOT A LAWYER, IN SHORT, THESE WORK MUST BE KEPT OPEN-SOURCED UNLESS IT'S FOR PERSONAL USE.
However, there are problems,I think(not verified) the server updates the arrow's position/velocity in a interval, which makes the trajectory look like this. (Yellow for history trajectory, blue for prediction.). (I am referring to the problem of the two arrows have different trajectory which is supposed to be the same.)
(screen shot from my video)
@IdkWhoMe he's saying that tpback option should be added. The original tphit send C04 to tp to the enemy and then send a attack, so the player is around the enemy. He wanted it to teleport back to the original position.
@chodeman
What I have been trying to do is to change
ScreenShotHelper.saveScreenshot(this.mcDataDir, this.displayWidth, this.displayHeight, this.framebufferMc)
to js.
Since it is in net/minecraft/client/Minecraft.java, the type of this is Minecraft (aka net.minecraft.client.Minecraft). And the instance of Minecraft is exposed as mc in scriptAPI.
So we change all this to mc.
But framebufferMc is not public so you cannot access it from a script.
So we accessing a private variable using reflection.
However the name of framebufferMc is not framebufferMc.
See about obfuscation.
You will have to use the Searge name(field_147124_at) to access variable and functions.
The file mcp-stable_22.srg have the mappings from MCP name to Searge name.
The reason you can use MCP name to in normal scriptAPI is because they did this.
But with Core.lib you don't have to do that anymore.
@CzechHek
THANK YOU BASED HEK. Don't have to look for srg name anymore.
And that should even solved the problem of using script in development environment, going to try it later.
@asd-dsa
it doesn't sound like some problem with your version, I think it's very much probably my fault. Will later look into it
@asd-dsa
I see, the version you used is the cross version. The script was designed for none cross version 1.8. Quite surprising it was still working with other mode. If you want to use that you might need to have extra modification since the cross version has some changes in scriptAPI.
Edit: But according to this exception, it seemed to be the one in render3D which should cause the whole script (anymode and the prediction) to break
Edit: nvm I was dumb this exception shouldn't affect might be other exception
@asd-dsa
quite weird, works on my machine. But usually in this case you can look into the logs to see if the script is spamming exception. The log should be at .minecraft/logs/latest.log
Idk if it only works on my build.
Edit: the snippet I posted in the last post was only to tell you what the new code is for, still recommended to pull the full script from github. This what has been changed actually.
@asd-dsa
now the script is updated with horizontaltp and horizontalmotion. The direction is perpendicular to arrow trajectory.
But there is not yet a check for tp into blocks, and still sometimes you could get shot. Might just going to look into FallingPlayer/Projectiles for reference.
Edit: hmm the it should be same as Projectiles but still strange, maybe later then.
the related code is here, but that is spaghetti anyway. you might want to give time the sin/cos since I think it might be a bit long.
if (dodgeMode.get() == "HorizontalTp") {
mc.thePlayer.setPosition(mc.thePlayer.posX + Math.sin(Math.toRadians(rot.yaw)),
mc.thePlayer.posY,
mc.thePlayer.posZ + Math.cos(Math.toRadians(rot.yaw)))
dodging = null
return
}
if (dodgeMode.get() == "HorizontalMotion") {
mc.thePlayer.motionX = Math.sin(Math.toRadians(rot.yaw)) // * 0.5 // or something like that
mc.thePlayer.motionZ = Math.cos(Math.toRadians(rot.yaw))
dodging = null
return
}
@asd-dsa
Yes but the challenging part is to make it the blink way. This is definitely fine and good work. blink teleport is kind of holding the movement packets and sending them in a instant, but the current setPosition is more like the clip thing (some ac may flag you for speed).
If you want to have it this way you might have to calculate the positions of the position packets in advance (and probably lower the timer(< 1) after dodging the arrow in case the ac flags you for timer).
btw we can make the tp direction perpendicular to the velocity of the incoming arrow, and see left/right is closer. (This would be easier than blink and already in horizontalSpeed mode). Also left/right variable in that part might not be really left/right, it could be opposite.
Anyway the scripts was originally for trolling only, never thought someone would need it but I am happy to see someone actually used it.
Also +1 for the effort.
@asd-dsa
hmm actually in some cases (when the arrow is heading to the player's head/foot) it has a big possibility of not triggering it (should be able to fix it by checking intersection between 2 bbox).
Iirc it should have a horizontal speed mode, but it is annoying to lock the view.
The code is spaghetti, but I would try to improve it when I have time. (Probably in a few days)
@idk-my-name Possible, but not doable. Use JNI, but too much work. Also itunes is botnet.
@phạm-phúc-hoàng
I have no idea of how to fix it. You might have to do it yourself if you want to use this branch, I have not yet look into this branch myself, and it is being actively developed, things might change. If you want to use the current usable version go master branch
The current branch of LB on github is nextgen branch. It is not yet a fully working build, but you can also try to fix it. If you are looking for the cross version one please go master branch. And if you are looking for the Legacy (aka non-cross version), there should be plenty of them but you might have to find it on your own although i do have a branch.