On the subject of gauges...
I was trying to create a "horizontal speedometer" for one of my mods. When I was trying to calibrate it I've noticed that the speedometer needle position is slightly different in MPH mode than it is in KM/H mode.
Here you can see what happens when I switch between KM/H and MPH units in options:
It was impossible to calibrate it to show accurate speed for both the KM/H units users and the MPH users. Because of that, I decided to scrap it and went with a fictional digital gauge cluster.
Anyway, what I'm trying to say - it would be nice if the needle position was identical for both MPH and KM/H setting. This would be helpful when creating custom gauges. Ability to adjust the thickness of the needle would also be useful.
I also have a question regarding the Modeller - why are we able to only have 32768 triangles in the main object if the total triangle limit for the mod is 65535? Is it due to some technical limitation or... ?
It's especially annoying when importing from .obj file. I would like to be able import an .obj with - let's say - 62k triangles and then split some of it into subobjects from within the LFS Editor. Currently you have to use 3rd party 3D software to split it into two .obj files (below 32768 triangles). I would prefer to do this in the LFS Modeller.
It would be even better if we were able to import .obj files bigger than 65535 triangles. So, let's say - I import a 3D model with 75k triangles into the LFS Editor and then I delete some stuff that I won't need in LFS - for example the engine bay - to reduce the polycount to less than 65535.
LFS Editor should not allow to "Export mod for UPLOAD" if it exceeds the 65535 limit.
Yeah, 16-bit unsigned integer, has a range 0-65535. I think he asks if there is any other technical limitation that LFS cannot handle 32-bit integers.
I'll try to answer. Well, most probably the reason is once you increase to 32-bit mesh models the frame rate will start to suffer greatly if you want to display all those polys with a full grid. So Scawen decided to make a compromise of good enough quality. But you have a very good point, in LFS editor one should be able to play with 32-bit models and at the time of export make it into 16-bit, similar to how people do with car skins when they make them in 4096x4096 and then export to 1024 as a final skin for upload.
Oh... I've read all of the changelogs in the first post, but didn't see anything about it so I've assumed this hasn't been addressed. What I didn't think about, is to read the changelogs for the test patches of the game itself as this issue is related to the game rather than the editor My bad! Although, now I've also read the changelogs for the D33 (game) Test Patch and didn't see a mention of that change. Anyway... I've installed the D33 Test Patch and the needle indeed is in the same position for both speed units. Thank you! I will make another attempt at "horizontal speedo" for my next mod, which happens to also use such speedo.
Thank you for the comprehensive answer, although I didn't understand much of it
All I want to know is - why can't we have 65535 triangles in the main object, if that's the triangle limit for the whole mod?
Just a clarification for the 32768 thing. Usually one only has to model 1 half of the car and the other half is just a mirrored copy. A full car model has to fit into a 16bit integer. I guess that Scawen can make an option in LFS editor to enable/disable a planar symmetry with 32k limit. When disabled a 65k limit for the whole car would be allowed. I'm not using the editor so I may be wrong as this feature might already be implemented.
I do recommend that mod creators should use the latest patch. I'm not like Microsoft. My updates contain many useful updates and more fixes than new bugs. Any new bugs are fixed extremely quickly, especially when there are more people testing.
I know it's not practical for everyone to get every update, but I'm sure it is best to keep up with the updates, which have been done with a lot of care and input from community members. Then there is no need to read such a long list that can leave your head spinning.
There are different reasons for limits on points and triangles.
Triangles refer to points using 16 bit integers. 15 bits for the point ID and one bit to specify whether the referred point is the original or mirrored version of that point. So no point can have an index above 32767 (the maximum number represented in 15 bits). So that's the point limit. Sure we could make all objects use 32 bit integers instead and be bigger, but then the pit out glitch would be worse. Related to CPU usage when creating the in-game model from the 'editor model' stored in the veh. So limits are a good thing, in the context of a game. In this case that sensible limit happens to be around that point where we would need to switch to larger integers, so as there is a natural 'hard limit' there is little incentive to change the format at this time. Better if artists work within boundaries. As it's a game efficiency is important.
For triangles, the same limit does not actually apply in the same way, but the number of triangles is in the same region as the number of points, so the same limit seems to make sense. It is intended that mirrored triangles should be used as most vehicles are mainly symmetrical. There is a limit on output triangles of 65536 and I think the modeller limit of 32768 "original" triangles is to prevent this number being easily exceeded by mirroring all the original triangles.
If the maximum number of original triangles was increased, then the artist would be able to exceed 65536 easily (by mirroring all) and the game would simply not add them to the output mesh. This doesn't seem clean. Although I see there is a case where number of modeller triangle could be increased without exceeding the output limits (but not mirroring them all) this doesn't seem a high priority. These are very high numbers anyway, and it seems better for people to work within the limits (that already cause a disruptive pit-out glitch on some computers).
Create a new subobject, position it near one of the wheels, set its object type to hub object. Then, when you exit to the vehicle editor, you should see it positioned at the wheel centre and it will move with the wheel.
There are two parts to making a dashboard. One part 'compulsory' and the other part optional.
The 'compulsory' part, edit the dashboard:
Vehicle editor
Textures tab
Select s_clock / s_clock_white / s_clock_formula
Click "EDIT" on the CLOCKS line
There are a lot of options
The optional part, create a dashboard back texture:
- backing texture appears *behind* needle, numbers, markings
- appears illuminated (self lit) like the default dashboards
- recommended texture size is 512 or 1024 for future-proofing
- load the texture in page mode in the modeller
- click the "fixed" button to mark it as "dash"
- there is a reload button in the dashboard editor
- alpha channel has no effect
There may be many tricks and tips but I guess from this point you will need to ask more specific questions.
Not sure if bug or not (probably not) but s_clock_formula dials are white from third person. Not game breaking but looks kinda weird since it should be black, at least on my mod. I've updated it to be fully lit and it's kinda more noticable now, before only indicator bulbs on side of lcd were white
@Scawen i wanna suggest something about hub objects, is there any way to remove it completely and move it to "LOAD WHL" setting. For example maybe you can make multiple LOAD WHL buttons (max 4, like configs) or you can just copy the layer selection chart of tri mode of edit model to edit spoke tab, so ppl can import or put different rims for different trims or setups of their cars, and maybe it can prevents the exceeding the polygon limit problems with this way.
well yes, why i should need to say this suggestion if i wasnt tried reducing something i'm working on a rare japanese classic rn but there is 3 different rims option of it real life, and car is around 54k even from now, all modelled by myself from blueprints (including interior).
and imo we should be able to import the png textures which contains "~" character as well. that can make things easier when trying to reduce megapixels imo.