[PowerPC603]

Quote:

Originally Posted by malaka So, the ban command is the first thing you do when you're working on a new gamemode? Isn't there something more important like the basic stuff? I don't know about you but I would start with the system itself and later on I would add some extras and the administration stuff.

It's because I already added register/login system and the ban-system is merged with it.
I can't test anything without loaded player-data. Or I would need to use GivePlayerMoney and GetPlayerMoney first everywhere a player earns money, and adjust everything again later on.

A player's IP and account are checked for a ban before the rest of the data is loaded (actual player-data like money, score, admin-level, ...).

Since I created features before and never really finished them (or I needed to make huge modifications to the existing system), I want to finish it before moving on.
Otherwise I would need to write a part of system A today, start working on system B, then move on to system C, and later on, continue working on system A, where stuff from part B also needs adjustments.

I would just move in circles and there may be features left eventually that are only partially finished, or perhaps even buggy.

Since the ban-system is already in there, I need to add the ban command first as it's directly related to the ban-system.

There will also be a /bans command, where the admin can browse the banned accounts and even unban them in-game.

Quote:

Originally Posted by [HM]Nicky Releasee this im looking for offlineban

I guess I could post the /ban command and it's related functions once I have added the reason to the database.
You just need to figure out the structure of the APlayerData array and the database itself to adjust it to your own code.
But it would show you how I got it working.
But it won't work with V1, as V1 still uses files and you can't browse directories (list files in directories) with default samp functions.
The /ban command uses MySQL to do the offline banning (in fact the entire script uses MySQL).
Using a database, it's simple, as it only takes a simple query to get all player-accounts which contain part of a player-name.
Using files, it's nearly impossible to get the same results.
Unless you know the EXACT filename (or exact playername), then it would be possible.

Quote:

You could make it in a way so that if 5 players vote for kick he will be kicked and if 10 people vote for it or if he already got kicked, he will be banned for few hours based on the default settings.

How could players vote 10 times when he'll be kicked at the count of 5 votes?



When that's finished, I'll start working on speedcams and police stations again.

After that, I'll see what I can do, perhaps start working on the companies again and add gas-stations as first company-type, so the refuelling works again.
There would be no point to have vehicles consume fuel already and not being able to refuel anywhere.

And after that, maybe start working on some classes and the job-system.
This will take time as it will be brand-new code, I can't copy-paste it from my previous V2 and make slight adjustments.

But in the end, when trucker class is working and I can define the jobtype inside the job itself, and allow the code to automatically use related functions, many classes may work at the same time, since several classes share the same job-type.
Like transporting some product from A to B, this will be a point-to-point jobtype.
The same can be done for point-to-multi-point jobtypes, where you load the product at one location and you need to drop it off at several destinations (like fuel perhaps, where you load the fuel at the refinery and deliver fuel to multiple gas-stations).
Then there will also be ending-route jobtypes, like the jobs with small planes (dropping packages and returning to homebase).
Also never ending routes like busdriver, these jobs keep looping around until the player himself finishes the job by going back to homebase.

And several other jobtypes as well.

Since these systems have their own code, but use data to work with, it could be made so several classes use the same code (possibly with a few exceptions here and there), and multiple classes work instantly, instead of creating split-up code per class like before.

Since V2 will have gradual loading, the entire job-system will be contained inside a timer that runs every half a second or so.
The /work command will still be used to setup the job-data, but the job itself is executed, checked and processed by the job-timer.
And it will hold many job-steps as well.
V1 only had jobstep 1 (going to load the products) and jobstep 2 (going to unload the products).

V2 will have much more jobsteps.
When the /work command has set the data, the jobstep will be set to JOB_STARTED.
Now the timer will take over and will update textdraws and create the first checkpoint.
The job will switch to JOB_GOINGTOLOAD.

This part will only check if you're within the checkpoint and you have a speed of 0.
Entering a checkpoint will no longer use TogglePlayerControllable, since I want to add a feature where players can leave the checkpoint early and depart with only a part of their vehicle loaded.

Once they're inside the checkpoint with a speed of 0, the job will be JOB_LOADING.
During this loading, the timer will check if you're still inside the checkpoint (speed won't matter) and gradually load your vehicle until it's full, or you leave the checkpoint.
Then it will switch to JOB_LOADED.

This step will delete the checkpoint and create a new one for your destination and update textdraws.
Then it becomes JOB_GOINGTOUNLOAD.

This will again check if you're inside a checkpoint with a speed of 0, which will then switch to JOB_UNLOADING.
Now you should stay inside the checkpoint until your vehicle is unloaded entirely.
If you leave the checkpoint early, you still won't get your money and you'll get a message you should keep unloading.
In case of a point-to-point job, when your vehicle is empty, the job will switch to JOB_UNLOADED.
This step will check if the job should end (in case of a point-to-point jobtype) or continue with JOB_GOINGTOUNLOAD in case of a point-to-multi-point jobtype.

In case the job should end, it will switch to JOB_FINISHED.
The JOB_FINISHED status will pay your money and end the job, then go to JOB_NONE.

In case of a point-to-multi-point jobtype, after unloading (the required amount of goods to unload at the destination will be displayed and could be random), it will again switch to JOB_GOINGTOUNLOAD, as there are more destinations to unload.
This goes on until your vehicle is empty, or the last destination has been reached.
At each unloading point, you would receive part of your payment as well.

This system will enable me to split up the job in multiple steps and create specific code for each step.
And since it's a timer, it will run all the time for all players and the job will automatically continue with the next step.

The timer will also be responsible to check if you're still inside your vehicle and check for fail-conditions.