Getting nowhere with script examples


Hi Folks,
Annoying noob here again!
I’m trying to attach a simple script to an entity using the example here:

I’ve tried putting the url in the script property of my freshly created red cube, I’ve tried pasting in the code, nothing gives any reaction on clicking the cube (I’m using desktop display mode though I do have a vive attached, mouse is selected under avatar->input devices )
I definitely have the cube selected as I can change it’s other properties and see that happen in edit mode.
Am I missing a step? Do I need to restart the server when making script changes? (Tried that anyway to no avail)
The log shows nothing instructive, either the click isn’t happening or the code binding didn’t work, any ideas?

When does code become active? is it as soon as you paste in to the script field? When you close the edit window? Do you have to exit edit mode? restart the server? Reload the cache? The docs are a bit light on these details :slight_smile:

a bit more info: I’ve tried in VR now too and shooting the cube with the hand controllers or generally touching it with avatar hands doesn’t work either… I’m sure it’s something straightforward but tutorial docs should work “out of the box” else confusion reigns!



Hello there @Zedsquared. A lot has changed since that code was written and it no longer works.

You can however get a lot of info by looking through two places for scripts and trying them out

You can also check over

Hope that helps a little bit!


!!! Seriously?! :frowning: surely you should get “Hello world” docs sorted out before public beta? SMH

OK, I’ll go look at what works first but that’s a pretty serious documentation bug there! You need at least one guaranteed to work simple hand holding example prominent in the docs or you’ll get a load more frustrated messages like mine I’m sure.

Also the ref has exactly the same code example as in it, so I just don’t know what to believe any more :slight_smile:



:confused: This script works.

It should give you an introduction to entity scripts.
Beyond that, as noted you’ll probably find it most effective to dig around the examples and consult the references.

There’s also a script that will print the API to the logs.


Hi and welcome, yes you will find lots of things that are unready.

In answer to a couple of your questions, you did everything right.
Place the script url in the right place and click off the field, thats all you should need to do, no need to restart or anything else. Code becomes active the moment you click off the field you inserted the URL into. At this point you should get a response in the log (click ctrl/shift/L to open log console). I got syntax error for this script

I played with this script and discovered the clickDownOnEntity() is borked, things do get added and removed around here and we dont get told and it isnt documented anywhere so we constantly fall into traps.

Or it could be that this function is simply bugged at the moment and needs reporting as a bug @Caitlyn

For this example I removed clickDownOnEntity() and replaced it with mousePressOnEntity() and it seems to work.

I can just offer a workaround but not an explanation of why a feature was removed or suddenly stops working.

@Chris or whoever looks after the docs nowadays…Can we get some attention to the fact that the main example in the docs no longer works please.
We need to either fix the clickDownOnEntity() issue or replace that script with a working example. @Zedsquared has a good point about the first example script.


HF is supposed to be beta now, right? That means documentation. Honestly, I cn understand the issues of diverting limited developer time into documentation, but then there are auto-documentation tools out there. Why is not Doxygen or any other interface auto-doc tool used in HF?

A wonderful win-win process. Leave the interface documentation to automation, then have some people write up the architecture and high level design summaries. In a very short time, we all will have the docs we need to move forward. This is beta after all.


Thanks for the solid info @Adrian! It’s good to know these details as there are so many unknown links in the chain when starting out.



this script works fine; clickDownOnEntity still works – whatever that ozblog thing is is screwing stuff up when its hosted from there. save the example code locally, then upload it to your asset server (edit --> asset browser) or to a server elsewhere. i just attached it to a sphere and it changed color when i clicked. i’ll look into why ‘direct injection’ is not working and whether we still support it. this docs page is seriously outdated, i’ll fix it. you should use for latest JS API


