Editor crashes when clicking Texture tab (Vehicle Editor).
This happens only when a specific mesh config is selected. Car can be still exported (test) and driven in-game.
Editor sometimes crashes after starting the app, loading the car & clicking the tab, with any config.
After adding some tris with new alpha type texture page & cutout, editor always crashes when clicking Vehicle's Texture tab.
Exporting and selecting the car in-game would make LFS-game crashes as well.
Is there a simple step-by-step way I could reproduce this? Maybe starting from an LFS vehicle, or a test vehicle you could provide?
Based on your description, I added a new texture page, cutout, mapping and triangle, exited back to vehicle editor but didn't get a crash with the Textures tab open.
But if I can reproduce the crash then I can fix it, that's for sure.
I've had a look into this, found a possible reason for the crash and recreated a crash that matches your description.
It looks as if the code will fail (and crash, unpredictably) if there are more than 64 different materials in the model (when the subobjects are combined with the main model, which LFS does automatically).
I'll need to decide how to allow more materials, limit the number of materials, or both, as it is of course not acceptable for the program to crash.
Although I will do that, I must also say that I feel it's an excessive number of materials. Eric's most extremely detailed vehicle, the RB4, has reached 50 materials. Although I shouldn't be surprised that someone else's model exceeds 64 materials, as a programmer I feel this is too much for in game use and somehow you should reduce the number of materials. Maybe you can achieve the same results by either reducing the number of textures (e.g. by using cutouts on fewer, combined, texture pages) or reducing the number of different material settings in the 'cutout' mode?
I can't give any specific suggestions without seeing the model, but I have made a note to consider a fix/limit/warning/etc. Please let me know if the explanation makes sense (if I've described it properly and if you model really does have so many materials).
1) Vehicle editor will not crash (in Textures tab or when creating car from model)
2) There is a message "Too many materials"
3) It will not export for testing or upload if there are too many materials
This must be the best way, as LFS itself will crash if there are too many materials. I believe there should be no need for so many materials, if you can share texture pages, etc.
Yeah, that gave me a hint. And model had something like 5 different glass texture pages and few other small ones with different material settings (fancy vshine, overlay, etc) so those really blew material count up.
That's a capture from 7D14. Switching to the problematic config would indeed make the editor crashes.
Right, I haven't actually tried the newer test patch as I managed to merge some textures and make progress (and it's very close to finish, kind of, maybe). So, no really need to panic now.
Much thanks
And sorry for not posting quite a while (yeah, seems like my head keeps crashing as hard as the editor did).
LFS Crashes to Desktop without any error message
It happens when joining a packed server (like 40 players), after clicking join host it loads everything up until screen changes and u get the connected message, but screen stuck on the blue background for like 10 seconds then it crashes.
Runing latest test patch D21.
Downgrading to D20 actually fixed it.
It seems unlikely that reverting to D20 would really fix it, as D21 has so few changes. Maybe it was a coincidence, that whatever caused the crash, disappeared at the same time you tried D20. How many times did you try with D21? This is the first time we have heard such a report, so I won't attach much importance to it yet. But if you can provide a crash address, I'll investigate.
sure, here u may find something.
the crash happens very often..i had this issue for a week .. i try multiple times, 9 out of 10 times it crashes.
Log Name: Application
Source: Windows Error Reporting
Date: 08/05/2023 06:03:37 م
Event ID: 1001
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: SuperMegaRetard
Description:
المستودع الذي يحتوي على أخطاء 1604433972694237219، النوع 1
اسم الحدث: APPCRASH
الاستجابة: غير متوفر
معرف ملف الخزانة: 0
قد تكون هذه الملفات متوفرة هنا:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_LFS.exe_4e87bbc6c8b1b21060e6a2881f425c30e07c186_d10da236_2f48d062-af40-4b13-8e02-2a94df6a3bfd
Thanks for that. The offset seems to be inside LFS and it is reading a block of memory from a file.
From the information available, it's not possible to know which code was calling that function at the time.
As no-one else has reported this bug, I am wondering if it could be a corrupted mod file on your hard drive. Corrupted files are rare but it can happen. There is one way to test this. I don't know how much you like this idea but if you would rename your mods folder to something else (or delete it) then you will download mods fresh again.
That doesn't explain why D21 crashed and D20 didn't. According to this theory, any available version would crash if someone on the server was using the mod that is corrupted on your hard drive.
If it's OK with you, I'd be grateful if you would try this test because if the problem doesn't come up again that could mean it really was a corrupted file issue, and not something I should look into right now.
Yesterday i had this issue for the first time in D20.. It happened multiple times after..
I was on TC City Driving with a full server..
So yes i guess the version doesn't matter.. I guess it was a coincidence so far that it didn't crash on D2 earlier.
I will try to remove mods temporarily and join server at it's peak then I'll give further information
*update : crash didn't happen recently, might have been a faulty mod that got updated*
Crashed when trying to enter the modeller from the "new vehicle" screen:
- Open Vehicle Editor
- Click NEW
- Select a vehicle layout
- Click "linear" next to "suspension layout"
- When the dialog appears, click "Edit" at the bottom right - LFS editor seems to get to an invalid state
- Press Esc and then keep pressing E until it crashes
Sorry I dont want to seem tone deaf and insult the devs.
Scawen, the way I deal with crash reporting is:
AppMain();//Put everything inside here WinMain(){ int l_RetVal = 0; try{ l_RetVal = AppMain(); }catch(std::exception& e){ SomeExceptionHandlingFunction(e); } return l_RetVal; }
Or a newer approach I addopted is to have a companion program. In thins case I would call it "LFS Crash Handler.exe" and it would report crashes. The second approach is a bit more flexible than the first.
[Edit]
I might have a stack trace lib I wrote a while ago somwhere. Since LFS is compiled as x86 it will work. Havent implemented a x64 version yet.
I could donate it if you need it.
Thanks for the report. This is fixed in D29 which I'll upload in a minute.
Thank you and don't worry, that is not insulting. I don't pretend to know everything.
I should have a look at a crash handler, though I don't want to spend much time on it now, a good one could save time in the future.
At least to write out exception code, crash address and the module might be nice so people don't have to look in Windows logs. A call stack would be great information too and could solve more cases, especially if the crash is in a commonly used function or in a non-LFS module (called by some function in LFS).
I seem to remember looking at this a bit in the past and it was apparently not easy to obtain a call stack for some reason, or maybe it required a lot of knowledge. Well, I guess that's why you made your own library for it. Anyway, I will read up a little can contact you for more information if I want to do something. Though my priority is to quickly release the new version and get back to the tyre physics.
Thanks for the report. I believe I have found a cause for this. I think this crash could happen sometimes if you redo or undo operations done on a subobject, in mapping, cutout or page mode.
The fix I have done, is to correctly assign the selected subobject before re-selecting the mapping, cutout or page that was stored in the undo node.
The crash was found by newbie1234.
To reproduce:
Multiplayer -> Display list of hosts
Set all of the toggles to no
Go back (doesn't matter if using escape or back button)
Go into list of hosts again
Toggle any of the toggles
Crash
EDIT: Seems like an old bug, booted up my 0.6R install, it also does crash
EDIT 2: Can't seem to crash 0.7B2 for some reason
It has been reported on the TC one server, that it crashes upon joining, I've narrowed it down to the version being used, 0.7D crashes, newer patches like 0.7D33 don't. I'd check more patches, but many have online broken with wrong version being displayed, here is the crash info (sadly in Latvian):
(I also posted this in a different post, because I forgot that this thread exists )
Edit:
Video of it:
EDIT 2: Seems like deleting the mod folder fixes the issue, but putting the newly downloaded mods in the old folder doesn't, weird, must be an older version of a mod screwing smth up?
EDIT again, seems like what i just said isnt true, crashes anyways
Thanks for the report. That crash isn't in the LFS.exe module so I can't narrow it down to the region of code that caused it. There are some undocumented crash fixes in the test patches, related to mods that have not yet loaded, so I hope maybe one of those fixes is the reason why the test patches aren't crashing.
Thanks. Can you think of any more info, were there other people there, were you in your own vehicle, what sort of things were on screen? Did anyone else get a crash at the time? Were you using any special draw modes?
This code is something to do with drawing an alpha part of a car, apparently referencing a bad pointer, but the question is why did that happen? I'm looking into it but any more info could possibly help.
I believe I found the cause of that crash and fixed it for 0.7E.
Thank you very much for the crash report, the crash address was extremely helpful.
If a remote player with alpha subobjects lagged, the subobjects could still be visible which obviously looked bad and was easily reproduced (without the crash). But the theory is this was related to the crash. If a player you had seen, had a mesh regeneration at some time when off your screen, and next time you saw them they were lagging, then your computer would attempt to draw their old subobjects that no longer exist, causing a crash. Well that's the theory.
