Add support please plugin "Spawn Modular Car"
Support for Spawn Modular Car pluginSuggestion
Link please
I'm open to a discussion about how the ideal integration would work since it's not super obvious to me in which plugins the functionality should go.
The ideal user experience, as I understand it, sounds something like this. A server command is issued to give a player a car with predetermined length, modules, engine parts, code lock, etc. The player is given an item in their inventory that looks like a car. When that item is placed, a modular car is spawned with all of those options (similar to how Spawn Modular Car can spawn a car with those settings). When the player picks up the vehicle with the hammer, all of the data about the car, such as health, modules, fuel, container items, engine parts, and locks would be recorded and associated with the item somehow. When placing that item back down, the car would be spawned as it was, with health, fuel, engine parts, etc. exactly as before.
My first question is, where should the functionality to keep track of all that info go? Arguably things like health should be persisted for other vehicles, so that's one argument for doing some kind of tracking inside the Portable Vehicles plugin. If this plugin is tracking some data, why not have it track more, and why not vehicle-specific features?
Tracking data in Portable Vehicles make sense to do for native game features like health and car modules, but some functionality is provided by other plugins such as car code locks. It's probably not wise to have the Portable Vehicles plugin be coded to be specifically aware of all the features of vehicle customization plugins like Spawn Modular Car or War Copter as their list of features is likely to grow, and we shouldn't be reliant on Portable Vehicles being updated to support new features they introduce.
When it comes to saving plugin-related data for a portable vehicle, it probably makes sense to keep Portable Vehicles generic and provide hooks for other plugins to save data or load data, such as OnPortableVehiclePlaced, OnPortableVehiclePickup. For example, the Modular Car Code Locks plugin could hook when the car is picked up to save data about the code lock, as well as hook when the car is placed to recreate the code lock. This additional data could potentially be tracked in the Modular Car Code Locks plugin, or alternatively it could somehow be generically injected into the data that the Portable Vehicles plugin saves via a hook, which would make it easier for other plugins to implement.
One consideration is that Portable Vehicles plugin is fairly simple and generic, and it would be nice to keep it that way rather than bloating it with concerns specific to modulcar cars. As far as I know, the way Portable Vehicles currently works with modular cars is that the item the player is given will have random modules assigned to it when placed. When picked up and placed again, the modules are randomized again. IMO, this experience is OK, not broken (except for the pickup experience maybe), so there is not an emergent need to bloat this plugin with functionality related to modular car presets.
---
Another way of looking at it, is Portable Vehicles shouldn't have any persistence information in it at all, and should simply provide hooks. The default behavior would be that a vehicle with fuel or items in containers would not be able to be picked up, unless another a plugin that knows what to do with that information decides to overrides the hook (e.g., hook could be called CanPickupPortableVehicle) and presumably persists that data in its own system, which would then be restored by that plugin when it detects the item is placed. My suggestion for that hook would be to allow true to allow pickup, false to prevent the pickup, and null for default behavior. Semi-generic plugins like a Portable Cars plugin could expose an additional hook like CanPickupPortableCar to allow resolving hook conflicts that would likely ensue when another plugin wants to block a special car from being picked up.
The ideal user experience, as I understand it, sounds something like this. A server command is issued to give a player a car with predetermined length, modules, engine parts, code lock, etc. The player is given an item in their inventory that looks like a car. When that item is placed, a modular car is spawned with all of those options (similar to how Spawn Modular Car can spawn a car with those settings). When the player picks up the vehicle with the hammer, all of the data about the car, such as health, modules, fuel, container items, engine parts, and locks would be recorded and associated with the item somehow. When placing that item back down, the car would be spawned as it was, with health, fuel, engine parts, etc. exactly as before.
My first question is, where should the functionality to keep track of all that info go? Arguably things like health should be persisted for other vehicles, so that's one argument for doing some kind of tracking inside the Portable Vehicles plugin. If this plugin is tracking some data, why not have it track more, and why not vehicle-specific features?
Tracking data in Portable Vehicles make sense to do for native game features like health and car modules, but some functionality is provided by other plugins such as car code locks. It's probably not wise to have the Portable Vehicles plugin be coded to be specifically aware of all the features of vehicle customization plugins like Spawn Modular Car or War Copter as their list of features is likely to grow, and we shouldn't be reliant on Portable Vehicles being updated to support new features they introduce.
When it comes to saving plugin-related data for a portable vehicle, it probably makes sense to keep Portable Vehicles generic and provide hooks for other plugins to save data or load data, such as OnPortableVehiclePlaced, OnPortableVehiclePickup. For example, the Modular Car Code Locks plugin could hook when the car is picked up to save data about the code lock, as well as hook when the car is placed to recreate the code lock. This additional data could potentially be tracked in the Modular Car Code Locks plugin, or alternatively it could somehow be generically injected into the data that the Portable Vehicles plugin saves via a hook, which would make it easier for other plugins to implement.
One consideration is that Portable Vehicles plugin is fairly simple and generic, and it would be nice to keep it that way rather than bloating it with concerns specific to modulcar cars. As far as I know, the way Portable Vehicles currently works with modular cars is that the item the player is given will have random modules assigned to it when placed. When picked up and placed again, the modules are randomized again. IMO, this experience is OK, not broken (except for the pickup experience maybe), so there is not an emergent need to bloat this plugin with functionality related to modular car presets.
---
Another way of looking at it, is Portable Vehicles shouldn't have any persistence information in it at all, and should simply provide hooks. The default behavior would be that a vehicle with fuel or items in containers would not be able to be picked up, unless another a plugin that knows what to do with that information decides to overrides the hook (e.g., hook could be called CanPickupPortableVehicle) and presumably persists that data in its own system, which would then be restored by that plugin when it detects the item is placed. My suggestion for that hook would be to allow true to allow pickup, false to prevent the pickup, and null for default behavior. Semi-generic plugins like a Portable Cars plugin could expose an additional hook like CanPickupPortableCar to allow resolving hook conflicts that would likely ensue when another plugin wants to block a special car from being picked up.
yes your description is great
the machine can be installed using an object, it is not necessary to select
the machine can be installed using an object, it is not necessary to select