I aim for simple and easy to read with my events if I can. Using arrays to store object info instead of sprites may or may not be better, it just depends on how you want to implement it.
You can sort arrays, but you can also sort sprites with “for each ordered”, just use the stop loop action when loopindex=0 if you just want the closest. Or use a higher number to do stuff with more.
The only time I use an array for terrain is if it’s in a grid formation, in which case a tilemap can work too for 2d. If the terrain is different sizes and whatnot I’d just use sprites.
Not sure I grasp your distance calculation. Would a 3D distance calc work better?
Sqrt((x1-x2)^2+(y1-y2)^2+(z1-z2)^2)
I have no technical expertise with the fov behaviour. I find behaviours seldom do what I want so I’m more inclined to do stuff from scratch than do things to bend behaviours to my will.
For your last question I think there’s a misunderstanding.
You get the position of objects with the x,y and z expressions as I recall.
The orientXX/Xy...Zz expressions is the orientation matrix of the 3D object. Aka. How it’s rotated.
You can think of those as three vectors.
OrientXX/Y/Z is the left vector of an object
OrientYX/y/z is the up vector of an object
OrientZx/y/z is the forward vector of an object.
Ok, cool. Thanks for the answers and 3d distance calculations. I will think of its use for sure.
But let me elaborate. The distance would be there to first check for objects within radius form the actor, and after that those objects that are near the actor are checked for collisions with it. Atm I'm doing isOverlapping,for each overlapping to test collision with grounds and walls for all actors. But since this is the only top condition to pick and check collisions, my idea is to get rid of those sprites and just test for nearby 3d objects with data inside array and then do radius check if actor is colliding.
Also the level loading is dynamic, or rather positioning of the objects is based on what is in the level array. If player has LOS to position, I pick idling terrain sprite, then set all of its values from data stored in array, then pick mesh and set it's parameters with values taken from the sprite. I've created level exporter you see. It exports everything in to array. Then I'm applying that data live based on objects XY in the array using LOS. This way I can have big levels with number of sprites under 200. But for each sprite I do need to update 3d mesh, static once, but others like those for actors or liquid and billboards all the time. In this case it feels like sprites are only a middle-man, and could be completely omitted. I already got rid of sprites for billboards like trees etc. But my worry is that 2k objects in array that needs to test against number of actors so that i can select which ones will be testing collisions against might impact performance more then if i have 111 terrain sprites at all times.
Idea is to narrow it down by first testing which level objects are visible to the player and then put them all in to it's own array and do sorting based on distance and only check collisions for those objects that have distance lower then some value, and stop the loop. And then do the same for other actors in the scene. I imagine this is how its done when picking overlapping objects, with the difference that if the sprite object has collision poly with more points then 4, like in my case my ellipses have 12, that collision check might have same or bigger impact on performance then simple distance check for nearby objects and then testing each for collision with radius from the center of each object.
Ik this is a lot in realm of theory. I guess I have to try it and if it won't perform well, I will get back to using sprites.