text:
Documentation website

@giobetti Please have a look at this video and let me know your thoughts

Excellent, I love the idea of staying on the same page, the alternative (to avoid losing the epw data loaded) would be to have the link to open in a new tab.
Pro: Contextual information as you are browsing the data is great (can we implement images? can we implement print to pdf?)
Contra: I was imagining that the documentation pages could become useful resources for students and people interested in learning more about climate analysis. As suuch  a separate website seems preferable... In this case we could have the titles to open the right docusaurus page in a  separate tab
What are your thoughts?

I guess we could allow users to print it to PDF but probably that feature will add a lot of complexity for very little benefit. However, it is feasible.
Yes, we can also include images, links, and possibly videos. See the example below with the image.

This does not stop us from assigning a link to the title (instead of the modal) which opens a new Docusaurus page. Alternatively, we could add a link in the modal saying ... read more which then redirects the user to the Docusaurus.
But fundamentally I think it is very nice that the user can get some info from the modal without having to leave the website, opening a new tab or page.
The main issue now is that we do not have any documentation material at all.

"The main issue now is that we do not have any documentation material at all."
absolutely right!
I think there are different types of information we might want to support for the documentation and maybe thinking about thaem and which ones we want to implement might help us.

general website usage (i.e. downloading files/images, resizing images etc. maybe it is not needed?)

How to read a chart: this could be reusable in the different chart types regardless of the variable contained in some cases (i.e. sunpath, psychrometric chart and windrose) this might be ore needed than in other (i.e. temperature profiles and barcharts)

Explanation of the variables (i.e. what is extraterrestrial solar radiation? how id it measured?) the epw documentation on bigladder help us https://bigladdersoftware.com/epx/docs/8-5/auxiliary-programs/energyplus-weather-file-epw-data-dictionary.html#field-extraterrestrial-horizontal-radiation or not? we could add some graphics here and there such as this explaining the difference between global horizontal, diffuse horizontal and direct normal solar radiation

Eplanation of the assumption behind more complex stuff like nat vent potential, UTCI etc.

Insights: what patterns are you looking for when you are reading a graph? what is "a lot" and what is "little"? this coud be done with docusaurus "admonitions" https://docusaurus.io/docs/markdown-features/admonitions

What do you think? I am afraid this will look like a textbook...
What is the MVP of the documentation?

we could record a video tutorial and write a few lines of text and add it to docusaurus.
we could add this information in the modal, and the same info (perhaps with a bit more depth) should also be added to docusaurus.
Documentation about the variables can be added both to the modal as well as in docusaurus, we will need to look at case by case.
This should perhaps go in docusaurus.
Agree, this should also go into docusaurus, maybe some small chunks of info could also be added to the modals

What is MVP?
Yes, this is going to be similar to a text book and it will take a lot of time, unless we are kind of able to copy and paste info from other websites.
We may also want to add some text to the tooltips. Like there is right now for the download button.

MVP: minimum viable product
https://en.wikipedia.org/wiki/Minimum_viable_product
i would try to avoid duplicate work as much as possible: docusaurus or modal, not both....
Minimum viable product - Wikipediahttps://en.wikipedia.org/wiki/Minimum_viable_product
A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.. A focus on releasing an MVP means that developers potentially avoid lengthy and (ultimately) unnecessary work. Instead, they iterate on working versions and respond to feedback, challenging and validating assumptions ...
en.wikipedia.org

From: Federico Tartarini @.>
Sent: 23 August 2021 11:10 AM
To: CenterForTheBuiltEnvironment/clima @.>
Cc: giobetti @.>; Mention @.>
Subject: Re: [CenterForTheBuiltEnvironment/clima] Documentation website (#88)

we could record a video tutorial and write a few lines of text and add it to docusaurus.
we could add this information in the modal, and the same info (perhaps with a bit more depth) should also be added to docusaurus.
Documentation about the variables can be added both to the modal as well as in docusaurus, we will need to look at case by case.
This should perhaps go in docusaurus.
Agree, this should also go into docusaurus, maybe some small chunks of info could also be added to the modals

What is MVP?
Yes, this is going to be similar to a text book and it will take a lot of time, unless we are kind of able to copy and paste info from other websites.
We may also want to add some text to the tooltips. Like there is right now for the download button.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCenterForTheBuiltEnvironment%2Fclima%2Fissues%2F88%23issuecomment-903584791&data=04|01||7f572ec5ba2c4611d72508d96615d8e0|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637653066285640810|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ZAqavW9lo%2B1JT0CYLBBusx7xi06%2FVQLX665vOBvQklg%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIWZJAFXTRD6TMWTHI44YR3T6IGAFANCNFSM5CP2K2EQ&data=04|01||7f572ec5ba2c4611d72508d96615d8e0|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637653066285650804|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Y0lR7d7Lmh2PmnfLO0ilGoIlosNAypUeLwQkYP%2B2BbM%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01||7f572ec5ba2c4611d72508d96615d8e0|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637653066285650804|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=cZnydW8zk4YY7ZJHAkkLZrmdIJIhLZjIZLUA97P5X%2BI%3D&reserved=0 or Androidhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26utm_campaign%3Dnotification-email&data=04|01||7f572ec5ba2c4611d72508d96615d8e0|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637653066285650804|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=x5youaBkLUC6sbLkG2fLBY0CJdIFSW1UtCEibNohE%2Bs%3D&reserved=0.

so what shall we do? If we only pick one the modals are nice since the user does not have to leave our tool. They are integrated inside the main website and can provide all the necessary information. However, each modal will need to be related to a title and cannot really describe how the tool works as a whole.

I think docusaurus is better, would give us more flexibility in structure and it would become as well a standalone reference for climate analysis…
Sent from my iPhone
On 24. Aug 2021, at 09:26, Federico Tartarini @.***> wrote:

so what shall we do? If we only pick one the modals are nice since the user does not have to leave our tool. They are integrated inside the main website and can provide all the necessary information. However, each modal will need to be related to a title and cannot really describe how the tool works as a whole.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCenterForTheBuiltEnvironment%2Fclima%2Fissues%2F88%23issuecomment-904392527&data=04|01||a154f6c856cd470f114d08d966d08021|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637653867948335049|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=x4lTvXS0SG%2F4b1FoVtsXLgkCH75j3iYg5Jp%2FH%2FTDtVM%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIWZJAB4S5Q2US4MXEXKGALT6NCSTANCNFSM5CP2K2EQ&data=04|01||a154f6c856cd470f114d08d966d08021|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637653867948335049|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=MkMiGlOhVGBwkyYZngfdi2viTKk72vuayaQcBZ750v8%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01||a154f6c856cd470f114d08d966d08021|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637653867948345041|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=DN73532umgC8oxf0g7xn5xpMdB3nTMWS2zDCMM3NpW0%3D&reserved=0 or Androidhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26utm_campaign%3Dnotification-email&data=04|01||a154f6c856cd470f114d08d966d08021|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637653867948345041|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Vc2Ew0Yzp0U3r7rEsWCdvy7sfcRW1KGSXrBxvRnomPY%3D&reserved=0.

So shall we avoid having the modals? How shall we move ahead. Where shall we source the documentation from? and what do you think is necessary for MVP?
At this stage, I would only focus on the essential documentation and the paper since they are critical. Then we can finalize the documentation in the months to come.

I think we can use GitBook instead of Docusaurs since it will be easier to maintain. I am working on it. I will update you once I have deployed a first draft of the documentation.

👍

From: Federico Tartarini @.>
Sent: 25 August 2021 10:59 AM
To: CenterForTheBuiltEnvironment/clima @.>
Cc: giobetti @.>; Mention @.>
Subject: Re: [CenterForTheBuiltEnvironment/clima] Documentation website (#88)
I think we can use GitBook instead of Docusaurs since it will be easier to maintain. I am working on it. I will update you once I have deployed a first draft of the documentation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCenterForTheBuiltEnvironment%2Fclima%2Fissues%2F88%23issuecomment-905315768&data=04|01||6d2c8947cdca449a4dd308d967a6a050|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637654787620538813|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=tBg4%2FmYdXFhrPNFVNc2n%2B2bdD4tvE792aLZsVCinKv8%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIWZJADB2D5QW66DNT2XROLT6SWGPANCNFSM5CP2K2EQ&data=04|01||6d2c8947cdca449a4dd308d967a6a050|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637654787620548807|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=aFWVH5wJFHO45R05%2BjaaZIsaDcKw1Ax7tHM7IfV%2BPck%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01||6d2c8947cdca449a4dd308d967a6a050|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637654787620548807|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ezkzD%2FdjdNoLY0Ga3w40cxnmLLlhErwhMrtwWfL7vy0%3D&reserved=0 or Androidhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26utm_campaign%3Dnotification-email&data=04|01||6d2c8947cdca449a4dd308d967a6a050|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637654787620558802|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=aLvzuPuB6lgxWq%2FcyqU3WHy%2B557YGBnTe7WfKVwqaig%3D&reserved=0.

GitBook has approved our request and we can now use it for free. Hence, the documentation link will not change, the official documentation is hosted at:
https://center-for-the-built-environment.gitbook.io/clima/
@giobetti how do you send an email to the BSG group?

Will clarify with Federico what documentation updates are required.

authors: FedericoTartarini danielh7-cs9 giobetti

repo: CenterForTheBuiltEnvironment/clima


text:
VMBDALI support missing

Hi,
Is it possible to support the VMBDALI module introduced through the original repository ?
It is the only thing missing for me at this point to fully use HA for my entire home.
The lights are to be supported as dimmers.
My coding skills are absent, but I would be happy to support through testing vigorously!

The first step is that
https://github.com/StefCoene/moduleprotocol
needs to be updated, i asked stef to do this

Perfect. Let me know how I can help!

can you send us your velbuslink file?
that would help

@Cereal2nd , can I send this to you privately ? Would only the VMBDALI entities suffice?

Seems to be there now ! https://github.com/StefCoene/moduleprotocol/commit/1bcdc616bd949e5e9ef79d2b3dfc0dc3df3240dc

yes it is, but now we need to implement/test is there a way we can login onto your bus so we can run some scans/debug info?

Unfortunately not, but I would be very willing to run many things for you and provide you with the output.

can you clone the master branch of this repo?
setup the package and run the examples/read_bus.py tool and provide me the output?

@Cereal2nd , attached you can find the output of read_bus.py and load_modules.py.
Relevant output from switching a Dali light on+off :
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a0, rtr=False, command=234, data=b'ea 08 00 00 33 0a 00 00')
DEBUG:velbus-packet:Received {"name": "TempSensorStatusMessage", "priority": 251, "address": 160, "rtr": false, "data": "", "local_control": 0, "status_mode": "run", "status_str": "run", "auto_send": 8, "mode": "safe", "mode_str": "safe", "cool": 0, "heater": 0, "boost": 0, "pump": 0, "alarm1": 0, "alarm2": 0, "alarm3": 0, "alarm4": 0, "current_temp": 25.5, "target_temp": 5.0, "sleep_timer": 0, "_status_str": "run"}
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=a6, rtr=False, command=0, data=b'00 01 00 00')
DEBUG:velbus-packet:Received {"name": "PushButtonStatusMessage", "priority": 248, "address": 166, "rtr": false, "data": "", "closed": [1], "opened": [], "closed_long": []}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ff8a604000001004e04' becomes b'0ff8a604000001004e04'
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=a6, rtr=False, command=0, data=b'00 00 01 00')
DEBUG:velbus-packet:Received {"name": "PushButtonStatusMessage", "priority": 248, "address": 166, "rtr": false, "data": "", "closed": [], "opened": [1], "closed_long": []}
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'0000000000000ffba602f5085104' becomes b'0ffba602f5085104'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=245, data=b'f5 08')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [4]}
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=245, data=b'f5 10')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [5]}
DEBUG:root:Trimming leading garbage from buffer content: b'0000000000000ff8020400060000' becomes b'0ff8020400060000'
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=02, rtr=False, command=0, data=b'00 06 00 00')
DEBUG:velbus-packet:Received {"name": "PushButtonStatusMessage", "priority": 248, "address": 2, "rtr": false, "data": "", "closed": [2, 3], "opened": [], "closed_long": []}
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='Task-203' coro=<VelbusProtocol._process_message() done, defined at /home/dieter/GIT/velbus-aio/velbusaio/protocol.py:167> exception=KeyError('Channels')>
Traceback (most recent call last):
  File "/home/dieter/GIT/velbus-aio/velbusaio/protocol.py", line 169, in _process_message
    await self._message_received_callback(msg)
  File "/home/dieter/GIT/velbus-aio/velbusaio/controller.py", line 55, in _on_message_received
    await self._handler.handle(msg)
  File "/home/dieter/GIT/velbus-aio/velbusaio/handler.py", line 86, in handle
    await (self._velbus.get_module(msg.address)).on_message(msg)
  File "/home/dieter/GIT/velbus-aio/velbusaio/module.py", line 262, in on_message
    for channel_types in self._data["Channels"]:
KeyError: 'Channels'
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ff8090400010000eb04' becomes b'0ff8090400010000eb04'
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=09, rtr=False, command=0, data=b'00 01 00 00')
WARNING:velbus-packet:UNKNOWN module, you should initialize a full new velbus scan: packet=01:00:00, address=9, modules=dict_keys([1, 2, 3, 4, 5, 16, 17, 18, 19, 20, 21, 32, 33, 34, 35, 36, 37, 144, 160, 176, 161, 177, 163, 179, 164, 180, 165, 181, 166, 182, 167, 183, 168, 169, 192, 193, 184, 194, 210, 195, 211, 196, 212, 197, 213, 198, 214, 199, 215, 200, 216, 201, 217, 224, 240, 250])
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=0a, rtr=False, command=0, data=b'00 08 00 00')
WARNING:velbus-packet:UNKNOWN module, you should initialize a full new velbus scan: packet=08:00:00, address=10, modules=dict_keys([1, 2, 3, 4, 5, 16, 17, 18, 19, 20, 21, 32, 33, 34, 35, 36, 37, 144, 160, 176, 161, 177, 163, 179, 164, 180, 165, 181, 166, 182, 167, 183, 168, 169, 192, 193, 184, 194, 210, 195, 211, 196, 212, 197, 213, 198, 214, 199, 215, 200, 216, 201, 217, 224, 240, 250])
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffbc102f540fe040000' becomes b'0ffbc102f540fe040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c1, rtr=False, command=245, data=b'f5 40')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 193, "rtr": false, "data": "", "leds": [7]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffbc102f580be0400000000' becomes b'0ffbc102f580be0400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c1, rtr=False, command=245, data=b'f5 80')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 193, "rtr": false, "data": "", "leds": [8]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffbc802f50136040000' becomes b'0ffbc802f50136040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c8, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 200, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffbc802f502350400000000' becomes b'0ffbc802f502350400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c8, rtr=False, command=245, data=b'f5 02')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 200, "rtr": false, "data": "", "leds": [2]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffbc502f50139040000' becomes b'0ffbc502f50139040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c5, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 197, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffba802f501560400000000' becomes b'0ffba802f501560400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a8, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 168, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba802f50156040000' becomes b'0ffba802f50156040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a8, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 168, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffba102f608550400000000' becomes b'0ffba102f608550400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a1, rtr=False, command=246, data=b'f6 08')
DEBUG:velbus-packet:Received {"name": "SetLedMessage", "priority": 251, "address": 161, "rtr": false, "data": "", "leds": [4]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba002f60856040000' becomes b'0ffba002f60856040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a0, rtr=False, command=246, data=b'f6 08')
DEBUG:velbus-packet:Received {"name": "SetLedMessage", "priority": 251, "address": 160, "rtr": false, "data": "", "leds": [4]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffba602f601570400000000' becomes b'0ffba602f601570400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=246, data=b'f6 01')
DEBUG:velbus-packet:Received {"name": "SetLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba602f60850040000' becomes b'0ffba602f60850040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=246, data=b'f6 08')
DEBUG:velbus-packet:Received {"name": "SetLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [4]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffba602f610480400000000' becomes b'0ffba602f610480400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=246, data=b'f6 10')
DEBUG:velbus-packet:Received {"name": "SetLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [5]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba602f680d8040000' becomes b'0ffba602f680d8040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=246, data=b'f6 80')
DEBUG:velbus-packet:Received {"name": "SetLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [8]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffb0103a54cfe0304000000' becomes b'0ffb0103a54cfe0304000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=165, data=b'a5 4c fe')
WARNING:velbus-packet:NOT FOUND IN command_registry: addr=1 cmd=165 packet=4c:fe
DEBUG:root:Trimming leading garbage from buffer content: b'0000000ffbe008ed903fff0000c1' becomes b'0ffbe008ed903fff0000c1'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=e0, rtr=False, command=237, data=b'ed 90 3f ff 00 00 c1 0a')
DEBUG:velbus-packet:Received {"name": "ModuleStatusMessage", "priority": 251, "address": 224, "rtr": false, "data": "", "closed": [5, 8], "led_on": [1, 2, 3, 4, 5, 6], "led_slow_blinking": [1, 2, 3, 4, 5, 6, 7, 8], "led_fast_blinking": []}
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=e0, rtr=False, command=234, data=b'ea 08 00 00 35 0e 00 00')
DEBUG:velbus-packet:Received {"name": "TempSensorStatusMessage", "priority": 251, "address": 224, "rtr": false, "data": "", "local_control": 0, "status_mode": "run", "status_str": "run", "auto_send": 8, "mode": "safe", "mode_str": "safe", "cool": 0, "heater": 0, "boost": 0, "pump": 0, "alarm1": 0, "alarm2": 0, "alarm3": 0, "alarm4": 0, "current_temp": 26.5, "target_temp": 7.0, "sleep_timer": 0, "_status_str": "run"}
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=a6, rtr=False, command=0, data=b'00 01 00 00')
DEBUG:velbus-packet:Received {"name": "PushButtonStatusMessage", "priority": 248, "address": 166, "rtr": false, "data": "", "closed": [1], "opened": [], "closed_long": []}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffbc508ed903f810000' becomes b'0ffbc508ed903f810000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c5, rtr=False, command=237, data=b'ed 90 3f 81 00 00 c1 0a')
DEBUG:velbus-packet:Received {"name": "ModuleStatusMessage", "priority": 251, "address": 197, "rtr": false, "data": "", "closed": [5, 8], "led_on": [1, 2, 3, 4, 5, 6], "led_slow_blinking": [1, 8], "led_fast_blinking": []}
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c5, rtr=False, command=234, data=b'ea 08 00 00 33 0a 00 00')
DEBUG:velbus-packet:Received {"name": "TempSensorStatusMessage", "priority": 251, "address": 197, "rtr": false, "data": "", "local_control": 0, "status_mode": "run", "status_str": "run", "auto_send": 8, "mode": "safe", "mode_str": "safe", "cool": 0, "heater": 0, "boost": 0, "pump": 0, "alarm1": 0, "alarm2": 0, "alarm3": 0, "alarm4": 0, "current_temp": 25.5, "target_temp": 5.0, "sleep_timer": 0, "_status_str": "run"}
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=a6, rtr=False, command=0, data=b'00 00 01 00')
DEBUG:velbus-packet:Received {"name": "PushButtonStatusMessage", "priority": 248, "address": 166, "rtr": false, "data": "", "closed": [], "opened": [1], "closed_long": []}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba602f60157040000' becomes b'0ffba602f60157040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=246, data=b'f6 01')
DEBUG:velbus-packet:Received {"name": "SetLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffba602f608500400000000' becomes b'0ffba602f608500400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=246, data=b'f6 08')
DEBUG:velbus-packet:Received {"name": "SetLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [4]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba602f61048040000' becomes b'0ffba602f61048040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=246, data=b'f6 10')
DEBUG:velbus-packet:Received {"name": "SetLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [5]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ff8020400000600ed040000' becomes b'0ff8020400000600ed040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=02, rtr=False, command=0, data=b'00 00 06 00')
DEBUG:velbus-packet:Received {"name": "PushButtonStatusMessage", "priority": 248, "address": 2, "rtr": false, "data": "", "closed": [], "opened": [2, 3], "closed_long": []}
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='Task-229' coro=<VelbusProtocol._process_message() done, defined at /home/dieter/GIT/velbus-aio/velbusaio/protocol.py:167> exception=KeyError('Channels')>
Traceback (most recent call last):
  File "/home/dieter/GIT/velbus-aio/velbusaio/protocol.py", line 169, in _process_message
    await self._message_received_callback(msg)
  File "/home/dieter/GIT/velbus-aio/velbusaio/controller.py", line 55, in _on_message_received
    await self._handler.handle(msg)
  File "/home/dieter/GIT/velbus-aio/velbusaio/handler.py", line 86, in handle
    await (self._velbus.get_module(msg.address)).on_message(msg)
  File "/home/dieter/GIT/velbus-aio/velbusaio/module.py", line 262, in on_message
    for channel_types in self._data["Channels"]:
KeyError: 'Channels'
DEBUG:root:Trimming leading garbage from buffer content: b'00000ff8090400000100eb040000' becomes b'0ff8090400000100eb040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=09, rtr=False, command=0, data=b'00 00 01 00')
WARNING:velbus-packet:UNKNOWN module, you should initialize a full new velbus scan: packet=00:01:00, address=9, modules=dict_keys([1, 2, 3, 4, 5, 16, 17, 18, 19, 20, 21, 32, 33, 34, 35, 36, 37, 144, 160, 176, 161, 177, 163, 179, 164, 180, 165, 181, 166, 182, 167, 183, 168, 169, 192, 193, 184, 194, 210, 195, 211, 196, 212, 197, 213, 198, 214, 199, 215, 200, 216, 201, 217, 224, 240, 250])
DEBUG:root:Trimming leading garbage from buffer content: b'00000ff80a0400000800e3040000' becomes b'0ff80a0400000800e3040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=f8, address=0a, rtr=False, command=0, data=b'00 00 08 00')
WARNING:velbus-packet:UNKNOWN module, you should initialize a full new velbus scan: packet=00:08:00, address=10, modules=dict_keys([1, 2, 3, 4, 5, 16, 17, 18, 19, 20, 21, 32, 33, 34, 35, 36, 37, 144, 160, 176, 161, 177, 163, 179, 164, 180, 165, 181, 166, 182, 167, 183, 168, 169, 192, 193, 184, 194, 210, 195, 211, 196, 212, 197, 213, 198, 214, 199, 215, 200, 216, 201, 217, 224, 240, 250])
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffbc102f540fe0400000000' becomes b'0ffbc102f540fe0400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c1, rtr=False, command=245, data=b'f5 40')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 193, "rtr": false, "data": "", "leds": [7]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffbc102f580be040000' becomes b'0ffbc102f580be040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c1, rtr=False, command=245, data=b'f5 80')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 193, "rtr": false, "data": "", "leds": [8]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffbc802f501360400000000' becomes b'0ffbc802f501360400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c8, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 200, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffbc802f50235040000' becomes b'0ffbc802f50235040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c8, rtr=False, command=245, data=b'f5 02')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 200, "rtr": false, "data": "", "leds": [2]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffbc502f501390400000000' becomes b'0ffbc502f501390400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=c5, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 197, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba802f50156040000' becomes b'0ffba802f50156040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a8, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 168, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffba802f501560400000000' becomes b'0ffba802f501560400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a8, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 168, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba102f50856040000' becomes b'0ffba102f50856040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a1, rtr=False, command=245, data=b'f5 08')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 161, "rtr": false, "data": "", "leds": [4]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffba002f508570400000000' becomes b'0ffba002f508570400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a0, rtr=False, command=245, data=b'f5 08')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 160, "rtr": false, "data": "", "leds": [4]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba602f50158040000' becomes b'0ffba602f50158040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=245, data=b'f5 01')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [1]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffba602f508510400000000' becomes b'0ffba602f508510400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=245, data=b'f5 08')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [4]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffba602f51049040000' becomes b'0ffba602f51049040000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=245, data=b'f5 10')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [5]}
DEBUG:root:Trimming leading garbage from buffer content: b'00000ffba602f580d90400000000' becomes b'0ffba602f580d90400000000'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a6, rtr=False, command=245, data=b'f5 80')
DEBUG:velbus-packet:Received {"name": "ClearLedMessage", "priority": 251, "address": 166, "rtr": false, "data": "", "leds": [8]}
DEBUG:root:Trimming leading garbage from buffer content: b'000000000ffb0103a55100fc0400' becomes b'0ffb0103a55100fc0400'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=01, rtr=False, command=165, data=b'a5 51 00')
WARNING:velbus-packet:NOT FOUND IN command_registry: addr=1 cmd=165 packet=51:00
DEBUG:root:Trimming leading garbage from buffer content: b'000ffba008ed902fd40000c10a03' becomes b'0ffba008ed902fd40000c10a03'
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a0, rtr=False, command=237, data=b'ed 90 2f d4 00 00 c1 0a')
DEBUG:velbus-packet:Received {"name": "ModuleStatusMessage", "priority": 251, "address": 160, "rtr": false, "data": "", "closed": [5, 8], "led_on": [1, 2, 3, 4, 6], "led_slow_blinking": [3, 5, 7, 8], "led_fast_blinking": []}
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=a0, rtr=False, command=234, data=b'ea 08 00 00 33 0a 00 00')
DEBUG:velbus-packet:Received {"name": "TempSensorStatusMessage", "priority": 251, "address": 160, "rtr": false, "data": "", "local_control": 0, "status_mode": "run", "status_str": "run", "auto_send": 8, "mode": "safe", "mode_str": "safe", "cool": 0, "heater": 0, "boost": 0, "pump": 0, "alarm1": 0, "alarm2": 0, "alarm3": 0, "alarm4": 0, "current_temp": 25.5, "target_temp": 5.0, "sleep_timer": 0, "_status_str": "run"}

