LiquidBounce Forum

@moon No, you should join Guilded. LB development is beyond this world, imagine someone helping someone else code something till 8 am. Totally normal.

@moon https://github.com/CCBlueX/LiquidBounce/pull/1347

Is this good enough?

CzechHek opened this pull request in CCBlueX/LiquidBounce

closed [LEGACY] Inventory Management Rework #1347

@rufus said in Russian translation:

@WDIlsb russian on top from with love VietNam

@rufus That's a bold thing to say these days.

After all those recently rejected pull requests with "skidded" code, I came to the conclusion that this is the main cause of inactivity when compared with other forks.

Perhaps such code should be tolerated, if it gets modified to work within LB or even if it works better than original?

@Gabriel nah, just execute the same commands as with intellij installation and then open the folder with eclipse

@RiceUser Well Core along with any script that uses LB utils doesn't support versions after my kotlin ports of LB from like b76+.

@rthrthwtrhg
Ports to kotlin + removal of unnecessary @JvmStatic means that you have to access LB utils and fields with kotlin getters and static .INSTANCE.

In this case MoveUtils.INSTANCE.strafe(), but its arguments have also changed, you have to put a few booleans as well, look at MovementUtils source.

ScriptAPI should get its own built-in utils to simplify stuff.

@RiceUser https://github.com/CCBlueX/LiquidBounce/pull/1037#issuecomment-1531600493

CzechHek opened this pull request in CCBlueX/LiquidBounce

closed ScriptAPI additions, description fixes, ... #1037

@isnotpuppy

since everything is in kotlin now, you most likely have to do moduleManager.INSTANCE.getModule()
commandManager.INSTANCE....

however this may be subject to change in the future because the documentation doesn't show this and it's not good

@isnotpuppy Probably because of the kotlin ports, however this wasn't expected since:

https://github.com/CCBlueX/LiquidBounce/blob/legacy/src/main/java/net/ccbluex/liquidbounce/script/Script.kt#L59-L63

I will look into this.

@Gabriel Should taking code from forks of your GNU v3 repo be considered as skidding tho?

@cxtspnzwzd It's not that easy to add something into original LB because of its required coding standards, major changes wouldn't also get approved because there isn't any active development on the legacy branch. Many pull request take long to accept or jut get rejected.

@cxtspnzwzd The code of LB was pretty messy when I look back and I have been therefore cleaning it up this year which greatly improved it in my opinion. However, all of these forks have the old LB as their base with some much worse skidded code applied to them. It wouldn't be so easy to just copy and paste because of merge conflicts, different naming schemes and coding conventions.

@Gabriel said in Remember me?:

@CzechHek I started using LB when Hypixel fly still worked on both Jartex and Pika.

5 block expand, faster than sprint scaffold on CubeCraft, with 7 reach, flagless vclipping and hclipping and several infinite flights >>>>

@Rafay ok so you joined after the cross-version accident saying that you are new and don't know what it is and then 3 years later you are back trying to figure out if you are remembered as an og of some sort

and then you respond to marco

oh well, I actually don't remember you too! Are you like an OG in this forum??

@ybyyby_-awa said in The latest version of b78 cannot be started:

I'm very happy to fix the API bug, but I can't start it.

The "API bug" wasn't a bug, there just wasn't any reason for having @JvmField or @JvmStatic there anymore, after all, here is CCBlueX team's thinking process: scripts were not intended to use LB utils, therefore LB utils don't have to support scripts when being manipulated with. I wanted to make stuff compatible, but I agree that putting
@JvmField and @JvmStatic everywhere is not a solution. Therefore, scripts will have to adapt to code changes and no compatibility will be made. Actually, I just voluntarily broke all Core scripts probably, not mentioning the base itself.

It is possible, that possible built-in script objects that will return calls from LB utils might get added. You therefore wouldn't have to import stuff every time you just want to change targetRotation...

Now regarding the "vanilla" situation.
The cause of this problem is:
[13:50:29] [main/ERROR] [mixin]: Error encountered reading mixin config liquidbounce.forge.mixins.json: java.lang.IllegalArgumentException The specified resource 'liquidbounce.forge.mixins.json' was invalid or could not be read
There were major backend changes which might have caused this, however, this makes no sense to me, when I build the identical branch and run it, it works without any errors, same with running from IntelliJ.

@WaterFlex-Gaming I think it is CzechHekV4 or V3, you can autoinstall it using Manager script or also manually.
.m theme download CzechHekV4
.m theme load CzechHekV4

@ybyyby_-awa I see, you also need to put keepLength parameter because there isn't @JvmOverloads, so just:
RotationUtils.INSTANCE.setTargetRotation(rotation, 0)

from src:
fun setTargetRotation(rotation: Rotation, keepLength: Int = 0)

after my pr gets merged, the previous syntax should work just fine:
RotationUtils.setTargetRotation(rotation)