Direct injecting scripts into entities not working for me


This problem has been apparent for some time but I havent had a chance to properly replicate the issue for posting.

I find the exact same script will work if hosted and the URL is pasted into the scriptURL param of the properties, yet will throw Script Not Constructor/// kind of error if I paste the function directly into the scriptURL param.

Has this ability been removed? Am I the only one with this issue?

Please can anybody else who sees this post here, or post even if direct injection works for you.



After more testing I find this is the actual problem I am having with the click scripts not working, because all my click scripts are pasted directly into the entity, and fail to work.

I now find if I host the script and paste the URL everything seems to work as expected.

I am happy to have found the source of my problems and surprised that nobody else has ever mentioned it, which leads me to allow the possibility that its just my system for some odd reason.

Its extremely laborious to be uploading a one line script every time.


I didn’t even know we could paste a script in there. Maybe it would be cool to have a button right next to the script url field that opens up the script editor so we can directly edit the script.


I tried this script pasted in the scriptURL field in a zone and it did not work.It should have sent me to 0,0,0 every time i tried to leave the zone.

this.leaveEntity.connect(function(eID) { MyAvatar.goToLocation({x:0,y:0,z:0}); })

Also tried it this way, still did not work.

(function(){ this.leaveEntity.connect(function(eID) { MyAvatar.goToLocation({x:0,y:0,z:0}); }) })

From the log:

[11/04 10:45:38] [WARNING] Error loading script from URL QUrl(“file:///”)
[11/04 10:45:38] [DEBUG] ScriptEngine::loadEntityScript() entity: [entity-id: “{5589267a-b756-47ad-9828-b5daa281dc2f}” ]
[11/04 10:45:38] [DEBUG] NOT CONSTRUCTOR
[11/04 10:45:38] [DEBUG] SCRIPT: “file:///”


This feature is even documented, I know this because I documented it.

I got some interest in the problem at the meetup so I’m bumping this in the hope we can get some love and bring this feature back.

(one thing I noticed all the time, these prototype functions dont work if there are any comments in the code. So the examples need those // lines removed before injecting.)


… found the problem – it’s a small bug in some of the more recent C++ code related to script loading and caching.

Is there a worklist item for this yet?

Since inline logic within the scriptURL field is broken for all right now, it seems like the perfect time to suggest that moving forward inline script logic ought to always have a javascript: prefix – that way, the C++ side won’t have to guess about the field’s current disposition.


It is now :smile:
Put in a bid and it will be more likely to get attention.


I would like to bid on some things but I have zero interest in disclosing my tax information.


Hmm Im not really sure how you get thru a working life without disclosing your tax details. Or why it even matters. But I’m sure you have your reasons.
Though it is a shame, you seem to have so much to contribute.


I don’t disclose my tax info every time I give somebody money. I don’t intend to do any paid work for hifi so I would prefer to not upload a w9.


I thought bids were for “paid work for hifi”, not the other way around.

And I would suspect that “MyAvatar.goToLocation” might only work in context of avatar.


Interesting, I have always used MyAvatar.position. Never tried goToLocation, maybe it works with a Place name?

I just tested it, MyAvatar.goToLocation seems to work just like MyAvatar.position, I cant get it to work using strings either Place names or Bookmark locations, maybe I’m doing it wrong.

According to the API they are both looking for a vector 3.

MyAvatar.goToLocation(glm::vec3) function


MyAvatar.position.x number
MyAvatar.position.y number
MyAvatar.position.z number

Sadly the API log is running into one long string again so is really hard to read, another one for the worklist.


I thought you could post money for jobs… if not maybe it should… like crowdfunding.

Your account is ineligible You are not eligible toplace fees on this item. Please check your settings and make sure you have:

Verified your Paypal address
Uploaded your completed W-9 (US citizens only)


No, that is actually for adding a fee they owe you for something on a job. Only a designer, once picked up, can flag it to accept bids then fund the project from HiFis pocket.

That is why it was warning you about no W9 attached.

I will say I understand your point about sharing info @Cracker_Hax but you one of the best people to come in right now and actually add features and getting paid for it can be a good incentive to do more…


Worklist could be an awesome group funding resource, and another way HiFi can make some money. Maybe allowing people to post independent projects would be a good thing to do. It could be like kickstarter.


… OK, as a temporary workaround I’ve written a universal inline script bootstrapper.

To use, prefix in front of your inline script code and in theory it should “just work” like before.

Here’s a full scriptURL to play with that sets a random color on click:{ this.clickDownOnEntity = function(uuid) { Entities.editEntity(uuid, { color: { red: 0xff * Math.random(), green: 0xff * Math.random(), blue: 0xff * Math.random()} }); }; })

… note the # (hash tag) between my hosted .js and your code snippet. That prevents your code from “participating” in the outbound web request at all and permits the .js resource to be well-cached locally (even across entities and different code snippets).

If anyone is curious,js.min.js works as a naive, self-aware surrogate script – interrogating itself within preload() to isolate your code snippet and then “evalving” into your constructor (or showing an error popup if unable to complete the metamorphosis).

The popup normally only shows if there are errors (and dismisses itself after a 10s delay). To have it displayed at each preload just add debug:true to the entity’s userData field and hit “Reload” to verify:



That is the most excellent bit of elegant hacking to make this so obviously broken inline scripting work here.

Great to see an interim solution, and a STRONG hint/want request to HF developers to please, please fix this bug.