strcmp on the wiki - time for a change?
#1

I wasn't sure whether to post this here or in E+N, but I think it's more suited here. Feel free to move it if need be.

We all know strcmp() is slow, and we all moan at people who use it telling them to use alternatives such as ZCMD/YCMD, so why is it still used on every page of the wiki? People use the wiki to learn, and they're learning bad practises. I know there's no 'official' command processor, but most people use ZCMD/YCMD (they are very similar anyway in syntax). Perhaps its time to update the wiki? The issue is, ZCMD or YCMD? ZCMD is more widely used, and I personally think YCMD has too many features for new scripters to understand, and ZCMD is very simple, so I think ZCMD would be a better starting point for new scripts. It should really be included in the SA-MP server package, along with Incognito's streamer (which everyone uses (or better yet integrated into SA-MP itself)).

Obviously for now there would have to be a note before the example that says something like this:



Obviously the download needs to contain clear instructions on how to include ZCMD. It's not difficult so shouldn't be a problem.

Another issue is that, as I said, almost every page on the wiki (I'd say at least 80%) use strcmp. Editing all those would take a lot of time and effort.

Thoughts please.
Reply
#2

Yes you are right...They should use ZCMD it's faster.
Reply
#3

For a short answer I say yes.

On the other hand, I think this post is worth a read:
Quote:
Originally Posted by AndreT
View Post
I agree that beginners need to be told about more efficient ways to handle commands, but the command "processors" that use CallLocalFunction only become favorable when there are more commands than just a few. CallLocalFunction, too, uses string comparisons, but does it using binary search resulting in logarithmic compexity. But it does not search from amongst your commands, but all public functions registered with the AMX (everything such as native callbacks, timers, etc. are included in the search).

So for just a few commands I would favor using string comparisons in OnPlayerCommandText. Especially when the code is created by or for beginners who could find the idea of callback hooking or includes confusing!
Even with that said, I still agree that the other options should be presented at the time you also show using OnPlayerCommandText. Maybe just have an additional warning box stating that there are more efficient ways. As pointed out, there are numerous pages that would need modifying, and you cannot register on the Wiki anymore (AFAIK), so you would have to get a select few to do that.

The reason I say don't strip the OnPlayerCommandText method completely is I believe they should know the different approaches they can take. That also makes it their responsibility on whether or not to choose the better method.
Reply
#4

Agreed. However, on the case of whether or not Incognito's Streamer or ZCMD should be included in the sever package is really, in my opinion, a far cry out. Both were not developed by the SA:MP Team so I doubt that they would be included in the package. It would be great, though, if the team could maybe develop an official efficient and fast command processor, and integrate it into SA:MP. But really these all should be pushed to be included in the 0.4 release.
Reply
#5

Quote:
Originally Posted by DBan
View Post
Agreed. However, on the case of whether or not Incognito's Streamer or ZCMD should be included in the sever package is really, in my opinion, a far cry out. Both were not developed by the SA:MP Team so I doubt that they would be included in the package. It would be great, though, if the team could maybe develop an official efficient and fast command processor, and integrate it into SA:MP. But really these all should be pushed to be included in the 0.4 release.
There are a few things included in the SA-MP server package that weren't made by the SA-MP development team such as a few filterscripts, but I guess they're different.
Reply
#6

It's okay the way it is, frankly if a budding scripter is a good one, then he shall always look for methods faster than those being used. If you don't, well, you actually won't make too much headway in this scripting world.
Reply
#7

I agree, but having tutorials with strcmp on another side, and the alternative command processors on the other side would be better. Don't forget, we had to use strcmp before better alternative command processors came into effect. So throwing something in the garbage when it helped you a few many years back is just evil.

Another problem is that, since Wiki registrations are disabled, how will the mass majority of users willingly to edit the Wiki for good going to make their instincts happen?
Reply
#8

Quote:
Originally Posted by Sublime
View Post
Another problem is that, since Wiki registrations are disabled, how will the mass majority of users willingly to edit the Wiki for good going to make their instincts happen?
There are about ~10 people that would probably contribute, including myself (I would probably do most of the work tbh). But yeah, I don't think it's a 100% good idea.

Also; Having two examples would be silly.
Reply
#9

Quote:
Originally Posted by Rajat_Pawar
View Post
It's okay the way it is, frankly if a budding scripter is a good one, then he shall always look for methods faster than those being used. If you don't, well, you actually won't make too much headway in this scripting world.
I know I might come off as a guy who is always complaining about efficiency and I do work on things myself all the time to make them faster and better.
But this doesn't get you anywhere in a real life scenario, lets say you are a developer paid Ђ1800 a month. If you fail to deliver on your projects in time, more importantly if you spend valuable time on micro-optimization and premature optimization, you will not be working on any more projects for the same company in the future and you can say goodbye to the nice paycheck!
The same applies on SA-MP servers. I described this in a thread by Gamer_Z which now appears to be deleted, but if I was to sum it up in a sentence - delivering small optimizations and code enhancements, not gameplay features will make you lose players.

What I'm trying to say that is that unless:
1) you are your own boss or
2) the freatures required are already completed or
3) you are hired to optimize or
4) profiling shows that you have to optimize
... do not spend too much time on optimizing!


