The hexvr from nanorasmus

First few spells can leave behind their info

When in a singleplayer world, drawing patterns in the air act like normal, but when a spell is properly cast, sometimes the info from previous patterns stick around mid-air, obstructing block placement, as well as being visible through blocks. Relogging removes them but they tend to happen with the first succesful spell cast in a session
Vers: 1.5.0, Fabric 1.19.2

HexVR crashes with HexDebug due to missing negative index check in MsgNewSpellPatternAck handler

Summary

When using HexDebug's debugger with HexVR installed, players are kicked from the game if they try to use the "step in" option in the debugger. The following traceback is printed in the logs (full latest.log, from ski on Discord):

[14:59:08] [Netty Local Client IO #0/ERROR]: Encountered exception while handling in channel with name "hexcasting:pat_sc"
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0
	at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) ~[?:?]
	at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) ~[?:?]
	at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) ~[?:?]
	at java.util.Objects.checkIndex(Objects.java:361) ~[?:?]
	at java.util.ArrayList.get(ArrayList.java:427) ~[?:?]
	at me.nanorasmus.nanodev.hexvr.casting.Casting.updateInstancesS2C(Casting.java:167) ~[HexVR-1.4.0%20%5BFABRIC%5D.jar:?]
	at at.petrak.hexcasting.common.network.MsgNewSpellPatternAck.handler$fgl000$hex_vr$handle(MsgNewSpellPatternAck.java:515) ~[hexcasting-fabric-1.19.2-0.10.3.jar:?]
	at at.petrak.hexcasting.common.network.MsgNewSpellPatternAck.handle(MsgNewSpellPatternAck.java:77) ~[hexcasting-fabric-1.19.2-0.10.3.jar:?]
	at at.petrak.hexcasting.fabric.network.FabricPacketHandler.lambda$makeClientBoundHandler$1(FabricPacketHandler.java:48) ~[hexcasting-fabric-1.19.2-0.10.3.jar:?]
	at net.fabricmc.fabric.impl.networking.client.ClientPlayNetworkAddon.receive(ClientPlayNetworkAddon.java:106) ~[fabric-networking-api-v1-1.2.12 def3f86d90-40dbcfca42bb4b90.jar:?]
	at net.fabricmc.fabric.impl.networking.client.ClientPlayNetworkAddon.receive(ClientPlayNetworkAddon.java:42) ~[fabric-networking-api-v1-1.2.12 def3f86d90-40dbcfca42bb4b90.jar:?]
	at net.fabricmc.fabric.impl.networking.AbstractChanneledNetworkAddon.handle(AbstractChanneledNetworkAddon.java:101) [fabric-networking-api-v1-1.2.12 def3f86d90-40dbcfca42bb4b90.jar:?]
	at net.fabricmc.fabric.impl.networking.client.ClientPlayNetworkAddon.handle(ClientPlayNetworkAddon.java:98) [fabric-networking-api-v1-1.2.12 def3f86d90-40dbcfca42bb4b90.jar:?]
	at net.minecraft.client.network.ClientPlayNetworkHandler.handler$dfp000$fabric-networking-api-v1$handleCustomPayload(ClientPlayNetworkHandler.java:2522) [client-intermediary.jar:?]
	at net.minecraft.client.network.ClientPlayNetworkHandler.onCustomPayload(ClientPlayNetworkHandler.java) [client-intermediary.jar:?]
	at net.minecraft.network.packet.s2c.play.CustomPayloadS2CPacket.apply(CustomPayloadS2CPacket.java:60) [client-intermediary.jar:?]
	at net.minecraft.network.packet.s2c.play.CustomPayloadS2CPacket.apply(CustomPayloadS2CPacket.java:8) [client-intermediary.jar:?]
	at net.minecraft.network.ClientConnection.handlePacket(ClientConnection.java:167) [client-intermediary.jar:?]
	at net.minecraft.network.ClientConnection.channelRead0(ClientConnection.java:152) [client-intermediary.jar:?]
	at net.minecraft.network.ClientConnection.channelRead0(ClientConnection.java:50) [client-intermediary.jar:?]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.local.LocalChannel.readInbound(LocalChannel.java:299) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.local.LocalChannel.finishPeerRead0(LocalChannel.java:445) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.local.LocalChannel.access$400(LocalChannel.java:50) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.channel.local.LocalChannel$5.run(LocalChannel.java:403) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) [netty-common-4.1.77.Final.jar:?]
	at io.netty.channel.DefaultEventLoop.run(DefaultEventLoop.java:54) [netty-transport-4.1.77.Final.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995) [netty-common-4.1.77.Final.jar:?]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.77.Final.jar:?]
	at java.lang.Thread.run(Thread.java:840) [?:?]

Analysis

HexDebug sends MsgNewSpellPatternAck with an index of -1 in these two places in order to update the stack/ravenmind of the evaluator:

The index is -1 because this message isn't responding to a MsgNewSpellPatternSyn, so we don't want to update the resolution type of any patterns that were already drawn.

The above exception is thrown by HexVR here:

HexVR/common/src/main/java/me/nanorasmus/nanodev/hexvr/casting/Casting.java

Lines 166 to 168 in 9826096

 if (index < castingPatterns.size()) { 

 castingPatterns.get(index).updateResolution(info); 

 }

The solution should be very simple - just change the condition to index >= 0 && index < castingPatterns.size().

As a side note, having an index of -1 seems to be fully supported by Hex's code, and it could theoretically happen in other cases - ie. in this code, if resolvedPatterns was empty, then index would be -1 (ie. resolvedPatterns.size() - 1 -> 0 - 1).

Versions

Minecraft: 1.19.2
Fabric API: 0.77.0
Fabric Language Kotlin: 1.10.19+kotlin.1.9.23
Hex Casting: 0.10.3
HexVR: 1.4.0
HexDebug: 0.2.2

nanorasmus / hexvr Goto Github PK

hexvr's People

Contributors

Watchers

Forkers

hexvr's Issues

First few spells can leave behind their info

HexVR crashes with HexDebug due to missing negative index check in MsgNewSpellPatternAck handler

Summary

Analysis

Versions

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

Jobs

	if (index < castingPatterns.size()) {
	castingPatterns.get(index).updateResolution(info);
	}