lennaert

I am not sure how to combine pathfinding with boids behavior. I might think about that later.

lennaert

It might be grouped by additional picking conditions.

I would add another more basic sample capx while released.

lennaert

Here is a snapshot of demo capx

F.Call( "SetLOS", F.Param(0) , 100, 180)[/code:350a2r01] would set the range and cone of view to 100 pixels and 180 degrees. Then pick instances by LOS behavior. Do cohesion/alignment/separation in actions.

xoros

In my understand, the logic of sprite would be separated into 2 levels.

Bottom level is the moving behavior or other appearance behaviors, to set the position/angle/opacity/... of this sprite. This level would export some commands like turn left/turn right/accelerate/brake for top level.

Top level is the controller, it would fire these commands by human input, or fire by logic (NPC/AI). This AI logic might be

if ( some_conditions )
    fire_command[/code:29ox0whs]
Boids and LJ potential would provide some values for condition checking, They would not set properties (position/angle) of this sprite directly.

Back to "collision avoidance behavior", it might be another kind of moving behavior since it needs set the position directly to become "collision avoidance". So it would be another behavior.
In above boids demo, sprite would try not too closed to the obstacles by some logic, but it might not "collision avoidance" for all cases without adjust any term of the controller logic.

lennaert

Instances which would affect this boids behavior is picked by line of sight in my default plan. So the range and the radius could be assigned at runtime.

Great, this one will be very useful. Will it be possible to set TargetX/Y for individual instances?

It might put dummy sprites instead of set position and angle by action of this behavior. Did I get your requirement?

Update:

Try to add obstacles avoidance.

Demo, capx

It uses separation term of boids behavior to make obstacles avoidance.

eli0s

The steer force in boids or LJpotential is a vector, the angle is "Expression:ForceAngle", and the scale is "Expression:ForceMagnitude" in polar axis. Or ( "Expression:ForceDx" , "Expression:ForceDy" ) in orthogonal axis.

But I only use "Expression:ForceAngle" in my sample. I would try to make another sample which using both boids or LJpotential behaviors.

Car behavior is one of possible moving behavior, it might use physics behavior, or just move sprite with bullet + set angle.

Sorry I had missed the last section. I prefer to make 3rd plugins even in C3.

The philosophy of official plugins might not be the same as 3rd plugins. Official plugins should be stable to become the foundation of engine/event sheet. 3rd plugins could be more aggressive.

I am interested in mapping requirements into well design plugins + events.

michael

I agree these features in rex_text_properties behavior should be put into official one. But after almost one year, they still had not be put.

You could wait, or use 3rd solution.

eli0s

I am confused for the name of "Dragging vector" sometime. I could not remember why I made the name inconsistently.

Second, I thought the usage of boids and LJpotential would be similar, they only provide a hint for the movement of sprite.

So

[quote:1v4g68k0]What is the moving behavior of this sprite?

and

[quote:1v4g68k0]How to use this hint?

would be other topics.

Another things about picking neighbors by line-of-sight. Uh, I would try not to repeat this function again in my plugin, since it almost copied form other plugin, sorry.

line-of-sight and boids would work together well.

Ruskul

That's why there would have C3.

newt

Yes, I would add obstacles avoidance.