Technically I suppose this is not a Tiled “bug”, but it sure is causing a bug in other software!
I am using PyTMX to read Tiled .tmx files into a Python program. I am seeing a crash in my Python program recently, like this one:
PyTMX is unable to interpret a value in the .tmx, which appears to be a “1.0.0” whereas it is expecting a valid float.
So I looked at the .tmx, and here is what I see:
Prior to the latest update, Tiled always produced a Map version value that was a valid float (stored in a string, but still a number here). In fact, looking back through my older saved .tmx files, that value was always “1.0”. The change to “1.0.0”, is causing interpretation issues downstream from Tiled, as that string gets converted to a float and then pukes.
Can this be changed so that a valid number is used here? Or other ideas to resolve? I just installed the most recent PyTMX and did not resolve it. Yes, maybe I can get those guys to change their parser code, but since the value written into Tiled really isn’t a valid number in the first place, the most logical place to fix this is here IMHO.
Ah, OK. I did not see that post but admittedly should have looked harder.
I like the idea of separating the “versions” and keeping each of them strings of valid floats. It’s easier at this stage than trying to track down the parser issues that result.
Thanks for the fast attention to this!
Best,
John
Bjorn -
Is there an estimated release date for 1.0.1 with the “map version” resolution? I want to share with our team, so they can update. Until then, map-making has stopped for us, since they won’t run without crashing.
BTW: I just submitted an “Issue” on PyTMX’s GitHub site to flag the problem and see if I can get them to update the parser to return a string for this param, rather than assuming it is a float. That might provide more flexibility in the future: https://github.com/bitcraft/PyTMX/issues/83
I was hoping today, but I need to figure out why AppVeyor isn’t building installers for the development snapshots first. In the meantime, the needed change to PyTmx appears to be trivial and could probably just be applied to your local copy (though not sure how Python package management responds to that).
Sounds good, thanks.
And yes, I agree the PyTMX change is probably very trivial. But I’d prefer it happen in the repository, so that future updates and installs don’t run into the same issue (we have several coders on the team, all with their own installs).
BTW: I saw your github comment. I did update PyTMX yesterday and still crashed. Let me see if there’s a problem with update.
(later)
Ah, I see what you mean by the “bump the version”. Presumably pip install --upgrade is looking for a version number change, which did not happen. So it is failing to pull in new code.
