Per the wiki at https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#Killed, it is possible that since A3 v1.65 if the instigator isNull, then respawn button was clicked. At least, this is how the BIS revive system detects for it in BIS_fnc_reviveEhKilled. However the unit is already dead at this point, so this does not help the issue.

Same goes for AcinPknlMwlkSrasWrflDb

Still reproducible as of 1.80.

Still a reproducible issue.

setUnconscious does what this desired command would do functionally. Is there still room for a new command that is a true ragdoll activation?

Because "respawnOnStart = 0" now functions correctly (see T72944), this particular ticket is irrelevant as the functionality already exists.

This issue seems to be resolved, and the command works quite well.

All I'm saying is the more material and more complexity that you require lay-users to know, the less you will see of them and from them.

Thank you for clarifying. You're right, the +=/-= would accomplish what I challenged.

However, I still emphasize the fact that SQF NEEDS to be simple, which it is due to its straight-forward-ness. Otherwise, it will certainly take people longer to get used to the language let alone use it successfully. I understand you programmers are all about performance down to the hundredth of a millisecond, but frankly, that kind of optimization is no where near needed in this setting. In the event that it is, you definitely could have some better organization of your executions. This is not the place to sacrifice ease of use for performance.

I am not opposed to adding _i++ in the event that what is currently employed stays working as well.

You cannot possibly argue that inc "_i" is easier to read than _i = _i + 1. As soon as you start expecting that knowledge from people is the time that the number of good missions drop in count.

So, a question outside the fiery argument...

_i = _i + 1 is the same as _i++ in what you are saying. I understand this. However, what is wrong with keeping it how it is? It is its own language and has no obligation to reflect other languages, AND it works not just fine but perfectly.

As well, what about the event where you don't want to add just 1? What if you want 2, or 3.5? Or a variable that was defined as a number earlier?

The reason that SQF is easy to pick up is because it is literal and easy to read. There are no shortcuts, and thus no questions about the syntax other than structure. Why fix it if it isn't broken?

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.

Confirmed that this command works as intended on 1.18 stable.

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

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.

For what its worth, this is still an issue.

:P Well, if you're offering...

But in all seriousness, I think the most beneficial step is just that ability to start a downward force (aka, gravity).

Good to see a dev post here!

Strongly in agreement for something like this, as an animation or a command. Ex:

player switchMove "Ragdoll";

or

player enableRagdoll true;