var clicked = false;
this.clickDownOnEntity = function(entityID, mouseEvent) { 
if (clicked){
    Entities.editEntity(entityID, { color: { red: 0, green: 255, blue: 255} });
	clicked = false;
    Entities.editEntity(entityID, { color: { red: 255, green: 255, blue: 0} });
	clicked = true;	


direct injection doesn’t work at the moment, so i’ve updated docs to reflect that. it will be added back when its properly supported. thanks for the heads up about this doc.


Removing direct injection from the documentation seems like a strange way to dea lwith the problem. It is that the feature is broken. Instead, a bug report needs to be written up to get that fixed.

There is a reason why having scriptlets built into entities is a good thing. It is is about efficiency and scaling. By having operant scriptlets in with the entity, once an entity is instantiated, then its behaviors are immediately operational. This is not so if the script has to be downloaded from an asset server.

People may then point out that interface caches assets, and that is very nice, but then we run into the next problem which is that it massively slwos down the process of iterated development. Becuse scripts are cached, one faces the problem of having to flush said cache to force the script, the model, whatever to get reloaded.

But then were told to place a query rgument to froce disambiuation: ?hack_version, bu that too is a manual process, a lesser one indeed and yet interface often ignores that disambiguation.

I was getting a bit steadfast with a developer to not remove the documentation of injected scripts, since that seems like a very wrongheaded approach since it should be fixed and not permanently forgotten, but the real problem is this, and this should be fixed:

We need selective cache invalidation. Any time that an entity property that is a reference is changed (a ref to a model URL, to a sound URL, to a script URL, etc.) whatever reference is being replaced should first be removed from the interface cache. Doing this will solve all of rapid delopment issues and it will do so without having the massive slowdown disruption of invalidating the entirety of caches. It also eliminated that ?wart workaround which to date rarely works correctly every time.


yes, a global ‘disable caches’ option would be nice while developing. i understand the desire to both develop quickly and load things quickly once they’re done, its definitely something we struggle with and can improve.


The cache is a big pain for developers. Menithal fixt it to make it more easy. But the removed it. (i hear it created problems) It create more problems without it. And this problem is not only for scripts but also for objects.

Using ?v= is really not solution. because after many ?v= you lose count and start to reuse combinations. I pointed about this problem endless. It;'s still not fixt. Now i need to flush the cache what means that all my open windows for edit etc. get closed too.

Disable cache would be nice , so i know it always reload the script or entity. But the clients that visit need to sent soem command to update too. AM pretty sure http support default something like cache-control but possible never implemented.

Because with cache control you could add the refresh button behind url and if you pres sit the things get updated. Ok, never jumped deep into cache.

Hmmm, now i know why i stopped scripting in high fidelity. because the stupid cache and complex way to update it. (without reuse)


Dang, read what I wrote! A global cache invalidation totally sucks as a development tool. SELECTIVE cache invalidation. seh lect tive

Global invalidation already exists.


WHat i mean, It would be nice to disable the cache complete at times in my viewer, Sofar i know that option is not available in the menu. But yes selective is better.

Anyway, wanted todo something with scripts again to try. but i forgot that stupid cache. So i mabye delay the scripting troubles. It’s already problematic enough without the cahce that add only more trouble on top.

More thinking…


Good to see talk on reducing developer friction … it’s very important if you want to grow beyond those who are willing to trawl through source or forum posts before getting started.

For instance, up til just now I didn’t know about uploading assets via the asset browser, so that answers my other question about how you develop locally without a web server running. That should be mentioned in your tutorial IMO as it’s fairly straightforward (once you know about it) and works with just the sandbox and interface.

I just got my first colour changing box in world … woo!

Aaand I just found out what @Balpien.Hammerer means about the cache as soon as I tried to edit the script and try again… Friction!


BTW, I was reacting to @james_hifi. Anyone who believes global cache invalidation is a rapid development tool needs to think again. Selective cache incalidation is decades old known art. Why interface does not do this is plainly wrongheaded thinking.

It is quite frustrating that developers would try to pretend it is not important, only to fulfill the need to reduce the pending problem list. That is dishonest. We have all been complaining about this since 2014! Now tis product is suposedly in beta and fundamentals like this should long have been fixed. And, if not, it shoul be very high priority because it is affecting others from testing the product and moving on with their own development.


re: caching, we follow normal http caching rules – wherever you serve your asset from, we respect those http headers. so for the most predictable experience, i recommend running an http server and serving your assets from there. personally, i use set your headers to whatever you want. move your assets to a remote server when you want others to be able to use them, where those headers are also set appropriately.

also be sure to hit ‘Reload All’ in the Running Scripts window, which will reload all scripts running on your Interface and also all entity scripts attached to entities that you can see in your local tree.

if you’re developing from disk or from the asset browser, there are definitely still some gotchas. i.e. asset browser doesn’t support query strings, so a “?whatever” trick won’t work and you also have to reupload the whole file every time; “file:///” assets are inaccessible to anyone else visiting you.

its a bit of a choose your own adventure, but there are ways to achieve what you’re described so far. again, @Balpien.Hammerer i can help with your specific use case if you’re willing to share, but its a hard problem to solve generally for everyone.

some kind of global ‘cache disabled’ toggle, seems like it would be the most useful, short term gain. also feel free to submit a PR if you’ve got a great solution and it isn’t happening fast enough for you.

you can even get paid if you submit a worklist job

if its valuable to you from a business perspective or something, or you don’t code, you might even consider paying a third party to build it for you.

please describe your specific setup and the problems your having, and i’m sure we can get you sorted out.


heya – tip on the “?” trick – make it “?” and you wont have to change that manually, ever. you could also do Math.random() but i prefer


#20 is not working if you do 5 updates in a minute as example.