LOL!

astaroth Assigned To => DarkDruid
DarkDruid Assigned To DarkDruid => Moricky

PinBALL!

Go Karel GO!

Yeah they're working their butts off. But,this A3 feedback will pay dividends a few patches from now. Thanks for hustling guys!

Hope this gets fixed soon. Having to kill players at mission start doesn't give a very great 1st impression to newcomers...

I was helping a guy out on the forum today and found this command. Unfortunately, it is still not fixed.

I tried repro'ing it to gather some more info for the devs, but it was literally not possible. Here's why I can't give a definite repro.

With MenuPosition and respawnOnStart = 1:

Markers "respawn_west_1" through "respawn_west_5" placed on map. Results in spawning at _2.

Backed out all the way to main menu, re-Played, spawned at _2.

Renamed _2 to _6. Spawned at _6.

Renamed _5 to _2, and _6 to _5. Spawned at _5.

So, this leads me to believe it has something to do with a "marker ID", not the name. Obviously, this would be the class Item# in mission.sqm.

Added "respawn_west_6", which is Item6 in my mission (_5 was Item5), and "tester", which is Item7. I spawned in at _6. Deleted _6, spawned at _5.

Conclusion:
respawnOnStart = 1 currently results in the player's initial spawn being the highest Item# of official respawn points (ie, respawn_west_X), which, without editing, also means it was the latest one placed. Note that position in mission.sqm is irrelevant, as what matters is the Item# in each class.

respawnOnStart = 2 and = 3 and = true had the same effect as = 1, I assume this persists (therefore is true when > 0)

respawnOnStart = 0 works as intended.

respawnOnStart = -1 and = false resulted in the same as = 0, so I assume if it is <= 0 then it is false.

Hope all this helps.

How is it going with this, somone found a better walk around insted of killing the carracter? in our mission we have added a big poster that are telling the players to repsawn via. the menu, this is so anyoing and stupid....

Since Zeus was relesed to the dev branch, players are now respawned on start automatically when MenuInventory or MenuPosition respawn template are used. respawnOnStart attribute is now obsolete.

(sorry for not closing this earlier, I overlooked it)

No way to disable respawn at mission start anymore?

Now ALL missions that use MenuInventory or MenuPosition are broken (All players die at mission start). Great.

to be honest this has broken my missions that use the Nimitz because when you re spawn on it you don't spawn on the deck but rather in the hull >.> I would prefer it if you could just allow respawnOnStart = 0 still available :/

Yes BI please allow the respawnOnStart parameter again.

Reopened, backward compatibility was missing. Sorry

Fixed in dev version, should appear there tomorrow.

MenuRespawn and MenuPosition templates will still respawn player automatically when he joins the game, but it can be now disabled by adding respawnOnStart = 0; to mission description.ext

Thank you, Sir!

Yes thank you!

Any idea how long it'll be before this will be seen in stable? Thanks for the fix though!

Just checking again a few days later to see if this fix hit Stable? :)

Confirmed that this command works as intended on 1.18 stable.

In 1.18 version did make the respawnOnStart=0 prevent player from "dying" but the player is still teleported to last placed respawn marker (mission.sqm order).

I would prefer players to start on the mission editor defined positions. I haven't tested yet but I hope not all players will be teleported on same single spot otherwise they might all die at the same time (and start the respawn menu which ironically breaks the solution).

I agree with d3nn16, just didn't know if that belonged in this report or a new one.

Here's what happens:
respawnOnStart = 1 -
Player inits, is "killed", and onPlayerKilled is executed, launching the menu. Upon selection of spawn, onPlayerRespawn is executing, moving the player to the spawn point. This is expected.

respawnOnStart = 0 -
Player inits, and onPlayerRespawn is still executed. Due to the lack of a selected spawn point from the menu, the spawn point is randomly selected. When happening multiple times over multiple units, it does NOT result in death. It is annoying, however. It is expected that this setting would have units spawn at their editor-based positions, and not run onPlayerRespawn at game start.

Now that I think of this, I'm going to add in if/then to my file that is executed onPlayerRespawn (which includes the menu function) that exits if init is true. We'll see.

Edit:
So, the way I have it setup (so I can manipulate and control it more effectively) is I split the MenuPosition function's two parts into my own files that I execute onPlayerKilled and onPlayerRespawn. In the killed file, I have a system setup to control the number of respawns remaining, which is defined in the init. I have a 2nd define that is a base number of lives (starting number) that doesn't change, while the first variable is diminished 1 per death. All I did was add the following to the top of onPlayerRespawn, and all is good. This works, once again, because onPlayerKilled is NOT executed when respawnOnStart = 0, only onPlayerRespawn.

if (G_Num_Respawns_Base == G_Num_Respawns) exitWith {player sideChat "Fresh spawn";};

Hope this helps.

here is the current temporary solution i'm using until they fix this:
http://feedback.arma3.com/view.php?id=18359#c68867

An additional annoyance when using respawnOnStart with MenuInventory/MenuPosition:

If you use the BIS establishing shot function (UAV intro), the respawn/inventory menu pops up in front of the intro at mission start.. preventing you from seeing the intro until you select your loadout, wait for timer, select respawn point.

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.