Movement question


#1

In Secondlife, you can do soemthing easy like this.

You can have a prim. and move it into a direction with a command.
If you rotate it you can still keep moving it in that direction.

I need something like that in High Fidelity for a long time.
And my math is bad. so i cannot figure out a trick to move a entity.

Not complete figured out how to implement my idea. So maby explaining it wrong.
It would by nice if entity can follow a path without messing with (i dont know how) x,y,z coordinates, rotation , anhulair velocity and linear velocity. to move soemthing in the correct direction.

It would be already so much more easy if you only need to adjust the rotating and keep the linear movement the same.

But how ?


#2

https://wiki.highfidelity.com/wiki/EntityItemProperties#Line

Start by creating your path, then use the properties of that entity to get it’s linePoints array. Then you can cycle through each of those points and set your target object to move along it. Finally, when you have it working, you can change visible:false and it will hide the path.

Hope that helps!


#3

Sounds like the old llSetpos way. need to study it.
Because correct done , you move by using linear velocity.

Let me think and sink this info on quite moment.


#4

I did a first look, i think i start to understand it.
Yes this could help very much, if i understand it right ! :joy:
More testing needed.


#5

Well, the first question is what is your intended goal? Is it to make semi-random movements like the virtual fish? Or, are you wanting to do movement along a fixed/unchanging path? If it is the latter then yes, what @AlphaVersionD suggested is a great way to avoid doing the hard math. But if it is the former, then what you have to do is not dissimilar to what is done in SL.

There is also a sub-question: Do you expect your movement to be kinematic (non-physical in SL terms, llSetPos based) or dynamic (physical in SL terms, or llMoveToTarget, llApplyImpulse, llSetVehicleParameter based).

For kinematic movement, in SL if you want axis local movement you would code something like this in a timer event:

timer() { vector pos = llGetPos(); rotation rot = llGetRot(); vector newpos = pos + <DeltaX,0,0> * rot; // convert axis local movement to world movement llSetRot(newpos); }

If this is what you need then my next post (or whomever gets to it first) can show you how it is done in HF. One important warning though. If your aim is to have some autonomous entities moving around, unlike in SL where scripts run all the time, in HF they run only while there is an observer (an interface client present).

And expecting this answer from others, don’t even try to justify moving this to an assignment client script. The environments are architecturally distant, one of the biggest flaws in HF.


#6

It’s for following predefined routes you created on the domain. it would need to run on assignment client soon or later.

I try to aim for linesr velocity use. but afraid that hit some big problem and i fall back to the less good position movement.

I first need to study a bit more on the line good and print the array to the console. With the line i can do some thing i have experiences with in SL/OS but, i can still go complete wrong. i know at least that speed is not the obsacle in high fidelity compared to OS

pos movement i did alrteady in the past in high fidelity. but made things for myself harder then needed :open_mouth: Now thinking more simple.

At the end it need to run on assignment client . client side is going to be a NoNo because it need to keep moving when there are no users. or it’s going to be a big boo boo.

First need to figure out how i did print the linePoints data to the console. results i now get back not make much sense.

var pos = Vec3.sum(MyAvatar.position, Vec3.multiply(3, Quat.getFront(Camera.getOrientation())));

var testLine = Entities.addEntity({
    type: "Line",
    position: pos,
    color: {red: 255, green: 255, blue: 255},
    dimensions: {x: 5, y: 5, z: 5},
    linePoints: [{
      x: 0,
      y: 0,
      z: 0
      }, {
      x: 1,
      y: 1,
      z: -2
      }]
    });
    
print(testLine.length);    

for (var i = 0; i < testLine.length; i++) 
{
    print(testLine[i]);
}

Result

[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 38
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< {
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 6
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< d
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 9
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< a
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< c
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 2
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< e
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 5
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< -
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 7
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< c
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 6
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 9
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< -
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 4
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 9
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< c
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< f
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< -
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< a
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 1
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< f
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< f
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< -
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 5
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 6
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< f
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 8
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< e
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< a
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 2
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 0
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 9
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 6
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 5
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< 7
[11/11 19:47:41] [DEBUG] [hifi.scriptengine] script:print()<< }

It would be anyway nicer to have a command that move entity smoot from point a to point b or soemthing like that. but you still need to figure out the end pos etc.

And a good idea to dif my 2014/15 code up.
Tired, then not a good idea to try things like this. :open_mouth:


#7
var pos = Vec3.sum(MyAvatar.position, Vec3.multiply(3, Quat.getFront(Camera.getOrientation())));

var testLine = Entities.addEntity({
    type: "Line",
    position: pos,
    color: {red: 255, green: 255, blue: 255},
    dimensions: {x: 5, y: 5, z: 5},
    linePoints: [{
      x: 0,
      y: 0,
      z: 0
      }, {
      x: 1,
      y: 1,
      z: -2
      }]
    });
    
print(JSON.stringify(Entities.getEntityProperties(testLine).linePoints));

#8

Ohhh. Always problem when you not do it for a while. you forget things.
And with high fidelity is for now a bit harder to remember thing.
Yes i make my own documentation for soem things too.

Thanks.

ADD: Now that’s not the result i expected back in the array.
script:print()<< [{“x”:0,“y”:0,“z”:0},{“x”:1,“y”:1,“z”:-2}]
That’s all, And that’s the start point i think ? but you still not know the end point.


#9

The biggest flaw in HF for physics and generally for any entity script is that there is no super observer. There has to be the observer of last resort when no other general observer (a scene presence client) is present. That design flaw needs to be fixed, I hope soonest.


#10

I understand the logic of things client side. minecraft is doing the same. And in high fidelity the ones that have access to the AC panel can run svripts there. and i think thats a fine way. yu want to keep the amount of AC scropt lower or at least gave control over it. Or you end mabye in the same hell as secondlife.

It would only be nice if there’s a good solution for doors. you cannot run that client side. But in multi user domain, you cannot let everybody to the AC panel. But give peole the power to run evey script with some observer, can be problem.

Anyway, i go first test some idea’s and hints people gave for shat i want in client mode.


#11

This is true only marginally. The AC script environment is very different than the client environment. The same script will not work unchanged both places. The changes are not minor at all. The same is true of physics simulation. What happens to dynamic entities while one or more clients are present is radically different than what happens when all clients leave the scene, or, even get far enough away from dynamic entities to be not seen.

So, what it means is that a dynamic entity physics simulation completely falls apart, literally, when the observer/clients go away. It means it is not possible to do what works in every other virtual world environment - a unified and unitary proper simulation of movement.

A similar situation arises in entity scripts where their activity ceases once observers are no longer present. In short what all this means is that by current design nothing behaviorally dynamic, whether scripted behaviors to make an entity reactive to its environment or whether physics interactions, works realistically.

Yes, there seems to be a way to mitigate that problem, but it through immense and unnecessary complexity at the user/builder. A user now has to think about having to program a double set of procedures in two very different environments. I contend that is a failure in user experience.

I do recall some months back that for at least physics, some thought was given to implement the same physics in the domain environment so that physics simulation ownership could be transferred to the domain when no client observers are present (again present also means not seen or out of distance range). That is a great first step that should happen soonest.


#12

Movement is mabye not so difficult… I have a new idea i need to try out. But my ideas are more times not what i get as result.