crew – Talk

Return format

Unfortunately the returned crew array will not always be in the format

[driver,gunner,commander,turrets,cargo].

It will automatically resize, meaning for example if there was no Commander, the array would resize to 4 elements. if there was no crew at all, it would resize to an empty array

In its present form this can only really be used for counting the total crew in a vehicle (count crew _vehicle)

You still need to use Gunner _vehicle Driver _vehicle Commander _vehicle

to return the actual crew positions correctly

What may be more useful would be to have the crew return an array that does not resize So for example, if there was no driver, no commander, no turrets and only 1 unit in cargo

hint format [ "%1",crew _vehicle];

would return something like

[objnull , B 1-1-C:1 , objnull , [],[B 1-1-C:3] ]

and then have a new command for returning the number of crew in a vehicle

For example "CrewCount" --Terox 23:25, 6 February 2013 (CET)

Relevance of old notes

This command's functionality has changed over time, and older versions of it were noted to return different results than it does now. In the past therefore, code written to get the crew of a vehicle may have done seemingly odd things with this command, or used workarounds to accomplish desired results. The value therefore of older notes can be to inform readers that although we now enjoy a certain type of behaviour, there may once have been good reason to do what would now seem illogical or ridiculous.

Might I suggest that where older notes exist that seem obsolete, redundant or contradictory, we qualify the notes instead of removing them? All the while notes are maintained as short, self contained post-it-notes, they are the best evidence we have of how and why things were the way they were. Moving away from this note structure to refined and continuous articles about commands and functions will allow us to lay out in qualified progressions what to expect from what code under what conditions. But until such a change, these notes (however old and irrelevant they may be or seem) serve to maintain coherence for more than just this document, but also for derivatives thereof (code produced at the time by people who used this document as a resource).

To kill these pesky notes, we'll need them available to form the articles without them (ironic), but once the notes have gone the way of the Dodo, and we're all free to edit a whole and contiguous article (with (especially) no bizarre sense of "personal space") in order to make it as complete and useful as possible.

In summary then: Perhaps until we have rid of the mess of tacked-on appendages we know as notes, can we just leave them alone as a historical reference to work from later? -- Fred Gandt (talk|contribs) 20:43, 2 August 2014 (CEST)

Well, the notes are not good representation of the history of command changes. Bugs have to be reported to the bug tracker and if someone left a note about a bug that later was fixed, why keep it? Nostalgia? Sentiment? BIKI is the reference and not a history book. --KK

But surely as a reference it needs to document all past and present behaviour that wasn't supposed to be documented elsewhere? i.e. If the note wasn't about bugged behaviour, but rather previously expected behaviour, it's good to note that.

I agree that sentiment has no place, but not that this is not at least in some small way a history of the development of the platform. Consider that although e,g, Arma 2 can be considered another game is is in a more true sense, an earlier version of Arma that is now obsolete (queue the sentimental backlash). If so, we should if following your edict be scrubbing the site clean of all references to it. Obviously that should not be done (I would argue in favour of separating the documentation for different games though).

With a platform like this, we have so many versions out there being run and used, that we have to provide documentation for all of them, especially since much code gets passed from project to project in the typical ugly script kiddie fashion we know and loath. If only for purely educational reasons, it is thus a good idea to keep track of why certain issues may be experienced or seemingly unnecessarily worked around. -- Fred Gandt (talk|contribs) 23:26, 2 August 2014 (CEST)

I would consider a site like php.net as a good role model, where we find that all behaviours are noted with qualifications by date or version, so that older code may be better understood. -- Fred Gandt (talk|contribs) 23:26, 2 August 2014 (CEST)