I tried making the configuration "gradle run" but the run task does not exist. How do I run this?

When you ctrl + shift tele far distances (out of regions), it causes your character to appear as if it's moving in the opposite of your teleport.

Short distances are fine.

Video: https://i.imgur.com/fL9jYQy.mp4

Exception in thread "DefaultDispatcher-worker-4" java.lang.IndexOutOfBoundsException: Index 41199 out of bounds for length 41120
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
	at java.base/java.util.Objects.checkIndex(Objects.java:359)
	at java.base/java.util.ArrayList.get(ArrayList.java:427)
	at org.rsmod.game.cache.ConfigTypeList.get(ConfigType.kt)
	at org.rsmod.plugins.api.cache.map.collision.CollisionMapLoader.loadCollision-iqjYmvk(CollisionMapLoader.kt:127)
	at org.rsmod.plugins.api.cache.map.collision.CollisionMapLoader.load-UzMyBeg(CollisionMapLoader.kt:44)
	at org.rsmod.plugins.api.cache.map.collision.CollisionMapLoader.load(CollisionMapLoader.kt:36)
	at org.rsmod.plugins.api.cache.map.collision.Collision_map_plugin$1.invoke(collision-map.plugin.kts:8)
	at org.rsmod.plugins.api.cache.map.collision.Collision_map_plugin$1.invoke(collision-map.plugin.kts:3)
	at org.rsmod.plugins.api.cache.map.xtea.loader.XteaFileLoader.load(XteaFileLoader.kt:74)
	at org.rsmod.plugins.api.cache.map.xtea.loader.Xtea_loader_plugin$1.invoke(xtea-loader.plugin.kts:9)
	at org.rsmod.plugins.api.cache.map.xtea.loader.Xtea_loader_plugin$1.invoke(xtea-loader.plugin.kts:3)
	at org.rsmod.game.task.StartupTaskKt$launchNonBlocking$1$ioJob$1$1$1.invokeSuspend(StartupTask.kt:30)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)
[INFO] Feb 20, 2021 16:38:22 PM [main] Server$startup$1 invokeSuspend
 Loaded 16 plugin(s)
[INFO] Feb 20, 2021 16:38:22 PM [main] Server$startup$1 invokeSuspend
 Game listening to connections on port 54900

Process finished with exit code 130 (interrupted by signal 2: SIGINT)

Noticed some regions have object id's larger than the definition count.

Kyle E pointed this out to me last night so I don't know if he brought it to your attention or not, but I do believe CRCs can be negative and while the check if greater than 0 allows for not checking index 16 (as it is 0) means any client could write all CRCs as zero or negative and completely bypass the verification no?

I would submit that the greater than zero check adds more overhead than to simply just check that index 16 is 0 like it should be (20 checks if the value is greater than zero as opposed to just a single check for each CRC received matching).

These are the CRC that the 193 client sent as proof they can be negative (note this is printed client side - not after being read/after being written etc):
[-1173228978, -1157589397, -1212584219, -570258262, 1319113061, 268483285, 187074646, -353829414, -1052908534, -1247884930, -597431892, -608311250, -274006329, -1116086727, 153718440, -445574398, 0, -1481854411, -2029010792, 342059222, 2108672106]

In rsmod1 I use the RL cache libs to retrieve the CRCs as so:
val crcs = filestore.indexes.map { it.crc }.toIntArray()

And that resulted in matching CRCs just fine for me. While CRCs themselves are not inherently signed, the int data type of the variable they are residing in within the client is inherently signed and if you read using the same encoding the client sends then you should also be looking at negative values server side.

The attached code snippet should sufficiently verify CRCs for you barring all the above is true:
patch.txt

Do you have a client for me that works with revision 192?

Hello,

RSMod uses the libraries from OpenRS2 for cache/crypto/buffer modules. After commit openrs2/openrs2@e62941b OpenRS2 switched to using Guice 7.0 which is no longer compatible with javax.inject and is jakarta only.

The guice version could be bumped to 7.0 which would involve migrating the javax.inject calls to the jakarta injector.

The only other notable change outside of Jakarta to be up to date with openrs2 would be renaming XteaKey to SymmetricKey for the usages from the crypto module.

Alternatively the openrs2 dependencies could be forked. Or they could be pulled in transitively. I am not sure if gradle build constraints would work here.

What should be the resolution pathway for the project?