Someone mentioned implementing the Streamer plugin and an efficient command parser into the server code natively. I actually consider a native streaming functionality a great idea, but this would not or perhaps only partially involve using Incognito's code for anything. An efficient command parser - what? - we already have one and coders can create their own.
For example I've made mine in C++ with std::map with a container that contains only the commands and pointers to their respective functions. This means that searching from amongst these entries is of O(log n) complexity. This could surely further on be improved by using a hashed map (unordered_map perhaps), but this is not necessary. Why?
Picture a large server with 270 players online (like mine once, hehe). These players are all extremely busy having fun and in a second, I assume there would be like 4-5 commands fired regularly. Even if this number is something like 30 commands per second, in terms of computers and their performance and speed, commands are not something often used. I would consider something frequent in this context if it happened perhaps a 1000 times in a second (if someone could emphasize, I'd be glad).

To sum it up, only optimize if:
1) current performance does not satisfy you (measure!)
2) it doesn't mean sacrificing too much of the readability
3) it is in your job description

With command processors, these points are often not met. Emphasize on delivering a fair ratio of quality and quantity of functions, guys.

// Alright, I just now realized how far from the subject I am going. See Bakr's quote of a post of mine to get my opinion on the strcmp stuff.
Reply
#10

Last night I was thinking about but. I think that SA:MP should use ZCMD as the default command processor. It's faster, that's a benefit for every scripter trying to make a code.
Reply
#11

Quote:
Originally Posted by AndreT
View Post
Someone mentioned implementing [...] An efficient command parser - what? - we already have one and coders can create their own.
Yes, but my point was that if it was included in the server package, people wouldn't use strcmp so much. ZCMD is easier and more efficient. strcmp() is very inefficient when you have many commands.
Reply
#12

Why is this a debate? If you can edit the wiki and know a way to improve the data there, do so!
Reply
#13

Quote:
Originally Posted by Y_Less
Посмотреть сообщение
Why is this a debate? If you can edit the wiki and know a way to improve the data there, do so!
It's not a debate, it's a discussion about whether it would be a good idea. I don't want to be responsible for something that's a terrible idea before first getting some opinions. It wouldn't be easy to change everything back if people didn't approve.
Reply
#14

I think the reason ZCMD and the Streamer Plugin aren't in the server package, is because when they were in the server package, it would stop the freedom of the creator to release updates whenever they want. Incognito could only release his Streamer updates when there's actually a new SA-MP update, if the plugin was included in the server package. (Or you would ship outdated plugins.) I think you are all quite familiar with the frequency of SA-MP updates the last years, so adding things like Streamer Plugin and ZCMD aren't really an option.

Back to the "should ZCMD be on the Wiki": I think it would be best if both were to be explained, including their ups and downs. If that's too repetitive, make a specific page about this subject and link to it on every page with uses strcmp or ZCMD commands.
Reply
#15

Quote:
Originally Posted by Basssiiie
Посмотреть сообщение
I think the reason ZCMD and the Streamer Plugin aren't in the server package, is because when they were in the server package, it would stop the freedom of the creator to release updates whenever they want. Incognito could only release his Streamer updates when there's actually a new SA-MP update, if the plugin was included in the server package. (Or you would ship outdated plugins.) I think you are all quite familiar with the frequency of SA-MP updates the last years, so adding things like Streamer Plugin and ZCMD aren't really an option.
Easy fix - download the updates :/
Reply
#16

Quote:
Originally Posted by MP2
Посмотреть сообщение
Easy fix - download the updates :/
What's the use of adding them to the server package then? In the end, you'll still need to download them separately.
Reply
#17

it is an easy fix on the wiki. that's what wiki's are designed for. you can just rollback edits.
the server package is the responsibility of the samp team. you could for instance make a patch, wich replaces/adds some files.
Reply
#18

Quote:
Originally Posted by Basssiiie
Посмотреть сообщение
What's the use of adding them to the server package then? In the end, you'll still need to download them separately.
Actually, the version in the package can be updated instantly - you don't need a new SA-MP version at all.
Reply
#19

I remember kalcor wrote that he wont put content from outside the sa-mp team into sa-mp.
Anyway, i dont see this as a problem. Just add info about zcmd' streamer etc. On wiki so new scripters can see it and use if they wish. This isnt even nescesary for scripters with a little bit of experience.
Reply
#20

Quote:
Originally Posted by Richie©
Посмотреть сообщение
I remember kalcor wrote that he wont put content from outside the sa-mp team into sa-mp.
Anyway, i dont see this as a problem. Just add info about zcmd' streamer etc. On wiki so new scripters can see it and use if they wish. This isnt even nescesary for scripters with a little bit of experience.
Including something in the package isn't the same as including it directly in to SA-MP.
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)