You insist that there's updates for different language SQLs but only one exists and ALL columns are in english.
In the update section in the readme you are say to add a column named fourrieremecano. Now that's great but that translates as 'mechanic pound'. So you want some columns in english and some not...you already have a pound table in the sql of typ tinyint which for lua acts as a boolean anyway. Your solution is inconistent and the 4 references to fourreremecano in lua should be updated to pound to match the column name as listed in your committed sql, RATHER than getting us to add a second column which then doubles up. Why keep in the pound column if we're adding another column for the same purpose...
I've also fix a remaining vehicle duplication issue where if you buy a vehicle but don't store it in garage. I have it so you can drive straight from dealership and NOT store, retrieve from impound and the original one is deleted. It's amazing to me that simple testing isn't done to catch these use cases.
You insist that there's updates for different language SQLs but only one exists and ALL columns are in english. In the update section in the readme you are say to add a column named
fourrieremecano
. Now that's great but that translates as 'mechanic pound'. So you want some columns in english and some not...you already have apound
table in the sql of typ tinyint which for lua acts as a boolean anyway. Your solution is inconistent and the 4 references to fourreremecano in lua should be updated to pound to match the column name as listed in your committed sql, RATHER than getting us to add a second column which then doubles up. Why keep in the pound column if we're adding another column for the same purpose...I've also fix a remaining vehicle duplication issue where if you buy a vehicle but don't store it in garage. I have it so you can drive straight from dealership and NOT store, retrieve from impound and the original one is deleted. It's amazing to me that simple testing isn't done to catch these use cases.