text:
Bindless/unbounded array reflection not always accurate

Hello,
Say I have a bindless array like so: layout( set = 0, binding = 0 ) uniform sampler2D textures[];
I noticed that when a shader does not actually index into this array with at least one non-uniform index, spirv-cross reflection will report a non-zero size for the array. Specifically, the size will be the highest static index + 1. Is this intentional? Dumb example repro:
#version 450
#extension GL_EXT_nonuniform_qualifier : enable

layout( location = 0 ) out vec4 FragColor;
layout( location = 0 ) in vec4 vColor;
layout( set = 1, binding = 0 ) uniform sampler2D textures[];

void main()
{
    FragColor = texture( textures[0], vec2( 0, 0 ) ).rgba;
}

The reflection will report a size of 1. If you change the final line to be texture( textures[5], vec2( 0, 0 ) ) it will report a size of 6. If you change it to be texture( textures[int( vColor.x )], vec2( 0, 0 ) ) it will report a size of 0 (which is what I expected for all of them, given how it was declared). I am doing the reflection by getting the SPIRType for that resource, and checking type.array (just like how it's done here: https://github.com/Themaister/Granite/blob/master/vulkan/shader.cpp#L338)
I noticed this as I was commenting out large swathes of shader code to debug some things, and noticed that the reflection suddenly considered the resource as non-bindless, with a size of 1. I was only accessing the first slot like this textures[0] because it contained a known debug texture. Things exploded since I was using the reflection to help build the descriptor set layout for the bindless textures, and then I was binding textures to it on the CPU side still expecting an unbounded array, but now that it was array of size 1, it was invalid to bind those textures.
Wondering if this is intentional, and if so, if there is any way around it?

For unaccessed arrays, glslang emits the array size as 1, so there's nothing we can do. This inherits legacy GLSL behavior where unsized resource arrays are supported if they are only accessed with constant indices and the size is inferred from that.

This inherits legacy GLSL behavior where unsized resource arrays are supported if they are only accessed with constant indices and the size is inferred from that.

Well that's unfortunate haha. Thanks for the info though!

authors: HansKristian-Work LiamTyler

repo: KhronosGroup/SPIRV-Cross


text:
spirv-val reports OpName and OpLine as not same section

the following shader
           OpCapability Shader
           OpCapability Linkage
           OpMemoryModel Logical GLSL450
           OpModuleProcessed "this is too early"
           OpName %void "void"
           OpLine %1 7 19
           OpName %other "other"

produces error:  Name is in an invalid layout section
but to my understanding, both OpName and OpLine are both in "class"  : "Debug", in the grammar file and mixing and matching I wouldn't expect this error, unless I am reading the spec wrong
cc @alan-baker

See logical module layout in the spec. In particular:

These debug instructions, which must be grouped in the following order:

All OpString, OpSourceExtension, OpSource, and OpSourceContinued, without forward references.
All OpName and all OpMemberName.
All OpModuleProcessed instructions.
...

All type declarations (OpTypeXXX instructions), all constant instructions, and all global variable declarations (all OpVariable instructions whose Storage Class is not Function). This is the preferred location for OpUndef instructions, though they can also appear in function bodies. All operands in all these instructions must be declared before being used. Otherwise, they can be in any order. This section is the first section to allow use of:

OpLine and OpNoLine debug information.
Non-semantic instructions with OpExtInst.

So OpLine can't be present until the type declaration section. When the validator sees OpLine it moves forward to that section which is why the error is that OpName is in the wrong section.

ok, it says

These debug instructions

and not

The debug instructions

so this seems fair to me, thanks for clarify, I have not caught that slight difference before

source: gharchive/issue

authors: alan-baker spencer-lunarg

repo: KhronosGroup/SPIRV-Tools

license_type: permissive

license_source: github-api


text:
Spirv-fuzz: Achieve coverage of TransformationAddDeadBlock test

This PR will solve #4290, by enhancing the test to get 100% of the lines covered.
Results 100% instead of 98%.

Please change the PR description to This PR fixes #4290, by enhancing the test to get 100% of the lines covered. so that the issue is closed automatically once the PR is merged.

source: gharchive/pull-request


text:
Encounter object export errors when using package

I encountered some export errors while using the dev branch package:
"Curve of animated property has no property type, can not validate [xxx] on [xxx]."
The object with animation works fine at runtime, but it doesn't play animation after exporting as glb/gltf. Additionally, I exported a large number of GameObject with same operations, but a few of them reported this errors, the others works well. I apologize that I am a web developer and not very familiar with Unity.
Can anyone give some help or advice? Q_Q

Please post a unitypackage with the models and animations that cause the issue here so that we can reproduce it.
Also please note

the full error message – it contains info what exactly can't be exported/validated
Unity version
SRP (e.g. URP or BiRP)
if you have KHR_animation_pointer enabled or not

Please post a unitypackage with the models and animations that cause the issue here so that we can reproduce it.
Also please post

the full error message – it contains info what exactly can't be exported/validated
Unity version
SRP (e.g. URP or BiRP)
if you have KHR_animation_pointer enabled or not

Thank you for your reply. I apologize for the late response, as I was waiting approval from game developers. They do not want me to upload any Unity resources to external platforms, so this issue can be closed. If I manage to solve the problem through any means, I will update the solution here. Thank you again for your help. ^ ^

@hanyaonian If needed I can set up a secure Drive folder for upload / NDA for specific projects.

Thank you. I have suggested to the game developers that providing you an NDA and sharing some resources will be helpful, but I am still waiting for response.
There were new characters in the game, so I re-exported them using the latest version of the UnityGLTF package, but the ouput can not play animation properly. I checked out the older package, 2.6.0 exp (from commit 122f9910693111afce6ccfa044a8af22b7faf7be), then everything went smoothly. (the export function in the menu bar and the export function in script)
Perhaps there have been some changes in the animation section?

@hanyaonian we really need models that reproduce the issue to see what is going wrong there, this is not enough information.
Between 2.6.0 and 2.10.0 there have been various changes to the plugin infrastructure, I recommend you double-check that KHR_animation_pointer plugin isn't enabled if your target software(s) don't support that extension. It's disabled by default but maybe you have turned it on?

authors: hanyaonian hybridherbst

repo: KhronosGroup/UnityGLTF

license: MIT


text:
vkcube: Remove unused command line option

The --validate-checks-disabled flag was unused, so will be removed.

CI Vulkan-Tools build # 1542 running.

CI Vulkan-Tools build # 1542 passed.

authors: charles-lunarg ci-tester-lunarg

repo: KhronosGroup/Vulkan-Tools

license_source: bigquery


text:
Feature Request: Even Cleaner Extension Menu

Thank you for the Cleaner Extension Menu Zen Mod!
Saw another variant on r/FirefoxCSS and thought it could work!
https://www.reddit.com/r/FirefoxCSS/comments/1g7u90r/i_want_this_style_in_my_extension_menu_can_anyone/

I can assign that and put it as an extra dropdown option yeah. Probably in November!

repo: KiKaraage/ZenMods


text:
Can't find Shader.exe?

I'm trying to run the program but it keeps telling that it can't find shader.exe. Am I missing something here?

When you load up a solution in VS, you need to specify which project is the startup project. This is a per-user configuration, so it is not checked in, you must set it yourself by right-clicking the project and selecting Set as Startup. The Shaders project is only there to compile shader code (hlsl) and does not generate an .exe.

Thanks for the response. What exactly am I suppose to set up as startup in order to run the projection mapping samples?

Sorry to be so slow to reply; you can set ProjectionMappingSample as the startup project.

authors: CedYF thundercarrot

repo: Kinect/RoomAliveToolkit

license: mit


text:
🛑 FSDH INT is down

In d4b6c50, FSDH INT (https://fsdh-portal-app-int.azurewebsites.net/register) was down:

HTTP code: 0
Response time: 0 ms

Resolved: FSDH INT is back up in 4de3bdb after 10 minutes.

repo: KingBain/proto-datahub-uptime


text:
Call screening can't be heard on A12

It can't be heard .
Device:- Redmi Note 10 Pro Max
Rom:- AOSP+ by Grewal
A12
How to fix?
And also i didn't get the latest gboard themes and smart compose

Smart compose should be there, for latest theme you need to spoof to pixel 5

For call screening not issue it device specific issue. I will let you know if I found out anything.
Commit I added on fixes fixed that issue on my device Redmi Note 4

It's spoofed to Pixel 5 but it's still the same gboard. Thanks for replying though. Really cool module btw.

As this is duplicate issue, I am closing this
for future reference comment on this https://github.com/Kingsman44/Pixelify/issues/12


text:
🚧Refactor WindowSizeEventArgs ctor param data types

Preview Feature Pull Request
📋Review Checklist📋

[ ] The head(source) branch for this pull request is a preview feature branch, with the correct naming syntax, in the following example:

A head(source) branch is the branch being merged into a target branch.
Example
Syntax: preview/feature/<issue-num>-<description>
Example: preview/feature/123-my-preview-feature

[ ] The head(source) branch for this pull request is created from a preview release branch, with the correct naming syntax, in the following example:
Example
Syntax: preview/v<major>.<minor>.<patch>-preview.<prev-num>
Example: preview/v1.2.3-preview.4

[ ] The base(target) branch for this pull request is a preview release branch, with the correct naming syntax, in the following example:

A base(target) branch is the branch that the head(source) branch is merging into.
Example
Syntax: preview/v<major>.<minor>.<patch>-preview.<prev-num>
Example: preview/v1.2.3-preview.4

💡For more information on branching, refer to the project's branching documentation.

[ ] Associated issue exists and is linked to this pull request.

One issue per pull request.

[ ] Pull request title matches the title of the associated issue.

[ ] A preview label has been added to the pull request.

[ ] The labels attached to this PR match the labels attached to the associated issue.

[ ] Project assigned matches the project of the associated issue.

[ ] Milestone assigned matches the milestone of the associated issue.

[ ] My code follows the coding style of this project.

The style is enforced by the .editorconfig files in the project and displayed as warnings.  If there is an edge case, reach out, and let's discuss it.

[ ] I have manually tested my code changes to the best of my ability.

[ ] All tests passed locally.

This is required because unit tests might pass locally but not in the CI environment during the status check process or vice-versa.
Tests might pass on the developer's machine but not necessarily on the code reviewer's machine.
Status checks run for this pull request when merging into the preview/v*.*.*-preview.* branch.  These status checks run every time a change is pushed to the pull request.  These checks validate version syntax, tagging, builds, unit tests, and more.

@CalvinWilkinson I followed the steps as you mentioned in the last PR. I hope this one satisfy all the requirements.

@CalvinWilkinson I followed the steps you mentioned in the last PR. I hope this one satisfies all the requirements.

@SyedMSawaid . Thanks for recreating the PR. Unfortunately, the branch name is still incorrect.
The branch names must always be all lower case and words are separated by hyphens, not underscores.
Here is the syntax of a preview feature branch:

Syntax: preview/feature/-
Example: preview/feature/171-refactor-ctor-params

So the previous PR that you closed had the branch below:

The hyphens for this one are correct but there are upper-case letters.
The branch for this one which is at the top of the page is below:

This one has uppercase letters and underscores.

I will apologize for this because I did not mention the lowercase requirement of the branch name.  I went back to look in the Branching Documentation as well and noticed that though it does show examples of the branch names, it does not explicitly say that they all have to be lowercase.
I take full blame for this of course.  I would make an exception but the CICD system will reject it.  Could you please recreate the PR with the correct branch again?  😟
Quick Note:
You also absolutely do not have to make the branch description the same text as the issue title.  Short and simple is ideal.  The issue number is the branch name is there for people to go to the issue for more detail if need be.  But there is nothing wrong with a longer branch name and it will not get rejected.  This is just a quick tip is all.
If you want to use the example below as the branch name, this would be great.
Branch Name: preview/feature/171-refactor-ctor-params

@SyedMSawaid
Just a quick positive note.   With the increased influx of outside contributions, this has been surfacing issues and details that need to be addressed with the outside contribution process.
So you are bringing value to the project!!  Don't sweat it.  I greatly appreciate this because I am improving the contribution docs and process as a direct result of you taking the time to contribute!!
This is exactly what open source is about.  Great job!!  🤘🏼

What doesn't kill me, makes me strong. 😅
It is okay. I will create a new one. I think once I get into the habit of it, it will be fine.
The problem I have is shortage of time so I hope it is okay on your end that I am a bit slow to adapt to the OSS system.

authors: CalvinWilkinson SyedMSawaid

repo: KinsonDigital/Velaptor


text:
[Bug] Dying in a shell when your your only other shell was destroyed (i.e. TNT, Creeper) causing a few issues

What happened?

You can still walk around and deal damage to entities/blocks. You cannot interact with XP and drops.
You must save and quit, then reload to be presented with the normal death screen.
There is a then ghost entry in the shell selection wheel that cannot be removed.

I recreated these issues in a few minute video here to demonstrate:
https://youtu.be/jafm4RoZnDA
Apologies for the quality.
Version
mc1.18-3.0
Minecraft Version
1.18.1
Fabric API Version
0.45.0+1.18
Installation Source
Modrinth
Logs
MultiMC version: 0.6.14-3001

Launched instance in online mode

authserver.mojang.com resolves to:
    [13.226.176.74]

session.minecraft.net resolves to:
    [52.21.65.46, 3.213.200.53, 34.205.58.168]

textures.minecraft.net resolves to:
    [99.86.100.63, 99.86.100.46, 99.86.100.119, 99.86.100.18]

api.mojang.com resolves to:
    [99.86.103.194]

Minecraft folder is:
C:/Program Files/MultiMC/instances/SFVNWH 6.00 (Isolation)/.minecraft

Java path is:
C:/Program Files/Java/jdk-17.0.1/bin/javaw.exe

Checking Java version...
Java is version 17.0.1, using 64-bit architecture, from Oracle Corporation.

Main Class:
  net.fabricmc.loader.impl.launch.knot.KnotClient

Native path:
  C:/Program Files/MultiMC/instances/SFVNWH 6.00 (Isolation)/natives

Traits:
traits FirstThreadOnMacOS
traits XR:Initial

Libraries:
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar
  C:/Program Files/MultiMC/libraries/com/mojang/blocklist/1.0.6/blocklist-1.0.6.jar
  C:/Program Files/MultiMC/libraries/com/mojang/patchy/2.1.6/patchy-2.1.6.jar
  C:/Program Files/MultiMC/libraries/com/github/oshi/oshi-core/5.8.2/oshi-core-5.8.2.jar
  C:/Program Files/MultiMC/libraries/net/java/dev/jna/jna/5.9.0/jna-5.9.0.jar
  C:/Program Files/MultiMC/libraries/net/java/dev/jna/jna-platform/5.9.0/jna-platform-5.9.0.jar
  C:/Program Files/MultiMC/libraries/org/slf4j/slf4j-api/1.8.0-beta4/slf4j-api-1.8.0-beta4.jar
  C:/Program Files/MultiMC/libraries/org/apache/logging/log4j/log4j-slf4j18-impl/2.16.0/log4j-slf4j18-impl-2.16.0.jar
  C:/Program Files/MultiMC/libraries/com/ibm/icu/icu4j/69.1/icu4j-69.1.jar
  C:/Program Files/MultiMC/libraries/com/mojang/javabridge/1.2.24/javabridge-1.2.24.jar
  C:/Program Files/MultiMC/libraries/net/sf/jopt-simple/jopt-simple/5.0.4/jopt-simple-5.0.4.jar
  C:/Program Files/MultiMC/libraries/io/netty/netty-all/4.1.68.Final/netty-all-4.1.68.Final.jar
  C:/Program Files/MultiMC/libraries/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar
  C:/Program Files/MultiMC/libraries/com/google/guava/guava/31.0.1-jre/guava-31.0.1-jre.jar
  C:/Program Files/MultiMC/libraries/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
  C:/Program Files/MultiMC/libraries/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar
  C:/Program Files/MultiMC/libraries/commons-codec/commons-codec/1.15/commons-codec-1.15.jar
  C:/Program Files/MultiMC/libraries/com/mojang/brigadier/1.0.18/brigadier-1.0.18.jar
  C:/Program Files/MultiMC/libraries/com/mojang/datafixerupper/4.0.26/datafixerupper-4.0.26.jar
  C:/Program Files/MultiMC/libraries/com/google/code/gson/gson/2.8.8/gson-2.8.8.jar
  C:/Program Files/MultiMC/libraries/com/mojang/authlib/3.2.38/authlib-3.2.38.jar
  C:/Program Files/MultiMC/libraries/org/apache/commons/commons-compress/1.21/commons-compress-1.21.jar
  C:/Program Files/MultiMC/libraries/org/apache/httpcomponents/httpclient/4.5.13/httpclient-4.5.13.jar
  C:/Program Files/MultiMC/libraries/commons-logging/commons-logging/1.2/commons-logging-1.2.jar
  C:/Program Files/MultiMC/libraries/org/apache/httpcomponents/httpcore/4.4.14/httpcore-4.4.14.jar
  C:/Program Files/MultiMC/libraries/it/unimi/dsi/fastutil/8.5.6/fastutil-8.5.6.jar
  C:/Program Files/MultiMC/libraries/org/apache/logging/log4j/log4j-api/2.16.0/log4j-api-2.16.0.jar
  C:/Program Files/MultiMC/libraries/org/apache/logging/log4j/log4j-core/2.16.0/log4j-core-2.16.0.jar
  C:/Program Files/MultiMC/libraries/com/mojang/text2speech/1.11.3/text2speech-1.11.3.jar
  C:/Program Files/MultiMC/libraries/net/fabricmc/intermediary/1.18.1/intermediary-1.18.1.jar
  C:/Program Files/MultiMC/libraries/net/fabricmc/tiny-mappings-parser/0.3.0+build.17/tiny-mappings-parser-0.3.0+build.17.jar
  C:/Program Files/MultiMC/libraries/net/fabricmc/sponge-mixin/0.10.7+mixin.0.8.4/sponge-mixin-0.10.7+mixin.0.8.4.jar
  C:/Program Files/MultiMC/libraries/net/fabricmc/tiny-remapper/0.6.0/tiny-remapper-0.6.0.jar
  C:/Program Files/MultiMC/libraries/net/fabricmc/access-widener/2.0.1/access-widener-2.0.1.jar
  C:/Program Files/MultiMC/libraries/org/ow2/asm/asm/9.2/asm-9.2.jar
  C:/Program Files/MultiMC/libraries/org/ow2/asm/asm-analysis/9.2/asm-analysis-9.2.jar
  C:/Program Files/MultiMC/libraries/org/ow2/asm/asm-commons/9.2/asm-commons-9.2.jar
  C:/Program Files/MultiMC/libraries/org/ow2/asm/asm-tree/9.2/asm-tree-9.2.jar
  C:/Program Files/MultiMC/libraries/org/ow2/asm/asm-util/9.2/asm-util-9.2.jar
  C:/Program Files/MultiMC/libraries/net/fabricmc/fabric-loader/0.12.12/fabric-loader-0.12.12.jar
  C:/Program Files/MultiMC/libraries/com/mojang/minecraft/1.18.1/minecraft-1.18.1-client.jar

Native libraries:
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-glfw/3.2.2/lwjgl-glfw-3.2.2-natives-windows.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-jemalloc/3.2.2/lwjgl-jemalloc-3.2.2-natives-windows.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-openal/3.2.2/lwjgl-openal-3.2.2-natives-windows.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-opengl/3.2.2/lwjgl-opengl-3.2.2-natives-windows.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-stb/3.2.2/lwjgl-stb-3.2.2-natives-windows.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl-tinyfd/3.2.2/lwjgl-tinyfd-3.2.2-natives-windows.jar
  C:/Program Files/MultiMC/libraries/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2-natives-windows.jar
  C:/Program Files/MultiMC/libraries/com/mojang/text2speech/1.11.3/text2speech-1.11.3-natives-windows.jar

Mods:
  [✔] fabric-api-0.45.0+1.18
  [✔] sync-mc1.18-3.0

Params:
  --username  --version MultiMC5 --gameDir C:/Program Files/MultiMC/instances/SFVNWH 6.00 (Isolation)/.minecraft --assetsDir C:/Program Files/MultiMC/assets --assetIndex 1.18 --uuid  --accessToken  --userType  --versionType release

Window size: 854 x 480

Java Arguments:
[-XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump, -Xms4096m, -Xmx8192m, -Duser.language=en]

Minecraft process ID: 13548

Using onesix launcher.

[23:20:45] [main/INFO]: Loading Minecraft 1.18.1 with Fabric Loader 0.12.12
[23:20:46] [ForkJoinPool-1-worker-3/WARN]: The mod "sync" contains invalid entries in its mod json:
- Unsupported root entry "includes" at line 49 column 13
[23:20:46] [main/INFO]: Loading 54 mods:
	- cloth-basic-math 0.6.0 via cloth-config
	- cloth-config 6.1.48 via sync
	- crowdin-translate 1.4+1.18 via sync
	- fabric 0.45.0+1.18
	- fabric-api-base 0.4.1+b4f4f6cd65 via fabric
	- fabric-api-lookup-api-v1 1.5.0+17be577f65 via fabric
	- fabric-biome-api-v1 6.0.1+ded849a965 via fabric
	- fabric-blockrenderlayer-v1 1.1.9+3ac43d9565 via fabric
	- fabric-command-api-v1 1.1.6+3ac43d9565 via fabric
	- fabric-commands-v0 0.2.5+b4f4f6cd65 via fabric
	- fabric-containers-v0 0.1.18+d154e2c665 via fabric
	- fabric-content-registries-v0 0.4.5+6f53a73d65 via fabric
	- fabric-crash-report-info-v1 0.1.8+3ac43d9565 via fabric
	- fabric-dimensions-v1 2.1.7+43d2957165 via fabric
	- fabric-entity-events-v1 1.4.5+6b21378a65 via fabric
	- fabric-events-interaction-v0 0.4.16+bfa23f1765 via fabric
	- fabric-events-lifecycle-v0 0.2.6+b4f4f6cd65 via fabric
	- fabric-game-rule-api-v1 1.0.10+3ac43d9565 via fabric
	- fabric-item-api-v1 1.3.0+691a79b565 via fabric
	- fabric-item-groups-v0 0.3.3+3ac43d9565 via fabric
	- fabric-key-binding-api-v1 1.0.8+c8aba2f365 via fabric
	- fabric-keybindings-v0 0.2.6+b4f4f6cd65 via fabric
	- fabric-lifecycle-events-v1 1.4.10+c15ca33565 via fabric
	- fabric-loot-tables-v1 1.0.8+3ac43d9565 via fabric
	- fabric-mining-level-api-v1 1.0.3+3ac43d9565 via fabric
	- fabric-mining-levels-v0 0.1.7+b4f4f6cd65 via fabric
	- fabric-models-v0 0.3.3+3ac43d9565 via fabric
	- fabric-networking-api-v1 1.0.18+3ac43d9565 via fabric
	- fabric-networking-v0 0.3.5+b4f4f6cd65 via fabric
	- fabric-object-builder-api-v1 1.11.0+3b82842e65 via fabric
	- fabric-object-builders-v0 0.7.8+3ac43d9565 via fabric
	- fabric-particles-v1 0.2.9+526dc1ac65 via fabric
	- fabric-registry-sync-v0 0.8.6+533be9ba65 via fabric
	- fabric-renderer-api-v1 0.4.9+3ac43d9565 via fabric
	- fabric-renderer-indigo 0.4.12+3ac43d9565 via fabric
	- fabric-renderer-registries-v1 3.2.7+b4f4f6cd65 via fabric
	- fabric-rendering-data-attachment-v1 0.3.4+7242e9d765 via fabric
	- fabric-rendering-fluids-v1 0.1.18+3ac43d9565 via fabric
	- fabric-rendering-v0 1.1.9+b4f4f6cd65 via fabric
	- fabric-rendering-v1 1.10.3+6b21378a65 via fabric
	- fabric-resource-loader-v0 0.4.11+3ac43d9565 via fabric
	- fabric-screen-api-v1 1.0.7+3ac43d9565 via fabric
	- fabric-screen-handler-api-v1 1.1.11+3ac43d9565 via fabric
	- fabric-structure-api-v1 2.0.8+295197a765 via fabric
	- fabric-tag-extensions-v0 1.2.5+3ac43d9565 via fabric
	- fabric-textures-v0 1.0.9+3ac43d9565 via fabric
	- fabric-tool-attribute-api-v1 1.3.4+7de09f5565 via fabric
	- fabric-transfer-api-v1 1.5.6+b4f4f6cd65 via fabric
	- fabricloader 0.12.12
	- java 17
	- minecraft 1.18.1
	- smart-recipes 0.2.0+1.18 via sync
	- sync 3.0
	- team_reborn_energy 2.0.0-beta1 via sync
[23:20:46] [main/INFO]: SpongePowered MIXIN Subsystem Version=0.8.4 Source=file:/C:/Program%20Files/MultiMC/libraries/net/fabricmc/sponge-mixin/0.10.7+mixin.0.8.4/sponge-mixin-0.10.7+mixin.0.8.4.jar Service=Knot/Fabric Env=CLIENT
[23:20:46] [main/INFO]: Compatibility level set to JAVA_16
[23:20:46] [main/INFO]: Compatibility level set to JAVA_17
[23:20:48] [main/WARN]: @Inject(@At("INVOKE")) Shift.BY=3 on fabric-lifecycle-events-v1.mixins.json:client.WorldChunkMixin::handler$zdg000$onLoadBlockEntity exceeds the maximum allowed value: 0. Increase the value of maxShiftBy to suppress this warning.
[23:20:49] [Render thread/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD'
[23:20:50] [Render thread/INFO]: Setting user: thatguyel0c
[23:20:50] [Render thread/INFO]: [Indigo] Registering Indigo renderer!
[23:20:50] [Render thread/INFO]: Backend library: LWJGL version 3.2.2 build 10
[23:20:53] [Render thread/INFO]: Narrator library for x64 successfully loaded
[23:20:53] [Render thread/INFO]: Reloading ResourceManager: Default, Fabric Mods (Cloth Config v6, Fabric API, Fabric API Base, Fabric API Lookup API (v1), Fabric Biome API (v1), Fabric BlockRenderLayer Registration (v1), Fabric Command API (v1), Fabric Commands (v0), Fabric Containers (v0), Fabric Content Registries (v0), Fabric Crash Report Info (v1), Fabric Dimensions API (v1), Fabric Entity Events (v1), Fabric Events Interaction (v0), Fabric Events Lifecycle (v0), Fabric Game Rule API (v1), Fabric Item API (v1), Fabric Item Groups (v0), Fabric Key Binding API (v1), Fabric Key Bindings (v0), Fabric Lifecycle Events (v1), Fabric Loot Tables (v1), Fabric Mining Level API (v1), Fabric Mining Levels (v0), Fabric Models (v0), Fabric Networking API (v1), Fabric Networking (v0), Fabric Object Builder API (v1), Fabric Object Builders (v0), Fabric Particles (v1), Fabric Registry Sync (v0), Fabric Renderer API (v1), Fabric Renderer - Indigo, Fabric Renderer Registries (v1), Fabric Rendering Data Attachment (v1), Fabric Rendering Fluids (v1), Fabric Rendering (v0), Fabric Rendering (v1), Fabric Resource Loader (v0), Fabric Screen API (v1), Fabric Screen Handler API (v1), Fabric Structure API (v1), Fabric Tag Extensions (v0), Fabric Textures (v0), Fabric Tool Attribute API (v1), Fabric Transfer API (v1), Fabric Loader, Smart Recipes, Sync (Fabric), Energy)
[23:20:53] [Render thread/INFO]: [STDOUT]: Inject generated resource packs.
[23:20:55] [Render thread/INFO]: OpenAL initialized on device OpenAL Soft on Headphones (HyperX Cloud Flight S Game)
[23:20:55] [Render thread/INFO]: Sound engine started
[23:20:55] [Render thread/INFO]: Created: 1024x1024x4 minecraft:textures/atlas/blocks.png-atlas
[23:20:55] [Render thread/INFO]: Created: 256x128x4 minecraft:textures/atlas/signs.png-atlas
[23:20:55] [Render thread/INFO]: Created: 1024x512x4 minecraft:textures/atlas/banner_patterns.png-atlas
[23:20:55] [Render thread/INFO]: Created: 1024x512x4 minecraft:textures/atlas/shield_patterns.png-atlas
[23:20:55] [Render thread/INFO]: Created: 256x256x4 minecraft:textures/atlas/chest.png-atlas
[23:20:55] [Render thread/INFO]: Created: 512x256x4 minecraft:textures/atlas/beds.png-atlas
[23:20:55] [Render thread/INFO]: Created: 512x256x4 minecraft:textures/atlas/shulker_boxes.png-atlas
[23:20:56] [Render thread/INFO]: Created: 256x256x0 minecraft:textures/atlas/particles.png-atlas
[23:20:56] [Render thread/INFO]: Created: 256x256x0 minecraft:textures/atlas/paintings.png-atlas
[23:20:56] [Render thread/INFO]: Created: 256x128x0 minecraft:textures/atlas/mob_effects.png-atlas
[23:21:41] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:21:41] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, targets] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:21:41] [Render thread/WARN]: Ambiguity between arguments [teleport, destination] and [teleport, targets] with inputs: [Player, 0123, @e, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:21:41] [Render thread/WARN]: Ambiguity between arguments [teleport, targets] and [teleport, destination] with inputs: [Player, 0123, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:21:41] [Render thread/WARN]: Ambiguity between arguments [teleport, targets, location] and [teleport, targets, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:21:41] [Render thread/INFO]: Reloading ResourceManager: Default, Fabric Mods (Fabric Tool Attribute API (v1), Sync (Fabric))
[23:21:41] [Render thread/INFO]: Skipped 0 recipes
[23:21:41] [Render thread/INFO]: Loaded 7 recipes
[23:21:41] [Render thread/INFO]: Loaded 1141 advancements
[23:21:41] [Render thread/INFO]: Applied 0 biome modifications to 0 of 61 new biomes in 1.348 ms
[23:21:42] [Render thread/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD'
[23:21:42] [Server thread/INFO]: Starting integrated minecraft server version 1.18.1
[23:21:42] [Server thread/INFO]: Generating keypair
[23:21:42] [Server thread/INFO]: Preparing start region for dimension minecraft:overworld
[23:21:43] [Render thread/INFO]: Preparing spawn area: 0%
[23:21:43] [Render thread/INFO]: Preparing spawn area: 0%
[23:21:43] [Render thread/INFO]: Preparing spawn area: 5%
[23:21:44] [Render thread/INFO]: Preparing spawn area: 18%
[23:21:44] [Render thread/INFO]: Preparing spawn area: 31%
[23:21:45] [Render thread/INFO]: Preparing spawn area: 44%
[23:21:45] [Render thread/INFO]: Preparing spawn area: 57%
[23:21:46] [Render thread/INFO]: Preparing spawn area: 72%
[23:21:46] [Render thread/INFO]: Preparing spawn area: 88%
[23:21:47] [Render thread/INFO]: Time elapsed: 4406 ms
[23:21:47] [Server thread/INFO]: Reloaded 1 recipes (removed: 1 | added: 0) on the 'minecraft:end_data_pack_reload' event
[23:21:47] [Server thread/INFO]: Changing view distance to 12, from 10
[23:21:47] [Server thread/INFO]: Changing simulation distance to 12, from 0
[23:21:47] [Server thread/INFO]: thatguyel0c[local:E:662ce85b] logged in with entity id 1 at (8.5, -60.0, 5.5)
[23:21:47] [Server thread/INFO]: thatguyel0c joined the game
[23:21:48] [Render thread/INFO]: Loaded 0 advancements
[23:22:09] [Render thread/INFO]: Loaded 4 advancements
[23:22:10] [Render thread/INFO]: Loaded 9 advancements
[23:22:50] [Server thread/INFO]: Saving and pausing game...
[23:22:50] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:overworld
[23:22:50] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_nether
[23:22:50] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_end
[23:22:51] [Server thread/INFO]: thatguyel0c lost connection: Disconnected
[23:22:51] [Server thread/INFO]: thatguyel0c left the game
[23:22:51] [Server thread/INFO]: Stopping singleplayer server as player logged out
[23:22:51] [Server thread/INFO]: Stopping server
[23:22:51] [Server thread/INFO]: Saving players
[23:22:51] [Server thread/INFO]: Saving worlds
[23:22:51] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:overworld
[23:22:52] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_nether
[23:22:52] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_end
[23:22:52] [Server thread/INFO]: ThreadedAnvilChunkStorage (Sync Bug Demo): All chunks are saved
[23:22:52] [Server thread/INFO]: ThreadedAnvilChunkStorage (DIM-1): All chunks are saved
[23:22:52] [Server thread/INFO]: ThreadedAnvilChunkStorage (DIM1): All chunks are saved
[23:22:52] [Server thread/INFO]: ThreadedAnvilChunkStorage: All dimensions are saved
[23:22:55] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:22:55] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, targets] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:22:55] [Render thread/WARN]: Ambiguity between arguments [teleport, destination] and [teleport, targets] with inputs: [Player, 0123, @e, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:22:55] [Render thread/WARN]: Ambiguity between arguments [teleport, targets] and [teleport, destination] with inputs: [Player, 0123, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:22:55] [Render thread/WARN]: Ambiguity between arguments [teleport, targets, location] and [teleport, targets, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:22:55] [Render thread/INFO]: Reloading ResourceManager: Default, Fabric Mods (Fabric Tool Attribute API (v1), Sync (Fabric))
[23:22:55] [Render thread/INFO]: Skipped 0 recipes
[23:22:55] [Render thread/INFO]: Loaded 7 recipes
[23:22:55] [Render thread/INFO]: Loaded 1141 advancements
[23:22:55] [Render thread/INFO]: Applied 0 biome modifications to 0 of 61 new biomes in 149.9 ?s
[23:22:59] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:22:59] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, targets] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:22:59] [Render thread/WARN]: Ambiguity between arguments [teleport, destination] and [teleport, targets] with inputs: [Player, 0123, @e, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:22:59] [Render thread/WARN]: Ambiguity between arguments [teleport, targets] and [teleport, destination] with inputs: [Player, 0123, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:22:59] [Render thread/WARN]: Ambiguity between arguments [teleport, targets, location] and [teleport, targets, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:22:59] [Render thread/INFO]: Reloading ResourceManager: Default, Fabric Mods (Fabric Tool Attribute API (v1), Sync (Fabric))
[23:22:59] [Render thread/INFO]: Skipped 0 recipes
[23:22:59] [Render thread/INFO]: Loaded 7 recipes
[23:22:59] [Render thread/INFO]: Loaded 1141 advancements
[23:22:59] [Render thread/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD'
[23:22:59] [Server thread/INFO]: Starting integrated minecraft server version 1.18.1
[23:22:59] [Server thread/INFO]: Generating keypair
[23:22:59] [Server thread/INFO]: Preparing start region for dimension minecraft:overworld
[23:22:59] [Render thread/INFO]: Preparing spawn area: 0%
[23:23:00] [Render thread/INFO]: Preparing spawn area: 4%
[23:23:01] [Render thread/INFO]: Preparing spawn area: 12%
[23:23:01] [Render thread/INFO]: Preparing spawn area: 12%
[23:23:01] [Render thread/INFO]: Preparing spawn area: 65%
[23:23:02] [Render thread/INFO]: Preparing spawn area: 75%
[23:23:02] [Server thread/INFO]: Reloaded 1 recipes (removed: 1 | added: 0) on the 'minecraft:end_data_pack_reload' event
[23:23:02] [Server thread/INFO]: Changing view distance to 12, from 10
[23:23:02] [Server thread/INFO]: Changing simulation distance to 12, from 0
[23:23:02] [Render thread/INFO]: Time elapsed: 2975 ms
[23:23:02] [Server thread/INFO]: thatguyel0c[local:E:38678d07] logged in with entity id 10 at (-6.5, -60.0, -4.5)
[23:23:02] [Server thread/INFO]: thatguyel0c joined the game
[23:23:02] [Render thread/INFO]: Loaded 0 advancements
[23:23:21] [Render thread/INFO]: Loaded 4 advancements
[23:23:22] [Render thread/INFO]: Loaded 9 advancements
[23:24:21] [Server thread/INFO]: Saving and pausing game...
[23:24:21] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo 1]'/minecraft:overworld
[23:24:21] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo 1]'/minecraft:the_nether
[23:24:21] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo 1]'/minecraft:the_end
[23:24:22] [Server thread/INFO]: thatguyel0c lost connection: Disconnected
[23:24:22] [Server thread/INFO]: thatguyel0c left the game
[23:24:22] [Server thread/INFO]: Stopping singleplayer server as player logged out
[23:24:22] [Server thread/INFO]: Stopping server
[23:24:22] [Server thread/INFO]: Saving players
[23:24:22] [Server thread/INFO]: Saving worlds
[23:24:22] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo 1]'/minecraft:overworld
[23:24:23] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo 1]'/minecraft:the_nether
[23:24:23] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo 1]'/minecraft:the_end
[23:24:23] [Server thread/INFO]: ThreadedAnvilChunkStorage (Sync Bug Demo 1): All chunks are saved
[23:24:23] [Server thread/INFO]: ThreadedAnvilChunkStorage (DIM-1): All chunks are saved
[23:24:23] [Server thread/INFO]: ThreadedAnvilChunkStorage (DIM1): All chunks are saved
[23:24:23] [Server thread/INFO]: ThreadedAnvilChunkStorage: All dimensions are saved
[23:24:26] [Render thread/INFO]: Attempt 1...
[23:24:28] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:24:28] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, targets] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:24:28] [Render thread/WARN]: Ambiguity between arguments [teleport, destination] and [teleport, targets] with inputs: [Player, 0123, @e, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:24:28] [Render thread/WARN]: Ambiguity between arguments [teleport, targets] and [teleport, destination] with inputs: [Player, 0123, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:24:28] [Render thread/WARN]: Ambiguity between arguments [teleport, targets, location] and [teleport, targets, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:24:28] [Render thread/INFO]: Reloading ResourceManager: Default, Fabric Mods (Fabric Tool Attribute API (v1), Sync (Fabric))
[23:24:28] [Render thread/INFO]: Skipped 0 recipes
[23:24:28] [Render thread/INFO]: Loaded 7 recipes
[23:24:29] [Render thread/INFO]: Loaded 1141 advancements
[23:24:29] [Render thread/INFO]: Applied 0 biome modifications to 0 of 61 new biomes in 124.8 ?s
[23:24:33] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:24:33] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, targets] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:24:33] [Render thread/WARN]: Ambiguity between arguments [teleport, destination] and [teleport, targets] with inputs: [Player, 0123, @e, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:24:33] [Render thread/WARN]: Ambiguity between arguments [teleport, targets] and [teleport, destination] with inputs: [Player, 0123, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:24:33] [Render thread/WARN]: Ambiguity between arguments [teleport, targets, location] and [teleport, targets, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:24:33] [Render thread/INFO]: Reloading ResourceManager: Default, Fabric Mods (Fabric Tool Attribute API (v1), Sync (Fabric))
[23:24:33] [Render thread/INFO]: Skipped 0 recipes
[23:24:33] [Render thread/INFO]: Loaded 7 recipes
[23:24:34] [Render thread/INFO]: Loaded 1141 advancements
[23:24:34] [Render thread/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD'
[23:24:34] [Server thread/INFO]: Starting integrated minecraft server version 1.18.1
[23:24:34] [Server thread/INFO]: Generating keypair
[23:24:34] [Server thread/INFO]: Preparing start region for dimension minecraft:overworld
[23:24:34] [Render thread/INFO]: Preparing spawn area: 0%
[23:24:34] [Render thread/INFO]: Preparing spawn area: 5%
[23:24:35] [Render thread/INFO]: Preparing spawn area: 20%
[23:24:36] [Render thread/INFO]: Preparing spawn area: 33%
[23:24:36] [Render thread/INFO]: Preparing spawn area: 47%
[23:24:37] [Render thread/INFO]: Preparing spawn area: 60%
[23:24:37] [Render thread/INFO]: Preparing spawn area: 69%
[23:24:37] [Render thread/INFO]: Preparing spawn area: 96%
[23:24:38] [Server thread/INFO]: Reloaded 1 recipes (removed: 1 | added: 0) on the 'minecraft:end_data_pack_reload' event
[23:24:38] [Server thread/INFO]: Changing view distance to 12, from 10
[23:24:38] [Server thread/INFO]: Changing simulation distance to 12, from 0
[23:24:38] [Render thread/INFO]: Time elapsed: 3601 ms
[23:24:38] [Server thread/INFO]: thatguyel0c[local:E:6bfcef83] logged in with entity id 43 at (3.5, -60.0, 10.5)
[23:24:38] [Server thread/INFO]: thatguyel0c joined the game
[23:24:38] [Render thread/INFO]: Loaded 0 advancements
[23:24:47] [Render thread/INFO]: Loaded 4 advancements
[23:24:48] [Render thread/INFO]: Loaded 9 advancements
[23:25:48] [Server thread/INFO]: thatguyel0c fell out of the world
[23:25:48] [Server thread/INFO]: [thatguyel0c: Killed thatguyel0c]
[23:25:48] [Render thread/INFO]: [CHAT] thatguyel0c fell out of the world
[23:25:48] [Render thread/INFO]: [CHAT] Killed thatguyel0c
[23:25:52] [Render thread/INFO]: [CHAT] The selected shell cannot be found
[23:25:59] [Server thread/INFO]: Saving and pausing game...
[23:25:59] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:overworld
[23:25:59] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_nether
[23:25:59] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_end
[23:25:59] [Server thread/INFO]: thatguyel0c lost connection: Disconnected
[23:25:59] [Server thread/INFO]: thatguyel0c left the game
[23:25:59] [Server thread/INFO]: Stopping singleplayer server as player logged out
[23:25:59] [Server thread/INFO]: Stopping server
[23:25:59] [Server thread/INFO]: Saving players
[23:25:59] [Server thread/INFO]: Saving worlds
[23:25:59] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:overworld
[23:26:00] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_nether
[23:26:00] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_end
[23:26:00] [Server thread/INFO]: ThreadedAnvilChunkStorage (Sync Bug Demo (1)): All chunks are saved
[23:26:00] [Server thread/INFO]: ThreadedAnvilChunkStorage (DIM-1): All chunks are saved
[23:26:00] [Server thread/INFO]: ThreadedAnvilChunkStorage (DIM1): All chunks are saved
[23:26:00] [Server thread/INFO]: ThreadedAnvilChunkStorage: All dimensions are saved
[23:26:03] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:26:03] [Render thread/WARN]: Ambiguity between arguments [teleport, location] and [teleport, targets] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:26:03] [Render thread/WARN]: Ambiguity between arguments [teleport, destination] and [teleport, targets] with inputs: [Player, 0123, @e, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:26:03] [Render thread/WARN]: Ambiguity between arguments [teleport, targets] and [teleport, destination] with inputs: [Player, 0123, dd12be42-52a9-4a91-a8a1-11c01849e498]
[23:26:03] [Render thread/WARN]: Ambiguity between arguments [teleport, targets, location] and [teleport, targets, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
[23:26:03] [Render thread/INFO]: Reloading ResourceManager: Default, Fabric Mods (Fabric Tool Attribute API (v1), Sync (Fabric))
[23:26:03] [Render thread/INFO]: Skipped 0 recipes
[23:26:03] [Render thread/INFO]: Loaded 7 recipes
[23:26:03] [Render thread/INFO]: Loaded 1141 advancements
[23:26:03] [Render thread/INFO]: Applied 0 biome modifications to 0 of 61 new biomes in 117.8 ?s
[23:26:03] [Render thread/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD'
[23:26:03] [Server thread/INFO]: Starting integrated minecraft server version 1.18.1
[23:26:03] [Server thread/INFO]: Generating keypair
[23:26:03] [Server thread/INFO]: Preparing start region for dimension minecraft:overworld
[23:26:03] [Render thread/INFO]: Preparing spawn area: 0%
[23:26:04] [Render thread/INFO]: Preparing spawn area: 1%
[23:26:04] [Render thread/INFO]: Preparing spawn area: 84%
[23:26:04] [Server thread/INFO]: Reloaded 1 recipes (removed: 1 | added: 0) on the 'minecraft:end_data_pack_reload' event
[23:26:04] [Render thread/INFO]: Time elapsed: 1072 ms
[23:26:04] [Server thread/INFO]: Changing view distance to 12, from 10
[23:26:04] [Server thread/INFO]: Changing simulation distance to 12, from 0
[23:26:04] [Server thread/INFO]: thatguyel0c[local:E:198f3b21] logged in with entity id 84 at (3.79206985931899, -60.0, 5.984118207131491)
[23:26:04] [Server thread/INFO]: thatguyel0c joined the game
[23:26:04] [Render thread/INFO]: Loaded 9 advancements
[23:26:37] [Render thread/INFO]: [CHAT] The selected shell cannot be found
[23:27:06] [Server thread/INFO]: thatguyel0c fell out of the world
[23:27:06] [Server thread/INFO]: [thatguyel0c: Killed thatguyel0c]
[23:27:06] [Render thread/INFO]: [CHAT] thatguyel0c fell out of the world
[23:27:06] [Render thread/INFO]: [CHAT] Killed thatguyel0c
[23:27:18] [Server thread/INFO]: Saving and pausing game...
[23:27:18] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:overworld
[23:27:18] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_nether
[23:27:18] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_end
[23:27:19] [Server thread/INFO]: thatguyel0c lost connection: Disconnected
[23:27:19] [Server thread/INFO]: thatguyel0c left the game
[23:27:19] [Server thread/INFO]: Stopping singleplayer server as player logged out
[23:27:19] [Server thread/INFO]: Stopping server
[23:27:19] [Server thread/INFO]: Saving players
[23:27:19] [Server thread/INFO]: Saving worlds
[23:27:19] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:overworld
[23:27:19] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_nether
[23:27:19] [Server thread/INFO]: Saving chunks for level 'ServerLevel[Sync Bug Demo]'/minecraft:the_end
[23:27:19] [Server thread/INFO]: ThreadedAnvilChunkStorage (Sync Bug Demo (1)): All chunks are saved
[23:27:19] [Server thread/INFO]: ThreadedAnvilChunkStorage (DIM-1): All chunks are saved
[23:27:19] [Server thread/INFO]: ThreadedAnvilChunkStorage (DIM1): All chunks are saved
[23:27:19] [Server thread/INFO]: ThreadedAnvilChunkStorage: All dimensions are saved
[23:30:57] [Render thread/INFO]: Stopping!
Process exited with code 0.
MultiMC: Log upload triggered at: 24 Dec 2021 23:31:04 -0600

Other Mods
None

Additional Information
I'm using MultiMC, but not sure that would be applicable to these particular bugs.

I somehow managed to forget that a block can be broken not only by a player :)
Thank you for reporting this one, the video is also deeply appreciated! Cool skin, by the way :)
P.S. - to remove a ghostshell in your existing world you can use /sync ghostshells remove nickname x y z

