API Testing - Failures Only


We’ll start near the top and throughout the API PLEASE correct me if I am wrong (that is the point of this exercise) Lets find out what is working and what isn’t. Therefore it won’t be up for debate. It will only be what is, and what is not. My examples will be easy to read so lets remember we are not hear to discuss technique. Thanks.
Let’s begin near the top of:

addEntity() does not accept rotation object hardcoded, or prepared as a var as seen below.
This code should result in a box entity that has rotation. It does create the box, but no rotation.

// Create the sphere properties
var pos = Vec3.sum(MyAvatar.position, Quat.getFront(MyAvatar.orientation));  
var dazRot = {x: 39.0, y: 17.0, z:67.0}
var properties = {
  type: "Box",  
  position: pos,
  rotation: dazRot

// Add the sphere
var Ent = Entities.addEntity(properties);
print("Entity added.");

var Ent_PROPS = Entities.getEntityProperties(Ent);
var eRotX = Ent_PROPS.rotation.x;
print("eRotX: "+eRotX);

I ran this twice and deleted the first box. Here is the Result:

I’m not here to demolish your API. I’m here as a “free” tester… that, and I get to learn proper HiFi scripting in the process. At the end of this, you guys should have plenty of bug fixes, and I should have a better grip on the API. Deal?

cc: @chris, @sam


Hi. The entity “rotation” property expects a Quat, so for your example the following should work…

var dazRot = Quat.fromPitchYawRollDegrees({ x: 39.0, y: 17.0, z:67.0 });

See also, Quat.safeEulerAngles(), to go from Quat to Vec3.


Our function tossed a syntax error passing it the full obj, so I used floats and it works great!

var dazRot = Quat.fromPitchYawRollDegrees(39.0,17.0,67.0);


Ah yes, sorry … there’s a Quat.fromVec3Degrees() method to use with a Vec3 object.


I have experimented with the action type “spring” using [code]addAction(actionTypeString, entityID, arguments) // Returns EntityItemID

enum EntityActionType {
// keep these synchronized with actionTypeFromString and actionTypeToString
I propose it be renamed to magnet because it does not follow the traditional expectations of a spring: (k is called the spring constant, which measures how stiff and strong the spring is. x is the distance the spring is stretched or compressed away from its equilibrium or rest position.) The force exerted by a spring is called a restoring force; it always acts to restore the spring toward equilibrium. The behavior of spring in Interface behaves more like a magnet and should be considered for renaming. The action type more closely resembles the snapping feature found in magnets. Also, support for traditional spring would be most welcomed. :slightly_smiling:


Consider the following:

I would like to hard code place the dice side by side. Upon closer inspection, it is the first diePin that renders close to me but reports (script console) as placed correctly in the Zed. I understand i=0 will yeild an x position of same, but does not account for the incorrect Zed.

fig3. can be seen with the Z coord at 538… NOT the same as reported in script console… This could be a problem if you guys are not aware of it?


Is velocity non zero?


There is a vel vector being calculated prior to the creation of the set:

var velocity = Vec3.multiply(HOW_HARD, Quat.getFront(Camera.getOrientation()));
    shootDice(position, velocity);

but that doesn’t effect the remaining in the set, only the first. So, while I think it is unlikely the root cause, I might try setting to 0, just to see if it is.


While you are at it you also might want to try gravity = 0.0 and try it with no physics floor. In other words somewhere high in the air where proximity to collision area is not involved.


I’m going to revisit the entity placement positions later today. This seems to be a bug with absolute positioning, and unrelated to my shoddy coding. :slightly_smiling: