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];
or
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”
i.e.
Squelchgrp = Group Squelch

Attached “int_waypoints.Stratis.zip”, 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.

The error is due to the waypoint array returned by addWaypoint (See https://community.bistudio.com/wiki/addWaypoint), 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).

eg:
_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.

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.

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.