repo: Kir-Antipov/sync-fabric


text:
Add connection object for developer ergonomics.

Create connection object and implementation to transform object to connectionString

Create connection object
Create complimentary data for connection object
Create tests for using the connection object

Looks nice! thank you for your contribution.
Just need to remove final modifier from that case object to get rid of that compile error.


text:
Do not show .git as a project folder

ZMA registers a directory as its "main dir" or something. Then every subdirectory of that "main dir" is considered a project. But not all of them should be. Probably no folder whose name begins with . should be shown, but especially not .git

Closed by https://github.com/KittyCAD/modeling-app/pull/4317

repo: KittyCAD/modeling-app


text:
Remove special visualization logic

This special case logic should be relegated to a plugin or otherwise simplified, see https://github.com/Kitware/romanesco/blob/master/romanesco/executors/workflow.py#L62-L119

This should probably be done before #127

authors: danlamanna jeffbaumes

repo: Kitware/romanesco


text:
Detail docs re installing from source

Leaving this here for @mgrauer to review

Is the entire list of plugins (those that need to be installed like pip install -e . [spark]) listed in the plugins.rst file?  I think so, but if not, this should be made explicit.
It might be good to include a link to the plugin docs page from the installation docs page and the developer docs page.  As someone less familiar with Romanesco, I wasn't sure of what I needed to do, the following info from the plugins docs page tells me exactly what I was looking for and couldn't find a few months back.  I think it should have more prominent display, or repetition, or linking, in the docs.

