Complexity
#1

How does a plug-in reduce complexity rather than an include ?

Example:

It's too difficult to implement SetPlayerGravity in an include, but plug-ins make it very much possible, why so that ?
Reply
#2

When you're making include you are limited to native function which are given to you and you can not go out of box. But with plugins it's different story because you can leave that "box" of native functions and create your own by changing server memory or reading from memory.
Reply
#3

@MicroD: So how can I leave that "box", while making a plug-in ?
Reply
#4

To be honest I have no idea because I'm not a plugin guru, but you can check amazing projects like YSF which are able to do it with ease.
Reply
#5

With SetPlayerGravity specifically you are doing it, as far as I know, by memory hacking.
But generally with plugin development you have access to more powerful features.

Currently SA-MP supports writing plugins in C and C++ which is native code, arguably running faster than code generated from PAWN. I heard many people argue which is faster because of the call to the native functions, but seems like it's in favor of the plugin.

C/++ offers many things you can't achieve with PAWN, making other things possible, just take a look at Plugin Development forum and see for yourself.
Reply
#6

The "box" which was mentioned is more specifically the AMX virtual space that the PAWN script operations are limited within. (Please correct me should the info be incorrect)

If by complexity you mean the actions generated in p-code (.amx) versus the instructions generated when compiling with a C++ compiler, see this post by ****** (much other stuff worth checking out there as well ).

I have been writing a huge gamemode in C++ for 2 years now. When I started, I did some timing tests when working with MySQL queries as my own method had eliminated the need for interacting with the AMX layer (calling plugin natives, pipelining the arguments, calling the AMX callback, etc) and provided a much better-looking system for working, the results showed significant improvement. Under strain testing, I'm quite sure everything would be a lot faster, but it most likely doesn't matter, because for me, the main gains from moving to C++ were better code structure, better access to dynamic memory management, better containers and OO-programming. To some extent, this all can be done in PAWN, but that has its own downfalls and C++ is really more convenient.
There are, though, some pitfalls that I took. I had been testing alone or with a few pals for months and then launched the server. It instantly got 30-40 players, who were all eagerly waiting, but since I was much more of a C++ novice back then, I was not aware of some common, some less common mistakes. You have to look out for more issues such as accidental invalid memory access or anything of the similar kind.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)