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)
This alternative implementation is theoretically 100% legit since this is based on changing the position/angle of the camera.
Demo: https://www.bilibili.com/video/BV1rv411N7SC/
The commit is here: https://github.com/commandblock2/LiquidBounce/commit/4d54b5a8e4b48dd68779678b22ee81f9b3aeb54d
I wrote this simply to prove this idea could work and this is currently not intended to merge to the official branch as there could be tons of improvement (
net/minecraft/client/render/GameRenderer.java:1043 (maybe) instead of in Camera class@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.
Same as Aftery I seldomly use the client recently.
But as of my experience I would use the latest b73 before cross version but that is quite out-dated as well. I didn't use the nextgen simply because of I couldn't have autoblock with multiconnect (I didn't even bother trying viafabric or to solve the problem but I've seen someone doing it).
Here is where you could see many forks.
https://github.com/CCBlueX/LiquidBounce/network
I just discovered this fork today and it seemed to be interesting.
https://github.com/hsheric0210/LiquidBounce
Updated 9 days ago.
This fork is not based on Nextgen but it's cross version so I guess many scripts may not work as well. But it seemed to have more than enough options. Maybe you could give it a try.
KillAura from hsheric0210: https://github.com/hsheric0210/LiquidBounce/blob/master/shared/main/java/net/ccbluex/liquidbounce/features/module/modules/combat/KillAura.kt
KillAura from FDP: https://github.com/UnlegitMC/FDPClient/blob/master/src/main/java/net/ccbluex/liquidbounce/features/module/modules/combat/KillAura.kt
@estiar-flynd
https://github.com/CCBlueX/LiquidLauncher/issues/7
You might need to compile it yourself or somehow pack the .deb yourself.
Or you could just use an alternative launcher like MultiMC5 or launch from Intellij Idea.
ModuleAntiBot = LiquidBounce.moduleManager.getModule("AntiBot")
filteredList = Java.from(mc.theWorld.loadedEntityList)
.filter(function(entity) {
// The function was private, you can use Reflector from Core.lib or you can manually setAccessible
return !Reflector(ModuleAntiBot).isBot(entity)
})
.filter(function(entity) {
// your code here
// EntityUtils ....
return true
})
This alternative implementation is theoretically 100% legit since this is based on changing the position/angle of the camera.
Demo: https://www.bilibili.com/video/BV1rv411N7SC/
The commit is here: https://github.com/commandblock2/LiquidBounce/commit/4d54b5a8e4b48dd68779678b22ee81f9b3aeb54d
I wrote this simply to prove this idea could work and this is currently not intended to merge to the official branch as there could be tons of improvement (
net/minecraft/client/render/GameRenderer.java:1043 (maybe) instead of in Camera class@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)