Adding new execution modes. Without any plugins enabled, the core Romanesco application can only perform two types of tasks: python and workflow modes. It's common for plugins to implement other task execution modes.

Is the entire list of plugins (those that need to be installed like pip install -e . [spark]) listed in the plugins.rst file? I think so, but if not, this should be made explicit.

It's not, opening an issue for documentation on swift plugin.

LGTM.

authors: danlamanna mgrauer


text:
R disabled by accident or temporarily?

I just initialized a new arbor instance 8/20/2015 and found out just now that R computation is gone.   I reprovisioned on 8/22 in case but same result.  Running an R script results in "invalid mode: r" error message.
Did I catch the master branch of tangelohub out of sync with the new romanesco architecture?  I'll try switching to the romanesco plug-in branch on romanesco and tangelohub.

Hi @curtislisle , this is due to a recent change in romanesco in which we created a plugin architecture within romanesco. R capabilities were moved within a plugin, so a little extra configuration needs to be done to get it enabled. I will update that in the ansible playbook this weekend.

@zachmullen, thanks so much for your quick answer and willingness to work on the playbook.  I will wait for the update, then plan to pull the update and reprovision my instance.  Glad I wasn't just going crazy :-)

Just realized I actually opened a PR to fix this issue at the same time I created the romanesco change:  #157 . It hasn't been officially QA'd yet, though. @curtislisle could you checkout that branch and rebuild the vagrant box and see if it fixes the problem?

