Page MenuHomeFeedback Tracker

MenuPosition respawning broken when adding markers without TYPE with BIS_fnc_addRespawnPosition
Closed, ResolvedPublic

Description

When using respawn template MenuPosition if a marker is added via BIS_fnc_addRespawnPosition that does not have a TYPE it will not display in the menu and has the knock on effect that other position names do not correspond to their correct positions.

For example take the linked test mission. When you spawn use the action on the player called "create respawn positions", respawn and compare the positions available to the linked test image for how they should appear. Also note how the positions have the wrong name applied where a marker of TYPE "" has been skipped.

Now load the mission again and instead use the action "create respawn positions with TYPE". Now when you respawn notice all positions are available and correctly named (markers are named as location positions see ALSO at the end of this report).

Now if it is intended that you can not create a quick marker in script and add it as a respawn position without setting its type then addRespawnPosition should check for this and show you an error.
I personally think it should be allowed and instead the markerType check in fn_getRespawnPositions
if (markerType _x != "") then {_x};
should be changed to....
if (_x in allMapMarkers) then {_x};
to make sure it still exists.
I suppose you could check for...
!(getMarkerPos _x isEqualTo [0,0,0])
but this could break if a mission maker was using a marker at [0,0,0] for something.

The isNil check on _pos further on needs removing aswell to allow nil values to be pushed into positions so the names stay insync with their positions, this is the main culprit for the desync, and instead add a check in fn_respawnMenuPosition for a nil value when adding the positions to the list.

ALSO note how adding a respawn position as a marker with the name argument via BIS_fnc_addRespawnPosition does not use the supplied name when viewing the respawn menu.
Maybe replace in fn_respawnMenuPosition ....
_text = markertext _x;
for
_text = [_respawnPositionNames select _foreachindex,0,"",[""]] call bis_fnc_paramin;
if ( _text == "" ) then { markerText _x };
So it uses the supplied name or falls back to the markerText, if thats not present then later in the script it falls back to location data, as it currently does. {F26347} {F26348}

Details

Legacy ID
2807518598
Severity
None
Resolution
Fixed
Reproducibility
Always
Category
Scripting
Steps To Reproduce

Event Timeline

Larrow edited Steps To Reproduce. (Show Details)Jun 3 2015, 10:31 AM
Larrow set Category to Scripting.
Larrow set Reproducibility to Always.
Larrow set Severity to None.
Larrow set Resolution to Fixed.
Larrow set Legacy ID to 2807518598.May 8 2016, 12:09 PM

Fixed by changing condition, marker is recognized by not being on [0,0,0] coordinates (where no mission entity should exist anyway).

Larrow added a subscriber: Larrow.May 8 2016, 12:09 PM

Generally I agree that entities should not exist at [0,0,0].
However the engines own marker system will place a marker at [0,0,0] if its given a crap position like an entity that no longer exist. OK you could say well the people who write their scripts should check for this occurrence but when the respawn menu craps out unless you know about this quirk the debugging could be a nightmare.
TBO i think youve taken the easy way out here when you could have changed a couple of more lines and provided a nice robust system for people to use. Which in doing so would not allow people to break your own systems.