Posts: 1,840
Threads: 399
Joined: Oct 2010
Reputation:
0
That would be great but i don't think that would be made for 0.3.7. In my opinion an open source is what sa-mp needs so we can fix bugs and add new functions but i don't think that will happen.
I hope to see more great stuff in 0.3.7.
Posts: 1,831
Threads: 69
Joined: Mar 2008
Reputation:
0
Making the software open-source would help those with a malicious intent to find critical issues and wreak havoc.
The changes I propose, however, would probably have the opposite effect!
At the moment there are many open-source projects made by good-willed people, who could be used and turned around to do bad things.
If Kalcor would disclosed information he deems safe, the good-willed plugin developers wouldn't need to do memory hacking in the first place, which would slow down the reverse-engineering of the SA-MP client/server.
Posts: 406
Threads: 16
Joined: Nov 2007
Reputation:
0
indeed, it's time to accept that reverse engineering the samp server is a big part of samp in 2015. Samp has benefited greatly from the rnpc and ysf plugins all created from reverse engineers who are trying to benefit samp. If kye can look at all the structs and approve the ones plugin developers can use, we wouldn't need to use hacky methods that might break in future versions.
Considering the ysf plugin hasn't been deleted from the samp forums yet it seems like kye approves of this kind of reversing of the samp server. Not everyone who knows how to reverse engineer in samp is making hacks. A lot of us want to benefit samp.
Posts: 985
Threads: 13
Joined: Sep 2011
Reputation:
0
That'd be great!
Though I doubt it would happen, anyways...
Posts: 2,203
Threads: 154
Joined: Oct 2009
Reputation:
0
Dont go straight to open source discussion...there are always pros and cons.
Anyway a solid API would help allot and its a great suggestion
Posts: 3,004
Threads: 12
Joined: May 2011
Quote:
Originally Posted by Slice
Making the software open-source would help those with a malicious intent to find critical issues and wreak havoc.
The changes I propose, however, would probably have the opposite effect!
At the moment there are many open-source projects made by good-willed people, who could be used and turned around to do bad things.
If Kalcor would disclosed information he deems safe, the good-willed plugin developers wouldn't need to do memory hacking in the first place, which would slow down the reverse-engineering of the SA-MP client/server.
|
On the other hand, you can see where you can improve and where you can make it more safe.
I, personally, don't see what's wrong with making SAMP open source.
Is he afraid other people will open more samp projects ?
MTA already is open source, people can copy their source and open their SAMP/MTA version.
Making it open source will give players of SAMP who have knowledge in memory hacking and C++ the option to constribute and improve samp, nevertheless, add an in-built anti-cheats, help remove the exploits and maybe even minimize the ping of the players. ( improving net management
)
Can RakNet copyright be the issue why SAMP isn't open source ?
Posts: 406
Threads: 16
Joined: Nov 2007
Reputation:
0
Don't turn this topic into "let's make SA-MP open source." - that's been discussed to death. That's not what this topic is about. What is being asked for is essentially a better plugin SDK.
Posts: 929
Threads: 135
Joined: Sep 2009
Reputation:
0
SA-MP doesn't even have a good ban system or something to get an unique player "KEY" or something.
Posts: 3,004
Threads: 12
Joined: May 2011
Quote:
Originally Posted by Whitetiger
Don't turn this topic into "let's make SA-MP open source." - that's been discussed to death. That's not what this topic is about. What is being asked for is essentially a better plugin SDK.
|
In my opinion, its completely redicolous that we must demand to receive basic needs.
I know its not the topic, but I wanted to share my opinion about it.
Posts: 1,180
Threads: 55
Joined: Apr 2005
Reputation:
0
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.
Posts: 2,938
Threads: 162
Joined: May 2010
Quote:
Originally Posted by Kalcor
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.
|
Yeah, basically the same as
https://sampforum.blast.hk/showthread.php?tid=128338.
How about adding most of the YSF's get/set functions, alot of servers could really use them, without having the hassle of YSF, since even kurta said most of it is bugged.
Code:
native GetPlayerSirenState(playerid);
native GetPlayerLandingGearState(playerid);
native GetPlayerHydraReactorAngle(playerid);
native Float:GetPlayerTrainSpeed(playerid);
native Float:GetPlayerZAim(playerid);
Functions like those are really helpful, kinda hard to rely on tracking KEYS to get those, lag and desync and cause incorrect results. ZAim would help in detecting some cheats.
Also could you really consider some of those get* functions? Guess you noticed how harder its getting to store data for those, pickups are limited at 4096, if someone wanted to track pickup models they would have to create an array that size. GetPickupModel would help.
"90% of the information held by the server can already be accessed using pawn." Even though you say that's the case, theres alot of information we still can't access without tracking them ourselves..
Posts: 1,831
Threads: 69
Joined: Mar 2008
Reputation:
0
I would say don't focus on those Get* functions for lazy scripters (such as GetPickupModel).
What about a slightly higher level API for sync data? To read, modify, and send sync packets. So many amazing things could be done.
Just look at my plugin & include where I fixed knife sync, made death animations synced, made fast-shooting RPGs/snipers synced, made HP bars synced for server-side health, and more.
Or the (A-Z)NPC plugins that make it possible to customize NPCs in many ways.
As long as there is some way to access the functionality, albeit hard, us Pawn scripters will find a way to make it work.
