Generally better includes

[Y-Less]

Since most of these natives were written, the vast majority of the community has settled on a fairly consistent naming scheme, of the form Library_FunctionName. The default functions don't use this, but could do:

#pragma deprecated Use `PlayerText_Create`.
native PlayerText:CreatePlayerTextDraw(...);
native PlayerText:PlayerText_Create(...) = CreatePlayerTextDraw;

This works well with https://github.com/sampctl/samp-stdlib/issues/15 and https://github.com/pawn-lang/compiler/issues/234 (should that ever be done, though the macros in there can be used even now).

Since this is (IMHO) "better a_samp", it could be "b_samp" for compatibility.

[Southclaws]

I like this, more consistency would be good for this API.

I've also wondered about the file layout too - I'd imagine most people just include a_samp and transitively get the rest of the dependencies. The file names can sometimes seem arbitrary, for example a_samp contains a ton of miscellaneous stuff including player functions/events and vehicle functions/events, then a_players contains some player functions, no events, etc.

Another issue I've had with the libraries is how updates don't stack - this is partly Kye's fault for changing function signatures instead of just introducing new functions. Right now, the 0.3.7 code is fully documented with XML, which is useful for some, but the 0.3.DL does not have any of this. This also makes diffs between versions very difficult because of the documentation.

I'd like to have docs and branches for each version, and be able to merge and diff between but it's difficult to figure out a nice solution for this. One idea I had was to introduce files names after versions, a_samp_03DL for example which only includes the new APIs. This would make updates additive if there were a way to deprecate APIs without modifying their files... food for thought.

On top of this, I've wanted (and consistently forgotten) to change versions to use branches instead of tags - maybe just for 0.3.DL, see #7 - another reason for this is the const-correctness changes completely missed 0.3.DL and adding them requires manual work because the code is so different (thanks to documentation strings and API changes).