Open CounterPillow opened 10 years ago
I agree there is a lot to not like about textures.py. It's huge, hard to maintain, and full of magic (both the good kind and the bad kind). However, as you said the oil stuff is in the work, and will have a different way of handling textures. Thus I am not willing to put in any serious effort to textures.py right now.
On the subject of settingsDefinitions and tilesets, that has often been a topic of discussion in #overviewer as well, so I'm sure that will be improved in time.
What information do you have on the minecraft world format changing? Any docs from Mojang or naything like that?
From what I know, Minecraft Block IDs will "go" in that there will be dynamic allocation of block ids in the future.
https://twitter.com/Dinnerbone/status/383724382079954944 http://dinnerbone.com/media/uploads/2013-09/files/28_00-44-23_YfmAkomVI.txt
According to this tweet, it won't break for another half year though: https://twitter.com/Dinnerbone/status/383923320724660224
Reference of them eventually going to be dynamic: https://twitter.com/Dinnerbone/status/384084118344306688
Will be pretty great for mod support.
Overviewer's code contains a lot of magic arrays or redundant lists of things that are all over the place.
Example: stairs are defined in
textures.py
(obviously), then also initerate.c
foris_stairs
and then also inprimitives/lighting.c
(twice) for lighting.Then we also have the example of config file settings. Defined in
settingsDefinition.py
, and then inoverviewer.py
(what?!) we have an array that says whether a setting should be passed totileset.py
.Of course, we also have hardcoded block ids specified for biome tinting in the C code, and so on.
Here's what I suggest:
Since minecraft world format is about to change, we will probably need to rethink everything anyways, because block IDs won't work as they used to anymore, from what I've heard. Plus, OIL is in the works as well, which may or may not resolve some issues. But for those cases where it's not possible to change something for performance reasons (
is_stairs
, probably), document them properly so people don't have to look for them using grep, and preferably move them into one place.Opinions and other suggestions welcome, also examples for more of these magic definitions.