3.0 Vehicles

[Jay]

I noticed thiaZ done some work on the vehicle manager for 3.0. Its unfinished however and since it hasn't been worked on for quite a few weeks I'd like to take over it.
Obviously however, a few things need to be discussed.

Wrapping

SA-MP doesn't really have many vehicle functions. For example, if we wanted to change a vehicles spawn position we would have to destroy it and re-create it. This can be quite messy. SetVehiclePos does not work if a vehicle is empty.

To give us more control in the longrun I'm proposing that we handle vehicles on our own. EG when a vehicle is respawned or "dies", we destroy it completely and just create a new one. Exceptions will, however, obviously be added for things such as NPC driven vehicles.

The disadvantage of doing it this way is efficiency vs organisation. It's obviously much more efficient to just leave a vehicle in after it respawns and let SA-MP do the rest.

It may also be useful when writing the wrapper method for creating the vehicle to add additional parameters for mods, number plates, and anything else mentioned in the list below.

External

I think vehicle data should be stored externally. This makes it possible for staff to modify various vehicle flags in the future and add and amend vehicles 'on the fly'.

Potential flags to save:-

Vehicle model ID
Vehicle current location + world(?)
Vehicle spawn location + world
Vehicle mods, such as spoilers, nitro, etc.
Vehicle number plate
Vehicle status (i.e. locked/unlocked) (?)
Vehicle owner - this can be discussed at a later date.

Is there anything else that needs to be tracked? I was thinking about vehicle alarms for example, but I'm not sure how we could use these.

In addition, how should this data be saved? The easy solution is a MySQL database, but a more thought-out answer maybe an SQLite database because:-

- Such vehicle data is only required locally to the server
- No need to thread the queries so it makes code organisation much easier
- Very little / No notable performance changes since these queries will potentially only run upon gamemode initialization / exit.

Management

As previously iterated it would be much more effective if staff members could modify vehicle attributes on the fly and amend the vehicle layout as they see fit.

What level of staff members should be able to control this data?
Should current vehicle attributes such as vehicle mods and colour save, or should these be forgotten about after a vehicle respawns? Perhaps this could be an option for the player saving the data?

Other features

Anything to add? I'm not sure if people had some ideas for things like speedometers, realistic fuel or random vehicle spawning.

[Russell]

I'd like to start by telling you a bit about the architecture of the new gamemode, which is quite important to keep in mind in order to avoid layer violations as much as possible.

Natives/ is the interface with the server, the real low-level stuff. This will contain the Vehicle class providing access to its information (location, health, adding mods/numberplates and the like) which communicates to the SA-MP server. All vehicle related natives should be implemented in this class, and must not be exposed to the rest of the gamemode. This will lead to code such as:

Code:

native internalSetVehicleVirtualWorld(vehicleid) = SetVehicleVirtualWorld;
class VehicleLocation union Vehicle {
    public inline setVirtualWorld(VirtualWorld: world) {
        internalSetVehicleVirtualWorld(_: world);
    }
};

A decent example of this can be seen in the Player class (Player*.pwn in Natives/). That isn't done yet either. This is rather boring and dull work, so I suggest you do it in parts.

Sources/Game/VehicleManager.pwn will be the manager in charge of creating and destroying vehicles, both as static functions. They'll take care of choosing random colors, registering them with the server and setting the proper initial state for the vehicle to work properly. We are not going to be using the AddStaticVehicle function because that reduces flexibility in the long term, and I believe that its minor benefits do not justify that. Instead, everything will be done using CreateVehicle.

Sources/Entities/ is for encapsulating the higher-level functions related to vehicles. I'm still not entirely sure what these have to be, given that vehicles are quite limited besides their interface, but this would be the place to handle at least some of the callbacks. When writing these, keep this rule in mind: If your method is longer than a hundred lines of code, you're doing it wrong.

SA-MP doesn't really have many vehicle functions. For example, if we wanted to change a vehicles spawn position we would have to destroy it and re-create it. This can be quite messy. SetVehiclePos does not work if a vehicle is empty.

