[zgintasz]

Quote:

Originally Posted by Y_Less I"kick with client message" is NOT a bug, as has been explained MULTIPLE times since the intentionally introduced change.

"Things like" doesn't mean "bugs like". I admit with your pawn-compiler argument, maybe you are right. But to make a workaround for this, sa-mp should somehow allow us to choose, which compiler version to use.

Quote:

Originally Posted by Y_Less Also, if the workarounds have already been written, it's not really a hassle even if it should be fixed internally - just include the fixes and go.

That's why developing for sa-mp sucks, you have to make these workarounds yourself or search on forum. Why can't these workarounds just be integrated to main source, then we all could just forget about them and develop more easily? Mistakes, bugs or [forgot that word] must be fixed internally, because they are made not by user, right? And there is no reason why not to fix them. And I'm sure a few lines of code added won't make any bad difference.

[Mellnik]

• Adding the latest SDK to the downloads on the main page.
• Fixing all these annoying bugs listed here and here

There is also a bug list by Y_Less but I couldn't find it. I am wondering why these bugs haven't been fixed in 0.3x, as it is the last 0.3 version.

I really like the server open-source idea, to faster fix bugs and vulnerabilities. Look at the MTA source, if they discover a bug its getting fixed in the next version for sure - meanwhile at SA-MP it takes a really long time.

[Kar]

Really. Y_Less this is for you.

Yes we've seen all the fixes, all the everything to do with pawn. But after so many releases in the 0.3 era

Why can't this be fixed? "native SetPlayerAmmo(playerid, weaponslot, ammo) - It asks you for the weaponslot but it should say weaponid."

Really? A TYPO can't be fixes as opposed to other bugs?

Yes we can change it ourselves... but wtf?

[Steven82]

Quote:

Originally Posted by Kar Really? A TYPO can't be fixes as opposed to other bugs? Yes we can change it ourselves... but wtf?

Probably because it really doesn't matter compared to all the other bugs. Probably because while fixing the important bugs, they just forgot to change it. [sarcasm]Or it's that they just want to continue to see people like you whine about it.[/sarcasm]

[[ABK]Antonio]

Quote:

Originally Posted by Kar Really. Y_Less this is for you. Yes we've seen all the fixes, all the everything to do with pawn. But after so many releases in the 0.3 era Why can't this be fixed? "native SetPlayerAmmo(playerid, weaponslot, ammo) - It asks you for the weaponslot but it should say weaponid." Really? A TYPO can't be fixes as opposed to other bugs? Yes we can change it ourselves... but wtf?

Why do that when the slots are all that matter... If you wanted, you could just GivePlayerWeapon...

[Kar]

Quote:

Originally Posted by Steven82 Probably because it really doesn't matter compared to all the other bugs. Probably because while fixing the important bugs, they just forgot to change it. [sarcasm]Or it's that they just want to continue to see people like you whine about it.[/sarcasm]

Hmm, well idk.

Quote:

Originally Posted by [ABK]Antonio Why do that when the slots are all that matter... If you wanted, you could just GivePlayerWeapon...

Uhh ... ok?

[Steven82]

Quote:

Originally Posted by Kar Hmm, well idk.

You do have a valid point though. I will back you up there.

Quote:

Originally Posted by [ABK]Antonio Why do that when the slots are all that matter... If you wanted, you could just GivePlayerWeapon...

Just stop..

[Gryphus One]

I too think that the fixes and workarounds that consist only of includes should be added to the server package and included in a_samp.inc so the server package would offer more of a "works out of the box" experience than if you have to first download the package and then search in the forums for the different includes and download them separately. Specially because if one is new to sa-mp scripting and stumbles upon one of those fixed bugs, he might just not know there's already a fix for them and he might try to fix it himself in a less optimized way, or just open a new thread in the forum crying about that bug, whereas if the fix had been included in the server package he wouldn't have even noticed that bug.

Quote:

Originally Posted by Y_Less "kick with client message" is NOT a bug, as has been explained MULTIPLE times since the intentionally introduced change.

