Hello, The recent RC version introduced a new error dialogue (Coll and VisGroups can not be set at same time) in DEV mode. While it is very helpful for solving issues, it is however unfortunately causing more issues for some specific tracks. One of the affected track is Targa florio, it is designed by original author in a way so that large amount objects have Coll set true for hardcore experience, and also have VisGroups tag enabled for low spec PC. Now with this new error dialogue, it is absolutely impossible to even load the track in DEV mode because there are over 8000 objects that have both Coll & various types of VisGroups enabled (would require press Enter key for 8000 times). See pic below: Please consider to output all those kind errors directly into separated LOG files instead (this way it will also help to track down issues easier), because currently it is impossible to loading tracks like this. Thanks!
I think those warnings (visgroup vs colltarget) were always in the trace file. They seem to have moved it to a dialog box to try and stop people making the same mistakes and ignoring the trace file errors. I don't know if having a track combine those is ever really a good idea, but no doubt at the stage of that project you probably aren't keen on implementing invisible walls to replace the actual objects at lower detail levels, which is what really should be done. I absolutely agree on at least having the option to just put them in the trace file though - if nothing else, it's definitely easier to track them down that way, and if you accidentally end up with many errors you end up basically having to force close devmode.
Lazza got the analysis just right. HAT/Coll and VisGroups at the same time is wrong input (like loading a model without normals, for example) and should not load at all. But because it did in the past, it was opted to still load already released mods with it. In Moddev however it was chosen to make it as obvious as possible so that it gets fixed for the content. The reason this is important is quite simple: It fundamentally breaks track loading and sends you in a somewhat bugged state. This state depends on game settings and time you join a server, giving you different results for collision each time, while also having a significant impact on loading times (adding whole minutes to loading times for larger tracks). Also, high detail visual models should never be used for collision to begin with, so if there's any reason to disable an object for performance reasons, it probably shouldn't be used as collision anyway. A quick fix would be basically just either removing the visgroups or making them non-collidable. A proper, real fix would be actually disabling collision and adding additional invisible collision-only simplified shapes in the same places that react properly to collisions. Or a hybrid workaround of duplicating all those objects, one with visgroups and no collision and one with collision but always there. Although obviously then you'd have invisible collision so that's not optimal either. Generally speaking though, game settings can't and shouldn't affect collision, so you'll have to plan carefully how you deal with collidable objects. I don't think any option to skip this will be introduced since the whole reason it was made to be as annoying as it is was to make absolutely sure it gets fixed in content. Just as a hint, you can make objects "collidable" without actually making them collidable by making them movable and giving them mass. This could be used for smaller objects, such as the haybales on historic tracks.
Thank you, no doubt that all those are very good suggestions (fixing 72km collision issue is more about the amount time it requires than difficulties it involves). And I fully understand the reasons of having those errors messages (as I have already read DEV stated in road map months ago). Still, it would be nice to have an option to save a separated log and temporally disable/bypass the error. One good way I would think, is to add an option in the dialogue and ask whether modder wants to review further error (continue button for example) or skip error (a skip button) for this loading only. This way modder will always be notified about errors, but also have the option to temporally skip the errors and continue to do things they have planned at that moment of time.
