Blog Post Scripting API blog post discussion

[Blog Post] Scripting API blog post discussion - Printable Version

+ open.mp forum (https://forum.open.mp)
-- Forum: open.mp (https://forum.open.mp/forumdisplay.php?fid=40)
--- Forum: Development Updates (https://forum.open.mp/forumdisplay.php?fid=43)
--- Thread: [Blog Post] Scripting API blog post discussion (/showthread.php?tid=1036)

Scripting API blog post discussion - Y_Less - 2020-04-14

This topic is for feedback on the latest blog post, found here:

https://www.open.mp/blog/scripting-api

Please read that, then feel free to comment on anything it brings up.

RE: API blog post discussion - dreftas - 2020-04-14

Hey. Everything you're doing, and everything you will do in the future with this new GTA:SA Multiplayer modification is so good and thats what everyone was waiting for all these years.

I quit scripting SA-MP a long time ago, but as I'm reading yours blog post about scripting, I like this thing:

Object_GetRotation

Vehicle_GetRotation

I mean the naming [entity]_GetRotation, [entity]_SetRotation, it's good to see scripting like this, I've always wanted this type of function names back then in SA-MP :)

As for invalid id's, as a some kind of programmer, I would agree with -1, because as you said yourself:

"Programmers start counting at 0, so it should be valid and something outside the realm of positive integers should be invalid."

Keep it up with this mod :)

RE: API blog post discussion - Polygon - 2020-04-15

Took me a solid one and a half hour to read through the whole thing, and to understand whats going on as a beginner but damn, appriceate the hard work. Favourite "change" is the per-player stuff for sure. Thank you!

RE: API blog post discussion - Riddick - 2020-04-15

So here's my statement:

I really appreciate the tags that are making appearance in the API. That way we're going to solve many common problems across Scriptwriters. They'll be forced to always provide correct information for the functions. That's a great start.

Another great thing is the naming convention. Sometimes noun "Player" didn't match with the feature that function provided. It's a better approach with underscores. C# OOP has . (dot) sign to follow up its members, C has its pointers and we will have underscores. The only matter of thing I have on my mind is to create open.mp syntax and make it downloadable in VS Code extensions store. So all the function names, parameters are going to be automatically provided while typing (as suggestions).

So that's a first suggestion I have: open.mp API syntax and suggestions gathering via VS Code extensions.

Another good thing about what you do is using boolean parameter for displaying an entity. It's better to pass that by param. instead of doing `if-else` condition since you can implement that condition in parameter.

I mean that example:

Code:
if (var) Checkpoint_Show(cpid, playerid);

else Checkpoint_Hide(cpid, playerid);

If possible, make all new functions appear the way as:

Code:
X_Toggle/Display(entity, forEntity, bool:display)

One thing that always bothered me is variable names and parameter names in pawn language. But that's probably because I'm used to C# too much. I always specify my variables as " playerId " instead of " playerid " - but that's a minor issue (and a personal one more rather).

---

Code:
// Just get `z`.

z = Player_GetRotation(playerid);

That's a great thing! It's so simple yet so useful! Can't remember how many times I was so annoyed by having getting all x, y, z to simply just get z of player's position OR facing angle. Good! And also retrieving the value by returning it from the function and not passing it by reference is also great thing. Thanks for that.

About your issue with invalid IDs returning.. I never liked that SA-MP's functions returned `1` as first valid objectId (from CreateObject), vehicleId (from CreateVehicle) etc. Valid items ID should always start from `0` and invalid one should return `-1`.

I'm happy to see everything is progressing, I'm just waiting for the initial release. I'm planning on migrating my The Last of Us (SA-MP) Project and call it The Last of Us (open.mp) Project for once... I will make an official live-stream migration process of the gamemode I have created (once open.mp is ready server-wise).

Another thing I really want to see in open.mp is provided features of:

- streamer plugin

- YSF

- and maybe some other (?)

internally. Basically server-sided plugins could be easily managed by default and provided in the package already instead of having to download dependencies separately (but then, what's the point of sampctl right?).

Anyway. Waiting for more, I wanna script in open.mp API already and try migrating my project.

RE: Scripting API blog post discussion - George - 2020-04-16

I like the use of tags and the naming scheme. I agree that using -1 as invalid value is a better choice.

I myself started using this naming conversation for the gamemode I am writing and I wonder if it will conflict with open.mp scripting API. For example, I have extra parameter to know if I have to update the database or not.?I hope I will not have to convert the whole gamemode in the future.

Code:
Player_SetWeather(playerid, weatherid, bool: update_db)

I also noticed few mistakes:

Code:
Eample

Code:
but found but found none ("_")

Code:
// Just set `z`.

Vehicle_GetRotation(vehicleid, z);

// Set x, y, and z Euler angles.

Vehicle_GetRotation(vehicleid, x, y, z);

// Set w, x, y, and z quaternion angles.

Vehicle_GetRotation(vehicleid, w, x, y, z);

RE: Scripting API blog post discussion - EOussama - 2020-04-28

Reading this really gets me more excited about the project, best of luck.

Side note: there is a small typo under the Building section. ?Eample?.

RE: Scripting API blog post discussion - Expert* - 2020-04-29

Is GetPlayerVehicleID Player_ or Vehicle_ module ?

And how about SetVehicleParamsForPlayer, IsPlayerInAnyVehicle, IsPlayerInVehicle or SetVehicleParamsForPlayer ?

Vehicle_IsPlayerInside works fine, but Vehicle_IsPlayerInAny doesn't sound right.

Maybe we could use the first parameter to guess the moduel type when possible ?

And how about consistency ?

If we dont want to shorten names SetPlayerPos becomes Player_SetPosition, and i've used 'Pos' so many times that it just doesn't sound right.

RE: Scripting API blog post discussion - EvilShadeZ - 2020-04-29

(2020-04-29, 02:16 PM)Expert* Wrote: Is GetPlayerVehicleID Player_ or Vehicle_ module ?

And how about SetVehicleParamsForPlayer, IsPlayerInAnyVehicle, IsPlayerInVehicle or SetVehicleParamsForPlayer ?

Vehicle_IsPlayerInside works fine, but Vehicle_IsPlayerInAny doesn't sound right.

Maybe we could use the first parameter to guess the moduel type when possible ?

And how about consistency ?

If we dont want to shorten names SetPlayerPos becomes Player_SetPosition, and i've used 'Pos' so many times that it just doesn't sound right.

You need to find out who is the 'subject' for the function to find out which to use.

1.?Player_GetVehicle sound's much better because you care more about the player being in a vehicle, not vehicle having that player in it.

2. Vehicle_SetParams (ForPlayer) (Whether it is merged or not is up to devs, but you are more interested about VEHICLE having these parameters, not player.)

Shortened names are not that good idea tbh. Yes, it is convenient saying Pos instead of position, but at the same time, it can easily turn into weird abbreviations that are non-descriptive.??

"SCM" and "SCMF" are some of the worst I have seen. It pretty much boils down to lazyness of typing a few more characters. If you wanna shorten it, you can always make your own macros, but I don't advise it.

RE: Scripting API blog post discussion - Jarnokai - 2021-01-07

(2020-04-29, 02:16 PM)Expert* Wrote: Vehicle_IsPlayerInside works fine, but Vehicle_IsPlayerInAny doesn't sound right.

I think the latter function simply looks more like a player function, as it isn't related to any specific vehicle.

Player_IsInVehicle, Player_InVehicle, Player_InAnyVehicle...

RE: Scripting API blog post discussion - Josh - 2021-01-07

Correct, that would be a Player module function. Being as it is related to the player only, not dependent on a vehicle.

RE: Scripting API blog post discussion - h3ckphy - 2021-05-26

Y_Less, please, replace Turf_Create and Turf_Destroy with Turf@Create and Turf@Destroy respectively here:

https://open.mp/blog/turfs-formerly-gangzones-module