read_bus.out.txt
load_modules.out.txt

@dverhelst, can you check with the latest dev?
niobos did a lot of work on implementing the dali module

Awesome @Cereal2nd and @niobos !
Attached you can find outputs of read_bus.py and load_modules.py. I switched a few lights on/off during the read_bus run. Hope this helps!
read_bus.out.txt
load_modules.out.txt

You will need to remove the cached memory of the DALI module, and re-run the read_bus/load_module commands. The location depends on your setup, but it will probably be /home/dieter/.velbuscache/1.p

Oops, didn't know, but will forever take it into account.
Here you go, 2 fresh files with a lot of DALI movement.
read_bus.out.txt
load_modules.out.txt

The output looks good. To get this into Home Assistant, this repo needs a release, and the Home Assistant a version bump to use that release.

This is seen in one of the files need to investigate if this is related to the PR.
the load_modules.py is not finishing, we will need to increase the timeout for your install, so we can not confirm yet that it worked
DEBUG:velbus-protocol:RX: RawMessage(priority=fb, address=e0, rtr=False, command=242, data=b'f2 09 ff ff ff ff')
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='Task-1501' coro=<VelbusProtocol._process_message() done, defined at /home/dieter/GIT/velbus-aio/velbusaio/protocol.py:167> exception=ParserError('ChannelNamePart3Message needs exactly one bit set in channel byte')>
Traceback (most recent call last):
  File "/home/dieter/GIT/velbus-aio/velbusaio/protocol.py", line 169, in _process_message
    await self._message_received_callback(msg)
  File "/home/dieter/GIT/velbus-aio/velbusaio/controller.py", line 55, in _on_message_received
    await self._handler.handle(msg)
  File "/home/dieter/GIT/velbus-aio/velbusaio/handler.py", line 93, in handle
    msg.populate(priority, address, rtr, data)
  File "/home/dieter/GIT/velbus-aio/velbusaio/messages/channel_name_part3.py", line 35, in populate
    self.needs_one_channel(channels)
  File "/home/dieter/GIT/velbus-aio/velbusaio/message.py", line 235, in needs_one_channel
    self.parser_error("needs exactly one bit set in channel byte")
  File "/home/dieter/GIT/velbus-aio/velbusaio/message.py", line 134, in parser_error
    raise ParserError(self.__class__.__name__ + " " + message)
velbusaio.message.ParserError: ChannelNamePart3Message needs exactly one bit set in channel byte

Based on the previous output, I concluded that the DALI module has address 1, so I ignored this Traceback.

@dverhelst what module is at address=e0?

That would be a VMBGP2-2 but with outdated firmware which I'm updating right now ( it's the latest addition to the bus ). Same as C8 which has been updated to the latest firmware already.

@dverhelst can you run a new load_modules but let it run a lot longer, we do not have all the data in there

Here you go!
load_modules.out.txt

this looks great
@niobos i'll release a new version so you can make the PR in hass

For reference: https://github.com/home-assistant/core/pull/80510

@ dverhelst today a new RC was released for hass, would you be able to check it out?
to see how the vmbdali reacts?

@Cereal2nd , I ran a quick test from the dev-branch last Friday and all looked quite ok !
There was 'something' with the status of the lights sometimes not being reflected back, but I plan to test some more over the weekend.
I was very happy to see all the lights functioning well!

ok, then we close this ticket, if something else pops-up we can alwasy create a new one

source: gharchive/issue

authors: Cereal2nd dverhelst niobos

license_type: permissive

license_source: github-api


text:
Query may fail if response is empty

Problem
Currently, the query response won't contain schema information if no data is found, which will lead to failure in parsing schema.
Proposal
Avoid parsing schema if no data is found.

Fixed by #17

repo: CeresDB/ceresdb-client-rs


text:
Undo monorepo conversion

This is essentially one big "CTRL+Z" for the things that have been done in https://github.com/CesiumGS/3d-tiles-tools/pull/64 . The goal is to eventually have a single 3d-tiles-tools package, because there have been some open questions about establishing an organization called 3d-tiles-tools on NPM for publishing the scoped @3d-tiles-tools/... packages.
For now, the contents of the workspaces/packages are moved back into a "flat" src folder. The build infrastructure (i.e. the individual tsconfig.json and package.json files) is removed. Further details will be added here soon.

The conversion back to a "not-monorepo" is done.
The original workspaces/packages have been moved back into the top-level /src folder.

