This was mentioned a while back, but was there any further thought on separating unlocks between the editor and LFS? People who use the modeller will be burning through twice as many unlocks now.
Be careful with the values in that thread, several - especially in the first post - are quite wrong. Some were corrected in text some posts later.
I have to agree that having the numbers auto-generated would be nice, however how useful they are does also depend on the angle of the specific body panels vs the map's projection. It would give a good guide to the roughly perpendicular ones though.
A value *per polygon* would be most accurate, but that's probably not practical
Just to add, (not that I've tested this) even if you're not using reflected triangles I think you should be able to copy the mapping and the cutout, change the new mapping to the new cutout, then move the new cutout position to immediately below the previous one on the skin page.
Not entirely sure how flipping the mapping for the sides works in the various mirrored/not mirrored situations, but you should at the very least be able to rotate the new mapping's heading (h) through 180 degrees.
Edit:
The tricky thing with the cutout/mapping combination is getting them the same aspect ratio to avoid stretching in the skin file. As far as I know, this *does* require fiddling with values and doing calculations. Nearly all the default LFS skins are are wrong aspect; most of them are different on the front/back vs the sides (though the top and sides are usually the same).
That sounds like a problem with Logitech's software, which is notoriously bad. I gave up using it for scripting years ago because they kept breaking things.
LFS script files & binding controllers to /press 3 etc in the CTRL+ ALT+ controller options pages still works fine in W54.
FWIW, if you want to bind whatever controllers (including several buttons/controllers for the same action) to the lights keys, you can use TC Lights https://tc-g.uk/TCLights
Since it would be automated, exporting one set per configuration would avoid having to make a decision. That would be needed for mods like the RC car, as each config is an entirely different shell.
The latter, basically this one: https://www.lfs.net/attachment/264151
People often use them overlaid over the skin using a blend mode to fake a shadow effect, hence the name. Can also be useful to see the contours more easily.
Looking good, just need some vector wireframes for ultimate precision
A suggestion that might be simpler than that - as it stands, this still requires mod creators to create and supply the skin templates themselves, which I'm sure won't happen in all cases.
Would it be possible to automatically generate and pack the skin templates in the mod export to be available to download as a zip on the mod page?
It tries to use the first instance (in the entire model) of the special "l_" name as the light. If you have more than one instance, it will ignore all the others so they don't illuminate.
This is easily done by accident when working with sub-objects, as the colours often get duplicated when importing/exporting/merging etc. I've also had it where there were some remnants in LOD2 that took ages to track down.
I guess this is why there are several special "l_" names for certain types of light (4 indicators, 4 brakes, 3 tail. There's only 1 of the other types).
If it's not to complicated to remove the restriction of 1 per name, that would make texturing more complex lights configurations a lot less hacky.
Can't think of a reason to use it on a dedi server - I think it would only be possible to do by typing into the console?
I suppose it could be used to allow two different insim apps to communicate, but there are other, probably better, ways to do that.
Guests would use /i for that anyway - /o only works on the local LFS
I asked a few days ago on the server whether it had been reported yet - I was told "yes, several times". Evidently not reported on the forums where it would actually be useful
Bug:
You can't place chalk objects (maybe others too) on the ground on the crown of the roads at X=0 or Y=0.
If you place one nearby and bump the X or Y position in a way that should take it to zero, LFS gives an error "Can't move : invalid position". See attached
Isn't that exactly what one of the blocks in LA1 already is (minus perimeter wall)? You can confine yourself to one of those without crossing a road and they're already 1km x 1km.