I noticed the corresponding changes.  So I just check out the PR for tangelohub and the corresponding romanesco commit, right?  Will be glad to.

On Aug 22, 2015, at 6:10 PM, Zach Mullen notifications@github.com wrote:
Just realized I actually opened a PR to fix this issue at the same time I created the romanesco change: #157 . It hasn't been officially QA'd yet, though. @curtislisle could you checkout that branch and rebuild the vagrant box and see if it fixes the problem?
—
Reply to this email directly or view it on GitHub.

Yep, that's correct. If that works, I will go ahead and merge #157.

I checked out the "support-romanesco-plugin-framework branch', performed an "npm instdall" in  /vagrant to rebuild the app, and then went to /vagrant/romanesco and performed a git pull to update romanesco, as well.  TangeloHub comes up but I still receive the "Invalid more: r" command when trying to run an R-based analysis.  Did I miss something?

It will require re-running vagrant provision from your host.

This worked and R is enabled again! Great!  Thanks for reminding me, reprovisioning failed the first time and I forgot about it by the time I fixed the issue, until your reminder.  So #157 works for me using this branch and the current head of romanesco  ( 8/27 9:03 AM commit c72fef48c3ffa32d5b6f19997519502b79d12f69)!

authors: curtislisle zachmullen

repo: Kitware/tangelohub