Some details:
The directory structure within this folder might look a bit unusual at the first glance: There are files like
src/base/base/Buffers.ts or
src/ktx/ktx/KtxUtility.ts
The reason for that is that the first subdirectory corresponds to the "package name", and the second subdirectory level reflects the structure within that package. Each of the first subdirectory levels contains an index.ts file, like
src/base/index.ts
that exports the "API". One reasoning behind that is that cross-package imports can be written in the form
import { BinaryBufferStructure } from "../../base";
which at least more closely resembles the
import { BinaryBufferStructure } from "@3d-tiles-tools/base";
from the packaged version. The alternative would be to descend into the respective subdirectory within the "package", as in
`import { BinaryBufferStructure } from "../../base/binary/BinaryBufferStructure";
Whether or not this really makes sense or is a good practice? I'm open for comments here...

I tested running the npm install and npm run package scripts (multiple times...).
I've tried out using the resulting package as...

a basis for installing an running the tools as a command line application
a dependency in a CommonJS JavaScript project
a dependency in a ESM JavaScript project
a dependency in a CommonJS TypeScript project
a dependency in a ESM TypeScript project
a dependency for the 3d-tiles-validator.... which actually required zero code changes.

I also ran all demos, and did a short review/cleanup pass of the README and IMPLEMENTATION, and have been ballsy enough to already put a release date into the CHANGES.md. Let's see how this goes...

source: gharchive/pull-request


text:
Holes while camera is moving

Fabric prims don't finish loading until the camera stops moving, which results in holes.
https://user-images.githubusercontent.com/915398/230969896-43627ef8-a840-4905-a5ac-0638ad0bde61.mp4

I've tried a few different options to force synchronous loading, but no luck so far:
app.asyncRendering = false
app.usdrt.scene_delegate.geometryStreaming.enabled = false
rtx.hydra.geometrySyncLoads = true

This was autoclosed in https://github.com/CesiumGS/cesium-omniverse/pull/265 (my mistake for writing fix #255 in that PR summary)

This should be fixed in the next official Kit release. We'll keep this issue open until then.

repo: CesiumGS/cesium-omniverse


text:
Add support for tileset displayColor and displayOpacity

A tileset will now forward its displayColor and displayOpacity attributes over to fabric prims.
Also fixes a long running issue where vertex colors with alpha didn't work: https://github.com/CesiumGS/cesium-omniverse/pull/338
Note:

You need to be in RTX - Interactive to see translucency. Otherwise any alpha less than 1.0 will appear completely black. There's a setting fractionalCutoutOpacity that's false by default for RTX - Real Time.
Omniverse doesn't let you edit Display Color or Display Opacity through the UI, hence the Python script below
These have no affect when using a tileset material. This seems to be consistent with general Omniverse behavior.

https://github.com/CesiumGS/cesium-omniverse/assets/915398/57429baf-ce2e-42af-a541-f795bda968cc
Script from the video:
import omni.usd
import pxr.Gf

stage = omni.usd.get_context().get_stage()
tileset_prim = stage.GetPrimAtPath("/Cesium_World_Terrain")
tileset_prim.GetAttribute("primvars:displayColor").Set([pxr.Gf.Vec3f(0.0, 1.0, 0.0)])
tileset_prim.GetAttribute("primvars:displayOpacity").Set([0.5])

Datasets for testing:

Vertex colors: vertex-color.zip
Regular tileset: tileset-display-color-opacity.zip
Point cloud rgba: point-clouds-rgba.zip (voxel sizes are too big, unrelated to this PR)

You need to be in RTX - Interactive to see translucency. Otherwise any alpha less than 1.0 will appear completely black. There's a setting fractionalCutoutOpacity that's false by default for RTX - Real Time.

Have we asked the Nvidia folks about if handling opacity in the real time renderer is on their radar?

Have we asked the Nvidia folks about if handling opacity in the real time renderer is on their radar?

It seems to be disabled for performance reasons, but can be enabled dynamically by the app / extension.

authors: lilleyse weegeekps


text:
How to style 3D tiles like in CesiumJS?

How to style 3D tiles like in CesiumJS?
https://cesium.com/learn/cesiumjs-learn/cesiumjs-3d-tiles-styling/

Hi @whisper-bye, please use our forum for questions like this,
https://community.cesium.com/c/cesium-for-unity/13
The community could have some great ideas, or will have answered this in the past.
Thanks

repo: CesiumGS/cesium-unity


text:
OpenGLES3 Error when rendering Cesium Tiles on Quest Devic

Reported from the community here,
We started getting this error when we switched to OpenGLES3 from Vulcan. Google seems to point to single pass/double pass issues with the shader.
AndroidPlayer "Oculus_Quest Pro@ADB:230YC01DB200SQ:0" Assertion failed: OPENGL NATIVE PLUG-IN ERROR: GL_INVALID_OPERATION: Operation illegal in current state
You can easily reproduce this in the sample cesium projects if you run them on Quest. The errors only appear when a cesium tile is rendering on Android.
We believe the shader is Cesium_RoundPolygonMask
If we put that in the scene on something unrelated to cesium tiles it doesn’t throw the error. So we assume its a specific pass being used within that shader.

same


text:
Android one wont run - Error Unity DllNotFoundException: CesiumForUnityNative

2024/03/21 20:37:44.121 27203 27307 Error Unity DllNotFoundException: CesiumForUnityNative-Runtime assembly: type: member:(null)
Weirdly I built it fine few days ago but when I try now I get this error. ideas?

Please provide more context. What version of Unity and Cesium for Unity are you using? When does this error occur? Does it also happen in the Cesium for Unity Samples project, or only in your own project? What process architecture are you building for? Keep in mind that Cesium for Unity supports 64-bit processors only: ARM64 and x86-64. Building for ARMv7 won't work.

I think the majority of the issue is the way supply Cesium. Since you supply it so awkwardly (not a package) people have to hack it into their project (ie, copy the assets/ folder from your sample project copy it into their proj and pray, then wait for errors and fix). It somehow worked fine when I first tried your sample proj (ie no hacking, even with ARMV7 worked all was fine, though there is NO way to untick arm7 and tick the others, boxes greyed out - still worked, does not 2 days later), but that too has the exact same issues a few days later (dont ask me how).  Unity 2022.2.21, error occurs when u build it and get it going on android, you see it in logcat. Also cesium has been crashing unity 8 or 9x a day with a segfault even when im not using it (webgl/android platforms both crash), which has made unity very unstable.  So a few mysteries, 1) why dont you ship it as a package? 2) why does it work then die over time, 3) why cant the arm checkboxes be ticked, 4) why does it segfault unity even when not in use?

@amigax we do supply it as a package. Have you seen the Quickstart?
https://cesium.com/learn/unity/unity-quickstart/
Cesium for Unity will definitely not work on ARMv7. The Samples project, however, is already configured to use ARM64, so you wouldn't have had to change anything to get that to work.
As for not being able to untick ARMv7 and tick ARM64 in your own project, that's probably because Unity is configured in your project is configured to use Mono, which only supports ARMv7. Switch to il2cpp and you'll be able to use the other platforms.
WebGL is not supported, and probably crashes when attempting to load the (non-existent) native code. The same will be true on Android if you're tying to use ARMv7.

Oh, sorry I forgot about the quickstar.t. I think it looked too much work so I tried to just use the sample assets. I guess I will start again and use that, seems like a lot of work to get started. I was unable to switch to il2cpp, but I think you need to install that separately somehow if I remember rightly. thanks will have another go.

authors: amigax kring


text:
Rework UCesiumEncodedMetadataComponent -> UCesiumFeaturesMetadataComponent

Part of the large metadata system overhaul. This PR does the following:

Deprecates UCesiumEncodedMetadataComponent.

Includes backward compatibility, so styling should still work.
Removed "Auto Fill" and "Generate Material" functions, to encourage people to upgrade to the new component.

Adds functions for handling different methods of encoding in CesiumEncodedMetadataConversions.h
Deprecates internal namespace CesiumEncodedMetadataUtility. Use CesiumEncodedFeaturesMetadata instead.

Incorporated ability to parse RGB colors from string from metadata-colors (delete that branch after this change?)

Adds support for encoding implicit feature IDs (passes them in a texcoord like other feature ID attributes)
Adds UCesiumFeaturesMetadataComponent.

Now displays descriptions of feature ID sets, separate from property tables
Property table properties now display their actual type info via FCesiumMetadataPropertyDetails. This way, unsupported properties can show up and users can decide if want to try encoding anyways.
Encoding info is displayed /  changed via FCesiumMetadataEncodingDetails.

This allows the user to specify how a property should attempt to be encoded, e.g. "Coerce" or "Parse Color From String".
This can be expanded in C++ for custom encoding functionality.

"Generate Material" now generates nodes for feature ID sets without requiring them to be connected to property tables
"Generate Material" detects when trying to change an asset with unsaved changes, to avoid a crash

Updates the upgrade guide for most of the changes

Example styling on San Francisco Ferry Building, using "Parse Color from String" as encoding method:

This PR does NOT address the following:

Property textures
~Normalized properties (will leave comment)~
~Null feature IDs -- will result in undefined property access in materials, e.g. random property colors will show up~
~Feature IDs aren't working for point cloud attenuation because the vertex factory isn't passing them in. It seems like the texcoord-related parameters are never binding, but I don't understand why :/~

Thanks for the pull request @j9liu!

:heavy_check_mark: Signed CLA found.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.

Got feature IDs in point clouds to work! This is what Montreal Point Cloud looks like with the styling borrowed from CesiumJS. This uses implicit feature IDs.

Just added support for including null feature IDs in the generated material. The value will appear in the description of the feature ID set.

Then, an if statement will be generated with the null feature ID value. It can then be used to do special behavior for "no feature" parts of the model. For example:

09/14 Update
I incorporated the changes from https://github.com/CesiumGS/cesium-native/pull/713, which involved refactoring FCesiumPropertyTableProperty to handle both normalized and non-normalized property views.
This also allows metadata picking and styling to work with offset, scale, noData, and default values from EXT_structural_metadata. I'm attaching the tileset I used for testing, which is modified from the one in CesiumJS's spec data.
TestStructuralMetadata.zip
In this tileset, there is a temperatureCelsius property that is normalized, and has scale defined in the class property. This is overridden by the scale defined in the property table property, which also defines an offset. So this results in the following material nodes:

The offset of 18 and scale of 6 means values are in the range 18-24. If you remap them to a color gradient you can see something like this:

The employeeCount property has a noData value specified, which results in these nodes. It's a bit hard to read visually, but essentially the value is being compared to the noData value. The user must define what happens when it equals the noData value, since no default value is defined for the property.

I also incorporated the changes from https://github.com/CesiumGS/cesium-native/pull/726, which allows omitted properties to be treated as special valid properties, such that their default value can be accessed. In the same example tileset, the year property has a default value specified, and it has absolutely no data in the property table. The property will still be visible while metadata picking, and can also be passed to the material as a parameter.
Set the encoded details on the property to be "Scalar", "Float", and "Coerce". This results in these nodes:

If the property actually encodes a texture with values, they will be used. Otherwise, this falls back on the default value parameter.
@kring This is ready for a look when you get the chance! My changes made the PR bigger, sorry 😅

Just dumping some thoughts / experiences as I run into them...
Material Layer Names
I had a lot of trouble getting styling to work at first. I eventually figured out the problem: I forgot to rename the material layer from Metadata to FeaturesMetadata. 🤦 I don't think there's any action there, it just reinforces the fact that good documentation - perhaps with a troubleshooting section - will be essential!
Offset / Scale
I noticed that when "Has Offset" and "Has Scale" are ticked, extra nodes are generated in the material to handle the offset and scale. The offset and scale values themselves presumably come from the ClassProperty, which makes sense. But I expected I would be able to tick those boxes and still have a working material even if my ClassProperty had no offset and scale. It would just use 0 and 1, respectively. But that doesn't seem to be the case; the material stops working. Is it possible / reasonable to to make this work? It sounds like it might be easy, and it would help for cases where some tiles have an offset/scale and others do not. But if it's difficult it probably isn't a big deal. Same with "Has No Data Value" and "Has Default Value"? I guess you'd need to use NaN or something for those, though, so maybe it's a bad idea.
A Feature ID Set is required
When I read this in the upgrade guide:

Everything that is listed in the descriptions will be encoded, and anything not listed will be skipped. As such, only include feature ID sets and metadata that will be actually used by the application. Otherwise, the unused properties may affect memory and performance.

I initially thought that if I didn't need to use the feature ID directly, I could remove the feature ID set. But that breaks the generated material and makes it impossible to access the property table data. It makes sense that a feature ID is required, so maybe just a doc tweak needed here to make it more obvious?

Undo
I can get a crash like this:

Open a version of the 06_CesiumMetadata level that I have previously converted to use the new system.
Click on the CesiumFeaturesMetadata component attached to the New York City 3D Buildings tileset.
Press Generate Material. The material editor opens.
Without closing the material editor, click the Auto Fill button.
Press Ctrl-Z to undo the Auto Fill. The Editor crashes.

	UnrealEditor-MaterialEditor.dll!FMatExpressionPreview::FMatExpressionPreview(UMaterialExpression * InExpression) Line 70	C++
 	UnrealEditor-MaterialEditor.dll!FMaterialEditor::GetExpressionPreview(UMaterialExpression * MaterialExpression, bool & bNewlyCreated) Line 6306	C++
 	UnrealEditor-MaterialEditor.dll!FMaterialEditor::RefreshExpressionPreviews(bool bForceRefreshAll) Line 6244	C++
 	UnrealEditor-MaterialEditor.dll!FMaterialEditor::PostUndo(bool bSuccess) Line 6039	C++
 	UnrealEditor-UnrealEd.dll!UEditorEngine::BroadcastPostUndoRedo(const FTransactionContext & UndoContext, bool bWasUndo) Line 5392	C++
 	UnrealEditor-UnrealEd.dll!UEditorEngine::HandleTransactorRedoUndo(const FTransactionContext & TransactionContext, bool Succeeded, bool WasUndo) Line 1209	C++
 	[Inline Frame] UnrealEditor-UnrealEd.dll!Invoke(void(UEditorEngine::*)(const FTransactionContext &, bool)) Line 66	C++
 	[Inline Frame] UnrealEditor-UnrealEd.dll!UE::Core::Private::Tuple::TTupleBase<TIntegerSequence<unsigned int>>::ApplyAfter(void(UEditorEngine::*)(const FTransactionContext &, bool) &) Line 324	C++
 	UnrealEditor-UnrealEd.dll!TBaseUObjectMethodDelegateInstance<0,UEditorEngine,void __cdecl(FTransactionContext const &,bool),FDefaultDelegateUserPolicy>::ExecuteIfSafe(const FTransactionContext & <Params_0>, bool <Params_1>) Line 611	C++
 	[Inline Frame] UnrealEditor-UnrealEd.dll!TMulticastDelegate<void __cdecl(FTransactionContext const &,bool),FDefaultDelegateUserPolicy>::Broadcast(const FTransactionContext &) Line 967	C++
 	UnrealEditor-UnrealEd.dll!UTransBuffer::Undo(bool bCanRedo) Line 1550	C++
 	UnrealEditor-UnrealEd.dll!UEditorEngine::UndoTransaction(bool bCanRedo) Line 1426	C++
 	UnrealEditor-UnrealEd.dll!UEditorEngine::Exec_Transaction(const wchar_t * Str, FOutputDevice & Ar) Line 5376	C++
 	UnrealEditor-UnrealEd.dll!UEditorEngine::Exec(UWorld * InWorld, const wchar_t * Stream, FOutputDevice & Ar) Line 5770	C++
 	UnrealEditor-UnrealEd.dll!UUnrealEdEngine::Exec(UWorld * InWorld, const wchar_t * Stream, FOutputDevice & Ar) Line 659	C++
 	UnrealEditor-MainFrame.dll!FMainFrameActionCallbacks::ExecuteExecCommand(FString Command) Line 547	C++
 	[Inline Frame] UnrealEditor-MainFrame.dll!Invoke(void(*)(FString) &) Line 47	C++
 	[Inline Frame] UnrealEditor-MainFrame.dll!UE::Core::Private::Tuple::TTupleBase<TIntegerSequence<unsigned int,0>,FString>::ApplyAfter(void(*)(FString) &) Line 324	C++
 	UnrealEditor-MainFrame.dll!TBaseStaticDelegateInstance<void __cdecl(void),FDefaultDelegateUserPolicy,FString>::ExecuteIfSafe() Line 731	C++
 	UnrealEditor-Slate.dll!FUICommandList::ConditionalProcessCommandBindings(const FKey Key, bool bCtrl, bool bAlt, bool bShift, bool bCmd, bool bRepeat) Line 217	C++
 	UnrealEditor-Slate.dll!FUICommandList::ProcessCommandBindings(const FKeyEvent & InKeyEvent) Line 161	C++
 	UnrealEditor-MainFrame.dll!FMainFrameActionCallbacks::OnUnhandledKeyDownEvent(const FKeyEvent & InKeyEvent) Line 256	C++
 	[Inline Frame] UnrealEditor-MainFrame.dll!Invoke(FReply(*)(const FKeyEvent &) &) Line 47	C++
 	[Inline Frame] UnrealEditor-MainFrame.dll!UE::Core::Private::Tuple::TTupleBase<TIntegerSequence<unsigned int>>::ApplyAfter(FReply(*)(const FKeyEvent &) &) Line 324	C++
 	UnrealEditor-MainFrame.dll!TBaseStaticDelegateInstance<FReply __cdecl(FKeyEvent const &),FDefaultDelegateUserPolicy>::Execute(const FKeyEvent & <Params_0>) Line 721	C++
 	[Inline Frame] UnrealEditor-Slate.dll!TDelegate<FReply __cdecl(FKeyEvent const &),FDefaultDelegateUserPolicy>::Execute(const FKeyEvent &) Line 588	C++
 	UnrealEditor-Slate.dll!FSlateApplication::ProcessKeyDownEvent(const FKeyEvent & InKeyEvent) Line 4473	C++
 	UnrealEditor-Slate.dll!FSlateApplication::OnKeyDown(const int KeyCode, const unsigned int CharacterCode, const bool IsRepeat) Line 4360	C++

Assertion failure here. Probably lucky it wasn't a crash?

Assertion failed: (Index >= 0) & (Index < ArrayNum) [File:C:\Program Files\Epic Games\UE_5.0\Engine\Source\Runtime\Core\Public\Containers\Array.h] [Line: 691]
Array index out of bounds: 0 from an array of size 0
A breakpoint instruction (__debugbreak() statement or a similar call) was executed in UnrealEditor-Win64-DebugGame.exe.

	UnrealEditor-CesiumRuntime-Win64-DebugGame.dll!UCesiumPrimitiveFeaturesBlueprintLibrary::GetFeatureIDFromFace(const FCesiumPrimitiveFeatures & PrimitiveFeatures, __int64 FaceIndex, __int64 FeatureIDSetIndex) Line 138	C++
 	UnrealEditor-CesiumRuntime-Win64-DebugGame.dll!UCesiumPrimitiveFeaturesBlueprintLibrary::execGetFeatureIDFromFace(UObject * Context, FFrame & Stack, void * const Z_Param__Result) Line 82	C++
 	UnrealEditor-CoreUObject.dll!UObject::execCallMathFunction(UObject * Context, FFrame & Stack, void * const Z_Param__Result) Line 945	C++
 	[Inline Frame] UnrealEditor-CoreUObject.dll!FFrame::Step(UObject *) Line 422	C++
 	UnrealEditor-CoreUObject.dll!UObject::execLet(UObject * Context, FFrame & Stack, void * const Z_Param__Result) Line 2656	C++
 	[Inline Frame] UnrealEditor-CoreUObject.dll!FFrame::Step(UObject *) Line 422	C++

My blueprint looked like this:

And the crash happened when my line trace missed the New York tileset and hit Cesium World Terrain instead.

I tried to use the fancy new "Parse Color from String" to color Cesium OSM Buildings, but I couldn't quite get it to work. I'm probably missing something small. The closest I got was this:

I set up the property encoding like this:

The material layer is pretty simple:

And it's incorporate into this material instance:

There are a bunch of message like this in the log:

LogCesium: Warning: The value type of the metadata property cesium#color does not match the type specified by the metadata description. It will still attempt to be encoded, but may result in empty or unexpected values.

Which is expected. Not all buildings have a color. Ideally I'd be able to specify a default value when the string can't be parsed as a color. Is this possible?

Thanks @kring for the thorough testing! I've gone through your comments and will address them incrementally.

I expected I would be able to tick those boxes and still have a working material even if my ClassProperty had no offset and scale. It would just use 0 and 1, respectively. But that doesn't seem to be the case; the material stops working. Is it possible / reasonable to to make this work?

Ah yes -- this was unintentional, and I'm adding a fix for it in my next commit.

Same with "Has No Data Value" and "Has Default Value"? I guess you'd need to use NaN or something for those, though, so maybe it's a bad idea.

Yeah... the "no data" value and default value are a little trickier, and there's (understandably) no fallback values provided by the spec. My initial thought was just pick the value 0 for both, so the value would be unchanged if both "Has No Data Value" and "Has Default Value" were true. But if only "Has No Data Value" is true, then we have just picked some arbitrary value from the data to be null, which isn't too great.
Following that, I then thought might be useful to specify custom "no data" or default values under the "Encoding Details". The value could be used as a fallback if the class property didn't provide such values -- or as an override, if desired. This could also be used to address this comment:

Ideally I'd be able to specify a default value when the string can't be parsed as a color. Is this possible?

But I worry the UI for this may be convoluted. The type of the values is determined by the type of the property -- at least, the type that it is trying to coerce to in the "Encoding Details". So the method of displaying / editing values in the UI would have to change based on that type. I'm not familiar with how to build custom editor UIs in Unreal, so I have no idea how feasible this is. Do you have any insights from the work you incorporated from #646 ?
If a custom UI isn't feasible, one workaround is to have users specify as a string, and have it attempt to parse a scalar / vector value from there. We could also simply document that it is a limitation of the metadata system that users should be aware of if the class definitions differ across a tileset. Any feelings about either option?

The commit I recently pushed does the following:

Use gsl::span instead of void* when encoding
Remove unintentional requirement of Feature ID sets for property tables
Fix typo that allowed a crash in GetFeatureIDFromFace

We talked offline about letting users specify their own "no data" / default values. Ultimately, we'll document the issue as a known limitation for now. While it's not impossible to implement, it's a bit out of the way for now.

Open a version of the 06_CesiumMetadata level that I have previously converted to use the new system.
Click on the CesiumFeaturesMetadata component attached to the New York City 3D Buildings tileset.
Press Generate Material. The material editor opens.
Without closing the material editor, click the Auto Fill button.
Press Ctrl-Z to undo the Auto Fill. The Editor crashes.

Auto Fill wasn't recording the changes to itself, so I've fixed that. But the crash actually happens whenever you're trying to do undo the "Generate Material" step. This keeps crashing in the "MaterialEditor::PostUndo" step where:

if there is a user-added node in the material, it crashes at GetExpressionPreview(UMaterialExpression * MaterialExpression, bool & bNewlyCreated) because InExpression->Material is null
if there is no user-added node in the material, it crashes at GetTabManager()->TryInvokeTab(FMaterialEditorTabs::GraphEditor);

It should be noted that with this window closed, undoing does not crash the application. So there's something with the Editor window that isn't able to handle our material changes via code, but not sure why. I'm trying to compare our code to other Editor code, but it's not obvious what we're missing.
For now, I think I'll focus on finishing the "Upgrade to 2.0" guide and then requesting another review. It's definitely important to fix the crash but given time constraints, maybe we can just list it as a known issue for now?

It's definitely important to fix the crash but given time constraints, maybe we can just list it as a known issue for now?

Yep that makes sense to me.

So I tried playing around with cesium#color on Cesium OSM buildings today. It looks like this in CesiumJS

(this is mainly for my personal reference)

In @kring 's screenshots, many buildings are bright white is because the colors are sent to the material as-is, in the range 0-255. Since Unreal colors are meant to be from 0-1, this results in really bright colors. The only reason the other non-white colors are showing up are because they don't use all three color components, so they're able to look red / yellow / green.
So we'd have to divide by 255 in the material before passing the color into the Base Color field. This is better, but it still results in really bright colors...

I thought perhaps this was a colorspace issue, and adding an "sRGB to Linear" node definitely desaturates all of the colors. But it looks rather grayscale...

But if you multiply this grayscale by the normalized color, it looks better!

This is the material graph that resulted in the above:

Something I also tried at first was dividing by 2550 instead of 255, without the sRGB to Linear / multiply nodes. It looks closer to the CesiumJS colors, but OSM Buildings in CesiumJS seem generally "darker" than Unreal, so I'm not sure if this is necessarily more correct.

In brief, I think that the data is passing accurately to the Unreal material, but there needs to be extra steps to convert it to a linear color. And it's possible, but I'm not sure if what I'm doing is correct.

Also, I tried adding an If node to catch the pure black (0, 0, 0) colors. And if so, use a default color of white. It makes the buildings look a nicer together, but weirdly, it changes a red building on the right to blue!

No default color
With default color

So I don't understand what's going on there 🤔 This is the material graph for the second screenshot:

@kring Now that CI has passed, this is ready for another review!

I got Cesium OSM Buildings working well!

Here's unlit so you can see the colors are correct:

It's still doing that thing where the one red building becomes blue. No idea! But the rest look correct.
To get this to work, though, I had to add this weird hack where I add 1 to the feature IDs. It seems they're all off by 1? Unless I'm doing something stupid (entirely possible!) that seems like a bug.

The other key bit is that Unreal's sRGBToLinear function only operates on a single float, not a whole vector. If you try to use it on a whole vector, Unreal helpfully grabs the red channel, converts it to linear, and then copies that to all the components. Hence the grayscale. The mind boggles. But anyway, easy fix. Here's the key part of the material:

Adding 1 to the feature ID seems to make it better overall, but there are a few cases where it's correct without the +1, and it becomes wrong with it. So I guess it's more subtle than a simple off-by-one.

Finally figured it out. Floating point precision. It's always floating point precision.
The old metadata styling system had a custom node with code like this:
uint propertyIndex = round(PropertyIndexUV.r);
uint width;
uint height;
Year_array.GetDimensions(width, height);
uint pixelX = propertyIndex % width;
uint pixelY = propertyIndex / width;

The new one looks like this:
uint _czm_width;
uint _czm_height;
cesium_color_DATA.GetDimensions(_czm_width, _czm_height);
uint _czm_pixelX = FeatureID % _czm_width;
uint _czm_pixelY = FeatureID / _czm_width;
cesium_color = asuint(cesium_color_DATA.Load(int3(_czm_pixelX, _czm_pixelY, 0)).rgb);
return FeatureID;

FeatureID is always rounded before it's passed into this function, but it's still a float (even though the value is an integer). When we use / and % on a float, we're not guaranteed to get integers. And then when we clamp them to integers, we'll sometimes end up with the next lowest integer instead.
I changed it to this, and all is well:
uint _czm_width;
uint _czm_height;
cesium_color_DATA.GetDimensions(_czm_width, _czm_height);
uint index = round(FeatureID);
uint _czm_pixelX = index % _czm_width;
uint _czm_pixelY = index / _czm_width;
cesium_color = asuint(cesium_color_DATA.Load(int3(_czm_pixelX, _czm_pixelY, 0)).rgb);
return FeatureID;

I also went through and changed all the metadata-related texture creation code to be sure to set the sRGB flag to false, because we don't want Unreal to mess with our texture values when it loads them.
And the red building turning cyan? Yeah that's caused by the If node doing a component-wise comparison. It treats the X,Y,Z channels are completely separate and does the comparison on each. So if we have this:

Then any component that is zero will be changed to 192. It doesn't require that all of the components be zero. 🙄

Replace the if with a custom node and I think it's finally all working!
return all(color == float3(0.0, 0.0, 0.0)) ? float3(192.0, 192.0, 192.0) : color;

Well, I certainly can't claim to have reviewed every line of code here, but I've played around with it quite a bit, and I think it looks really, really good! I think you've been extremely thorough (This PR single-handedly increases our test count 10x!). So I'm going to merge this into the staging branch. You should probably take a look at the changes I've made @j9liu to make sure I haven't done anything terrible, and then feel free to merge it to ue5-main whenever you're ready! 🎉🚀:shipit:

Thanks for the thorough reviewing @kring! Don't worry about not poring over the code, there's around 20K changed lines and only so much time :')

authors: cesium-concierge j9liu kring

repo: CesiumGS/cesium-unreal


text:
Template to confirm project delete

Closes #75

@bennovack sorry, one last thing -- could you close this PR and re-open it against the development branch instead?

authors: bennovack themightychris

repo: CfABrigadePhiladelphia/laddr

license: mit

license_source: bigquery


text:
Latest gnomesome doew not work properly on GNOME Shell 3.28.4

When installing the latest version of gnomesome from git on Ubuntu 18.04.4 LTS, https://extensions.gnome.org/local/ displays "Error" (instead of "ON" or "OFF").
$ gnome-shell --version
GNOME Shell 3.28.4

At first sight everything still works, except launching a new terminal with Mod4+return.
When reverting to 2e19a64242ced00ed533e0b458e890721a3f0a40, everything works again.

@ghuls Could you let us know how to revert to 2e19a64242ced00ed533e0b458e890721a3f0a40?

git checkout 2e19a64242ced00ed533e0b458e890721a3f0a40

authors: francisco-simoes ghuls

repo: ChWick/gnomesome


text:
chore: upgrade rust toolchain to 1.74

Summary of changes

Changes introduced in this pull request:

upgrade rust toolchain to 1.74
fix clippy warnings
simplify code with the newly stabilized std::io::Error::other

warning: `&` without an explicit lifetime name cannot be used here
  --> src/shim/machine/manifest.rs:30:31
   |
30 |     const MANDATORY_BUILTINS: &[BuiltinActor] = &[BuiltinActor::Init, BuiltinActor::System];
   |                               ^
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #115010 <https://github.com/rust-lang/rust/issues/115010>
   = note: `#[warn(elided_lifetimes_in_associated_constant)]` on by default
