Objects at different height in MP

[jamesg 0]

I've designed a lot of SP missions for OFP/Arma but have recently come across a weird issue in MP missions for Arma.

This is that when using the "This SetPos [GetPos This Select 0, GetPos This Select 1, 6]" command in the init line to raise objects off the ground (for example, to place sand bags on the roof of a building), they appear as wanted in the editor and when exported as a MP mission on my PC; but when played on a dedicated server they don't appear at the correct altitude, they are stuck on the ground.

Has anybody else encountered this and if so found a workaround?

[Dr. Mojo- PhD 0]

From the wiki, it says that some statics do not sync their position in multiplayer, for lord knows what reason. They sync locally, but not over the network. I'd love to know a work-around myself.

[jamesg 0]

Oh monkey nuts, I guess that means you can't build any decent fortifications in MP missions then

[Frantic 0]

yes thats correct getpos doesnt work for change the high of an object, just the flags can be changed...

[doc_no1 0]

All my maps are co-op type maps multy player and have ai static M2 guys on top of castles and towers,they work for me? uk dvd patched to 1.5.

[jamesg 0]

Yeah, its weird that some objects work and others don't. I've also noted that M2s will position ok, while sandbags for example don't.

[-SPA-LynxEye 0]

Hi all

Some weeks ago i found this issue with SetPos.

Try yourself.

Put an ammo crate in the map, your soldier spawning at 10 meters, more or less.

Then, in the init field of the ammo crate, just type setpos to 50 meters height.

When you starting the mission, and when the object is placed by the mission.sqm at 50 meters height, you will see how the ammo crate is falling down till 'meet' the ground.

If you trying to do the test with placing a building below the ammo crate, you will see how the ammo crate is falling down 'THROUGH' the building. Yep, through.

So, in MP, maybe you have to refresh the position constantly or at least with certain loop avoid lagging others.

I'm agree with the post saying the coordinates of the object will be local to the player... but if the player is not launching that script... why still getting stuck onto ground?

I suppose, ArmA doesn't allowing 'static' objects can 'freeze' on air.

So, maybe the script that can setPos units on certain height, has to be launched by the server, and only by it, because it is sending the real coordinates of all objects to all real players.

I hope, me, not wrong.

[-SPA-LynxEye 0]

Just another example.

Always i suspected the way why players when going outside a chopper or parachute, you seeing how the soldier is like 'falling down inside an invisible lift' to the ground, or the nearest surface below him. In parachutes this can be seen when so close to ground, from 0 to 2.5 meters, more or less.

I suppose, that ArmA engine, is putting the soldier in a certain height, just the original height of the vehicle, and thx to this 'object in height' issue, you will see how he is falling down till meet the ground in that tricky way.

And yes, not all objects is falling down.

Try to put an ammo crate over a car.

It will spawn below the car, just at ground height (0 meters).

Well, im into a mistake. Ammo crate is not falling down, to see an object falling down, try palets (pallets?).

[F2kSel 0]

Is it the same if you use setPosASL to position sandbags?

I know setPosASL has a few problems with height anyhow.

[-SPA-LynxEye 0]

First you have to know the height ASL where you want to put the object. But the 'bug' remains the same.

It seems like ArmA is simulating the gravity.

[somethingcool 0]

Not quite knowing where else to look, has this problem been worked around yet, or are we waiting for a word on it from bis?

[Big Dawg KS 6]

Not quite knowing where else to look, has this problem been worked around yet, or are we waiting for a word on it from bis?