text:
Add wheel for python 3.8 to pypi

Hello,
Currently, PyPI lists 2.7, 3.5, 3.6 and 3.7 wheels for VTK 8.1.2. is it possible to have 3.8 wheels for the supported platforms?
Can you provide wheels for VTK 8.2.0 too?
Thank you

Hi,
We are currently working on update VTK and will plan on publishing wheels for VTK 9.0. See https://gitlab.kitware.com/vtk/vtk/merge_requests/5543
We currently do not plan to provide wheels for VTK 8.2

ok, thank you and good job to the team for that!
By curiosity, is there an ETA?

This is pending few tasks:

finalize work associated with this issue and release of python versions integrating the change. See https://bugs.python.org/issue38728
update our internal continuous integration infrastructure to test wheel generation

We expect this to be done by end of Q1 2020

For reference:

See https://pypi.org/project/vtk/#files

yes, thanks @jcfr!  this is why I closed this issue 👍🏾

authors: jcfr skoudoro

repo: KitwareMedical/VTKPythonPackage


text:
Derive the analytic form for the CDF and its inverse

Computing the inverse CDF is a huge bottleneck for rvs() to sample random values. Instead of numerically computing it, just derive the analytical form for both the CDF and its inverse to save some computation time

resolved in v0.1.2

repo: Kiyoshika/inverse-exponential


