Bug #24368

SetPos broken on dedicated servers

Added by Morbid_DK almost 4 years ago. Updated over 3 years ago.

Status:Closed Start date:09/10/2011
Priority:Normal Due date:
Assignee:Suma % Done:

100%

Category:Scripting: Problem
Target version:1.60.87580
Affected ArmA II version:1.60 BETA First affected build:84467
Reproduced by another DH user:Yes First affected ArmA II version:1.60 BETA
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

Expected

When starting a CTI mission, the player initially spawns near the AI team leaders and MHQ.

Observed

X, Y and Z coordinates for spawning are ignored leading to undesirable and gamebreaking outcomes. Often the player is killed on spawn. Vehicles vital to gameplay never spawn, disappear or are otherwise bugged (see below).

Repro Fireball

- start attached mission on a DS and watch

Repro Xeno

1. Once ingame, press Radio Alpha (0-0-1). This should setPos the chopper to the player position.

- restart the mission.

2. Enter the chopper as pilot/driver (so locality changes to the client) and leave it again, move some meters and use Radio Alpha again.

- both cases should setPos the chopper to the player position

Notes

This bug has been introduced with beta build 84467 and requires the server to run this beta version. Connection was made with a beta build 84467 client.

CIT_24368_setPosBroken.Desert_E.pbo (2.4 kB) Fireball, 09/11/2011 14:39

_setpos2.Desert_E.pbo (2.1 kB) Xeno, 09/12/2011 16:44

ATFSakhe-36.Takistan.pbo (1.1 MB) ViperMaul, 09/13/2011 21:36

_setpos2.Desert_E.avi (8.8 MB) kju, 09/15/2011 10:21


Related issues

related to ARMA2 Community Issue Tracker - Bug #24413: Structure orientation not transferred Closed 09/11/2011

History

Updated by Varanon almost 4 years ago

The same happens when you launch Cipher CO-10: the part of the team that is supposed to spawn near the start location is still at their original position (where they have been placed in the editor).

Mission download: http://www.armaholic.com/page.php?id=6768&highlight=CIPHER

Updated by Sickboy almost 4 years ago

  • Status changed from New to Feedback
  • Assignee set to Morbid_DK

I think it would be beneficial to the ticket/bi if there would be a small repro mission included that only includes a single man, and the script command executed e.g by Trigger, showing the issue immediately without all the layers of complex missions.

Updated by Sickboy almost 4 years ago

  • Due date set to 09/24/2011

Updated by Varanon almost 4 years ago

Sickboy wrote:

I think it would be beneficial to the ticket/bi if there would be a small repro mission included that only includes a single man, and the script command executed e.g by Trigger, showing the issue immediately without all the layers of complex missions.

I tried it, but it isn't a simple "setPos isn't working". It definitely works if you just (setpos getMarkerPos "XXX") for each member of the player team. Cipher is relatively heavy on initialization scripts, so my guess is that the setPos that ultimately sets the position is being executed after the player joined.

Updated by Fireball almost 4 years ago

  • Reproduced by another DH user changed from No to Yes

Varanon wrote:

I tried it, but it isn't a simple "setPos isn't working". It definitely works if you just (setpos getMarkerPos "XXX") for each member of the player team. Cipher is relatively heavy on initialization scripts, so my guess is that the setPos that ultimately sets the position is being executed after the player joined.

Well I can confirm the issue now. Insurgency is also broken due to this.

It looks like it won't setPosATL/setPos in init code, I'll try to make a repro.

Updated by Fireball almost 4 years ago

  • File CIT_24368_setPosBroken.Desert_E.pbo added
  • Description updated (diff)
  • Status changed from Feedback to Assigned

New repro! Dedicated server only!

Updated by Fireball almost 4 years ago

  • Subject changed from Initial spawning in CTI missions ignore location settings leading to gamebreaking outcomes to SetPos broken on dedicated servers
  • Description updated (diff)
  • Due date changed from 09/24/2011 to 12/24/2011
  • Assignee changed from Morbid_DK to Suma
  • First affected build changed from ARMA 2: OA beta build 84467 to 84467
  • First affected ArmA II version set to 1.60 BETA

Updated by Suma almost 4 years ago

The new repro is great. The ticket was a bit confusing before, with three possible repro scenarios mixed together, and none of them very clear. This looks very good.

(I think I have most likely fixed the issue meanwhile, using this repro I should be able to verify the fix quickly. Stay tuned...)

Updated by Fireball almost 4 years ago

  • File CIT_24368_setPosBroken.Desert_E.pbo added

In my previous repro mission, I hardcoded the destination postion, because I wanted to be sure it's not something with get(Marker)Pos and forgot to swap it with the variable which is filled by getMarkerPos (in case you want to move the marker).

This is now corrected in my repro, as a surplus I added setDir on the player (180°) and barracks (45°) to be sure. But I cannot repro any setDir issue.

Updated by Fireball almost 4 years ago

  • File deleted (CIT_24368_setPosBroken.Desert_E.pbo)

Updated by Morbid_DK almost 4 years ago

The problem with setDir is not related to values already hardcoded into the mission. In CTI you build your base in-game after spawning. It is those values that are not transmitted or registered properly at the server-side of the equation. On the client side the values work fine, as you can see how you want to place your building before you place it. They just end up north-south once placed, regardless of what the player wishes or tries to do. So the values are lost (or ignored) somewhere on the way from client to server.

Updated by Fireball almost 4 years ago

You misunderstood my comment, it was just some change to the setPos repro. I should remove the setDir addition again and add a separate setDir repro to the new bug ticket #24413.

Updated by Fireball almost 4 years ago

Done, only setPos repro now.

Updated by Fireball almost 4 years ago

  • File deleted (CIT_24368_setPosBroken.Desert_E.pbo)

Updated by ViperMaul almost 4 years ago

I was able to reproduce the setPOS issues as well. Seem to be intermittent at times.
I had to revert back to one of the previous betas.
Keep up the great work though!

Updated by Suma almost 4 years ago

  • Status changed from Assigned to Resolved

Should be fixed in 84492

Note: in the repro mission there is a script which is unreliable by its nature:

b1 setPosATL loc; pos = b1 modelToWorld [-10,-7,0]; player setPosATL pos;

As setPosATL is asynchronous for remote objects (not executed directly, it is the computer where the object is local where the position change is done), when you call modelToWorld on the same object immediately after it, there is no guarantee the b1 position will be already updated to the new one if b1 is not local.

As a result, when watching the repro, on first iteration of the script only the barracks are moved. Player is moved in the second iteration. This seems as an expected behaviour to me and I suppose it was present in previous versions as well. Unfortunately the repro is missing observed / expected results.

Updated by Fireball almost 4 years ago

Suma wrote:

As setPosATL is asynchronous for remote objects (not executed directly, it is the computer where the object is local where the position change is done), when you call modelToWorld on the same object immediately after it, there is no guarantee the b1 position will be already updated to the new one if b1 is not local.

Thanks for the explanation.

As a result, when watching the repro, on first iteration of the script only the barracks are moved. Player is moved in the second iteration. This seems as an expected behaviour to me and I suppose it was present in previous versions as well. Unfortunately the repro is missing observed / expected results.

Well, it was definitely only about setPos of the barracks, not the player, which was only added to watch the happening; I admit it was unneeded to move the player too, as the barracks could have been seen after moving from the same position.

Updated by Xeno almost 4 years ago

The problem isn't fixed.

You still can't change the position of non local objects with setPos.

Updated by kju almost 4 years ago

  • Due date deleted (12/24/2011)
  • Status changed from Resolved to Feedback
  • Target version set to Upcoming version

Updated by Xeno almost 4 years ago

Attached is a really simple testmission, run the mission on a dedicated server.

Once ingame, press Radio Alpha (0-0-1). This should setPos the chopper to the player position. But it doesn't happen.
Now, enter the chopper as pilot/driver (so locality changes to the client) and leave it again, move some meters and use Radio Alpha again. The chopper now gets setposed to the player position.

Updated by ViperMaul almost 4 years ago

Yep similar issues here. Not fixed.

Updated by Suma almost 4 years ago

  • Status changed from Feedback to Resolved

Fixed in 84554

Updated by Xeno almost 4 years ago

What is now happening with the setpos test mission is that when you enter the chopper as driver before using radio alpha, get out again, move some meters and then call radio alpha is, the chopper is for a split second at the player position (thus killing the player) but is immediately setposed back to it's original position.

Without a locality change the chopper is at the new setpos position and stays there.

:)

Updated by Fireball almost 4 years ago

  • Status changed from Resolved to Feedback

I guess, this is not fixed then.

Updated by Fireball almost 4 years ago

  • Description updated (diff)

Updated by Fireball almost 4 years ago

  • Description updated (diff)

Updated by Suma almost 4 years ago

the chopper is for a split second at the player position (thus killing the player) but is immediately setposed back to it's original position

Anyone else can confirm you also see this? I have tried this repro several times and the helicopter never moved back.

Updated by ViperMaul almost 4 years ago

  • We have a mission that has similar issues on a dedi with moving the flag using 1.59.84554. Not Fixed.
  • 1.59.84260 confirmed working.
  • I have not tried the other betas in between 84260 - 84467
  • I tested XENO's test mission attached however it was a non-dedi LAN server test. The helo moved to me. I was not hurt.
  • I tested Fireball's mission in the same LAN server test but discovered I need to test on a Dedi. It more or less worked but should be deemed invalid. Let me test on a Dedi. brb.

Updated by Fireball almost 4 years ago

Viper can you create a small mission with repros the issue with the flag? Or can you attach the CTF mission, if you cannot isolate the issue, so I might have a look at it.

And you always need to test the issue on DS.

- I tested Xenos mission both on host and on DS and it behaves properly
- I re-checked my mission on DS and it also behaves as it should

Updated by ViperMaul almost 4 years ago

Fireball,

I concur with your findings on DS with both test missions.
However, with the Goschie's Public ATF mission the flags still disappears when deployed. The expected result is for the flag to remain.

First I will attach the mission along with repo steps so that others may repro.
I do know somewhere in this mission the author likes to use a combination of SetPosASL / ATL.

