The issue seems to lie internally with how GetGame().CreateStaticObjectUsingP3D functions. There seems to be a difference in how the position coordinates are processed in comparison to normal GetGame().CreateObjectEx() functioniality. After looking into the ObjectSpawnerHandler script level class, there is nothing done to the input of position coordinates and or the orientation data that would result unexpected behavior with placement.

In T171861#2435369, @markkoky44 wrote:

The issue seems to lie internally with how GetGame().CreateStaticObjectUsingP3D functions. There seems to be a difference in how the position coordinates are processed in comparison to normal GetGame().CreateObjectEx() functioniality. After looking into the ObjectSpawnerHandler script level class, there is nothing done to the input of position coordinates and or the orientation data that would result unexpected behavior with placement.

This would suggest that it's not limited to trees, but all p3d's referenced through the object spawner

I'm having this issue placing monolith rocks. just tried to place a bunch south of Krona castle and they all appear to be about 6 meters too high.

Hi Geez,

So is the height (Y) coordinate not required for spawning these p3d structures via the Object Spawner in that case?

@Geez why is this closed, there is still an issue present here.

I've been struggling with laying out monolith rocks being placed many meters higher than they are within DayZ editor.
I spent many hours over the past 2 days attempting to design a cliff face to have all my objects at a height I did not specify. I'll post a comparison later but they are not the same at all.

It's as if the tools we have and the tools you're using are referencing different points on the objects were spawning.

Hello again.
We are not planning to change the current system, however, we would like to try to add a new function which will tell you the offset for one of the future updates.

So basically we are not going to be able to use these new p3d objects with 1.21?

In T171861#2439960, @JortWbusch wrote:

So basically we are not going to be able to use these new p3d objects with 1.21?

We aim to include the new function for the stable. It will most likely appear in the third experimental update.

In T171861#2440002, @Geez wrote:

In T171861#2439960, @JortWbusch wrote:

So basically we are not going to be able to use these new p3d objects with 1.21?

We aim to include the new function for the stable. It will most likely appear in the third experimental update.

We're looking forward to it.

I know buildings are not supported via the official object spawner, but was using it as a test bed. I'm only using vanilla types and models. But it seems like any P3D not using autocenter 0 seems to have an offset when spawning with CreateStaticObjectUsingP3D. I've created a simple test to prove the difference. Attached is code an the local watched variables for the object transformations. The typed object stays true to the original position, while the P3D only one does not. It also seems like you're unable to move the P3D static object after it's been created either through SetTransform or SetPosition.

Any P3D that has autocenter 0 flawlessly spawns the static P3D at the expected position. @TrueDolphin can back up this claim.

class Wardog
{
    static Object TypedObject;
    static Object RawObject;

    static vector ConstantPos = "4472.96 339 10212.9";
    static string ConstantType = "Land_Village_HealthCare";
    static string ConstantP3d = "dz/structures/residential/medical/village_healthcare.p3d";

    static void SpawnTest()
    {
        if (TypedObject)
        {
            GetGame().ObjectDelete(TypedObject);
        }

        if (RawObject)
        {
            GetGame().ObjectDelete(RawObject);
        }

        TypedObject = GetGame().CreateObjectEx(ConstantType, ConstantPos, ECE_SETUP | ECE_CREATEPHYSICS | ECE_NOLIFETIME | ECE_DYNAMIC_PERSISTENCY);
        RawObject = GetGame().CreateStaticObjectUsingP3D(ConstantP3d, ConstantPos, vector.Zero);

        vector matTyped[4];
        TypedObject.GetTransform(matTyped);

        vector matRaw[4];
        RawObject.GetTransform(matRaw);

        Print("");
    }
}

geometry missing / binarize ignored property autocenter with value of 0.

example of working model:

example of not working model:

tested with custom models adding the property working as expected, and removed causing the issue to present itself again.

with the bottom 02script and powershell code it could be fixed internally with some folder selection to not break things not actually wanted to be placed on maps inheritly.

but I'd assume its currently named in such a way that binarizing strips the property so when it's accessible for people to use externally, the value is missing.
if it was to be pushed, there would need to be some kind of coordination/prior warning for map makers to prepare to push an update.

another option would be, add a function that gives the coords of the p3d "0 0 0" location regardless of properties/boundingbox selections added for a quick calculation/placement. "like, Object::GetModelOrigin();"

usecase example:

this.SetPosition(GetGame().ObjectModelToWorld(this, GetModelOrigin()));

$files = Get-ChildItem -Recurse -include *.p3d
foreach ($file in $files){
start-sleep -s 1.0
write-host $file
& "D:\DayZ Tools\Bin\ObjectBuilder\O2Script.exe" -a "D:\DayZ Tools\Bin\ObjectBuilder\O2Scripts\PropertyAdd.bio2s" $file autocenter 0
}

similarly, could also be fixed with the following powershell code and o2script run in the DZ folder to not have to worry about breaking anything.
gives people the option to spawn, check memory point "Origin" position then adjust as needed for any p3d.

$files = Get-ChildItem -Recurse -include *.p3d
foreach ($file in $files){
write-host $file
& "D:\SteamLibrary\steamapps\common\DayZ Tools\Bin\ObjectBuilder\O2Script.exe" -a "D:\SteamLibrary\steamapps\common\DayZ Tools\Bin\ObjectBuilder\O2Scripts\AddMemoryPoint.bio2s" $file
}

@Geez is there any update to when this will be fixed given the above information provided by @TrueDolphin & @OfficialWardog as this issue is causing quite an issue for map development? I've personally tested this with multiple p3d objects on both console & PC and get the same results on both the current game build and the current experimental build, I apologize for the mentions my reasoning being this was last addressed to my knowledge in May 3 months ago and myself personally and maybe other feel in the dark with the current status of this issue.

In T171861#2489621, @GraceKelly wrote:

@Geez is there any update to when this will be fixed given the above information provided by @TrueDolphin & @OfficialWardog as this issue is causing quite an issue for map development? I've personally tested this with multiple p3d objects on both console & PC and get the same results on both the current game build and the current experimental build, I apologize for the mentions my reasoning being this was last addressed to my knowledge in May 3 months ago and myself personally and maybe other feel in the dark with the current status of this issue.

Hello GraceKelly,
If you mean p3d objects such as trees and rocks, the response is the same as is in your ticket in regards to this matter: https://feedback.bistudio.com/T173427
as for other objects, for example buildings, it is not supported for p3d spawning with CreateStaticObjectUsingP3D.