-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SA-MP Standard Library Item List #3
Comments
Tested (with one client) and working on (currently) Natives:
Events:
|
Revive nativegen for automatically building include files? If so, natives in C++ would probably need some kind of pattern (I'm guessing we're not using pawn-natives) |
We are actually |
holy based |
I'll update nativegen to output stuff from this then, and I probably won't bother with the compat macros |
Tbh we might not need it if we decide on just using the normal names and move to the new ones later if it matters that much. |
Would still be nice to have proper organised libraries though, and by generating them it keeps the source of truth simple in one place. |
you got mentioned but you dislike discord apparently so, what about using native gen to actually become what its name suggests, generate the native functions for impl in omp? writing 500 ish natives with all the params will make everyone sad, I already did over 200 myself back in the day! Then we can generate with our new names if we care on the other version of native-gen that generates the native signatures for pawn. IMHO automation > manual labour any day. |
Yes I am always for automation, so I agree. I do have some data somewhere that codifies all the natives as structured data, like: name: SetPlayerPos
desc: Sets a players position
return:
tag: _
params:
- name: playerid
tag: _
- name: x
tag: Float
- name: y
tag: Float
- name: z
tag: Float From this, we can generate:
|
On the documentation side, probably best to avoid because translations are a bastard but we can definitely generate C++ headers and pawn natives |
What do you mean by documentation exactly? pawn side or cpp side, pawn side we can take the stdlib stuff already afaik? I'm not expecting the order to change |
I meant generating pages on open.mp/docs based content from the same source as all the other stuff - but that's probably a bit too far, I'll start with just generating code |
Given that the current goal is to emulate SAMP functionality 1-1, what is the actual problem needing to be addressed? Wouldn't the already existing includes work fine? |
Yes the existing includes will work fine, this is more just about generating both C++ function stubs and natives at the same time - which can help in future as we add more new natives. Having a single point of truth which generates code saves time and reduces the chance of typos when copy-pasting. It's also much better than macros because intellisense actually works properly. |
Edited OP as there were some duplicate entries with exactly the same set of parameters. Happened because these are declared in both
There are however also some entries with the same name, but different set of parameters. I've explicitely added the set of parameters to these in the OP to show the difference. native GetPlayerArmour(playerid);
native GetPlayerHealth(playerid);
native IsPlayerStreamedIn(playerid);
native IsVehicleStreamedIn(vehicleid);
forward OnPlayerDeath(playerid);
forward OnPlayerStreamIn(playerid);
forward OnPlayerStreamOut(playerid);
forward OnVehicleStreamIn(vehicleid);
forward OnVehicleStreamOut(vehicleid); a_players: native GetPlayerArmour(playerid, &Float:armour);
native GetPlayerHealth(playerid, &Float:health);
native IsPlayerStreamedIn(playerid, forplayerid);
native IsVehicleStreamedIn(vehicleid, forplayerid);
forward OnPlayerDeath(playerid, killerid, reason);
forward OnPlayerStreamIn(playerid, forplayerid);
forward OnPlayerStreamOut(playerid, forplayerid);
forward OnVehicleStreamIn(vehicleid, forplayerid);
forward OnVehicleStreamOut(vehicleid, forplayerid); |
Implemented and tested GetPlayerName(), repaired format() EDIT: Minor caveat worthy of note (could break compatibility for some people) - our version will ALWAYS include a null terminator in output string, so if you ask for 4 characters, you actually get 3 from the name and a null terminator. |
Tested:
EDIT: As it turns out, even with a working client, PlayAudioStreamForPlayer doesn't seem to work on open.mp for some reason... EDIT2: Amir tested and it works for him so I'm guessing that's just my client being weird indeed. So these four are all good. |
Closing this because it's superseded by #158 |
SA-MP Standard Library Tracking List
List of
native
s andpublic
s (callbacks) specified on samp-stdlib.Each entry can have one of the following status:
Feel free to update as you work along them, and tag in the respective issue to notify of status changes and any other important stuff relevant to that item.
Natives
Generated by
grep -Eoh '^\s*native ?([^\(]*)\(.*\);' *.inc | tr 'Float:[X-Z]' 'Float:[x-z]' | sed -E 's/\t*native ([a-zA-Z0-9]+:)?//' | sort | uniq | cut -d"(" -f1 | xargs -n 1 sh -c 'echo "| $0 | U | N/A |"'
onsamp-stdlib
on this commit.If you want the data only, then run the command without
xargs
.Callbacks
Generated by
grep -Eoh 'forward ?([^\(]*)\(.*' *.inc | sort | uniq | cut -d" " -f2 | cut -d"(" -f1 | xargs -n 1 sh -c 'echo "| $0 | U | N/A |"'
onsamp-stdlib
on this commit.If you want the data only, then run the command without
xargs
.The text was updated successfully, but these errors were encountered: