Beta Release 27


Beta Release 27 includes up to Developer Release 5693. This release contains a protocol change, so you will need to update.

Notes in full:

  • Updates to the tutorial content
  • Use ConvexHull shape for irregular “spheres”
  • Make sure we delete the hrtfs associated with the killedNode
  • Tool to list and extract files from the atp assets directory.
  • Fix failed script includes from locking the ScriptEngine up
  • Display “content loading” while there are pending GPU texture transfers
  • Prevent Script retries when HTTP errors are irrecoverable
  • Decrease the volume of the tutorial firecracker
  • Logging Improvements
  • Server log files will contain 100% of the log on a proper shutdown.
  • Debug tool that prints out the skeleton hierarchy of fbx files including joint indices, bindPose and defaultPoses.
  • Fix numeric keyboard for hmd Window.prompt
  • Log snapshot upload and user story creation errors
  • Remove scripts from avatar attached entities for other avatars
  • Fixed the issue of menus not being removed from VrMenu after they have been added.
  • Add support for whitelist entity scripts
  • Allow only those who have kick permissions in a domain to request an environment mute
  • Disable Users Online interactions while the window is hidden.
  • Fix names of model-entity joint setters
  • Remove incremental texture transfers
  • Fix crashes in OpenGLVersionChecker
  • Fix users.js maximize button unclickable with hand controllers
  • Fixed menu out of view with HMD and Xbox controller
  • Change minimum cores to 3 to enable OpenVR
  • Add a min/max avatar scale in domain-server settings
  • Add a stat for stutters per second (the number of additional times a frame was scanned out to the display without reprojection)
  • The GPU buffers count display on the stats should no longer always be the same number as the texture count.
  • Add AC ip address whitelist to domain server
  • Protect against empty packet lists
  • Add a lastEditedBy property for entities
  • If you have kick rights, you can also mute someone


Sugegstion, post this topic after the version is released :open_mouth:
Waiting for the correct version to download.


you can download now


If you see release notes up before you can actually access the new release, it’s because it’s coming in a few minutes. There’s no way to simulpost notes with a release, so they will usually get posted few minutes early. Posting afterward would result in, “I see there’s a new release, BUT WHERE ARE THE NOTES??” and then some foot tapping, so we’ll be avoiding that when possible.


Since my comments on github hasnt been answered, Ill put here,

#9038 Scripts in Attachments

What if you want to make an Entity that is attached to an avatar that other users can interact with?
How about a secondary field that is set as the entity script when the attachment is on an avatar?

####9043 Entity Script Whitelist

While off by default, and solving issues for possible “blackhat scripts” it may make accessibility to scripting more unclear for newcomers (which I am trying to solve with an framework library). It also limits growth for alternative marketplaces as its extra configuring for a domain. It also may give the wrong impression to some, giving an illusion to a closed system. There also is no UI event for end users putting in the script saying the script is not whitelisted.

This still leaves marketplace scripts open. Regardless of the whitelist/blacklist: anyone can put up a temporary script into the marketplace on an alt, even if it is just “hosted there” without going into-review or even “submitted” state. The hosted assets on the marketplace are still available to be placed on and run on entities and still be in the whitelist.

It also means any admin scripts / toys one may develop can still be put into the marketplace can be used by anyone who has temp rez rights.

At best the solution is a temporary/partial work around.

However I’d be impartial to just setting it for objects with a lifetime (except I tend to use this quite often even If I have permissions for something). And not sure why is it necessary to have it done Server-side: aren’t entities scripts after all loaded and run on the client side? Why Not just ignore the script if your client doesn’t like it?

I’d prefer to for entities to have ownership, and depending on your trust level on the user, the script can run if regardless of state. But I know this may add some overhead. Instead, this should always apply on temporary objects, but not on permanent object (where there should be a bigger level of trust)

And to fix the marketplace, I suggest non-submitted / in-review scripts to have a different path to default that could be turned on with “allow marketplace dev scripts”

CC: @ZappoMan (lol sorry for the friday shock :smiley: )


If it’s an “avatar attached entity” - then it will not run on other people’s machines, only on the machine for the person “wearing” it. You can still “attach” an entity to an avatar, but those will live in the domain, and only be attached while in the domain, and in that case, those scripts are controlled by the domain settings. If the domain operator trusts your script, it will be allowed.

I don’t understand this question. Can you elaborate.

It puts control into the hands of the domain operator. It is that simple. Domains are like websites in this way. At your domain you can have scripts that do whatever you want… and at my domain, I can choose to only let scripts I trust run.

This makes the correct relationship of trust between you the domain operator and your visitors.

A domain that constantly that runs scripts that grief and annoy it’s visitors will surely gain a reputation of ill repute… where a domain with exciting and fun dynamic content will become popular.


From what i understood is disables all scripts in entities which parent is the Avatar for other users but the avatar it self. This means any intractable toy that user wants to make available to others wouldn’t work as intended. Since you cannot create an attachment with scripts, we been left with attaching entities to avatars.

I don’t understand this question. Can you elaborate.

For example, Id like to have an attachment that would be interactable by other users. Forexample an a intractable attachments that plays a sound when it is clicked on by anyone. A secondary script field or a boolean to enable the entity script for other users even if the entity is attached to an avatar.

Lets say It is an attached piece of clothing that has a button that when pressed will make a sound or play an action (like forexample, a squaker on the nose, or a stack of money that when clicked by anyone poofs money flying around all over the place)


Does that mean that if,for example, I would attach some skates, with a script in them to change the walking animation to a skating one, to my feet, nobody but myself would see me skating?
That would not be good.


If your script changes your avatars pose data - it will be sent to everyone to see… so - your skates example will still work.


As @ZappoMan mentioned its unlikely to effect that as the script is only modifying your avatars pose, which gets synced anyway.

It effects more scripts which other users could interact with, than those which only effects your own avatar.


I lost connection to my mic once mid conversation, it remained selected and was showing a vu level in windows recording devices but nothing in hifi. I had to reboot to get it to work again in hifi. Only did it the once so could be not a hifi thing so will keep u posted …


I suspect that’s not new behavior. We acknowledge that better “on the fly” audio device add/remove support is something we could improve on.


It could be a one off but if it happens and no-one mentions it anywhere, then if it happens again it can go un noticed

closed #15

This topic was automatically closed after 30 days. New replies are no longer allowed.