below u find screenshots of how it looks in editor and how it looks inside LFS after exporting for test
I've attached a file of whole mod which is exported for development
you can find the triangles that are having this issue in second subobject named " lights and others"
all lights are mirrored and they aren't appearing correctly as in editor.. i was mistaken for whole tris loss but its just the textures now.
I've tried making a flipped cutout and using it in opposite mapping but nothing did it.
Nice dashboard, thanks for the result image and testing!
Please can you remove your suggestions and instead put them on the appropriate thread in the suggestions forum?
It's really impossible for me to follow things and retain my sanity if random suggestions are all over the place and the test patch thread is spammed up with off topic.
This thread is for discussions about the current editor test patch. Off topic suggestions here will be ignored.
By the way, did you get any better results with the bus mirrored texture?
sorry i looked over and somehow i did not find that correct thread
I did a fresh installment of LFS and LFSE and patched to latest .. the issue was still there when i opened the file in editor but i tried to mirror both subobject and tris and it worked somehow.. all i can guess is its my editor acting up.
I just wondered, how does it look, if you view that veh in an older copy of LFS (from before the dashboard updates) ? You should be able to see quite simply by running an older exe.
It is happening if subobject's angle is given from subob section, from the rotation and position bar. But if you rotate it from the point section with selecting every point and rotating with same angle, there isn't any problem when merging. Tried and worked on my Dorito Astro 1000
The mappings *should* be retained when merging a subobject (since at least D23) but I see that there are cases when it goes wrong. For instance I made this LX4 test with a dash mapping in a rotated subobject. When I merge the subobject, the rotated dash mapping is preserved correctly. But I do notice a problem with mapping "C1_hdLB" which you can see as a wrong mapping on part of the painted outer of the subobject after the merge.
I don't yet know why it went wrong but I've made a note to look.
A new patch D38 fixes some reported issues and includes a new feature to copy wireframe or plain mappings for any texture, previously only available for skins.
1) I've fixed the corrupted number plate issue that was even simpler than expected to reproduce.
2) I think you should no longer need to change the texture page to a skin as you can now copy mappings for any texture.
The combination of rotations when merging subobjects is now fixed. Before this fix, it would work reliably if only the heading of the subobject was changed (not pitch or roll).
Changes in D38:
Modeller:
Export plain / shaded / wireframe for any texture (not only skins)
FIX: Merge subobjects, mappings wrong if subobject had pitch / roll
FIX: Map mode showed texture file for skin cutouts as [no texture]
Misc:
FIX: Alpha number plate texture went wrong if more than one on page
FIX: Modeller - reload textures - vehicle editor: 2 plates on page
One issue i think is that hub objects are using body colors, so it's a bit weird in a way if let's say a bus front wheel and rear wheel colors will be separate.
I'm not sure how serious this problem is (or if I'm seeing the full problem). I think you are talking about the user customisable colours, and that any the mod creator adds for the new hub objects will end up on the left side of the screen (with the body colours) instead of the right side, with the other wheel colours?
But how much of a problem is this? At first thought it seems like it would be hard to change how this works, but of course I will look into it if it is bad, or could cause problems in the future.
I think this cannot be done by any official method, though if there are no rotation connections (on multiple spoke wheels, between one spoke and the next) then I think it might work if you rename the spk to sre and hex edit the header (first 6 bytes). But I haven't tested that.
The spk and sre files are kept separate, because there is an important difference. If I remember correctly, ordinary models (sre) have the "mirrored points" which triangles can connect to but in the spk files these are reused as "rotated points" so you can create a whole wheel by working on one slice of it.
These methods are not compatible and it's just slightly complicated to allow saving and loading between the two formats. I guess there could be "save spoke as sre" which could be enabled if there are no triangles connected to rotated points, and there could be "save object as spk" if there are no triangles connected to mirrored points. Is it worth adding these functions? Can they be added without wasting screen space?
So basically it takes one color slot of 4 possible for the body. It's not a huge problem though, i just thought it's kinda confusing a bit and it limits coloring options.
It's an issue for me because you now have to tie in 1/4 body customization options to the wheel. I will be using this new hub feature to allow my mods to have separately paintable front and rear wheels, and to be able to run 2 different wheel designs and spoke face offsets. Great for Drift and Drag cars.