I think by now BIS has just put this one off. What you are calling a 'bug' has been stated by BIS to be by design, and it seems they really have strong reasons for doing it (though I'm not quite sure what they are).

[somethingcool 0]

Well can they give me some sandbags, and other defences that dont turn the AI into a bunch of tards.

I have to setpos them 0.25 into the ground then they work much better, the AI can see through and enage properly.

Also perhaps i want sandbags on roof tops, or to build up defences!?

It seems odd to me that it dosnt work

[zyklone 1]

Not quite knowing where else to look, has this problem been worked around yet, or are we waiting for a word on it from bis?

I think by now BIS has just put this one off. What you are calling a 'bug' has been stated by BIS to be by design, and it seems they really have strong reasons for doing it (though I'm not quite sure what they are).

I think they've just not understood how much of a problem this is for mission design.

Let's keep complaining and berhaps they'll fix it for Game 2

[POPKA 0]

Maybe its the command your using, give this variation a go:

this setpos [Getpos this select 0,(Getpos this select 1), Height]

[Big Dawg KS 6]

Well can they give me some sandbags, and other defences that dont turn the AI into a bunch of tards.

I have to setpos them 0.25 into the ground then they work much better, the AI can see through and enage properly.

Also perhaps i want sandbags on roof tops, or to build up defences!?

It seems odd to me that it dosnt work

I suppose you can simply use setPos locally for each client. There's also one thing that nobody has seemed to try yet; setPos isn't the ONLY way to change the height of objects in a mission. If you open the mission.sqm you can change the position the object as seen from the editor (this position can be considered it's true original position), it contains x, y, and z values. This way the height above ground can actually be included in the original position the object is created at when the mission is loaded (rather than moving it with setPos the instant the mission initializes). I only wish the editor interface allowed easy modification of this position without having to alt-tab out of ArmA all the time to change it in Notepad (or whatever you use).

[somethingcool 0]

Would you be able to give me an example of that Kyle?

I tried setPos'ing by a script which is passed via a public variable, and uses a gamelogic as something to setpos by, and it still wouldnt setpos!

POPKA that works fine in SP but its a no-goer in dedicated MP

[fasad 1]

I suppose you can simply use setPos locally for each client. There's also one thing that nobody has seemed to try yet; setPos isn't the ONLY way to change the height of objects in a mission. If you open the mission.sqm you can change the position the object as seen from the editor (this position can be considered it's true original position), it contains x, y, and z values. This way the height above ground can actually be included in the original position the object is created at when the mission is loaded (rather than moving it with setPos the instant the mission initializes). I only wish the editor interface allowed easy modification of this position without having to alt-tab out of ArmA all the time to change it in Notepad (or whatever you use).

Editing the object height in the mission file doesn't work, even in SP. When the static object is created it instantly moves to ground level even if their is a valid roadway object between it's sqm defined position and the ground.

[Big Dawg KS 6]

I suppose you can simply use setPos locally for each client. There's also one thing that nobody has seemed to try yet; setPos isn't the ONLY way to change the height of objects in a mission. If you open the mission.sqm you can change the position the object as seen from the editor (this position can be considered it's true original position), it contains x, y, and z values. This way the height above ground can actually be included in the original position the object is created at when the mission is loaded (rather than moving it with setPos the instant the mission initializes). I only wish the editor interface allowed easy modification of this position without having to alt-tab out of ArmA all the time to change it in Notepad (or whatever you use).

Editing the object height in the mission file doesn't work, even in SP. When the static object is created it instantly moves to ground level even if their is a valid roadway object between it's sqm defined position and the ground.

Well that's pretty odd, it worked in OFP I don't understand why it wouldn't in ArmA. The only remaining option I suppose is to use createVehicle to create the object at a given 3d position.

Quote[/b] ]I think they've just not understood how much of a problem this is for mission design.

I'm sure they are well aware, after all BIS uses setPos in many of their own (SP) missions. But like I said they must have some (likely a technical problem, they're seemingly unwilling to change it, maybe they see a way it could be used for cheating) reason why they made the decision to not synchronize static objects.

[TheElite 0]

I think because for new animations such as building class destruction , many objects are auto set to ground if now already ,to prevent an error on destruction concerning the data obtained by the animation on destruction. i think its hard coded and unless these objects are reconfigured to _x class ,the problem wont go away.