Isn't it a bug? an intentionally introduced change? I had no notice about this then. I guess you are talking about using SendClientMessage and then Kick, and the kicked player seeing only "Server closed the connection." and not the client messages sent to him, right?

[Y_Less]

An intentionally introduced change is by definition not a bug.

[Gryphus One]

Ohh Y_Less, by the way:

Quote:

Originally Posted by Y_Less I also don't see much point in integrating the streamer plugin in to the core - it's already loaded as a dll so already runs at native speed. If people don't understand how plugins work that's not really the team's fault, especially given the high number of useful plugins used by most people - should they all be integrated? And if so, how should the various licenses be resolved? Maybe an enhanced plugin API would be of some use, and there actually are ways to bypass PAWN entirely for things like the streamer plugin, it just doesn't use them.

If it's a problem of licenses, why not integrate your sscanf into the core so it doesn't need a plugin? sscanf is both an universally used plugin and one developed by a member of the sa-mp team, so I think it meets the conditions to be integrated.

[AndreT]

I agree that is would not make much sense to actually take the code of the plugins and write them into the SA-MP source, for the very reasons Y_Less said before. Also sscanf as a native function provided by the server would probably not be any faster than the one provided in a plugin as he also mentioned, which makes sense...

But what I meant with my post on the 1st page is that having objects and other world elements streamed fully in client-side (perhaps with the amount of objects limited by memory or some arbitrary value) would decrease the load on servers... since having 30000 objects on the server - although divided into cells efficiently by Incognito's clever code - with 200 actively roaming/teleporting players online uses very much resources. So it would make things easier for server owners and hosting providers. I don't know what the downsides to this would be, although it could be argued the profit from this is going to be small...

[Gryphus One]

Quote:

Originally Posted by AndreT sscanf as a native function provided by the server would probably not be any faster than the one provided in a plugin as he also mentioned, which makes sense...

It's not about making it faster or slower, it's about making server package more complete so it works more out of the box instead of having to download lots of additional files from different forum threads.

[Basssiiie]

Quote:

Originally Posted by Gryphus One It's not about making it faster or slower, it's about making server package more complete so it works more out of the box instead of having to download lots of additional files from different forum threads.

The downside of adding sscanf to the server package is that Y_less will get less freedom at updating his plugin. Sscanf releases would be limited to main SA-MP updates. So when he wants to add a new feature, we have to wait until SA-MP releases a new update before we can use it.

[zgintasz]

I don't agree with sscanf or any other plugin integration, it makes no sense. Sa-mp source means SA-MP source and nothing not related with it.

[zgintasz]

Quote:

Originally Posted by Gamer_Z I would actually really realllylllylylylylylyy LOVE to have a DEBUGGER

Check this topic, I guess it could be possible to integrate it into a custom IDE.

[Dan..]

Quote:

Originally Posted by AndreT I agree that is would not make much sense to actually take the code of the plugins and write them into the SA-MP source, for the very reasons Y_Less said before. Also sscanf as a native function provided by the server would probably not be any faster than the one provided in a plugin as he also mentioned, which makes sense... But what I meant with my post on the 1st page is that having objects and other world elements streamed fully in client-side (perhaps with the amount of objects limited by memory or some arbitrary value) would decrease the load on servers... since having 30000 objects on the server - although divided into cells efficiently by Incognito's clever code - with 200 actively roaming/teleporting players online uses very much resources. So it would make things easier for server owners and hosting providers. I don't know what the downsides to this would be, although it could be argued the profit from this is going to be small...

Some plugins would be faster. For example, if Incognito's streamer had access to the player updating process it would have skipped some objects instead of creating and removing them when a player is around.

[maddinat0r]

Quote:

Originally Posted by Gamer_Z I think because you also need to be able to debug with players online. (not simulated players).

Did you ever debugged a C++ gamemode with players on the server? When you debug something, you freeze the application. Freezing the server results in a huge desynchronization, the client thinks the server is not online and looses the connection to it.