Closed Septaris closed 7 years ago
I agree it is ugly. The thought behind StarMade independent block ids was to prevent a single format change rendering SMBEdit useless. I have been considering an optional argument to read the configuration file and was so far to lazy to write a parser. I have a version 0.1.1 done, but I will consider adding your module BlockConfig for 0.1.2 after I had a look at it.
If it works out and I can not longer bear looking at the hard coded mess I probably make it mandatory.
You've already done a lot of work to parse Starmade blueprint^^ I hope your library will become the python reference api to read starmade BP.
The BlockConfig parser is written in python 3 style but the only difference with python 2 is the metaclass definition (easily editable)
Thanks, There are still quite a few secrets I have not figured out yet. The parsing of a block orientation is still guesswork for the most part. And while SMBEdit is finally able to parse the data in a meta file, it is s still anyones guess what the data there means, mostly.
I see the Starmade config file was made part of the repository. Do you have any experience with copyright law? I do not have any, that is one reason I choose against that. But if someone trustworthy could confirm that it would be no issue, it might be an option!
I have added and modified the BlockConfig module a little: 60a035284a6c899d68f1122db6e658f24f1fa38c It still needs a bit of work before it can replace the hard coded stuff.
Nice. Just be carefull with the metaclass, it's not a simple inheritance. The python 2 equivalent of :
# Python 3
class BlockConfig(object, metaclass=MetaBlockConfig):
pass
is
# Python 3
class BlockConfig(object):
__metaclass__ = MetaBlockConfig
pass
For a code compatible with both python 2 and 3 you have to use the future library (pip install future) and write:
# Both python 2 and 3
from future.utils import with_metaclass
class BlockConfig(with_metaclass(MetaBlockConfig, object)):
pass
I only tried to keep functionality, but kept the class name. I will rename it to prevent confusion. Would be best to avoid special libraries to keep it simple for people.
Unfortunately the future library is the only way to have python 2/3 compatibility. In any case, it is possible to create an .exe (and equivalent for linux / mac) using pyinstaller for example. And in this way, users do not have to worry about dependencies.
To have it work identical in both, yes. But most common things have simple workarounds or will get the identical result in any case. The 'metaclass' is the one thing I would like to use but can not think of a workaround. Is there something else that would make difficulties, what specific makes you think it is absolutely required?
There is a guide here that shows how to develop code that works on both python 2 and python 3 without six/future
. But it's very restrictive (no metaclass, verbose syntax, different behavior for python 2 and 3 which can lead to bugs).
I think the fact that the code requires pip
will not prevent python users to use SMBEdit. However, on Windows Python is not available by default. That's why I have integrated the possibility of generating an executable in the p2p3 branch. Thanks to this, Windows users can use SmBEdit without python.
Good list. It would certainly be risky, without unit tests. Originally I had no plans to make it public, I would have written it in java otherwise.
For the moment blocks config data are hard coded in blueprintutils.py. I suggest to use the config files (BlockConfig.xml and BlockTypes.properties) to fetch directly starmade data. This will allow to be always up to date with the latest starmade IDs/version while removing a lot of tedious code. (see the pull request)