text:
Login with Token?

I think a token login would be easier and more effective.

Do you mean login with a bot token or just copy the user token?

Do you mean login with a bot token or just copy the user token?

i was thinking a simple click to log into discord  button

Hello, I'm looking for a Discord bot login instead of self bot, is it possible?

authors: Bealze Kleinrotti Rysanlos xDelito

repo: Kleinrotti/TeamCord


text:
[App] Remove decimal from number of retirements

Total retirements is always an integer, so a decimal point is unnecessary.

Unable to reproduce this.

repo: KlimaDAO/klimadao


text:
[Translatable] Custom translatable row id

Hi,
I'm trying to make an existing Symfony project translatable with your bundle.
The problem is that the previous developper gave custom name to the entities id (ex: id_tableName).
When I generate SQL schema with doctrine, I have the following error :
An exception occurred while executing
'ALTER TABLE post_translation ADD CONSTRAINT FK_945A30422C2AC5D3
FOREIGN KEY (translatable_id) REFERENCES post (id) ON DELETE CASCADE':

  SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint

Because Doctrine is trying to add fk to a non existing field ('post'.'id instead of 'post'.'id_post').
How can I tell your bundle the real SQL id name ?
Thanks

Currently in 2.0 even translatable use native entity id

authors: TomasVotruba benjhoo

repo: KnpLabs/DoctrineBehaviors


text:
Smart Step feature seems to have major performance problems

When there are a large number of features / scenarios the following function can cause huge numbers of calls leading to major performance problems.

\Knp\FriendlyContexts\Reader\SmartReader::extractScenarios

Unfortunately it is not possible to disable the smart step feature to prevent these problems. At the moment we have a fork where we remove the environment.reader service tag on friendly.reader.smart_reader in core.yml to stop the SmartReader from being registered.
Perjaps there is a way to reduce the performance impact. Alternatively it would be good if there was a way to disable the Smart Step feature.

Hello. Can you be more explicit about what performance problem you have? I never experiment performance outage without using the smart step feature. (that I don't recommend to use precisely because of performance outage)

Hi Nek,
We were puzzled why our complete behats on a large project were taking over 4 hours to run. After using blackfire to profile the problem we discovered that registering thefriendly.reader.smart_reader triggers code to be fired after all the time while it looks through the scenarios (even if you are not using smart steps anywhere in the code). It seems this lookup is not cached either so it is parsing real files.
We forked this repo and disabled this environment reader and our behats ran in half an hour.
Unfortunately i cannot share the blackfire code with you, but if you run it on a larger project you will see what i mean.

PS: we were a bit unsure if the repo was actually maintained anymore as there does not seem to be much activity and we have offered a couple of PR's that never got a response. Should we continue or is this repo semi-abandoned? We would be happy to contribute, but otherwise we would just maintain our own fork.

I'll take a look at the issue. Thanks for reporting and also thanks for the fix. (is it also MIT ?)
About the PS... Until now yes it was semi-abandoned, but I was promoted maintainer, I'll try to make the project move in the right direction :) .

Just so you know, our solution is not a fix. It just disables smart steps it on our fork 😄 . We dont use them anyway. I guess it would be better if the features were disabled by default and you can opt in.
Great new that there is a maintainer again. We will try to provide more help again in the future.

authors: Nek- yakobe

repo: KnpLabs/FriendlyContexts


text:
Issue with ZZH on ESXi 6.7 with USB passthrough

I cannot get ZZH to work on ESXi 6.7 passthrough. After inserting a flashed (on another computer) stick with the latest firmware (znp_CC26X2R1_LAUNCHXL_tirtos_ccs)
I an getting:
[  316.939929] usb 2-2.2: ch341-uart converter now attached to ttyUSB0
which is fine, but already at this point when I'm trying to run znp-uart-test.py script I am getting:
./znp-uart-test.py
Got 0 bytes in response to PING command: b''
FAIL|Expected length mismatch

But the things get worse when I'm trying to run Zigbee2MQTT on this machine - Z2M fails to connect to the adapter and dmesg shows a lot of -110 errors on that interface. I also tried connecting the stick through a powered USB hub and after even more of -110 errors the hub just switched off the port (seems like some kind of failsafe).
Ive got several other USB devices connected to that server (including RFlink which uses same ch341-uart driver) and USB passthrough works perfectly fine with all of them.

Same here

@Zuse2k donypu remember what have you done? Im still struggling with this, reflashed the stick multiple times and went back to using conbee

I've exactly the same issue with my new ZZH stick flashed with CC26X2R1_20201026.hex.

I've exactly the same issue with my new ZZH stick flashed with CC26X2R1_20201026.hex.

Uses zigbee2mqtt as LXC - Linux container without usb pass through.
i don’t have anymore this issue.
For promox, use this guide:
https://www.martinellis.me/posts/2020/03/zig-a-zig-ah/

Uses zigbee2mqtt as LXC - Linux container without usb pass through.
i don’t have anymore this issue.
For promox, use this guide:
https://www.martinellis.me/posts/2020/03/zig-a-zig-ah/

Same issue here with esxi 7.0.1. Anyone tried to pass-through the usb controller ?
[mer. févr.  3 00:14:26 2021] ch341-uart ttyUSB0: failed to read modem status: -110
[mer. févr.  3 00:15:39 2021] usb 2-2.1: failed to send control message: -110

Same issue here with esxi 7.0.1 (Intel NUC). Anyone tried to pass-through the usb controller ?
[mer. févr. 3 00:14:26 2021] ch341-uart ttyUSB0: failed to read modem status: -110
[mer. févr. 3 00:15:39 2021] usb 2-2.1: failed to send control message: -110

In my case this error was solved by disabling zigbee2mqtt in HA. As far as I understand you cannot run both zigbee2mqtt and ZHA to use the same USB controller.

a new version of firmware has been released today, could you guys test if it helps (i have loaned my stick to a friend since i couldnt use it myself)

Bumping up to avoid bot

Bump

After many hours of troubleshooting I finally stumbled upon this issue. I also have this exact problem, and have performed quite a bit of troubleshooting. Up until now I have been using the CC2531 which have served me well, but with the continuous Zigbee expansion in my home it was time to upgrade to CC2652R. It was recognized by ESXi as "QinHeng USB Serial" and it's showing up on the guest OS:
ls /dev/serial/by-id/
usb-1a86_USB_Serial-if00-port0

However, the system is not able to access it either through the flashing (Python script) as well as accessing it using Z2M. Also checked with the UART test script and it returns fail as well:
python3 znp-uart-test.py
Got 0 bytes in response to PING command: b''
FAIL|Expected length mismatch

Environment:

Dell R720 server running ESXi 6.7
Virtual machine with HA OS (Same issue)
Virtual machine with Debian (Same issue, tested to eliminate any problems related to HA OS driver support)
Connected USB2 front IO ports, tried with and without extension cable.
RPI3 b+ for testing

Troubleshooting:

Updated all packages and systems to latest version (Except ESXi 6.7 due to licensing)
Went through all the FAQ steps
Restarted VMs multiple times, and re-added the adapter
Tested with RPI3 b+ where it's recognized and the znp-uart-test.py returns success (Also used the ZNP export/import script and it's able to communicate with the ZZH on the RPI)
Verified baud rate
Re-plugged the USB multiple times

Error messages same as mentioned above:
[ 1067.071130] usb 2-2.1: failed to receive control message: -110
[ 1870.349380] usb 2-2.1: failed to send control message: -110
[ 1872.351184] usb 2-2.1: failed to send control message: -110
[ 1874.356063] usb 2-2.1: failed to receive control message: -110

Flashed with the latest version, using Flash Programmer 2 no errors. FYI @Dinth
If you would like me to test any further please let me know, otherwise I will migrate back to the CC2531 as a temporary solution.

This is most probably not a firmware issue because of the way these sticks are put together. Borrowing this block diagram from the zzh quick start guide:

As far as the WMCU (and the firmware in question) is concerned, they are just speaking through UART as CC1352/CC2652 series of chips do not have USB (unlike CC2531) and rely on an external chip to do the conversion. In the case of zzh, this is the CH340.
Given that firmware has no direct control/interaction with USB at all, and the fact that testing out of the virtualised environment works just fine, this points the finger directly at ESXi. Specifically the drivers in use or perhaps the interaction between the host USB controller and the ESXi bypass mechanism. Given that there are people who managed to get their setup going on ESXi, I am wondering if we are seeing some sort of ESXi host controller bypass bug type of issue here?

Given that firmware has no direct control/interaction with USB at all, and the fact that testing out of the virtualised environment works just fine, this points the finger directly at ESXi. Specifically the drivers in use or perhaps the interaction between the host USB controller and the ESXi bypass mechanism. Since there are people who managed to get their setup going on ESXi, I am wondering if we are seeing some sort of ESXi host controller bypass bug type of issue here?

Fair point, but what's intriguing me is that other devices ive got which are using CH340/1 chip are working fine under ESXi. Also i have tried to google for issues with CH340 support on ESXi and havent found any other reports of devices not working under ESXI.

That is indeed curious and makes me think that maybe there are different versions of CH340 that work differently with the drivers ESXi provides. It's not uncommon that these chips have different revisions. Then again, given that there are working installations out there this is not a strong theory.
A bit of a tall order but wondering if there is any chance you can try and replicate this on another system that has different USB host controllers. This is essentially the USB on the motherboard of the host. Alternatively, if folks having this issue can report what they have here we can see if there is a pattern.

Definitely sounds like an ESXi 6.7 issue yes. I think we should do some more testing on 7.0, do you still have this issue @christophebonnay? Also I found this, might be somewhat relevant:

Reddit thread
And this message from Discord:

I think I read somewhere that the Linux kernel 5.x has some bugfixes for the CH340 (the usb-serial chip in the zzh) so if you are trying it on another Linux box, make sure the kernel version isn't the same. I'm stuck with 4.x on my server and on occasion the zzh doesn't work the first time it's plugged in but other than that it works just fine.

I'm aware ESXi is not based on the Linux kernel anymore, but it might be worth to be aware of here. I have been able to confirm people used pass-through on Proxmox (kernel 5.3 atm) with no issues at all.
For testing on other systems, I have 2x Dell r210ii servers (ESXi 6.7) and will try to replicate the issue on them as well. If this does not work I might be able to get my hands on ESXi 7.0.

Another much simpler variable to check is the OS or more specifically the kernel version you are running for the guest OS as well. This might actually be the easiest starting point.

Debian Buster 10  kernel 4.19.0-14-amd64
Unfortunately, i dont have another host i could use to test it on a different motherboard.

The different kernels I tried before was on HA OS (kernel 5.4.99) and Debian 10 (buster) 4.19.0-8-amd64.
Test on different host (Dell R210ii, ESXI 6.7)
VM: Debian 10 (buster) 4.19.0-8-amd64

Recognized as QinHeng USB Serial in ESXi
Connected to VM and booted it:

ls /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0

Ran znp-uart test with PASS:

python znp-uart-test.py
Got 7 bytes in response to PING command: b'\xfe\x02a\x01Y\x06='
PASS|OK

Trying to run the zigby/znp script to doublecheck connectivity. This fails due to not being able to open the port:

python3 -m zigpy_znp.tools.network_backup /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -o network_backup.json
Traceback (most recent call last):
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial/serialposix.py", line 322, in open
    self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
OSError: [Errno 5] Input/output error: '/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/zigpy_znp/tools/network_backup.py", line 107, in <module>
    asyncio.run(main(sys.argv[1:]))  # pragma: no cover
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/asyncio/base_events.py", line 612, in run_until_complete
    return future.result()
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/zigpy_znp/tools/network_backup.py", line 99, in main
    backup_obj = await backup_network(
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/zigpy_znp/tools/network_backup.py", line 23, in backup_network
    await znp.connect()
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/zigpy_znp/api.py", line 219, in connect
    self._uart = await uart.connect(self._config[conf.CONF_DEVICE], self)
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/zigpy_znp/uart.py", line 158, in connect
    transport, protocol = await serial_asyncio.create_serial_connection(
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial_asyncio/__init__.py", line 445, in create_serial_connection
    serial_instance = serial.serial_for_url(*args, **kwargs)
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial/__init__.py", line 90, in serial_for_url
    instance.open()
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial/serialposix.py", line 325, in open
    raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 5] could not open port /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0: [Errno 5] Input/output error: '/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0'

Trying the znp-uart script again and now it fails:

python znp-uart-test.py
Traceback (most recent call last):
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial/serialposix.py", line 322, in open
    self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
OSError: [Errno 5] Input/output error: '/dev/ttyUSB0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "znp-uart-test.py", line 28, in <module>
    ser = serial.Serial("/dev/ttyUSB0", 115200, timeout=2)
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial/serialutil.py", line 244, in __init__
    self.open()
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial/serialposix.py", line 325, in open
    raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 5] could not open port /dev/ttyUSB0: [Errno 5] Input/output error: '/dev/ttyUSB0'

Rebooting the host to try again, same thing happens:

First it passes:
python znp-uart-test.py
Got 7 bytes in response to PING command: b'\xfe\x02a\x01Y\x06='
PASS|OK

Then fails:
python znp-uart-test.py
Traceback (most recent call last):
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial/serialposix.py", line 322, in open
    self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
OSError: [Errno 5] Input/output error: '/dev/ttyUSB0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "znp-uart-test.py", line 28, in <module>
    ser = serial.Serial("/dev/ttyUSB0", 115200, timeout=2)
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial/serialutil.py", line 244, in __init__
    self.open()
  File "/root/.pyenv/versions/3.8.1/lib/python3.8/site-packages/serial/serialposix.py", line 325, in open
    raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 5] could not open port /dev/ttyUSB0: [Errno 5] Input/output error: '/dev/ttyUSB0'

