WerSus Опубликовано: 16 сентября 2023 Поделиться Опубликовано: 16 сентября 2023 Скрытый текст https://youtu.be/n-M9zuC7QMI AuBuKOPE3_TyT 1 Ссылка на комментарий
_kaktysshow_ Опубликовано: 16 сентября 2023 Поделиться Опубликовано: 16 сентября 2023 как будто проще нажать ПКМ по блоку рядом, и вуа-ля, блок на месте Ссылка на комментарий
WerSus Опубликовано: 16 сентября 2023 Автор Поделиться Опубликовано: 16 сентября 2023 Ты тут не показушничай!!! Ссылка на комментарий
WTF Опубликовано: 16 сентября 2023 Поделиться Опубликовано: 16 сентября 2023 Спасибо за полезную информацию Ссылка на комментарий
iKpudka Опубликовано: 16 сентября 2023 Поделиться Опубликовано: 16 сентября 2023 UPD: решили все же чинить баг на самом серверном ядре, так как это априори правильнее, но можно почитать и мои танцы в клиенте Краткий ввод, почему вообще происходит такой визуальный баг: когда сервер заменяет где-либо блок с одного типа на другой, он проверяет, нет ли у этого блока гравитации, и если есть, то начинает спавнить EntityFallingBlock, который мы знаем в простонародье как "падающий блок". Конечно, в Spigot есть возможность менять блоки без применения физики, оно и понятно, ведь на самом деле блок никуда не пропадает, а остается на своем месте, просто визуально для игрока он пропадает, и мы скоро узнаем почему Я считаю, что фикс должен быть немного другим. Действительно сложно постоянно стрелять по бетону, чтобы он не падал. Поэтому я решил обратиться к коду клиента и сервера Minecraft. Буду честен, копался довольно продолжительное время, дебажил все процессы, которые происходят и не происходят. И наконец - удалось найти косяк! Дело в том, что оригинальный код подразумевает удаление блока в том месте, где появляется сущность падающего блока. Другой вопрос, что такой код на самом деле дублируется - на стороне сервера и на стороне клиента. Быть кодером необязательно, чтобы понять, что делают эти отрывки кода, и понять, что они повторяют друг друга // Код с клиента Minecraft if (this.fallTime++ == 0) { BlockPos blockpos = new BlockPos(this); if (this.worldObj.getBlockState(blockpos).getBlock() == block) { this.worldObj.setBlockToAir(blockpos); } else if (!this.worldObj.isRemote) { this.setDead(); return; } } // Код с сервера Spigot BlockPosition blockposition; if (this.ticksLived++ == 0) { blockposition = new BlockPosition(this); if (this.world.getType(blockposition).getBlock() == block && !CraftEventFactory.callEntityChangeBlockEvent(this, blockposition.getX(), blockposition.getY(), blockposition.getZ(), Blocks.AIR, 0).isCancelled()) { this.world.setAir(blockposition); this.world.spigotConfig.antiXrayInstance.updateNearbyBlocks(this.world, blockposition); } else if (!this.world.isClientSide) { this.die(); return; } } Но одно отличие все же есть - второй код не будет вызван при замене блока на падающий. Да, во время выключенной физики выполняется только второй блок с условиями, где этот блок просто "умирает". В следующие моменты в любом случае падающий блок появится и удалит блок, на котором он был, соответственно клиенту необязательно сразу же удалять появившийся у него падающий блок (на самом деле там было еще много процессов, в том числе отправка пакета на создание такого блока), потому что еще не факт, что он действительно будет падать после отмены ивентов физики. Делаем совсем немножечко изменений и получаем возможно не очень красивый результат, ведь все же на микромомент падающий блок успевает появиться на клиенте из-за получения пакета от сервера, но тут я бессилен, ядро редактировать у меня нет возможностей. if (this.fallTime++ == 0) { // VimeWorld start // BlockPos blockpos = new BlockPos(this); // if (this.worldObj.getBlockState(blockpos).getBlock() == block) { // this.worldObj.setBlockToAir(blockpos); // } else // VimeWorld end if (!this.worldObj.isRemote) { this.setDead(); return; } } Забавный факт, что помимо исправления визуального бага с сыпучими блоками, исчезает и надоедливый баг, когда невозможно спамить такими блоками, например при строительстве на BuildBattle Скрытый текст До: После: NekitFbetc, Charkos0ff, WerSus и 2 других 2 3 Ссылка на комментарий
HeSwaka Опубликовано: 16 сентября 2023 Поделиться Опубликовано: 16 сентября 2023 18 минут назад, iKpudka сказал: Краткий ввод, почему вообще происходит такой визуальный баг: когда сервер заменяет где-либо блок с одного типа на другой, он проверяет, нет ли у этого блока гравитации, и если есть, то начинает спавнить EntityFallingBlock, который мы знаем в простонародье как "падающий блок". Конечно, в Spigot есть возможность менять блоки без применения физики, оно и понятно, ведь на самом деле блок никуда не пропадает, а остается на своем месте, просто визуально для игрока он пропадает, и мы скоро узнаем почему Я считаю, что фикс должен быть немного другим. Действительно сложно постоянно стрелять по бетону, чтобы он не падал. Поэтому я решил обратиться к коду клиента и сервера Minecraft. Буду честен, копался довольно продолжительное время, дебажил все процессы, которые происходят и не происходят. И наконец - удалось найти косяк! Дело в том, что оригинальный код подразумевает удаление блока в том месте, где появляется сущность падающего блока. Другой вопрос, что такой код на самом деле дублируется - на стороне сервера и на стороне клиента. Быть кодером необязательно, чтобы понять, что делают эти отрывки кода, и понять, что они повторяют друг друга // Код с клиента Minecraft if (this.fallTime++ == 0) { BlockPos blockpos = new BlockPos(this); if (this.worldObj.getBlockState(blockpos).getBlock() == block) { this.worldObj.setBlockToAir(blockpos); } else if (!this.worldObj.isRemote) { this.setDead(); return; } } // Код с сервера Spigot BlockPosition blockposition; if (this.ticksLived++ == 0) { blockposition = new BlockPosition(this); if (this.world.getType(blockposition).getBlock() == block && !CraftEventFactory.callEntityChangeBlockEvent(this, blockposition.getX(), blockposition.getY(), blockposition.getZ(), Blocks.AIR, 0).isCancelled()) { this.world.setAir(blockposition); this.world.spigotConfig.antiXrayInstance.updateNearbyBlocks(this.world, blockposition); } else if (!this.world.isClientSide) { this.die(); return; } } Но одно отличие все же есть - второй код не будет вызван при замене блока на падающий. Да, во время выключенной физики выполняется только второй блок с условиями, где этот блок просто "умирает". В следующие моменты в любом случае падающий блок появится и удалит блок, на котором он был, соответственно клиенту необязательно сразу же удалять появившийся у него падающий блок (на самом деле там было еще много процессов, в том числе отправка пакета на создание такого блока), потому что еще не факт, что он действительно будет падать после отмены ивентов физики. Делаем совсем немножечко изменений и получаем возможно не очень красивый результат, ведь все же на микромомент падающий блок успевает появиться на клиенте из-за получения пакета от сервера, но тут я бессилен, ядро редактировать у меня нет возможностей. if (this.fallTime++ == 0) { // VimeWorld start // BlockPos blockpos = new BlockPos(this); // if (this.worldObj.getBlockState(blockpos).getBlock() == block) { // this.worldObj.setBlockToAir(blockpos); // } else // VimeWorld end if (!this.worldObj.isRemote) { this.setDead(); return; } } Забавный факт, что помимо исправления визуального бага с сыпучими блоками, исчезает и надоедливый баг, когда невозможно спамить такими блоками, например при строительстве на BuildBattle Показать содержимое До: После: Не верю, все что ты написал было енотакином сделано еще пол года назад! Charkos0ff, 4abypka, rsb0e и 2 других 3 2 Ссылка на комментарий
WerSus Опубликовано: 17 сентября 2023 Автор Поделиться Опубликовано: 17 сентября 2023 14 часов назад, iKpudka сказал: UPD: решили все же чинить баг на самом серверном ядре, так как это априори правильнее, но можно почитать и мои танцы в клиенте Краткий ввод, почему вообще происходит такой визуальный баг: когда сервер заменяет где-либо блок с одного типа на другой, он проверяет, нет ли у этого блока гравитации, и если есть, то начинает спавнить EntityFallingBlock, который мы знаем в простонародье как "падающий блок". Конечно, в Spigot есть возможность менять блоки без применения физики, оно и понятно, ведь на самом деле блок никуда не пропадает, а остается на своем месте, просто визуально для игрока он пропадает, и мы скоро узнаем почему Я считаю, что фикс должен быть немного другим. Действительно сложно постоянно стрелять по бетону, чтобы он не падал. Поэтому я решил обратиться к коду клиента и сервера Minecraft. Буду честен, копался довольно продолжительное время, дебажил все процессы, которые происходят и не происходят. И наконец - удалось найти косяк! Дело в том, что оригинальный код подразумевает удаление блока в том месте, где появляется сущность падающего блока. Другой вопрос, что такой код на самом деле дублируется - на стороне сервера и на стороне клиента. Быть кодером необязательно, чтобы понять, что делают эти отрывки кода, и понять, что они повторяют друг друга // Код с клиента Minecraft if (this.fallTime++ == 0) { BlockPos blockpos = new BlockPos(this); if (this.worldObj.getBlockState(blockpos).getBlock() == block) { this.worldObj.setBlockToAir(blockpos); } else if (!this.worldObj.isRemote) { this.setDead(); return; } } // Код с сервера Spigot BlockPosition blockposition; if (this.ticksLived++ == 0) { blockposition = new BlockPosition(this); if (this.world.getType(blockposition).getBlock() == block && !CraftEventFactory.callEntityChangeBlockEvent(this, blockposition.getX(), blockposition.getY(), blockposition.getZ(), Blocks.AIR, 0).isCancelled()) { this.world.setAir(blockposition); this.world.spigotConfig.antiXrayInstance.updateNearbyBlocks(this.world, blockposition); } else if (!this.world.isClientSide) { this.die(); return; } } Но одно отличие все же есть - второй код не будет вызван при замене блока на падающий. Да, во время выключенной физики выполняется только второй блок с условиями, где этот блок просто "умирает". В следующие моменты в любом случае падающий блок появится и удалит блок, на котором он был, соответственно клиенту необязательно сразу же удалять появившийся у него падающий блок (на самом деле там было еще много процессов, в том числе отправка пакета на создание такого блока), потому что еще не факт, что он действительно будет падать после отмены ивентов физики. Делаем совсем немножечко изменений и получаем возможно не очень красивый результат, ведь все же на микромомент падающий блок успевает появиться на клиенте из-за получения пакета от сервера, но тут я бессилен, ядро редактировать у меня нет возможностей. if (this.fallTime++ == 0) { // VimeWorld start // BlockPos blockpos = new BlockPos(this); // if (this.worldObj.getBlockState(blockpos).getBlock() == block) { // this.worldObj.setBlockToAir(blockpos); // } else // VimeWorld end if (!this.worldObj.isRemote) { this.setDead(); return; } } Забавный факт, что помимо исправления визуального бага с сыпучими блоками, исчезает и надоедливый баг, когда невозможно спамить такими блоками, например при строительстве на BuildBattle Скрыть содержимое До: После: Круто, что об этом задумались, хоть и долго Ссылка на комментарий
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВойти
Уже зарегистрированы? Войдите здесь.
Войти сейчас