A different type of suggestion - help the SA-MP community contribute
#21

Only reason why i used YSF:
Code:
native GetPlayerGravity(playerid, float:gravity)
native SetPlayerGravity(playerid, float:gravity)
Reply
#22

@Slice : I think that even accessing the packets is too low level to be put in an API. Plus how would you decide of which packets you'll edit ? Unless you use addresses, I can't think of any solution.

The idea is brilliant anyway, and great things could be done by manipulating packets or RPC's.
Reply
#23

Quote:
Originally Posted by Slice
View Post
I would say don't focus on those Get* functions for lazy scripters (such as GetPickupModel).
work.
I think you're referring to me. I suggested that. I just want to say that I know It's possible to do by hooking CreatePickup and saving the model to an array. However, when It's there at the server's memory, why should I add an array to my script and waste resources when It's possible to get this data from the server itself? Yes, there are indeed Get* functions that can easily be scripted within PAWN however things like these which already exist at the server memory are not useful.

See this, when an API is released, It's fully released. You can see ARMA3's API here. (https://community.bistudio.com/wiki/...ommands_Arma_3) It's fully-fledged so the scripter can acquire all data he needs through the functions the devs provide. This is a good example for how an API should be.

Anyway, I already covered my needs for GetPickupModel, so I no longer need it.
Reply
#24

Agree 100%!
Reply
#25

Wrong
Reply
#26

Quote:
Originally Posted by Slice
View Post
What about a slightly higher level API for sync data? To read, modify, and send sync packets. So many amazing things could be done.
This. Some plugins would no longer be needed if this were here, AFK detection would be almost nothing, and just so much more!
Reply
#27

I think people here would much rather modify their code for every new version in exchange for new functionality and low level access than have a few new functions, but compatibility from version to version. Since updates are very rare - one per year, I don't see a problem. If cheaters are able to update their tools in a few days without any sdk, just analyzing and guessing how internal structures changed then PAWN scripters and plugin developers can do that in a few hours.
Reply
#28

I'm going to be blunt with you, Kalcor. Do not take offense, as it is not intended to be offensive.

Quote:
Originally Posted by Kalcor
View Post
My opinion is you are better off requesting pawn functions/callbacks for the data you want to access/set.
You don't create functions for minorities, and people are getting tired of having to ask the same questions over and over again only to see their topic drown without a single reply from the SA-MP staff.

One example that really gets on my nerves is this:
https://sampforum.blast.hk/showthread.php?tid=564512
Zeex has revolutionized Pawn scripting, profiling, and debugging. You don't even dignify him with a response.

Quote:
Originally Posted by Kalcor
View Post
I toyed with the idea of making all the server's internal structures available to the plugins.
It's a shame you only toyed around with the idea of saving hours of work for many developers looking to update their plugins just to satisfy others using your mod.

Quote:
Originally Posted by Kalcor
View Post
I don't want to put SA-MP in a position where internal parts can't be changed because it would require all the plugins to be updated.
That's the situation we're in right now. Even if you did need to do big changes in the future, the effort needed to update plugins would not be near how much is required currently.

Quote:
Originally Posted by Kalcor
View Post
I have already seen one case where a server couldn't update to the 0.3.7 RC because there is no YSF plugin available.
One? More than 100. Some servers would die without the plugins they require, as they are vital to their gamemode(s).

Quote:
Originally Posted by Kalcor
View Post
So for now SA-MP's API is the pawn scripting, with all its limitations. That's the interface I try to keep consistent across versions.
Clearly that is not enough, since people have to memory hack the server or make new ones from reverse engineering just in order to get the features they require.
That's just a bad excuse.

Quote:
Originally Posted by Kalcor
View Post
Things like RPCs are too low level for an API. These are deliberately changed around for every new version to make sure old attack tools are fully deprecated.
There's no point. Those with malicious intentions will work hard to find a way, or even use the research from plugin developers and turn it into something evil.


I understand you're probably a busy person. You're not being asked to spend more time, just shift your focus slightly to give the community more power.
Why not unburden yourself from hundreds of feature requests and angry end-users by allowing others to help pull the weight?
Reply
#29

Quote:
Originally Posted by Slice
View Post
...
This post really needs more attention.

I've always understood Kye's decision to develop SA-MP alone, and accept that there is are limited resources for the massive amount of feature requests and suggestions that are made. And I understand that, considering what's happened in the past, it's not reasonable to just request that more developers are hired.

This thread is the solution to that. Give the community the ability to extend SA-MP. Pawn was okay in 2006 for the limited features that SA-MP had back then, for what the team anticipated SA-MP would be. But we've grown so far beyond that, and the possibilities would literally be endless if we were given the capability to add to SA-MP in ways that we can't at the moment. We can add the features that are too small and insignificant, or too big and time-consuming, that players have been requesting for almost ten years.

Out of thousands of suggestions, this is probably the most important and the most necessary for the future of SA-MP.
Reply
#30

I am really curious whether this thread will have some affect on new features in incoming version. I hope it will, because if it won't that means any suggestions and new ideas can go straight to hell on this forum.
Reply
#31

I suppose the mod needs more interest either Dev wise or community wise. There has to be a solution.
Reply
#32

Quote:
Originally Posted by ev0lution
View Post
We can add the features that are too small and insignificant, or too big and time-consuming, that players have been requesting for almost ten years.

Out of thousands of suggestions, this is probably the most important and the most necessary for the future of SA-MP.
Thats it, i think people just need some capability to do more things related to samp servers... Kalcor, you should see it as we can take care of the less importtant things and you just get focused on biggest ones for updates, as Slice said, you don't need to pull all the weight alone.
Reply
#33

In my opinion there's a lot of things that need to be fix and improved, we've watched programmers creating plugins/scripts to fix or improve things, I guess with a low-level API we could improve more things and fix bugs, we also would have the oportunity to create something new, this is a good idea every server use some type of include or plugin, e.g: Objects, we know that the SA-MP supports only 2000 objetcs but with the plugin streamer the limit has increased, so giving a low-level API has good things! And Kalcor, about people creating cheats and stuff like that just forget it, we're a community and we work has a community, so if someone creates something new we will find a solution but we need support from you because sometimes things got dificult to fix.
Reply
#34

Quote:
Originally Posted by Kalcor
View Post
I toyed with the idea of making all the server's internal structures available to the plugins. The problem is similar to the issue with memory hacking plugins. The internal structures in the server are being changed around all the time. I don't want to put SA-MP in a position where internal parts can't be changed because it would require all the plugins to be updated.

I have already seen one case where a server couldn't update to the 0.3.7 RC because there is no YSF plugin available.

So for now SA-MP's API is the pawn scripting, with all its limitations. That's the interface I try to keep consistent across versions.

My opinion is you are better off requesting pawn functions/callbacks for the data you want to access/set. Things like RPCs are too low level for an API. These are deliberately changed around for every new version to make sure old attack tools are fully deprecated.
Makes sense. Sounds like a solid strategy. Good luck with that!
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)