[vJASS] UnitIssueOrder

[Krogoth]

We have IssueImmediateOrder, IssuePointOrder and IssueTargetOrder.
Is it good if we would have this:

function IssueOrder takes unit u, integer id, real x, real y, unit target returns nothing

Is it good in point of "clean progamming" to do IssueOrder(u, STOP, 0, 0, null) if we want stop, IssueOrder(u, MOVE, x, y, null) if we want move, IssueOrder(u, ATTACK, 0, 0, target) if we want attack. It removes a lot of crap conditions and shorters code. (Really, Blizzard made a lot of functions with 5132850708 parameters useless in most of cases)

 

[Dr Super Good]

IssueOrder(u, STOP, 0, 0, null)
[0,0] is a valid point. It usually is the exact middle of the play field. Worse still is [0,0] is what all invalid positions point at (such as the position of null unit) so often a lot of garbage gets sent there.

It is bad programming practice since you have limited scope control and bad argument coupling. Their current way is the best since it avoids passing unnecessary arguments (no argument coupling) and allows you to explicitly define what is being targeted.

An example being... Are you using "patrol" a unit (follow) or the ground (patrol)? Currently both use separate natives to invoke but your suggestion would make it impossible for the game to distinguish between the two.

 

[Krogoth]

Their current way is the best since it avoids passing unnecessary arguments (no argument coupling)

Is it so really important? 2-3 arguments? And it removes conditions as were said, so I am not even sure what exactly is efficient.

An example being... Are you using "patrol" a unit (follow) or the ground (patrol)? Currently both use separate natives to invoke but your suggestion would make it impossible for the game to distinguish between the two.

Ofc no.
If I need to patrol ground, I type:

call IssueOrder(unit, PATROL, x, y, null)

but if I need to patrol unit:

call IssueOrder(unit, PATROL, <ANYTHING>, <ANYTHING>, target)

Here is how I differentiate it:

    function IssueOrder takes unit u, integer id, real x, real y, widget target returns nothing
        if     Orders.Type[id] == ORDER_TYPE_IMMEDIATE then
            call IssueImmediateOrderById(u, id + ORDERS_OFFSET)
        elseif Orders.Type[id] == ORDER_TYPE_POINT then
            call IssuePointOrderById(u, id + ORDERS_OFFSET, x, y)
        elseif Orders.Type[id] == ORDER_TYPE_TARGET then
            call IssueTargetOrderById(u, id + ORDERS_OFFSET, target)
        elseif Orders.Type[id] == ORDER_TYPE_SMART then
            if target == null then
                call IssuePointOrderById(u, id + ORDERS_OFFSET, x, y)
            else
                call IssueTargetOrderById(u, id + ORDERS_OFFSET, target)
            endif
        endif
    endfunction

Added:
Without this function I need to write this ^ garbage every time I work with orders.

So, num(+) > num(-), or not?

 

[Dr Super Good]

You only need that "garbage" when using some orders. Most orders expect a specific target.

As for efficiency...
You pass unused arguments. This is called argument coupling and is often frowned upon in programming.
You run unnecessary tests. There is no need to test if an order is point or target or smart as an order either is or is not and that is known during development.

It does have some merits though. It could be used to support dynamic order systems where the exact nature of an order is not know during development (varies depending on game state). Then you need to check what sort of order it is as you may have to cope with an order of an unknown kind. An example would be for a role play map to get a unit to automatically issue orders.

The biggest problem is that orders target widget not unit. This means your approach will be unable to cope with orders targeting items and destructible such as ordering a unit to pickup an item or ordering a worker to harvest from a tree.

 

[Krogoth]

The biggest problem is that orders target widget not unit.

Y, i fixed already.

 

[Zwiebelchen]

Also, it requires to register all order strings that exist in the map manually.
Plus, it doesn't work as soon as channel is involved, as channel allows for order strings to be used for any kind of order.

It's only useful for those general orders like move, patrol, attack, etc..