help: use the `'static` lifetime
   |
30 |     const MANDATORY_BUILTINS: &'static [BuiltinActor] = &[BuiltinActor::Init, BuiltinActor::System];

Reference issue to close (if applicable)

Closes
Other information and links

Change checklist

[x] I have performed a self-review of my own code,
[x] I have made corresponding changes to the documentation,
[x] I have added tests that prove my fix is effective or that my feature works (if possible),
[x] I have made sure the CHANGELOG is up-to-date. All user-facing changes should be reflected in this document.

no green checkmark, no review!

no green checkmark, no review!

@LesnyRumcajs  Fixed

repo: ChainSafe/forest


text:
Run permanent node in cloud with Alerts

[x] Fix dockerhub image builds, build on master and tag
[x] Setup a node + validator on Pyrmont to Contabo
[x] Setup watchtower to update automatically
[ ] Setup Grafana alerts to Discord

got a beacon node running on contabo-2.  trying to get the validator set up on there too

Just setup a node at contabo-1. If you want  @3xtr4t3rr3str14l  you can setup a validator there, right now there's only the node

@dapplion  sure, i'll set it up there instead.

I have no idea how this reopened 😄

authors: 3xtr4t3rr3str14l dapplion mpetrunic

repo: ChainSafe/lodestar