Can you give use-cases for this feature? I see no reason to allow changing the spawning position of a vehicle - why would we need this? One of the things I'd like to avoid with LVP 3 is bloat of the gamemode - reduce the amount of code to the absolute minimum. Assuming that there are just a few trivial use-cases, it would be better for these pieces of code to simply remove and re-create the vehicle when that may be needed.

To give us more control in the longrun I'm proposing that we handle vehicles on our own. EG when a vehicle is respawned or "dies", we destroy it completely and just create a new one.

You know these parts of SA-MP better than I do. What is the benefit of this? Requesting the client to create new vehicles rather often (because vehicles will die quite frequent) will lead to an increase in traffic, but also to an increased chance of crashing.

It may also be useful when writing the wrapper method for creating the vehicle to add additional parameters for mods, number plates, and anything else mentioned in the list below.

Don't overdo it -- there already are a bunch of parameters in VehicleManager::create(), but that should be limited to the really required information. Right now, interior and virtual world are included but I'm not sure whether they really should be - the vast majority of the vehicles won't be having a need to change them. If a functionality only applies to a minor amount of the uses, then it probably shouldn't be included in the common path.

I think vehicle data should be stored externally. This makes it possible for staff to modify various vehicle flags in the future and add and amend vehicles 'on the fly'.

Agreed. These can perfectly be stored in the Vehicle class in Natives/. We do the same with various pieces of code in the Player classes, mostly with things that the SA-MP server doesn't expose. Alternatively we could write a plugin exposing these features, but we should only do that if the necessity of the said feature is trivial (e.g. amending the mods -- it's not a major inconvenience if that is broken).

Is there anything else that needs to be tracked? I was thinking about vehicle alarms for example, but I'm not sure how we could use these.

We can add Vehicle::setAlarm and Vehicle::hasAlarm methods, same with the objective pointer above vehicles, if I recall that correctly. They are trivial to implement and expose a much nicer interface to the features may we ever need them. Maybe it's useful to store their state in a "m_flags" property in the class, using one bit per status (dito with mods and the locked/unlocked status), to save file-size.

In addition, how should this data be saved? The easy solution is a MySQL database, but a more thought-out answer maybe an SQLite database because:-

- Such vehicle data is only required locally to the server
- No need to thread the queries so it makes code organisation much easier
- Very little / No notable performance changes since these queries will potentially only run upon gamemode initialization / exit.

Agreed. We need to start synchronizing the SQLite databases anyway. I suggest we save the vehicles upon modification (e.g. a change by an administrator) and load the vehicles on gamemode initialization.

As previously iterated it would be much more effective if staff members could modify vehicle attributes on the fly and amend the vehicle layout as they see fit.

LVP needs more stability, so we'll have to discourage changes in this respect. Nonetheless, I agree. We will have to figure out how to differentiate between changes that only apply to the current session (e.g. adding nitro using /nos), and changes which have to be persistent. Also important, it shouldn't become a mess: nitro or modifications by default should be special.

What level of staff members should be able to control this data?
Should current vehicle attributes such as vehicle mods and colour save, or should these be forgotten about after a vehicle respawns? Perhaps this could be an option for the player saving the data?

I'd say the entire Staff. Having some trust in them is important, and we can implement policies on how to handle them preventing abuse. For most vehicles I think it'd be beneficial to re-spawn in different colors every time, but we do need the ability to serialize a specific combination of colors and mods. Coming up with a proper database schedule for that is important. Do you mind if I write the Database-communication part?

Anything to add? I'm not sure if people had some ideas for things like speedometers, realistic fuel or random vehicle spawning.

These do not belong in the Vehicle classes, as they are separate features. They might be controlled as vehicleFlags in the Player class and be called from inside the Player::processControl method, but only if necessary (e.g. check the value of the flag before actually invoking the method). We're getting rid of rediculous things such as ninety-minute-timers

Thank you for doing this!

[Matthias]

I don't have much to add, Russell pretty much summed up all my points already, I agree on everything with him.