Page MenuHomeFeedback Tracker

Misleading script error report for an unassigned AddWaypoint command in a trigger activation
Closed, ResolvedPublic


If the AddWaypoint command is used in any activation or initialisation field and is not assigned to a variable. A script error is returned:

group transport addwaypoint [position player, 0, 1];

"Type array, expected nothing"

and the following is written to the rpt:

control[Rectangular]: Unexpected control type [6]
control[Rectangular]: Unexpected control type [6]
control[Repeating]: Unexpected control type [6]
control[Repeating]: Unexpected control type [6]
control[Presence]: Unexpected control type [6]
control[Presence]: Unexpected control type [6]
control[Interruptable]: Unexpected control type [6]
control[Interruptable]: Unexpected control type [6]
control[CA_ValueActivation]: Unexpected control type [4]
control[CA_ValueActivation]: Unexpected control type [4]
control[CA_ValueType]: Unexpected control type [4]
control[CA_ValueType]: Unexpected control type [4]

Both of these are either misleading or cryptic.

The command as above typed into the execution field of the debug console works without error.

{F19775} {F19776}


Legacy ID
Steps To Reproduce

Using the attached mission:

  1. Preview the mission and move ahead to the opposite side of the runway. A hint will appear with the desired action.
  2. Paste the following code into the debug execution window to confirm that the following two commands work as expected.

group transport addwaypoint [position player, 0, 1]; [group transport, 1] setWaypointType "MOVE";

  1. A Hunter should drive to the players current position.
  2. Suspend the mission and return to the editor.
  3. Paste the same two commands into the trigger "ON ACT" field. - observe the script error, and rpt entries.
  4. Only paste the AddWaypoint command to confirm this is causing the error.
  5. Try pasting in any other editor entity that has an activation or initialization field to observe the same script error.

The command as given above should throw a script error when used form the debug console.
The script error should read "Type nothing, expected array"
The same error should show in the rpt.

Additional Information

Editor mission and rpt files attached.

Heavily amended to emphasise the error report which can lead to confusion.

Event Timeline

Squelch edited Steps To Reproduce. (Show Details)Jun 8 2013, 12:12 AM
Squelch edited Additional Information. (Show Details)
Squelch set Category to Editor.
Squelch set Reproducibility to Always.
Squelch set Severity to None.
Squelch set Resolution to Open.
Squelch set Legacy ID to 3452500819.May 7 2016, 2:29 PM
b101uk added a subscriber: b101uk.May 7 2016, 2:29 PM

It’s the space in “group transport” as “group” is a function word, thus if it sits with space after it, it is a function and not part of a name, would “grouptransport” or “transportgrp” or “grptransport” be better.

Also I assume you haven’t created the group with:

group transport = group transport;

As that its self would throw up an error due to the space, as you would have 2 instances of “group” both trying to act as functions though the first one is really a name while the second is a function.

Assuming you use one of the alternate names, you would need in the leader unit’s Initialization box (assuming the leader unit name is “transport”)
grouptransport = group transport;
transportgrp = group transport;
grptransport = group transport;

Then the following should work using the middle group name above
transportgrp addwaypoint [position player, 0, 1];
transportgrp addwaypoint [position player, 1]; (if you don’t want to add a radius)

[transportgrp, 1] setWaypointType "MOVE";

Think of it as
“NameOfCollectiveGroup” = “Group” “LeadUnitOfThatGroup”
Squelchgrp = Group Squelch

Attached “”, a simple test using only the unit’s Initialization box or trigger activations to add waypoints and change function.

Thank you b101uk. I was heavily amending this issue while you posted your note.

Transport is the name of the vehicle, so group transport should and does return the actual group name of B Alpha 1-2. This is not the issue at all.

I had an error while attempting to create a scenario for another issue report. Unfortunately I did not note the exact error, and nor was this recorded in the rpt, so the exact error remains unknown. I did however resort to the debug console and typed the following into the exec field:

group transport addwaypoint [position player, 0, 1];

This had the desired effect, and the same command was attempted in the activation field of a trigger. Unfortunately this will not work, and threw the error as reported. As soon as I read your mission in the other issue report I realised the error of failing to assign the addition of a waypoint to a variable.

The net result is this. The error report is backwards as described above, and debug console allows incomplete script commands to be executed.

ceeeb added a comment.Jun 10 2013, 4:30 PM

The error is due to the waypoint array returned by addWaypoint (See, this is normal and is not a bug.

In the mission editor, any code in on activation, init, etc fields must return nothing, or you will get an error. Sometimes this behaviour is useful, and sometimes it's not.
The simplest way to get around this is to just use a throw away variable name (so that the return value for the code becomes nothing).

_whatever = group transport addwaypoint [position player, 0, 1];

I absolutely agree ceeeb, but as I point out above, the incorrect form worked ok in the debug console and I became target blind with the reversed script error.

ceeeb added a comment.Jun 11 2013, 3:56 AM

The error message is not specific to any command (other that those that return a value), nor is it in the wrong order. A more verbose version would read:
"Returned value of statement in field is type array, required is type nothing"

The error messages are solely a feature of the mission editor, presumably as an error-checking feature intended to help the user. The game's script interpreter does not require returned data to be assigned to a variable. This behaviour can be seen when using the debug console, or running a script file, or manually editing the mission init or activation statements in the mission.sqm file.

In my opinion, these error messages should be changed to warnings, which can be dismissed allowing the editor dialogue closed. However, the mission editor does work as is, and the basic features of the mission editor (including the error messages) haven't changed since OFP some 12 years ago, so I don't think it's likely to happen. I will update the BI wiki mission editor articles to include information about these errors.

That does make far more sense when explained. In the heat of an edit session, little quirks like this can completely throw me. I'd normally work with a script and not the editor, so the inconsistency is a gotcha. I'm sure I'm not the only one.

Thanks for the biki attention, I'm sure it will help many.

MadDogX added a subscriber: MadDogX.May 7 2016, 2:29 PM

Mass closing ancient tickets with no activity for > 12 months; assume fixed or too trivial.

If this issue is still relevant in current dev build, please re-post.