text:
Build and collect docs CI broken

Describe the bug
After merging ESM seems the Build and collect CI step needs tweaking
https://github.com/ChainSafe/lodestar/runs/6604580588?check_suite_focus=true
lerna info Executing command in 1 package: "yarn run build:refdocs"
@chainsafe/lodestar-cli: $ ts-node docsgen docs/cli.md
@chainsafe/lodestar-cli: TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /home/runner/work/lodestar/lodestar/packages/cli/docsgen/index.ts
@chainsafe/lodestar-cli:     at new NodeError (node:internal/errors:372:5)
@chainsafe/lodestar-cli:     at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:76:11)
@chainsafe/lodestar-cli:     at defaultGetFormat (node:internal/modules/esm/get_format:118:38)
@chainsafe/lodestar-cli:     at defaultLoad (node:internal/modules/esm/load:21:20)
@chainsafe/lodestar-cli:     at ESMLoader.load (node:internal/modules/esm/loader:407:26)
@chainsafe/lodestar-cli:     at ESMLoader.moduleProvider (node:internal/modules/esm/loader:326:22)
@chainsafe/lodestar-cli:     at new ModuleJob (node:internal/modules/esm/module_job:66:26)
@chainsafe/lodestar-cli:     at ESMLoader.#createModuleJob (node:internal/modules/esm/loader:345:17)
@chainsafe/lodestar-cli:     at ESMLoader.getModuleJob (node:internal/modules/esm/loader:304:34)
@chainsafe/lodestar-cli:     at async Promise.all (index 0) {
@chainsafe/lodestar-cli:   code: 'ERR_UNKNOWN_FILE_EXTENSION'
@chainsafe/lodestar-cli: }
@chainsafe/lodestar-cli: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
@chainsafe/lodestar-cli: error Command failed with exit code 1.

As mentioned in June 10th's call, we should fix this ASAP alongside Doppelganger before releasing a v0.39.0

Is this issue related to https://github.com/ChainSafe/lodestar/pull/4144 ? If so, we can close this too.

