Conclusion

[Jay]

Targets, Goals and Priorities

We are going to release one last version of the current gamemode. This version will address all known issues.

After this we will start on a new open source version: LVP: Remixed. This will be on google code and will be a total rewrite of all the core and most of the features. We will be porting over some handlers though.

This is going to be developed in 3 phases:


Phase 1:

- Core*
- Skins, Spawns, Vehicles*
- User account system*
- Administration*
- Minigames:-

Deathmatch Handler* - Sawnoff, Rocket, Sniper, Minigun, Grenade, Random, WalkWeapon
Hide and Seek
Robbery
RWTW

- Spawn Weapons*
- Races
- Properties
- Bank*
- Ship safety zone*
- Taxi system
- Gangs
- Reaction tests
- Fightclub
- Essential Commands: /commands /help /me, /tp, /ctp, /my, /time, /rules, /credits, /changelog *

Phase 2:

- Exports
- Derbies
- /chase minigame and killtime
- Taxes*

Phase 3:

- World Features*
- More essential commands, like /call etc*
- Tutorial*

Phase 4:

- This will be the start of the new features. We will hold a further meeting when we get to this stage.

* Items marked with a * will be rewritten.

We are going to release LVP Remixed as each phase is complete. The first phase will have an ETA of 3 months. Each phase thereafter will have an ETA of 1 month.

We will develop the core first of all and use the YSI libraries to speed up the process. YSI has the following features:

y_commands*
y_ini*
y_timers*
y_hook*
y_testing
y_scripting -
y_stringhash
y_als
y_bintree
y_bit
y_debug*
y_master
y_utils*
y_flooding*
y_classes*
y_colours*
y_groups*
y_td*

We will only use the libaries marked with a *.

For more information see the YSI topic:
http://forum.sa-mp.com/showthread.php?t=185611

The core will be written in PAWN. It will be divided into two parts.



Minigames will be handled from a seperate core which will be discussed as development of that begins.

Rules, Policies and Documentation

A new rule will be introduced effective to all developers: Every developer must make at least two commits a week or one ticket, or, show evidence of dev work. A Notices of Absence board will be setup in the development forum boards shortly.

New coding policies will be introduced and enforced:

Formatting

- One level of indentation equals 4 spaces, no tabs should be used.

- The opening curly brace of a block should be on a new line. Everything inside the block must be indented to the next level, of course excluding the closing curly brace.

- Binary operators (operators with 2 operands) must have a single space on either side of them.

- Opening parentheses must be preceded by a single space, but not followed by one. Likewise, closing parentheses must not be preceded by a space.

- Commas must be followed by a space, but not preceded by one.

Code:

stock RegisterPlayerAccount( const sPlayerAccountName[], const sPlayerPassword[])
{
    SendPlayerMessage(playerid, MSG_STYLE_BOX, "You have registered an account.");
    return;
}

Naming

- The names of all variables functions and methods should start with a lowercase letter, all subsequent words must have their first letter capitalized.

Code:

new bool:bIsPlayerRegisterd;
new iPlayerState;
new sPlayerMessage[128];

- Variable names must be as descriptive as possible.

- Do not use the Hungarian notation.

Style

- You must have knowledge of the core and the functions contained within it. These will be clearly documented on the trac. You must not use repetitive code. If a function already exists in the core, use it! Don't write your own.

- The core will have functions for formatting strings and most other everyday tasks such as sending simple textdraw messages, countdowns or debugging. You must use these functions where possible. If you need to, for example, send a different textdraw message with a different style, you should amend the core function to support this to allow for flexible use in the future.

- Variables must be local where possible.

- Array sizes should be kept to a minimum to keep the compiled amx small. If an array index value does not exceed 108, you should use the char operative to save memory.

Documentation

- The core will have dedicated wiki pages for every single function that it consists of with a full and frank explanation of the function together with comments in the source and a commented native call of the function so that it shows up in the PAWNO function list.

- When opening a new file it must contain a header detailing the contents and purposes and the authors / contributors. The header will also include a standard license.

How NOT to comment

- Each function should include a minor explanation of what the function does. However, do not over- comment. Let me pick out an example from the IV:MP source:

Code:

