Ok one unit is this. One car is half a unit so one car is named South and one car is named North and these reference the end so south end and north end these can’t be called front and back because depending what way you drive the train from the front and back side will change and it makes it easier to tell.
Also one unit would be one train and 2 units coupled would be 1 train and 4 units coupled would be 1 train but 2 units uncoupled would be 2 separate trains
So basically South and North aren’t two trains going two different directions they are just the 2 ends of 2 units.
When the train couples it gets the coupler from the south side of one unit and it gets the coupler from the north side of the other unit.
I was thinking more of when the train updates it’ll parent all the units from both trains and convert it into one train and delete the 2 original train models, reason for this is its easier to handle headlights, taillights, doors, and whatever else.
Speaking of which, both methods rely on Attributes, which, although they are significantly faster than value objects, are still poor compared to OOP’s use of metatables.
I would use OOP here, with a train or carriage class in the ModuleScript, so yes, using metatables would be best. Using colon methods to automatically pass the self parameter, you can couple up carriages, etc.
Here’s a tutorial if you’re stuck:
I think it’s worth pointing out why attributes aren’t optimal because they get replicated to all clients and hence OP is just wasting resources doing that when no client really need to know whether the train is coupled or not. Btw good call, I didn’t catch that.
How could I save the newCar table for later?
Do I have another table for Vehicles and then add the newCar table into that or can I find the newCar table from the metatable that it saves to?
I want to be able to find it like Vehicles[VehicleModel] and then be able to change things from that. I would like to create the class for the vehicle when the vehicle is spawned not when the player enters the seat.
I’ve probably made this reply very confusing but let me know if you need me to add more details for what I mean!
Yes, the key point being server, the clients have no business in knowing about it but using attributes replicates the state to every client, since the train will be parented to workspace. Attributes aren’t as bad as ValueBases as @ValtryekRBLX pointed out, but there really isn’t a reason to use it here as you can just create a property called IsCoupled which will reflect the state
Modules save their state so you can just store all the classes in a local dictionary and have a static function called Get which returns the class with corresponding model.
local TrainMap = {}
local Train = {}
Train.__index = Train
function Train.new(model)
local self = setmetatable({...}, Train)
TrainMap[model] = self
return self
end
function Train.Get(model)
return TrainMap[model]
end
local TrainMap = {}
local Train = {}
Train.__index = Train
function Train.new(model)
local self = setmetatable({}, Train)
TrainMap[model] = self
self.Thing = "OOF"
return self
end
function Train:Get(Model)
print(#TrainMap)
if not TrainMap[Model] then
print("New")
return Train.new(Model)
elseif TrainMap[Model] then
print("Find")
return TrainMap[Model]
end
end
return Train
The server script just shows how I call it and its just firing random things to test and it works ok. Would using metatables be the most performant way to create a vehicle system or another way?
mb I shud have left it as blank but the … was just a placeholder for the properties of the class.
I would use OOP because I’m more familiar with it and tbh it’s pretty good way to go about this. As for optimization, I don’t recall OOP having any performance overhead and I have seen many top devs use the OOP pattern so it should be just fine. But just like I said before, don’t sacrifice readability over optimization in such cases. Using OOP or generic tables here would essentially just harbor the same results with little difference in performance which half of the time won’t even be noticeable
