Reply to Re: New *WORKING* cross-platform editor
If you don't have an account, just leave the password field blank.
September 28th 2011, 06:25 AM
shevek
But, I don't get how it works internally. Does it still try to make a mix of existing hardness blocks to try to match the shape of the white area you set? Or is it pixel perfect hardness?
In hard.dat, there are 800 hardness tiles. Every tile in the tile screens has one of those assigned as default. Lots of the 800 are not the default for any tile. Some (especially the empty one) are the default for multiple tiles.
Tiles in game screens can either say "use default hardness", or they can say "use this one", which is any tile from the 800 options (except 0, because that means "use default").
In my editor, things work differently:
- Every tile screen is two images: one for the tiles, and one for the hardness.
- Every game screen either uses the default hardness for all tiles in it, or has an image containing the hardness for the entire screen.
When building a dmod, it will compute hardness for every tile in every tile screen, and for every tile in every screen which is not using default hardness. Any duplicates are detected. All unique hardness tiles are inserted into the list. If there are more than 800, it won't work, of course.
So yes, this is pixel perfect hardness. If you don't make too many hardness screens, everything works without a problem.
Oh, and there's a reason that the hardness has a name. If you use the same hardness name for two screens, they use the same image. If you are getting over the 800 limit, you can move some houses a few pixels and make the hardness of several screens identical.
I can see a benefit to using a different language, especially if it would support math in one line, nested conditionals, ...
That already works. However, I haven't checked if nested for loops work as well. I think they should...
I saw it has gold as a setting for sprites
Well, duh.
Everything that ends up in the dmod can be set with the editor. (Except for all the junk bytes that are not usable by the game anyway.) I didn't know this wasn't true for WDE+.
In hard.dat, there are 800 hardness tiles. Every tile in the tile screens has one of those assigned as default. Lots of the 800 are not the default for any tile. Some (especially the empty one) are the default for multiple tiles.
Tiles in game screens can either say "use default hardness", or they can say "use this one", which is any tile from the 800 options (except 0, because that means "use default").
In my editor, things work differently:
- Every tile screen is two images: one for the tiles, and one for the hardness.
- Every game screen either uses the default hardness for all tiles in it, or has an image containing the hardness for the entire screen.
When building a dmod, it will compute hardness for every tile in every tile screen, and for every tile in every screen which is not using default hardness. Any duplicates are detected. All unique hardness tiles are inserted into the list. If there are more than 800, it won't work, of course.
So yes, this is pixel perfect hardness. If you don't make too many hardness screens, everything works without a problem.
Oh, and there's a reason that the hardness has a name. If you use the same hardness name for two screens, they use the same image. If you are getting over the 800 limit, you can move some houses a few pixels and make the hardness of several screens identical.
I can see a benefit to using a different language, especially if it would support math in one line, nested conditionals, ...
That already works. However, I haven't checked if nested for loops work as well. I think they should...
I saw it has gold as a setting for sprites
Well, duh.
Everything that ends up in the dmod can be set with the editor. (Except for all the junk bytes that are not usable by the game anyway.) I didn't know this wasn't true for WDE+.