/**
* This function registers a player.
* @author Matthias
function RegisterPlayer (playerid, Password, Email)

That is pointless commenting. It's pretty obvious what the function does by the name alone. Instead this should have been commented like so:

Code:

/**
* This function first of all checks if a player is registered by querying the database.
* If not it inserts some basic player data into the database and flags the player as 'registered'
* Database fields: registered, name, email

- Looping

This is an area with a lot of debating and speculation. For looping we will be using the foreach library which is included in the YSI libraries as this is the most efficient and certainly the most popular method around.

Recruitment

We are going to open up a child board in the Las Venturas Playground Related Subjects board for development recruitments. In that board will be a stickied topic explaining the application process. Players will have to fill out a basic form:

Real, Full name:
Ingame Nickname (if different):
IRC Nickname (IRC is a requirement)
Age:
Date of Birth:
Nationality:
E-mail address:
SA-MP Froum profile URL (if applicable):
Previous Experience*:
Outline the reasons you believe that you would be a good developer:
If you can provide a reference, then please do so:

* Outline any previous teams you may have worked in, any other communities you have contributed towards in terms of development, or any scripts you may have released

A new childboard will also be setup in the dev forums so that we can discuss each applicant.

Once all that is setup, we will then create a new topic in the SA-MP Forum Scripting Discussion board to promote this and hopefully attract potential new applicants.

[xBlueXFoxx]

"3 phases" there's four. [me=xBlueXFoxx]Runs[/me]


On-topic, about phase one, will there be new guidelines about the new weapon handlers? People always complain about nading and drive-by's, soon after hopping off and finishing the player off. Clearly these forms of "abuse" can not stay much longer, is there any ways to solve this?


If drive-by's are going to still be considered a lame kill, I propose using the GetPlayerHealth, and GetPlayerArmour functions, as I believe estore suggested if the drive by'ing player takes X amount of health they get punished, punishment should not be harsh, possibly just eject them off the bike, RemovePlayerFromVehicle. (Only make it work for bikes as cars are much easier to evade.)


Same with the ship, "ship laming, ship shooting, ship nading" it would also be a great time to make more potential to get these features more automated, so that crew no longer has to deal with "abusive" nonsense. Mainly because as we know some "smart asses" love to read over the rules and try to create loop holes around them.


My proposal to "ship shooting" (shooting players who are on the ship) to remove the shooters weapons after taking X damage, the damage could range from what damage a sniper or D.eagle does, if removing weapons does not sound good enough then jail them. Even the goodie fighters love to ship shoot when admins are not around.


Ship nading, some people do not like nades, people nade the ship, I suggested before to remove grenades from anyone within the area of the ship and where the armor pick up is at the parking lot across the street of the ship, if you really want to throw a grenade into a fight, pick a different area.


Now for Ship laming! Something that's been pestering crew away from their jobs for ages since the rule was born, meaning when a player gets into a fight and notices or knows he is going to lose, runs to the safe-zone for protection and refills.


My proposal to ship laming, possibly use the world boundies script or what ever is used for the admin "box" script that traps the player within a box, when you leave the box you get forcefully pushed back in. I would say use this, if someone shoots and runs back to the ship without killing X people or X amount of time (what ever works best) gets ejected out or set the player position to the center of the road.


As for other forms of abuse, "command abusing" will it still exist? Will players now be able to disappear away from a fight? How ever this is a cheap method of running, this is nearly impossible to over come unless the rule is removed, my proposal to /world abusing would be to make worlds only accessed by admin permission, with a good reason possibly, what reason would a user have to go to another world?


/TP /CTP abusing, probably the hardest to overcome when it comes to command abusing, Jay mentioned if the server gets upgraded to a more stunt friendly server, the server will need more precautions to TP abusing if it is going to contain stunting and death match in the same area. Death matchers love to kill the random new people who join the server, they're new, easy, easy ratio whoring, and it makes them look better than all. Which really drives the new players away, the only way to really get this to work out properly is to seperate the 2 forms of players away, but the death matchers will complain. I personally have no proposal to this, I just want an opinion on what can be done to solve this, it's going to be a massive problem if not solved.


Now a bit of a different turn in discussion, Idling. People some times need to go AFK, because they may have important, or less important things to do for a quick moment like go take a piss or get a bite to eat, but don't want to leave the game and lose stats or their spawn weapons. Also annoying enough to say, idle whores do indeed make the server look bigger, people always want to join bigger servers, kind of a snow ball rolling down a hill and getting bigger and bigger.


My proposal to idle "whoring" would be to allow it up to 20 minutes in the new LVP, but after 5 minutes get no benefits, no money from the ship, no money from properties.


Also in a different direction, Flaming! People who DM, most likely love to flame, cuss at players, friendly comp, racism. These are some issues in which are sometimes hard to punish because people also love to find loopholes in such a manner [Example: "nigga" means "friend" and "nigger" means an black person.] These things can not be excepted, possibly have some sting detection to tell if someone has said these things, but people would find their ways around it. [Example: N!gg@] Another possibility though would be a somewhat no tolerance guideline, better notification not to swear in the main chat, swear words directed to other players will not be tolerated. Once again something that would make a crew members life easier without having to tolerate some one finding their ways around the rules or pushing them to the limits.




The reasons I conclude this is because this is almost a new start for LVP, a more stable crew will be able to control the server much more stable without having to deal with the trolls. A player can not argue with the server itself, automated systems are definitely a big help rather than giving an admin a shovel and a pile of shit. Instead if he dislikes the server, he can file a complaint in the CSI, or get lost.

[Matthias]

Both of your coding policies examples are wrong.

Code:

stock RegisterPlayerAccount( const sPlayerAccountName[], const sPlayerPassword[])
{
    SendPlayerMessage(playerid, MSG_STYLE_BOX, "You have registered an account.");
    return;
}

How are the variables passed on to that function constant in any way? It should look like this:

Code:

stock registerPlayerAccount (playerAccountName[], playerPassword[])
{
    SendPlayerMessage (playerid, MSG_STYLE_BOX, "You have registered an account.");
    return;
}

And this:

Code:

new bool:bIsPlayerRegisterd;
new iPlayerState;
new sPlayerMessage[128];

Code:

new bool:isPlayerRegistered;
new playerState;
new playerMessage[128];

Should be something like that. Although I still wouldn't know what "playerMessage" would contain.

[Jay]

How are the variables passed on to that function constant in any way?

In what circumstances would these parameters not be constant darling? Please elaborate here.
In no instance should the function modify any of these variables.
Using initialisers allows for more efficient compiling.

It should look like this:

Code:

stock registerPlayerAccount (playerAccountName[], playerPassword[])
{
    SendPlayerMessage (playerid, MSG_STYLE_BOX, "You have registered an account.");
    return;
}

Whilst it may be better coding practice to prefix functions with lowercase letters in other languages, SA-MP's syntax is different to this and would complicate matters if we changed it now.

Code:

new bool:isPlayerRegistered;
new playerState;
new playerMessage[128];

Should be something like that. Although I still wouldn't know what "playerMessage" would contain.

Again not only is it better coding practice to prefix variable names with a single lowercase letter to indicate the variable type but it makes future reference much easier. It is pretty obvious that the sPlayerMessage variable is a string given the s prefix.

[Matthias]

In what circumstances would these parameters not be constant darling? Please elaborate here.

When data is passed on to the function? I doubt all players will have the same name and the same password. It seems pretty useless to make function parameters constant. I've never seen anyone do that in any language.

In no instance should the function modify any of these variables.
Using initialisers allows for more efficient compiling.

I strongly doubt this is the case. It seems silly to make a constant of what once was a variable, this isn't even possible in some languages. In C++ (or C#), try setting a constant to a variable which isn't known at compile-time. I'm not sure about PHP but I doubt it's possible there and it doesn't seem like good coding practice to me.

Whilst it may be better coding practice to prefix functions with lowercase letters in other languages, SA-MP's syntax is different to this and would complicate matters if we changed it now.

Then why do I see "The names of all variables functions and methods should start with a lowercase letter, all subsequent words must have their first letter capitalized." in your coding policies?

Again not only is it better coding practice to prefix variable names with a single lowercase letter to indicate the variable type but it makes future reference much easier. It is pretty obvious that the sPlayerMessage variable is a string given the s prefix.

Please Google Hungarian notation, if you know what it is, re-read your post. And I know it's a string, but what would it contain? A message about a player? A message to be output to the player? A message set by the player?

[Jay]

When data is passed on to the function? I doubt all players will have the same name and the same password. It seems pretty useless to make function parameters constant.

What the hell are you talking about? These are parameters local to the function -- I suggest you look up the functionality and purpose of the const initialiser in PAWN and most other languages darling.

I strongly doubt this is the case. It seems silly to make a constant of what once was a variable, this isn't even possible in some languages.

Again you are not making any sense whatsoever and I again suggest you look up the point of declaring function parameters constant.

Code:

native SendClientMessage(playerid, color, const message[]); // Just like 90% of SA:MPs natives which have string parameters

Here's a helping hand:

const is not widerly used however it declares a variable which can not be modified by code. There are a few uses for this - functions with const array parameters can sometimes be compiled more efficiently or you may want something like a define but which is an array. const is a modifier, it must go with new or another variable declarator. If you try modify a const variable the compiler will complain

Then why do I see "The names of all variables functions and methods should start with a lowercase letter, all subsequent words must have their first letter capitalized." in your coding policies? Please Google Hungarian notation, if you know what it is, re-read your post.

It was late. This post took me a while to make and we had been discussing this shit for 2 and half hours. I literally copied and pasted the documentation off the IV:MP wiki. I will be reviewing and amending it before the new policies go live.

And I know it's a string, but what would it contain? A message about a player? A message to be output to the player? A message set by the player?

The message itself is not at all relevant or important in anyway whatsoever.

[Matthias]

What the hell are you talking about? These are parameters local to the function -- I suggest you look up the functionality and purpose of the const initialiser in PAWN and most other languages darling.

Which is exactly why I don't get the use of making them const. But apparently it turns out it's neat to do that in PAWN, so forget about it.

The message itself is not at all relevant or important in anyway whatsoever.

I was just pointing out that it also said that all function and variable names should be as descriptive as possible.

Could you also stop calling me "darling"? I don't like being looked down at.

[Jay]

Could you also stop calling me "darling"? I don't like being looked down at.

Lol relax, I didn't mean to for that to be offensive, darling