I've started a spinoff thread as this request is not easy to implement at the moment but is important to do eventually, to get different types of dashboards looking correct.
This ties in (to some extent) with something else on one of my note papers. In that case, I noted that the system materials are fixed in their settings, with an example that s_plate_alp is always ALPHA and material settings have no effect.
The idea for improvement is that there should be system *textures* instead of system *materials* and then the user would be able to set material settings in the normal way. I'm talking about the internally generated or live textures like number plates, the info texture and dashboards.
How this ties in with your request: The various s_clock_x are also hard coded as materials rather than simply textures. As a result, user settings (like matt / shine) have no effect at all on these materials. There is no good reason for this now, but LFS has developed from a simpler era and this was how it was implemented to suit our needs at the time, and this part hasn't yet been modernised. In order to support your suggestion by this method, in addition to changing the system materials to be textures (as they should be) I think a new material setting may need to be added, a "self-lit" option.
Currently this proposed self-lit option is forced on dashboard textures but is unavailable for any static textures. So that option would be set, in the material settings of the cutout editor, for all existing uses of s_clock_x pages (and I expect MATT would also be set for existing cutouts).
If this is the way forward, I'm not yet sure yet how the self-lit option should be implemented. Would it be a separate switch, still allowing the other material options, or would it be a separate material type in like MATT/CSHINE/etc?
I've had a look at how how self-lit things are done in the track editor and see if it could be consistent with that. This brings up another point. The self-lit things in the world environments, e.g. the lens of a street light or a lit logo on a shop front, actually receive light from the environment, or can be self-lit. This is done by setting a switch on the *mapping* (or colour) rather than in the material settings.
So it seems there are 3 main types of self-lit status.
1) Not self-lit - just like all static textures in the game
2) Totally self-lit - like a computer screen, and current LFS dashboards
3) Lit by environment and also self-lit - like traditional dashboards
I'm not sure yet how these 3 options should be supported, or if there are other types in this category.
Maybe...
2) above is a material setting (currently it is in LFS although the user cannot control it)
3) above is a switch to be enabled on mappings/colours (as can now be used for track editor objects)
I think that for now is too complicated to change the new graphics to support this and to also implement it in the old D3D9 engine. I think it would be best to do it when there is only one version of LFS. So what I have done is added the note about clocks, to my existing notes regarding the other system textures. But this thread is open for discussion.
This ties in (to some extent) with something else on one of my note papers. In that case, I noted that the system materials are fixed in their settings, with an example that s_plate_alp is always ALPHA and material settings have no effect.
The idea for improvement is that there should be system *textures* instead of system *materials* and then the user would be able to set material settings in the normal way. I'm talking about the internally generated or live textures like number plates, the info texture and dashboards.
How this ties in with your request: The various s_clock_x are also hard coded as materials rather than simply textures. As a result, user settings (like matt / shine) have no effect at all on these materials. There is no good reason for this now, but LFS has developed from a simpler era and this was how it was implemented to suit our needs at the time, and this part hasn't yet been modernised. In order to support your suggestion by this method, in addition to changing the system materials to be textures (as they should be) I think a new material setting may need to be added, a "self-lit" option.
Currently this proposed self-lit option is forced on dashboard textures but is unavailable for any static textures. So that option would be set, in the material settings of the cutout editor, for all existing uses of s_clock_x pages (and I expect MATT would also be set for existing cutouts).
If this is the way forward, I'm not yet sure yet how the self-lit option should be implemented. Would it be a separate switch, still allowing the other material options, or would it be a separate material type in like MATT/CSHINE/etc?
I've had a look at how how self-lit things are done in the track editor and see if it could be consistent with that. This brings up another point. The self-lit things in the world environments, e.g. the lens of a street light or a lit logo on a shop front, actually receive light from the environment, or can be self-lit. This is done by setting a switch on the *mapping* (or colour) rather than in the material settings.
So it seems there are 3 main types of self-lit status.
1) Not self-lit - just like all static textures in the game
2) Totally self-lit - like a computer screen, and current LFS dashboards
3) Lit by environment and also self-lit - like traditional dashboards
I'm not sure yet how these 3 options should be supported, or if there are other types in this category.
Maybe...
2) above is a material setting (currently it is in LFS although the user cannot control it)
3) above is a switch to be enabled on mappings/colours (as can now be used for track editor objects)
I think that for now is too complicated to change the new graphics to support this and to also implement it in the old D3D9 engine. I think it would be best to do it when there is only one version of LFS. So what I have done is added the note about clocks, to my existing notes regarding the other system textures. But this thread is open for discussion.