MTL Conversion Bug with Mineways OBJs

[StandingPadAnimations]

It seems like if a user names their OBJ anything with spaces (like Beach Town.obj), Mineways will export an MTL where the name has underscores (like Beach_Town.mtl). This causes the MTL conversion function to fail since the first thing it does is read the MTL file in.

The MTL filepath is recieved by replacing the file extension of the OBJ filepath. Seems like we need to implement some check for underscores in MTL names as well

[TheDuckCow]

I got my analytics reporting working again. As suspected, this is the culprit of a large quantity of bugs, see this overall uptick corresponding to the v3.4.2 release:

And filtering just for v.3.4.2 (the above chart was overall), we get 700 reports. Apparently, 494 of them (70%) are coming from this issue (another 70 or 10% are coming from the fixed block spawning material issue).

Therefore, I will be seeking to release this update as quickly as possibly - today or tomorrow.

[TheDuckCow]

I realized we already merged this change @StandingPadAnimations but could we add one more precaution?

Could we actually skip overwriting the file unless we specifically know we have a pending modified a line? This way, we aren't unnecessarily modifying it for users who don't have the aces issue anyways (even if yes, it means having to reparse the entire MTL each time). Parsing the mtl should be generally speaking quite fast (at least not much slower than the type it takes to open the file to check for the MCprep header).

Essentially I'd imagine before the with open(mtl, 'w') as mtl_file: block something like this:

any_lines_changed = False
...
    if line.startswith("map_d "):
        lines[index] = "# " + line
        any_lines_changed = True

if not any_lines_changed:
    # Don't change file if nothing changed.
    return

[StandingPadAnimations]

Sure thing, I'll commit that on dev by the end of the day

[StandingPadAnimations]

Ight, finally pushed the requested changes (or rather a check for map_d at the start, it may be slightly inefficient, but it's a simple additional condition to the beginning if statement)

[TheDuckCow]

Ight, finally pushed the requested changes (or rather a check for map_d at the start, it may be slightly inefficient, but it's a simple additional condition to the beginning if statement)

I see the branch merged, but not that last part of exiting early if no map_d's found - maybe still local on your machine?

[StandingPadAnimations]

I pushed it directly on the dev branch
3e6c940