Standby for my next post...

Updated by ViperMaul almost 4 years ago

STEPS TO REPRODUCE:
1. Take the BluFor Top Slot (Squad Leader)
2. Start game and face 030 deg NE and find the flag poll labeled "FLAG ALPHA"
3. Use the addAction RE-Deploy Alpha.
4. Open your map. Left-Click on the road going south outside the west base and inside the yellow circle and inside the green battlefield boundaries.

EXPECTED RESULTS:
  • The new position is immediately marked on the map as ALPHA.
  • The flag poll labeled "FLAG ALPHA" will be immediately placed at that new position clicked.
OBSERVED RESULTS:
  • The new position is immediately marked on the map as ALPHA.
  • However, the flag does not move. Searching for the flag at the expected position reveals no expected results.

NOTES:
It looks like the main difference in this repo mission is that mission designer (Goschie/tacticalNuggets) uses server side setPosATL. Or SetPosASL in a certain situation if the player is alive and setPos if the play died before he could plant the flag. The mission designer can explain more. Or the Developer can create a very simple repo mission.

I have notified the mission designer.

References:
http://pastebin.com/xXDtQFkY [Line: 49] of ZONE_SYSTEM\SERVER_ZONE_SYSTEM\reDeployFlagZone.sqf
http://pastebin.com/RSr0rZuy [Lines: 40-54] ZONE_SYSTEM\SERVER_ZONE_SYSTEM\DeployFlagZone.sqf

Updated by Goschie almost 4 years ago

Hello gentlemen. This ATF is using the regular mode of redeploy. This means it uses a setPosATL using a [x,y,0] position converted from a map click position. It has always worked and only breaks in this beta. It also does not work in micro mode, which it doesn't appear that the mission has been posted. ATF in micro mode uses a setPosASL for active deployment, and when the person dies it uses a regular setPos if the person dies.

Updated by Suma almost 4 years ago

I confirm the issue with flagpoles (the ATF mission), I have reproduced in and fixed in 84560. However I am still unable to reproduce the issue with helicopter, or with other objects types I have tried.

Updated by Goschie almost 4 years ago

All the setPos type code is running on the server and the flags are local to the server so it should be working just fine.

Updated by Goschie almost 4 years ago

All the different setPos types that appear to fail server side are:
setPosATL (which you said you have now fixed)
setPosASL
setPos

The setPosASL and setPos command is being used server side in the micro ATF version that has not been posted.

Updated by ViperMaul almost 4 years ago

fixed in 84560

All three repro missions attached confirmed working for me on a dedicated server.
Nice.

Updated by Fireball almost 4 years ago

Xeno? Any comment from your side?

Updated by kju almost 4 years ago

  • Target version changed from Upcoming version to 1.60 BETA

Updated by kju almost 4 years ago

  • % Done changed from 0 to 90

My results using 84580 both on the DS and client:

  • Fireball: Seems to work. Structure gets beamed to player position again and again. Fixed.
  • VM: Flag gets beamed to mapClickPosition. Fixed.
  • Xeno:
    • Using the trigger immediately: Helo gets beamed to player position. Player gets injured/dies. Fixed.
    • Getting into the helo, starting up the engine, getting out and to a nearby position: Helo gets beamed to player position. Player gets injured/dies. Fixed.
    • Getting into the helo, NOT starting up the engine, getting out and to a nearby position: Helo gets beamed to player position. Player gets injured/dies. Helo gets beamed back to original position. NOT fixed.

In both later situations the helo is said to be local by the console.
There seems to be a difference though of engine on vs not.

Updated by kju almost 4 years ago

Hm it seems to be connected to dying?!
When I die, the helo gets beamed back to the original position.

The video shows a working setPos via the radio that only injures the player
with the chopper next to it. However used again and now killing the player,
the helo magically gets beamed back to the source position - at least it seems so.

When the setPos'ed helo kills the player immediately, the helo is also back
to its source position.

Client: 84580
Server: 84581

YT: http://www.youtube.com/watch?v=BV0Vd6rYBVQ

Updated by Suma almost 4 years ago

Great, this was the missing piece. If I kill the player soon enough after setPosing the chooper (killing by setDamage is enough), the chopper will move back. I guess it is something related to locality ("ownership") change - once player has died, the heli probably moves back to the server. If this happens soon enough, before the setPos was fully communicated to the server, it results in the heli moving back.

I will verify and if this shows to be the case, the fix will most likely be easy.

Updated by Suma almost 4 years ago

  • Status changed from Feedback to Resolved

Fixed in 84627

Was related to position updates not handled properly when a vehicle was "suspended" (physical simulation sleeping). Such updated were stored as pending until the vehicle woke up, and could put it back to the original position then.

Updated by kju almost 4 years ago

Confirmed fixed. Good job

Updated by ViperMaul almost 4 years ago

Good job both Kju and Suma!

Updated by Suma almost 4 years ago

  • Status changed from Resolved to Closed

Updated by Fireball almost 4 years ago

  • % Done changed from 90 to 100

Updated by kju over 3 years ago

  • Target version changed from 1.60 BETA to 1.60.87580

Also available in: Atom PDF