While this test ran the same error messages as before showed up:
[   39.670977] usb 1-2.1: failed to send control message: -110
[   41.674944] usb 1-2.1: failed to send control message: -110
[   53.801916] usb 1-2.1: failed to send control message: -110
[   55.805584] usb 1-2.1: failed to send control message: -110
[   57.810249] usb 1-2.1: failed to receive control message: -110
[   57.810274] ch341-uart ttyUSB0: failed to read modem status: -110

@davidusken Out of curiosity, any errors reported on the host logs?

Surprisingly nothing, maybe @Dinth is able to see something?

I havent found anything either in /var/log on the host, but dont take my word for it, as im not very proficient in ESXi

I had the same issue, ZZH on ESXi 7.0.1 USB passthrough to a Debian based iobroker installation.
Either the stick wasn't recognized, or if it was, it wasn't very stable and the communication stopped after some hours.
Also had the failed to read modem status messages etc.
Reverted back to my old 2531 stick

I'm following the topic even if I'm not concerned actually.
Do you force USB ports to be always on on Host/Guest side ?
You can check it with:
grep . /sys/bus/usb/devices/*/power/control
control content value can be "on" for 'always on' or "auto" for 'auto-suspend'.
It is possible that the usb port get in suspend state and so lost power supply.

Ehh, bad bot!

I've exactly the same issue with my ZZH stick flashed with latest CC2652R_coordinator_20210708.hex. Any progress? I use ESXi 6.7.

@jokejoke I didn't get to manage the issue but I made a workaround with a raspberry pi. Did plug ZZH into RPi and made a ser2net socket to pipe serial usb over ethernet vlan to the vm which utilizes ZZH. Works so far stable and reliable.
Did not try so far if ZZH via usb passthrough works with ESXI 7 - VMware changed some major things afaik - probably you can give this also a try.

@jokejoke I didn't get to manage the issue but I made a workaround with a raspberry pi. Did plug ZZH into RPi and made a ser2net socket to pipe serial usb over ethernet vlan to the vm which utilizes ZZH. Works so far stable and reliable.

On bare metal with Debian and HomeAssistant I have no problem. It looks like some problem only with virtualization ESXi (6.7 and 7.0.2) USB 2.0 controller. I have older HW (HP Prodesk 400 G3 mini).

for those on exsi, i found changing usb controller for the VM to usb3.1 controller help ch340

Thank you so much @luckybruce your solution worked for me on esxi 7.0 !

authors: Dinth Zuse2k aztazt beilmaierQM christophebonnay davidusken jokejoke juslex luckybruce marviins87 omerk oschwieger zen2

repo: Koenkk/Z-Stack-firmware


text:
bump proc-macro2 to 1.0.36

Signed-off-by: Jérémie Drouet jeremie.drouet@gmail.com

fixed in v0.3.4

authors: Kogia-sima jdrouet

repo: Kogia-sima/sailfish


text:
[kong] add missing root object type to CRD OpenAPI v3 schema

What this PR does / why we need it:
Currently all installed CRDs are throwing violations warnings due to missing root type values.
kubectl describe crd kongconsumers.configuration.konghq.com
...
Status:
  Accepted Names:
    Kind:       KongConsumer
    List Kind:  KongConsumerList
    Plural:     kongconsumers
    Short Names:
      kc
    Singular:  kongconsumer
  Conditions:
    Last Transition Time:  2021-01-20T14:41:12Z
    Message:               spec.versions[0].schema.openAPIV3Schema.type: Required value: must not be empty at the root

See the following for more information on this topic:

https://github.com/kubernetes/kubernetes/issues/81445
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema

Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
OpenAPI will not be published to kubectl explain unless we also set preserveUnknownFields: false or set the apiVersion: apiextensions.k8s.io/v1 (it is v1beta1 today).
kubectl explain kongingress
KIND:     KongIngress
VERSION:  configuration.konghq.com/v1

DESCRIPTION:
     <empty>

See https://github.com/kubernetes/kubernetes/issues/95702 for more info on this topic.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] PR is based off the current tip of the next branch and targets next, not main
[x] New or modified sections of values.yaml are documented in the README.md
[x] Title of the PR and commit headers start with chart name (e.g. [kong])

Thanks @Starefossen for your contribution.
Could you please make this change instead to the CRDs defined in this file in the Kong/kubernetes-ingress-controller repo? You'll also need to run the hack/build-single-manifests.sh scritpt there when you're done.
We have some changes there not yet promoted to the helm chart. Also, it's the KIC repo that's the source of truth for CRDs.

authors: Starefossen mflendrich

repo: Kong/charts


text:
Insomnia Designer installation fails

Describe the bug
The installation of insomnia designer 2020.1.1 fails. The logs can be found here: https://pastebin.com/JM8b45R7
To Reproduce
Steps to reproduce the behavior:

Execute the exe file as administrator.

Expected behavior
The installation is successful.
Screenshots

Desktop (please complete the following information):

OS: Windows 10 Version 1909 Build 18363.815
App Version 2020.1.1

Duplicate of #2078
Thanks for reporting! We are actively investigating the issue. I am going to close this in favor of the other one for easier tracking purposes.

repo: Kong/insomnia


text:
Support for Apple M1 Silicon

I'd like to submit this as a feature request for a future build. After using the new 2020 Macbook Pro M1 for awhile, I can see the value in having M1 support in Insomnia. It would be great if it could take advantage of the new chip and would make for more efficient use of Insomnia when running it on an M1 Mac.

Tracking M1 support request here #2964

I second @ermirry.

authors: ermirry nijikokun nirvaansingh47


text:
feat(zipkin): allow configurable local serviceName

Closes #119

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @Tieske, I'd be happy to write tests but am not sure how to run them. Could you provide instructions?

@bforbis you can run them using Pongo

any chance you can add an integration test? (the ones that spin up Kong, make a request and verify the result)

Hi @Tieske, could you please take a look?

Thanks a lot, I have approved and merged this PR, with very small changes.

authors: CLAassistant Tieske bforbis kikito

repo: Kong/kong-plugin-zipkin


text:
UDP proxy(stream_listen) get real IP

Summary

Kong version ($ kong version)
2.4.1
A concise summary of the bug.

I use kong(v2.4.1) forward udp stream to my DNS server.  DNS server want get request client real IP.
I referenced this post.
The forwarding function failed after configuration.
I want to know how stream listen can get the real IP.
Steps To Reproduce

docker-compose.yml set env KONG_NGINX_SPROXY_PROXY_BIND: $$remote_addr transparent
docker-compose.yml set user: "0"
docker-compose up -d
dig @127.0.0.1 -p 53 example.com

@wskit Could you describe how do you observe for forwarding function failed?
Is there an error log, an unexpected behaviour we can refer to? Note you will also need to configure
iptables on your upstream/the DNS server to make it accept those packets.

When I initiate a dns query request, after 60 or 70 seconds, I see in the gateway log.
[01/Jul/2021:02:09:26 +0000] UDP 200 0 208 66.006

But my DNS server doesn't have any request logs.
If I remove the configuration from the issue, everything is fine, but I can't get the real ip.
I've tried configuring iptables, dnat snat and more.  But none of them worked,
probably because the Kong gateway and DNS server is running in docker.
But I think the iptables rules that come with docker should be able to get the request to the DNS server,
need to configure iptables rules should just snat modify the port.
I can provide docker-compose.yml to reproduce the problem.

@wskit This looks very likely the iptabels or kernel networking config on the DNS server is not configured
properly, so the request get "dropped" by the upstream DNS server. Thus you saw the 66 seconds in
access log, it's similar to a "timeout" in stateful connection since the destination never replies.
I would suggest to have a tcpdump on the upstream DNS server, or on host machine since you
are using docker, to pin point the issue.

@fffonion  It's the problem of firewall, the DNS server can receive requests.  but the response will have error.
Reply from unexpected source: $DNS-server-ip#30053, expected $gateway-ip#53

I tried to configure iptables
iptables -t nat -D POSTROUTING -o eth0 -p udp -s $DNS-server-ip --sport 30053 -j SNAT --to-source $gateway-ip:53

or
iptables -t nat -D OUTPUT -p udp -s $DNS-server-ip -dport 30053 -j DNAT --to-destination $gateway-ip:53

Both seem to be ineffective.
Even if I put the dns-server in the same environment as the gateway and don't use docker to run it.
I want to know how to configure iptables.
thanks.

@wskit Where do you observe the Reply from unexpected source: error, is it a Nginx error log or an error from
tools like dig? I think you are looking at the IP transparency in this doc, nat chain won't work, try the marking approach in
this doc or tproxy in this (https://ask.csdn.net/questions/347887)

@fffonion  From dig.  I referenced this doc.  The result is that only the ip is modified, port is unchanged.
Reply from unexpected source: $gateway-ip#30053, expected $gateway-ip#53

I referenced this post redirecting traffic to gateway (tcpdump can capture the request), But gateway does not respond. I've also tried tproxy and it doesn't seem to work for multiple vps.

http://disq.us/p/292lyfk Try using tc pedit to solve the problem.

@wskit I assume your latest comment suggested you have found the solution. If that's the case could you
close the ticket, and if possible briefly describe the solution you take here for community knowledge sharing?

As the original problem is solved, closing the issue.

authors: fffonion wskit

repo: Kong/kong


text:
uri_captures are url decoded

Is there an existing issue for this?

[X] I have searched the existing issues

Kong version ($ kong version)
2.5.0
Current Behavior
URI captures (ngx.ctx.router_matches.uri_captures) are URL decoded, which make them difficult to use in plugins. In prior versions of Kong, uri_captures were not decoded, whereas in 2.5.0 they are.
For example, in 2.0.4, a uri_capture looked like this:
{
  [0] = "/foo/bar/some%20resource%20document"
}

In 2.5.0:
{
  [0] = "/foo/bar/some resource document"
}

I didn't see anything in the changelog that would indicate that this change was intentional. Otherwise, it would be a breaking change for plugins using capturing groups.
Expected Behavior
For a given request
https://example.com/foo/bar/some%20resource%20document
the uri_capture would contain:
{
  [0] = "/foo/bar/some%20resource%20document"
}

Steps To Reproduce
1. Running Kong 2.5.0:
2. Create plugin that uses ngx.ctx.router_matches.uri_captures
3. kong.log(ngx.ctx.router_matches.uri_captures[0])

Anything else?
No response

Hi, I have found the reason is that below line added from 2.3 causing this issue
req_uri = normalize(req_uri, true)
So I add a new parameter to decide whether to normal request uri
Please check more details in my PR.

authors: agringeri yankun-li-kong


text:
Precondition failed when passing If-Match

Is there an existing issue for this?

[X] I have searched the existing issues

Kong version ($ kong version)
2.8.1
Current Behavior
When I have custom plugin and function response() is defined (even empty) then traffic works ok, except passing header If-match which stops whole flow (to be precise response part which is overriden by out-of-nowhere code 412):
http localhost:8000/my-route
HTTP/1.1 200 OK

http localhost:8000/my-route "If-Match: 22"
HTTP/1.1 412 Precondition Failed

Expected Behavior
Pass request to upstream, get response from there.
For now code 412 is overriding response from upstream.
Steps To Reproduce
1. create custom plugin
2. define response() function - leave it empty
3. do test with header If-Match
4. change response() to body_filter()
5. do tests from 3.

Anything else?
I created test environment: git clone https://github.com/salvadoriume/kong-workshops.git
where it is very easy to reproduce "Steps to reproduce"

What is more under the hood:
my-kong               | 2022/06/27 10:36:38 [alert] 1#0: worker process 1109 exited on signal 11 (core dumped)

If anyone want more details or I can also arrange demo to show it (but I think docker-compose I prepared is enough). Anybody?

Hello @salvadoriume, I don't think Kong does anything special with If-Match headers.
Does the problem still happen if you use header_filter instead of response in the plugin?

Using header_filter seems to work. Is it possible to verify my steps to reproduce? In long term I wanted to switch to response function, but there is some issues. If my testing is wrong, please correct me. But out of nowhere kong response with 412, maybe it respect that header?

Looks like this happens when the Response phase does body buffering by executing ngx.print(). I could replicate the behavior with the following:
function _M:access(config)
 local table = {}
 kong.log("Status before: ", ngx.status)
 ngx.print(table)
 kong.log("Status after: ", ngx.status)
 ngx.exit(200)
end

Which logs:
Status before: 0
Status after: 412

and returns: 412 Precondition Failed
Apparently Nginx handles the if-match header when ngx.print() is executed (or ngx.send_headers(), or ngx.say()), it will generate an nginx output filter error in case of a mismatch of the Etag (and return status 412).
The following should work to avoid this behavior, i.e. from the custom plugin, clear if-match from the request headers in the response phase:
function _M:response(config)
    ngx.req.clear_header("if-match")
    <your code here>
end

That was my suspicion that I couldn`t prove as I am not operating on such low level.
Thank you very much @samugi
@kikito apparently it does :)

Thanks a lot, @samugi ! I'm closing this issue then.

We understand that executing ngx.print() causes the If-Match to be evaluated by nginx.
But why does it causes the worker to exit on signal 11 ?
This issue still exists and causing a lot of our workers to fail. IMO, this should be re-opened and triaged in depth.

Same behaviour is observed when kong.service.request.enable_buffering() was used in access phase and response body was read in log phase. It ended up doing the If-Match precondition validation check and the worker exited on signal 11.
This is a serious issue as it opens Kong up for DOS attacks.
If one figures out a url which has response buffering turned on, sending a request with If-Match header would lead to nginx worker being killed.

authors: kikito nishant95 salvadoriume samugi


text:
fix(kempty): use correct warning icon

Summary

warning2 -> warning

A side effect is that this closes #286
Changes made:
PR Checklist

[x] Does not introduce dependencies
[x] Functional: all changes do not break existing APIs and if so, bump major version.
[x] Tests pass: check the output of yarn test packages/
[x] Naming: the files and the method and prop variables use the same naming conventions as other Kongponents
[x] Framework style: abides by the essential rules in Vue's style guide
[x] Cleanliness: does not have formatting issues, unused code (e.g., console.logs), or leftover comments
[x] Docs: includes a technically accurate README, uses JSDOC where appropriate

Verified: https://deploy-preview-289--kongponents.netlify.app/style-guide/colors.html

authors: darrenjennings kaiarrowood

repo: Kong/kongponents


text:
Having more than 100 httproutes may causes excessive resource conflicts

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
When I create more than 100 httproutes, the kong ingress controller causes excessive resource conflicts on kube-apiserver side, as it cannot correctly determine the attachedRoutes of a Gateway resource but the value keeps fluctuating.
Expected Behavior
When I create more than 101 httproutes, the resource usage of kube-apiserver does not increase to an insane level, and attachedRoutes is correctly set.
Steps To Reproduce

Create more than 101 httproutes.

$ cat test.sh
#!/usr/bin/env bash

function create_gateway {
  local num="${1}"
  cat <<EOF | kubectl create -f -
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: test-httproute-${num}
spec:
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: test-gateway
    namespace: test-gateway
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: test-service
      port: 80
      weight: 1
    matches:
    - path:
        type: PathPrefix
        value: /test-httproute-${num}/test
EOF
}

for i in {1..102}; do
  create_gateway ${i}
done

$ ./test.sh

Make sure that kube-apiserver's (code_resource:apiserver_request_total:rate5m{verb="write", resource="gateways"}) metric is excessively increased.

Make sure that the issue is addressed after removing those httproutes.

Kong Ingress Controller version
v2.10.3

Kubernetes version
$ kubectl version
Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.5", GitCommit:"c285e781331a3785a7f436042c65c5641ce8a9e9", GitTreeState:"clean", BuildDate:"2022-03-16T15:52:18Z", GoVersion:"go1.17.8", Compiler:"gc", Platform:"linux/amd64"}

Anything else?
No response

https://github.com/Kong/kubernetes-ingress-controller/blob/7e567cc4192532561b630d58f6500009e067ba88/internal/controllers/gateway/gateway_utils.go#L700-L710
found that issue is related to the fact that the mgrc.List returns httpRouteList without Continue token.

mgrc.List always returns exactly 100 items which are a subset of the total resources. It ends up generating different attachedRoutes values, as each given subset changes every time.

I believe that we MUST not use continue token in a cached client.
We can simply remove those pagination.

@gjkim42 Thank you for reporting and handling the fix yourself. I believe you can apply for a contributor T-shirt having a bug fixed.

repo: Kong/kubernetes-ingress-controller