In reference to BeamNG.drive\lua\ge\extensions\core\vehicles.lua lines 337-340. Game version 0.6.1.0 Currently in a configuration (such as info_race.json for the Covet) the default_color must be declared as a text string which matches a string in the colors array from info.json for the Covet. If we want to create a new configuration such as info_custom-covet-torsion.json we are restricted to only those colors already created from the stock Covet. I would like to be able to declare numeric values instead. I propose specific code changes below. We must currently do something like this: Code: "default_color":"Fire Red", But I would like to do something like this: Code: "default_color":"0.93 0.56 0.56 1.2", Here is the existing code from line 337-340 which I would like to replace: Code: if configData.default_color then configData.default_colorname = configData.default_color configData.default_color = model.colors[configData.default_colorname] end Here is my proposed replacement which determines whether the string is a set of numeric color values or not: Code: if configData.default_color then if not string.find(configData.default_color,"^[0123456789.]+%s[0123456789.]+%s[0123456789.]+%s[0123456789.]+") then configData.default_colorname = configData.default_color configData.default_color = model.colors[configData.default_colorname] end end EDIT: I've attached a mods-folder compatible zip to demo the change.
the problem i see with that is, that the color you then have is only known to lua and get's lost when the data is forwarded to the ui. Let me pose two alternatives we could add: First we could have a colors table in the info of the config, that gets merged into the official colors list, so you would also see the new colors inside the vehicleselector. This is rather easy, since it jsut reuses all the stuff thats around already. The code would later look somewhat like this (insert before 337) Code: if configData.colors ~= nil then for i,v in pairs(configData.colors) do if model.colors[i] == nil then model.colors[i] = v end end end Or second we merge them in a seperate mods color list and display them in the user interface seperate as well, so ther would be factory colors, config colors and user colors in different sections But both have of couse the mergin problem of what happens if there is a namespace clash. So there is no guarantee, that if the user has two configurations with the same color names which one will be in the list and which won't... edit: Sorry if i wasn't clear what color table means: i meant you could do this in the info_race.json Code: "default_color": "some really cool color name", "colors": { "some really cool color name": "1 1 1 2" }
Thanks for the response, it seems like you've put some thought into this. (So have I !) The color is not lost to the UI. It's brought over into the color selector although the selector doesn't always update it's indicators correctly (you may need to ESC out of the menu and then go back into it). That color may be successfully saved to "user colors" from there. The solution I posted above was intended to address a very specific limitation of the game. It's not an overall solution for all of the game's limitations. I'll quote from the OP of this thread for an example "Warning : in order to put the custom color on the pessima, I'm obliged to overwrite an official file (info.json) . If I don't update the mod with the newest version of BeamNG ( actual version : 0.6.1 ), the description and colors of the pessima might become outdated" Obviously that's not acceptable for mods in the repository and it's a silly limitation! I think that my solution can be implemented immediately with no adverse affect at all. Furthermore it's my opinion that something similar should be implemented everywhere the game handles a color, in both directions where possible. In fact, now that I think about it the ability to determine whether a color is a name or a set of values which apply to the current vehicle could probably be put into a function... I suspect that some of the places where I'd like to see it could make this complicated though. If you want to increase the portability of the color, simply put a textbox under the color selector in the way that common graphics programs do today for hex values. Reading from all of the configs and dumping them into the standard colors table would turn into a mess in any case where there were a decent number of config packs installed: Collisions would occur where multiple names are given for the same color. Collisions would occur where the same name is used to describe different colors. The current system for loading these colors into a table would certainly need to be bulked up to handle these collisions. An alternative would be to pull all of these add-on colors into a separate table. But why bother? I don't see any benefit to putting these colors into a table. If the user wants to grab a color they can do so from the color selector. Hopefully I'm making some sense here. Again, the code above is a "do no harm" solution for an existing problem. A color system which is more robust would be great, but it can't happen overnight like this fix can.
Not doubting that a second Yes you are right the color is carried on to the ui, but the thing is: once the user selects another color and then decides he liked the standard one better, he is not able to get that color anymore, since it's not in the list of default colors. The only way for him or her is to select a different config and then the previous one again, so the default color is loaded again. This doesn't seem very user friendly and will most likely be missed by everyone. Sorry, my mistake was speaking about a lua table here, so that in the color selector the user would have a list of factory colors, user colors and something like config colors. I'll have to disagree with you here. I don't believe having a dual system where every value could be either a reference by string name or a value by itself is a good approach. Since it makes stuff complicated and we could just extend the available structure. Plus we already have a huge overhead of converting and interpreting colors (just take a look into the color.js file)
I think that we aren't communicating effectively about the tables issue. Please go back and re-read my post with the assumption that I *do* understand what you mean about the Lua table. I'm telling you that there are problems with collisions if you use the existing table and problems with presentation if you create additional tables. Don't forget that the user can currently save the original color using the custom color picker (not the swatch picker). As for your concerns about overhead - AFAIK those are completely unfounded. We are only talking about routines which bring data into the engine from files. Once it's in-game all colors are converted to the same format. The code I'm suggesting shouldn't slow the game down on an ongoing basis, so its not what I'd call overhead.
Came back from holiday and had a new Idea i added. You will be able to use Code: "default_color":"0.93 0.56 0.56 1.2", in your configurations since the latest update. The problem i have with your proposal is that it's quite user unfriendly. It makes reconsidering a color choice very annyoing, since you cannot go back to the default color as easily as you could usually do. So the solution that is now implemented inserts the rgb code as key and value into the factory color list. Thus not having any problem with name clashes. Only downside is that the tooltip for this color then will be the rgb string, but since we'll have to find a way to translate the color names anyway this should work out rahter nicely later.
@Saniamos revived - That seems like a good compromise until you can hash out how you want to handle it in the long term. Thanks! As far as that goes - I'd say that the second option you described in post #2 is my preferred one. I do still think that you'll have some decisions to make in order to prevent a mess with multiple config packs installed; but at least now we have some breathing room since you've implemented that temporary solution.