authors: dapplion philknows


text:
Backup for Metrics server

As a backup strategy we want to persist metrics data on a storage bucket. Solution need to be cost efficient.
Data to be backed up :

Grafana volume
Loki volume
Kuma volume
Prometheus volume

I don't think this issue belongs here, @philknows can you transfer?

I am creating a new repo for generic infrastructure and will move this today.

authors: Aminechakr dapplion jonpurdy


text:
K8s deployment recommendation

I've dockerized a chainlit application and I would like to run it in a kubernetes environment to enable multiple concurrent users.  Is there any guidance on how best to do this?  Simply run some number of pods in a deployment behind either an Ingress or Load Balancer?

No special advice except that your load balancer should have sticky sessions since Chainlit uses web sockets. I would also not spawn lots of pods, one pod should handle hundreds of users.

repo: Chainlit/chainlit


text:
Unable to download kotlin meta artifact missing for 1.0.6

I'll try to use qr-kit 1.0.6 but gradle is unable to download a meta artifact qr-kit-iossimulatorarm64-1.0.6-metadata.jar see exception below:
Execution failed for task ':composeApp:transformIosTestCInteropDependenciesMetadataForIde'.
> Could not resolve all files for configuration ':composeApp:iosSimulatorArm64TestCompilationDependenciesMetadata'.
   > Could not find qrcodeScanner-iossimulatorarm64-metadata.jar (network.chaintech:qr-kit-iossimulatorarm64:1.0.6).
     Searched in the following locations:
         https://plugins.gradle.org/m2/network/chaintech/qr-kit-iossimulatorarm64/1.0.6/qr-kit-iossimulatorarm64-1.0.6-metadata.jar

I tried 1.0.5 but got missing cmp-image-pick-n-crop:1.0.6
Execution failed for task ':composeApp:transformIosTestCInteropDependenciesMetadataForIde'.
> Could not resolve all files for configuration ':composeApp:iosTestResolvableDependenciesMetadata'.
   > Could not find network.chaintech:cmp-image-pick-n-crop:1.0.6.
     Required by:
         project :composeApp > network.chaintech:qr-kit:1.0.5

Are these artefacts missing?

Can you Please check in V 1.0.8 and let us know if it's working or not

@dzwicker if it's fixed let us know so we can close this issue

@dzwicker  if it's fixed let us know so we can close this issue

Sorry, hollidays. Will check.

@dzwicker Please check in Latest version

There is no reply on this thread so we believe that it's fixed, if it's still there you can reopen this thread!

authors: RT-000 ctn-mobile-innovation dzwicker


text:
fix: 查询使用量支持代理&修正使用量文案

查询使用量文案同步更正，函数名同步语义化。
查询使用量接口支持走代理。

再帮忙测试下有代理的情况下是否会异常～感谢

再帮忙测试下有代理的情况下是否会异常～感谢

测试正常。

repo: Chanzhaoyu/chatgpt-web

license: MIT


text:
Cow: Watch universemetal.com

Cow requests the watch of the watch_keyword universemetal\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

universemetal\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ

authors: SmokeDetector metasmoke

repo: Charcoal-SE/SmokeDetector


text:
Cow: Watch instapromanager.com

Cow requests the watch of the watch_keyword instapromanager\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

instapromanager\.com has been seen in 2 true positives, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


text:
Cow: Watch skalet.agency

Cow requests the watch of the watch_keyword skalet\.agency. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

skalet\.agency has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


