I think Euler angles should be used instead of quaternions. Quaternions are less intuitive and will be a nightmare for the most of beginners. Or maybe there should be an enbedded function for the Euler <-> Quaternion conversion. In addition, it would be easier to move previously created maps on createBuilding without an effort.

I think Euler angles should be used instead of quaternions. Quaternions are less intuitive and will be a nightmare for the most of beginners. Or maybe there should be an enbedded function for the Euler <-> Quaternion conversion. In addition, it would be easier to move previously created maps on createBuilding without an effort.

Yes, i think so. I didn't found euler to quaternion functions.

We're going from euler, to quaternion, to matrix now
Could we also please allow skipping euler ?

element-building createBuilding(number modelId, float x, float, y, float z, float rx, float ry, float rz, float rw [, number interior = 0])

If rw is nil interpret as Euler otherwise quaternion

Could we also please allow skipping euler ?

We can add quaternion -> euler utility function

Well the point would be to get rid of that conversion altogether (where some euler angles are problematic) since the GTA function accepts a quaternion.

But i'm not too steadfast on it, since it can be worked around by setting matrix.
I can see the point where scripters are used to euler angles and we want to keep it similar.

createBuilding function must check if modelId argument is actually a building model. It can be done by looking at usDynamicIndex field: auto modelInfo = pGame->GetModelInfo(modelId); if (modelInfo->GetInterface()->usDynamicIndex != 0xffff) return nullptr;

Otherwise GTA will create a dummy object instead of a building and this type of object will never be deleted. You can check what will happened if create a building with model ID 3797.

I also noticed that shadows and grass are still on the map even after a resource restart. But they disappear after the respawn(I guess shadows and grass are spawned once after the building creation).

There also a problem with the rotation. When you spawn an object and a building with the same coordinates and the same rotation, their actual transformation differs.

also noticed that shadows and grass are still on the map even after a resource restart. But they disappear after the respawn(I guess shadows and grass are spawned once after the building creation).

This can be fixed manually via setWorldSpecialPropertyEnabled('randomfoliage', false).

There also a problem with the rotation. When you spawn an object and a building with the same coordinates and the same rotation, their actual transformation differs.

Fixed

also noticed that shadows and grass are still on the map even after a resource restart. But they disappear after the respawn(I guess shadows and grass are spawned once after the building creation).

This can be fixed manually via setWorldSpecialPropertyEnabled('randomfoliage', false).

This disables the grass no doubt. But what if I want to keep grass on the default SA objects? And what about the shadows?

also noticed that shadows and grass are still on the map even after a resource restart. But they disappear after the respawn(I guess shadows and grass are spawned once after the building creation).

This can be fixed manually via setWorldSpecialPropertyEnabled('randomfoliage', false).

This disables the grass no doubt. But what if I want to keep grass on the default SA objects? And what about the shadows?

My opinion is that we should restream(reload or recreate) grass and shadows somehow at each change in the buildings. Or even better leave a mark that grass(and shadows) should be recreated and do it in the next frame to eliminate tons of excessive calculations.

My opinion is we should restream grass and shadows somehow at each change in the buildings.

It causes performance degradation when you have significant amount of buildings. I prefer additional restreamShadows function.

My opinion is we should restream grass and shadows somehow at each change in the buildings.

It causes performance degradation when you have significant amount of buildings. I prefer additional restreamShadows function.

See my additions to the comment: Or even better leave a mark that grass(and shadows) should be recreated and do it in the next frame to eliminate tons of excessive calculations. In my opinion a deletion procedure should leave the game as it was before the building creation. It should be by default. But function restreamShadows can be added as well.

Nice work on this pr
Getting 30 % less cpu usage with createBuilding over createObject

#1921 is also fixed with this PR

There are still problems with the rotation(it doesn't match the rotation that objects created via createObject have). I believe that this is an important point because most of the players will use buildings as a substitute for objects.

Oh. rx between 90 and 270 is broken

I think there is no more issues with rotation

Merge this!

I come here to add my voice with the previous people and say please merge this ASAP as we need it in our upcoming project.

What about:
-LOD Distance (How far can we see buildings? Infinite draw distance like in MTA:Eir?)
-Shaders - should we be able to restrict shaders to buildings?
-Can buildings be altered with setElementPosition and other functions?

-LOD Distance (How far can we see buildings? (Infinite draw distance, like in MTA:Eir?)

Draw distance is limited by GTA SA only. Buildings have equal draw distance with SA world world elements.

-Shaders - should we be able to restrict shaders to buildings?

I think only global shaders work. Personally, i don't prioritize shaders over dynamic pool size / LODs / dynamic map box.

-Can buildings be altered with setElementPosition and other functions?

setPostion / setRotation / setMatrix functions work, but they are expensive. I suggest not use them

@TheNormalnij https://wiki.multitheftauto.com/wiki/CreateBuilding doesn't exist 2 weeks after merge, please add it