Hi I'm doing the below steps
Installed the decentraland SDK
$ node -v
v16.0.0
$ npm -v
8.13.2
$ dcl -v
3.11.0
created a new scene with dcl init
Installed the dependencies.
$dcl start
application started.
When we load the preview it is struck forever.
with reaching 88% waited for an hour
the scene did not load
I was having this issue last week too, tried again this morning and looks like they've put out an update for the decentraland-ecs package
6.11.2 -> 6.11.3
Running npm install decentraland-ecs#latest in my local project has fixed the issue for me
Sometimes the local dev instance will hang at a certain point. You should try refreshing a few times while the browser is active. I'm not sure why, but sometimes if you have the tab open in the background, it will not fully load.
Also make sure that if you are calling/modifying a Transform, that it already exists on the entity. This will sometimes hang and not give a proper error.
So if you call myEntity.getComponent(Transform).position = new Vector3(8,0,8) before you add a Transform to the entity with myEntity.addComponent(Transform) this annoying non-error will happen and leave you scratching your head.
Related
Getting the attached error when I run the webui.bat. Any idea what I might be doing incorrectly ?
Here is what I did:
1.) I installed the latest version on Windows-11 (git clone).
2.) Then I copied the SD 2.1 (768-v-ema.ckpt) model into the models directory "..\stable-diffusion-webui\models\Stable-diffusion"
3.) Then ran the webui.bat
Update 1 : If I restart the computer, it runs fine the first time, but then gives the same error if I have to stop/start the application for some reason. Hence it's some kind of caching/lock.
I have such a de problem and absolutely do not understand how to solve it, because it is always solved in different ways. Today it helped to remove the entire python cache and crash dump from disk C. Also delete the venv folder. But sometimes even this doesn't work, the feeling that win11 is cursed
Here is how I resolved it:
Removed the independent python I had installed
Confirmed my PATH variable didn't have a python in it
Restarted machine
I have a NodeMCU board running the Lua interpreter, I can access the serial connection via the nodemcu-tool to input commands but when using the nodemcu-tool to upload or reset the filesystem it returns
[NodeMCU-Tool]~ Unable to establish connection
[NodeMCU-Tool]~ Timeout, no response detected - is NodeMCU online and the Lua interpreter ready ?
I might have an answer:
I ran into the same (or very, very similar) problem, on Mac OS X Mojave.
In the end, I reverted to completely uninstalling Node.js (this experience does not help convincing me of Node.js but that is another story) and start from scratch.
Even that did not help because I ran into trouble installing nodemcu-tool ...
Previously I installed it as a global package, and that somehow worked, but it caused me to always sudo my nodemcu-tool invocations - not a good thing!
In any case, sudo-ing plus the commandline parameter "--connection_delay" (or as a project setting, "connectionDelay") helped getting me going.
Until I messed up, and reinstalled everything from scratch. However, the key difference to the instructions for installing nodemcu-tool was adding the '--unsafe-perm' parameter to it, like so:
sudo npm install --unsafe-perm nodemcu-tool -g
That was to be able to get past the repeated installation errors for the serialport package...
IMO, relying on unsafe permissions (for what exactly, anyway!?) is, well, UNSAFE! GRRRRR
To the OP, make sure that:
you have installed Node.js and nodemcu-tool properly (download stable installer etc), and
that you use the --connection_delay parameter in each and every nodemcu-tool invocation!
I had the same problem!
The solution was to reset the board:
Conect the board via USB and press FLASH + RST (two buttons on the board)
relese FLASH
relese RST
Now you can upload your sketch.
If it doesn't work try to disconnect all pins. In my case the GPIO4 was soldered to a LED-Strip and i it was imposible to load the sketch until i disconnected it.
I'm getting an error msg "Load Generator Unavailable" pop up evry 2 iterations when I run the script via check virtual user.Closing and reopeing Neoload solves the issue.Could any of you please help me in resolving this issue?
This looks like it is a common issue with Neoload across versions, we have seen this across all of our windows installations where we run with localhost as a load generator or when we run with stand-alone generators. Most of the time a stop and restart of the load generators and load controllers will solve this issue. On more rare occasions a complete restart of the controller server needs to happen. This is issue is appearing in the latest version as of the date of my response.
I use to have this problem. I just needed to restart my load generator. All I did was ssh into my load generator that was acting up. Then ran sudo –u neoload /opt/neoload/bin/LoadGeneratorAgent stop then after that I would run sudo –u neoload /opt/neoload/bin/LoadGeneratorAgent start & Exit and restart neoload and I stopped having the problem. You will just replace the path with your own. This is for external load generators not local host generators.
I used the build instructions from this link
centos install docs
It seemed to install fine. I ran hhvm --version
HipHop VM 3.5.0-dev+2014.12.11 (rel)
Compiler: heads/master-0-g546087bf1b0560c4a9e254fcad46a9212e42ccc2
Repo schema: cf1780b3cc3857e091e924935ae6267e9794de9c
Extension API: 20140829
So following the bootstrapping docs I create a directory with 2 files (test.php and .hhconfig)
I added the following code to test.php
<?hh
function f(): int {
return 'not an int';
}
f();
In this directory i run hh_client and the following message appears for a long time 20-30mins+. Is this normal? I tried using a docker container with hhvm already and installed and got the same behavior.
This might be a known problem: can you do killall -9 hh_server; export USER=$(logname) before trying again? If that fixes it, you've hit an issue I just fixed this week in https://github.com/facebook/hhvm/commit/53b4d9b1ad7ccf99ef7b80d5d673f1578c9791c8. That fix should be in the latest nightly build, so if you update your build, that might fix it too.
If not, it sounds like you've set it up correctly. Please file a bug at https://github.com/facebook/hhvm/issues and I'll work with you on looking into it. StackOverflow isn't really the right forum for debugging like this.
I'm developing a web app on Yaws 1.65 (installed through apt) running on Debian etch on a VPS with UML. Whenever I do /etc/init.d/yaws restart or a stop/start, it initializes according to an old version of the config file (/etc/yaws/yaws.conf).
I know this because I changed the docroot from the default to another directory (call it A), then a few weeks later changed it to directory B, and the config file has stayed with B for the last several months. But then, after a restart, it switches back to A. If it switched back to the package default, that would be understandable, but it switches to an old customized version instead.
The funny thing is that if I leave it stopped for several minutes, when I start it again, everything switches back to normal (using directory B). But while it's stopped, if I run ps, I don't see any yaws-related processes (yaws, heart, etc). This problem has survived several reboots, so it's got to be an old cached copy of the config somewhere, but I have yet to find anything like that.
Any idea what could be going on?
Update:
#Gorgapor - I stopped yaws, renamed the config file and tried to start it again. It failed to start. However, I was able to restart a couple of times and this time it didn't switch back to the old version.
I'm completely inexperienced with yaws, but I have a troubleshooting suggestion: What happens if you remove the config file completely? If it still starts yaws without a config file, that could be a clear sign that something is being cached.
For what it's worth, with a quick 5 minutes of googling, I found no mention of any caching behavior.