text:
Vickel: Watch +51-1705-0255(?#NO NorAm)

Vickel requests the watch of the watch_number +51-1705-0255(?#NO NorAm). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Jeff Schaller in Charcoal HQ


text:
General Grievance: Watch revcord.com

General Grievance requests the watch of the watch_keyword revcord\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

revcord\.com has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


text:
cigien: Watch kiperline.com

cigien requests the watch of the watch_keyword kiperline\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

kiperline\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


text:
Yatin: Watch whitebazaar.in

Yatin requests the watch of the watch_keyword whitebazaar\.in. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

whitebazaar\.in has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by cigien in Charcoal HQ


text:
Ethan: Blacklist (?-i:W4qNH0h)(?#cutt.ly)

Ethan requests the blacklist of the website (?-i:W4qNH0h)(?#cutt.ly). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

(?-i:W4qNH0h)(?#cutt.ly) has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Approved by cocomac in Charcoal HQ


text:
Ian Campbell: Watch gardreen.com

Ian Campbell requests the watch of the watch_keyword gardreen\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

gardreen\.com has been seen in 2 true positives, 0 false positives, and 0 NAAs.

Approved by Spevacus in Charcoal HQ


text:
Dragonrage: Watch delmarpharma.com

Dragonrage requests the watch of the watch_keyword delmarpharma\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

delmarpharma\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by cigien in Charcoal HQ


text:
Jesse: Watch ayurleafherbals.com

Jesse requests the watch of the watch_keyword ayurleafherbals\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

ayurleafherbals\.com has been seen in 2 true positives, 0 false positives, and 0 NAAs.

Approved by cigien in Charcoal HQ


text:
user16217248: Blacklist dissertationhomework.com

user16217248 requests the blacklist of the website dissertationhomework\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Rejected by Jeff Schaller in Charcoal HQ. Reason: 'only 2 TP seen so far, which doesn't yet qualify for blacklisting'


text:
Not compatible with the two stable versions of Forge (v11 b315 or v12 Stable 5)

When I try to download the .zip file using either of the recommended stable versions of Foundry on the Forge, this module states that it is not compatible with the core system (Version 11 Build 315 or Version 12 Stable 5).
Do you have a recommended version to use this module with?
(P.S. Also, do you have a Discord for easier conversation? I have no idea how to use GitHub...)

You shouldn't manually download the source code, you should probably just use the manifest URL or grab it from the module list?

authors: ChasarooniZ noellescoa

repo: ChasarooniZ/ready-for-the-stage


text:
added a blog

Fixes # .
Make sure these boxes are checked before creating your pull request -- thank you!

[x] Add Blog Header, including title, author, date.
e.g.

---

 title: "'Score Your Face Photo' a ML&Wechaty practice"
 date: 2017-09-18 09:00 +0800
 author: huyingxi
 ---

 > Author: [@huyingxi](https://github.com/huyingxi/wechaty_selfie) enjoying ML&Wechaty at BUPT

[x] Keep all filenames & url as lowercase, and use - to connect words instead of space. e.g. 2017-10-06-wechat-pc-impactor instead of 2017-10-06-WeChat PC Impactor,
[x] Embed the photo & video before publishing, save all external file to the blog /download/2018 directory.
[ ] Add <!--more--> section to just show the abstract in blog homepage.

See more

 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.

Cloud you please fix the problems which failed the CI, and add your self as an author to the author data file at https://github.com/Chatie/blog/blob/master/docs/_data/authors.yml with your GitHub username?
And please also remember to reference yourself with the Github username in your blog post, so that we can have nice author information besides your blog after we published it!

 All committers have signed the CLA.

Kindly ping @Jesn

ping @Jesn

ping @Jesn

ping @Jesn
If you couldn't fix this pr, I will close this at the end of May.
Thanks!

Close this pull request for a long time no reply.

authors: CLAassistant Jesn claassistantio huan lijiarui

repo: Chatie/blog


text:
hello I would like to collaborate with your project by serving as a translator to Spanish which is my native language could translate the readme, contributing and any other text document as a license among others

Provide Your Network Information

Where is the location of your server? (i.e. City, or In/Out China)
Which cloud platform(AliYun/Qcloud/DigitalOcean/etc) are you using?

Run npm run doctor or wechaty run doctor(for docker user), paste output here
Expected behavior
Actual behavior
Steps to reproduce the behavior (and fixes, if any)
Full Output Logs
$ WECHATY_LOG=silly npm run ts-node mybot.ts

# or

$ WECHATY_LOG=silly node dist/mybot.js

Show Logs

### Paste the full output logs here with `WECHATY_LOG=silly` set
# PASTE FULL LOG OUTPUT AT HERE:

Welcome to join us! We are so glad to hear this, pull request is welcome, and if you have any doc problem, feel free to contact with me.

@UlisesTJ https://github.com/cockroachdb/cockroach/issues/23038#issuecomment-368220870

ok translate all the text documents as changelog, code_of_conduct, contributing and readme. I'm already working @lijiarui

@UlisesTJ have you made any progress this far? did you bumped into any problem at all?

Close this issue due to:

It's not active
It's not very necessary

authors: UlisesTJ knz lijiarui suntong zixia

repo: Chatie/wechaty


text:
Cannot send pdf file using MediaMessage

Cannot send pdf file,  It can send pic successfully but not pdf file.
related to #538
It says pdf file sending 0 data.
get the following sending result:

log as follows:
TaskList: #TALK #3 #SUCCEED #interval: 3 #taskLog: broadcast file
21:02:29 SILL Message constructor() SN:6
21:02:29 VERB Room say(5步获得AWS的6万云服务代金券.pdf, )
TALK Task Done
21:02:29 VERB PuppetWebBridge getBaseRequest()
21:02:29 VERB PuppetWebBridge proxyWechaty(getBaseRequest, )
21:02:29 SILL PuppetWebBridge execute()
21:02:29 SILL PuppetWebBrowser Browser.execute("return typeof WechatyBro === "undefined"")
21:02:29 SILL StateSwitch Browser:target() is open
21:02:29 SILL StateSwitch Browser:current() is open
21:02:29 SILL PuppetWebBridge execute()
21:02:29 SILL PuppetWebBrowser Browser.execute(" const callback = arguments[arguments.length - 1] const isAsync = (typeof  ... ")
21:02:29 SILL StateSwitch Browser:target() is open
21:02:29 SILL StateSwitch Browser:current() is open
21:02:29 VERB PuppetWebBridge getPassticket()
21:02:29 VERB PuppetWebBridge proxyWechaty(getPassticket, )
21:02:29 SILL PuppetWebBridge execute()
21:02:29 SILL PuppetWebBrowser Browser.execute("return typeof WechatyBro === "undefined"")
21:02:29 SILL StateSwitch Browser:target() is open
21:02:29 SILL StateSwitch Browser:current() is open
21:02:29 SILL PuppetWebBridge execute()
21:02:29 SILL PuppetWebBrowser Browser.execute(" const callback = arguments[arguments.length - 1] const isAsync = (typeof  ... ")
21:02:29 SILL StateSwitch Browser:target() is open
21:02:29 SILL StateSwitch Browser:current() is open
21:02:29 VERB PuppetWebBridge getUploadMediaUrl()
21:02:29 VERB PuppetWebBridge proxyWechaty(getUploadMediaUrl, )
21:02:29 SILL PuppetWebBridge execute()
21:02:29 SILL PuppetWebBrowser Browser.execute("return typeof WechatyBro === "undefined"")
21:02:29 SILL StateSwitch Browser:target() is open
21:02:29 SILL StateSwitch Browser:current() is open
21:02:29 SILL PuppetWebBridge execute()
21:02:29 SILL PuppetWebBrowser Browser.execute(" const callback = arguments[arguments.length - 1] const isAsync = (typeof  ... ")
21:02:29 SILL StateSwitch Browser:target() is open
21:02:29 SILL StateSwitch Browser:current() is open
21:02:29 VERB PuppetWebBrowserCookie read()
21:02:29 SILL PuppetWebBrowserCookie read() webwx_data_ticket,MM_WX_SOUND_STATE,webwx_auth_ticket,MM_WX_NOTIFY_STATE,mm_lang,wxloadtime,wxpluginkey,pgv_si,wxsid,wxuin,webwxuvid,pgv_pvi
21:02:29 VERB PuppetWebBrowser hostname()
21:02:29 SILL PuppetWebBrowser Browser.execute("return document.domain")
21:02:29 SILL StateSwitch Browser:target() is open
21:02:29 SILL StateSwitch Browser:current() is open
21:02:29 SILL PuppetWebBrowser hostname() got qq.com
21:02:29 VERB PuppetWeb self()
21:02:31 SILL PuppetWebEvent onServerDing(heartbeat@browser)
21:02:31 SILL PuppetWebWatchdog onFeed: 60000, HEARTBEAT[heartbeat@browser]
21:02:31 SILL StateSwitch Puppet:target() is live
21:02:31 SILL StateSwitch Puppet:inprocess() is false
21:02:31 SILL PuppetWebWatchdog clearWatchDogTimer() [45] seconds left
21:02:31 SILL PuppetWebWatchdog setWatchDogTimer(60000, HEARTBEAT:[heartbeat@browser])
21:02:31 SILL PuppetWebWatchdog monitorScan(HEARTBEAT)
21:02:31 SILL PuppetWebWatchdog autoSaveSession()
21:02:31 SILL PuppetWebWatchdog memoryCheck() free: 29 MB, require: 4 MB
21:02:31 SILL PuppetWeb send() destination: @@688884a466d382ba5040e2c0bfbe7fa327ac813f4edb6169b2620431f8a385ee, mediaId: @crypt_351c728f_7f1c3d10846338c49d6439fbd8905cd9e6f2b2af3b04e4e4d5ab428c45bdc809ee7c083f0c5581866c6160b38618077469013b833539b6fb6df8342bf10281537534ec64a4e84e630902eb0702007606)
21:02:31 VERB PuppetWebBridge proxyWechaty(sendMedia, @@688884a466d382ba5040e2c0bfbe7fa327ac813f4edb6169b2620431f8a385ee, @crypt_351c728f_7f1c3d10846338c49d6439fbd8905cd9e6f2b2af3b04e4e4d5ab428c45bdc809ee7c083f0c5581866c6160b38618077469013b833539b6fb6df8342bf10281537534ec64a4e84e630902eb0702007606, 49)
21:02:31 SILL PuppetWebBridge execute()
21:02:31 SILL PuppetWebBrowser Browser.execute("return typeof WechatyBro === "undefined"")
21:02:31 SILL StateSwitch Browser:target() is open
21:02:31 SILL StateSwitch Browser:current() is open
21:02:31 SILL PuppetWebBridge execute()
21:02:31 SILL PuppetWebBrowser Browser.execute(" const callback = arguments[arguments.length - 1] const isAsync = (typeof  ... ")
21:02:31 SILL StateSwitch Browser:target() is open
21:02:31 SILL StateSwitch Browser:current() is open

Donate for this issue $20 here :
https://www.bountysource.com/issues/48000926-cannot-send-pdf-file-using-mediamessage
Anyone who solve this problem will get the donation.

已解决，发图占坑，稍后pr

authors: binsee lijiarui


text:
Can't send messages [Windows 11]

Checklist

[X] I'm reporting a problem with Chatterino
[X] I've verified that I'm running the most recent nightly build or stable release
[X] I've looked for my problem on the wiki
[X] I've searched the issues and pull requests for similar looking reports

Describe your issue
Since installing Windows 11, I can't use the enter key to send messages. When I press enter, it adds a new line to my message instead of sending it.
Screenshots
No response
OS and Chatterino Version
Windows 11 (version 21H2 | build # 22000.376),  Chatterino Nightly 2.3.4 (commit 79db02aa6, )

#3363 with https://github.com/Chatterino/chatterino2/issues/2844
You should be able to see the channel name highlighted in white when this issue happens, and highlighted in blue (via actually clicking into chatterino) when the issue is "resolved"

vs

I still get this bug every now and then, no idea what causes it; but seems to somewhat be when I open a new split (not consistent)

I only get this when I disable the "show input when it's empty" setting, in which case it happens quite frequently. Quiet annoying as I like this setting 😞

I only get this when I disable the "show input when it's empty" setting, in which case it happens quite frequently.

Yes, that setting is sadly a bit buggy rn, in that it messes with the way splits are being focused. If you take a look at the channel name in the split header, if the split is currently focused it should appear blue.
Now, with “Show input when its empty” disabled, press i.e. Ctrl+E to open the emote picker and close it again using ESC. You will see that while you can still type messages, the split itself is no longer focused (channel name is displayed white) and does not receive key presses correctly, which results in all hotkeys seizing to function (see #2714 #2844). Previously that meant things like Ctrl+E, Ctrl+F etc stopped working, but since #2340 that includes whatever keybinding you have set to send a message as well, thus enter is not being caught by chatterino itself but instead the text field just creates a new line.

Fixed. Turns out all of my keybindings had been removed somehow.

@mfmarlow did you happen to turn off your PC while Chatterino was still running? I have a little suspicion that hotkeys don't save properly if you do that but instead they just get emptied.

I just updated Chatterino last night. Coming from a month or 2 old build and I get this issue way too much. Basically I can't chat at all. Haven't had it before ever.

[14:34:16.059] Mm2PL: if it's empty just reset it FeelsDankMan
[14:34:39.471] VulpesHD: okay that fixed it PagMan

had this issue today, apparently, all my hotkeys really did go away somehow

had this issue today, apparently, all my hotkeys really did go away somehow "Reset to defaults" in the "Hotkeys" tab fixed it for me.

Update to the newest nightly, we attempted to blind fix this in dfa3818a701d5445dea10c102712404fbc104f27

I'm using chatterino2-nightly-appimage because building from source takes an eternity. Would be nice if that package got updates every now and then.

the appimage the package is downloading would always be the latest.

Correct, while the date is not updated, the source of the appimage in the package comes directly from our automated builds, found here which was last updated 5 hours ago.

Is there anything to test now that I do have the latest nightly?
If the issue was that the hotkeys can be wiped randomly, it's not like there are steps to reproduce here.

Is there anything to test now that I do have the latest nightly? If the issue was that the hotkeys can be wiped randomly, it's not like there are steps to reproduce here.

More or less no, as mm2pl mentioned above, he believed it to be related to the hotkeys not being saved correctly, so other than attempting to turn off your machine while Chatterino is open, you are basically just waiting to see if it breaks again.

My computer did go down unexpectedly multiple times while chattering was running, not that I would notice the issue right away, but yeah something to keep an eye on from now on :D

I have the same Issue in macOS.
It happens usually after i use the emote inline search and tab for autocomplete.

I have the same Issue in macOS. It happens usually after i use the emote inline search and tab for autocomplete.

What version of Chatterino are you using? Commit hash is relevant if running a nightly version

I suspect this isn't reproducible in the latest nightly version or in the upcoming stable release. If it happens for you, please re-open this issue.

authors: ALazyMeme BluMarshmallow Felanbird L1Q LosFarmosCTL Mm2PL VulpesHD mfmarlow pajlada romeogiggletoes


text:
p115 rename的用法

大佬按文档的方法重命名会报错，请问是哪里用法出问题了呢、
>>> fs.rename("anyfile.mp3", "xyz.mp4")
{'name': 'xyz.mp4',
 'is_directory': False,
 'size': 0,
 'id': 2793078164048314194,
 'parent_id': 0,
 'sha1': 'DA39A3EE5E6B4B0D3255BFEF95601890AFD80709',
 'etime': datetime.datetime(2023, 12, 19, 17, 7, 43),
 'utime': datetime.datetime(2023, 12, 19, 17, 7, 43),
 'ptime': datetime.datetime(2023, 12, 19, 17, 7, 43),
 'open_time': datetime.datetime(1970, 1, 1, 8, 0),
 'pick_code': 'e0bgvc5mdo6sxzlvx',
 'star': False,
 'lastest_update': datetime.datetime(2023, 12, 19, 17, 7, 43, 798793),
 'path': '/xyz.mp4'}

#实际上
Traceback (most recent call last):
  File "main.py", line 37, in <module>
    fs.rename(f1.name, f1.new_name)
  File ".venv\Lib\site-packages\p115\component\fs.py", line 3646, in rename
    return run_gen_step(gen_step, async_=async_)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".venv\Lib\site-packages\iterutils\__init__.py", line 265, in run_gen_step
    ret = send(ret)
          ^^^^^^^^^
  File ".venv\Lib\site-packages\p115\component\fs.py", line 3539, in gen_step
    raise PermissionError(
PermissionError: [Errno 1] rename a path to its ancestor is not allowed: '/云下载/文件夹挑选/11111/333.mp4' -> '/云下载/文件夹挑选/11111'

你好，是bug，刚修复，更新一下模块

你这是涉及到改扩展名，我待会有空看一下

我试了一下，能成功重命名，并没有报错

我试了一下，能成功重命名，并没有报错，你试试其它文件，看看是否报错

大佬我刚刚试了一下还是会报错
    fs.rename(f1.name, f1.new_name)
    f.rename(f1.new_name)
    fs.fs_rename(f.id, f1.new_name)

这三个用法只有最后一个能成功，f1.name、 f1.new_name分别是当前路径下文件旧名字和要改的新名字，你看一下这个参数是对的嘛

没错，是这样使用

authors: ChenyangGao Ephemeralwanning

repo: ChenyangGao/web-mount-packs


text:
Training speed

Hello, I've tried to train this whole model, but I found that the training speed is very slow because the KNN calculating. Is there any other choice? Thank you!

Yes, the KNN calculating is quite slow.

You can try to train on downsampled images (e.g., half resolution) and then finetune on full resolution images
You can try to save the calculation results of KNN first.

Yes, the KNN calculating is quite slow.

You can try to train on downsampled images (e.g., half resolution) and then finetune on full resolution images
You can try to save the calculation results of KNN first.

Ok, Thank you!

authors: ChenyangLEI dwangxxx