BUFFY & HOF Mod Releases

[Sun Tzu Wu]

I recently generated a bunch of Large Great_Plains Deity level Maps for Challenge II Game 5. I noticed that the Forest count MapFinder provided was often much less than the number of Forests that could be manually counted in the JPG image.

After a little analysis, I was able to determine that all Desert Tiles with Forests were being ignored. The Forest count was short by exactly the number of Desert Forest Tiles visible in the JPG image. The Desert count was also short by exactly the number of Desert Forest Tiles visible in the JPG image.

Sun Tzu Wu

 

[Denniz]

I recently generated a bunch of Large Great_Plains Deity level Maps for Challenge II Game 5. I noticed that the Forest count MapFinder provided was often much less than the number of Forests that could be manually counted in the JPG image.

After a little analysis, I was able to determine that all Desert Tiles with Forests were being ignored. The Forest count was short by exactly the number of Desert Forest Tiles visible in the JPG image. The Desert count was also short by exactly the number of Desert Forest Tiles visible in the JPG image.

Sun Tzu Wu

Desert Forests? Do you mean Plains Forest? Desert tiles aren't supposed to have forests, only floodplains, oasis or nothing.

Could you send an example MapFinder save file along with its text and jpg files?

 

[Sun Tzu Wu]

Desert Forests? Do you mean Plains Forest? Desert tiles aren't supposed to have forests, only floodplains, oasis or nothing.

Why can't Deserts have Forests? The Great_plains BtS Map script generates a lot of them; also Forests on Gems, Gold, Silver, Sheep, Dye, and maybe others with or without Desert.

Could you send an example MapFinder save file along with its text and jpg files?

Yes, I've included a sample from MapFinder where it says there is one Forest and two Deserts, but if one counts them in the JPG image, one can see six Forests and seven Deserts. The five Desert Forest Tiles (four Desert Hills and one flat Desert) are completely ignored.

Sun Tzu Wu

 

[Denniz]

Why can't Deserts have Forests? The Great_plains BtS Map script generates a lot of them; also Forests on Gems, Gold, Silver, Sheep, Dye, and maybe others with or without Desert.

I didn't realize they had changed the valid combinations. When I was creating mapfinder those weren't valid combinations of plot type, feature and bonus. It is not something that can be fixed just with the data files. It will require a change to the code to recognize additional base combinations. A little to-do for the next BUFFY release.

Were there other changes beside those listed? What about other mapscripts?

 

[Sun Tzu Wu]

I didn't realize they had changed the valid combinations. When I was creating mapfinder those weren't valid combinations of plot type, feature and bonus. It is not something that can be fixed just with the data files. It will require a change to the code to recognize additional base combinations. A little to-do for the next BUFFY release.

Given that Desert Forest ("no bonus", Dye, Gems, Gold, Silver, Sheep, etc.) are a valid combinations of plot type, feature and bonus that implies (suggests) that there may not be any combinations that are invalid. It might be best to not assume any combination is invalid, regardless of how nonsensical the combination seems, because some map script is bound to create such an "invalid" combination and BUFFY may have to be modified yet again.

Were there other changes beside those listed? What about other mapscripts?

Sorry, I wasn't looking for "bugs" in MapFinder, so I'm not aware of issues with other map scripts or other plot type, feature and bonus combinations aside from those I already mentioned above.

Sun Tzu Wu

 

[EmperorFool]

I looked to see if this was something I could fix, but alas it is not. MapFinder defines a bunch of numeric codes based on the aspects of the terrain: plot type (water/land/hills/peak), terrain type (grass, desert, plains, etc), and feature type (forest, oasis, etc).

TYPES_BY_CODE = {  # BasicPlot_TypesToCode
	401 : ('water', TERRAIN_OCEAN, NO_FEATURE),
	402 : ('water', TERRAIN_COAST, FEATURE_ICE),
	403 : ('land', TERRAIN_DESERT, NO_FEATURE),
	404 : ('hills', TERRAIN_DESERT, NO_FEATURE),
	405 : ('land', TERRAIN_DESERT, FEATURE_FLOOD_PLAINS),
	406 : ('land', TERRAIN_GRASS, NO_FEATURE),
	407 : ('land', TERRAIN_GRASS, FEATURE_FOREST),
	408 : ('hills', TERRAIN_GRASS, NO_FEATURE),
	409 : ('hills', TERRAIN_GRASS, FEATURE_FOREST),
	410 : ('hills', TERRAIN_GRASS, FEATURE_JUNGLE),
	411 : ('land', TERRAIN_GRASS, FEATURE_JUNGLE),
	412 : ('land', TERRAIN_DESERT, FEATURE_OASIS),
	413 : ('water', TERRAIN_OCEAN, FEATURE_ICE),
	414 : ('peak', TERRAIN_PEAK, NO_FEATURE),
	415 : ('land', TERRAIN_PLAINS, NO_FEATURE),
	416 : ('land', TERRAIN_PLAINS, FEATURE_FOREST),
	417 : ('hills', TERRAIN_PLAINS, NO_FEATURE),
	418 : ('hills', TERRAIN_PLAINS, FEATURE_FOREST),
	419 : ('water', TERRAIN_COAST, NO_FEATURE),
	420 : ('land', TERRAIN_SNOW, NO_FEATURE),
	421 : ('land', TERRAIN_SNOW, FEATURE_FOREST),
	422 : ('hills', TERRAIN_SNOW, NO_FEATURE),
	423 : ('hills', TERRAIN_SNOW, FEATURE_FOREST),
	424 : ('land', TERRAIN_TUNDRA, NO_FEATURE),
	425 : ('land', TERRAIN_TUNDRA, FEATURE_FOREST),
	426 : ('hills', TERRAIN_TUNDRA, NO_FEATURE),
	427 : ('hills', TERRAIN_TUNDRA, FEATURE_FOREST),
	428 : ('water', TERRAIN_COAST, FEATURE_LAKE),
}

As you can see not every combination is given a code. I'm stuck because these same codes are built into the MapFinder application (EXE) for which I don't have the source code. I can only fix one side of it.

 

[ParadigmShifter]

Tut tut Denniz (or whoever wrote the original mapfinder exe).

First rule of coding: No magic numbers.

Separate interface from implementation.

If there are 3 data fields (terrain base type, terrain specific type, and terrain feature), leave them as 3 different fields.

If you need to optimise it make a simple hash which combines the three (e.g. as bit groups), but make the hash function public and don't make the code dependent upon the hash used. Both sides of the program just need to know the hash function exists and the interface for it.

Don't work around a bad design, fix the design.

 

[Denniz]

I looked to see if this was something I could fix, but alas it is not. MapFinder defines a bunch of numeric codes based on the aspects of the terrain: plot type (water/land/hills/peak), terrain type (grass, desert, plains, etc), and feature type (forest, oasis, etc).

TYPES_BY_CODE = {  # BasicPlot_TypesToCode
	401 : ('water', TERRAIN_OCEAN, NO_FEATURE),
	402 : ('water', TERRAIN_COAST, FEATURE_ICE),
	403 : ('land', TERRAIN_DESERT, NO_FEATURE),
	404 : ('hills', TERRAIN_DESERT, NO_FEATURE),
	405 : ('land', TERRAIN_DESERT, FEATURE_FLOOD_PLAINS),
	406 : ('land', TERRAIN_GRASS, NO_FEATURE),
	407 : ('land', TERRAIN_GRASS, FEATURE_FOREST),
	408 : ('hills', TERRAIN_GRASS, NO_FEATURE),
	409 : ('hills', TERRAIN_GRASS, FEATURE_FOREST),
	410 : ('hills', TERRAIN_GRASS, FEATURE_JUNGLE),
	411 : ('land', TERRAIN_GRASS, FEATURE_JUNGLE),
	412 : ('land', TERRAIN_DESERT, FEATURE_OASIS),
	413 : ('water', TERRAIN_OCEAN, FEATURE_ICE),
	414 : ('peak', TERRAIN_PEAK, NO_FEATURE),
	415 : ('land', TERRAIN_PLAINS, NO_FEATURE),
	416 : ('land', TERRAIN_PLAINS, FEATURE_FOREST),
	417 : ('hills', TERRAIN_PLAINS, NO_FEATURE),
	418 : ('hills', TERRAIN_PLAINS, FEATURE_FOREST),
	419 : ('water', TERRAIN_COAST, NO_FEATURE),
	420 : ('land', TERRAIN_SNOW, NO_FEATURE),
	421 : ('land', TERRAIN_SNOW, FEATURE_FOREST),
	422 : ('hills', TERRAIN_SNOW, NO_FEATURE),
	423 : ('hills', TERRAIN_SNOW, FEATURE_FOREST),
	424 : ('land', TERRAIN_TUNDRA, NO_FEATURE),
	425 : ('land', TERRAIN_TUNDRA, FEATURE_FOREST),
	426 : ('hills', TERRAIN_TUNDRA, NO_FEATURE),
	427 : ('hills', TERRAIN_TUNDRA, FEATURE_FOREST),
	428 : ('water', TERRAIN_COAST, FEATURE_LAKE),
}

As you can see not every combination is given a code. I'm stuck because these same codes are built into the MapFinder application (EXE) for which I don't have the source code. I can only fix one side of it.

Except for the above table all the values are soft-coded in the data files. The numbers are arbitrary. The new combinations would just be 429, 430, ... The hardest part will be coming up with icons for the new plot combos. Of course, all the groups will have to be checked/updated as well. (i.e. Forest, Desert, Commerce, etc.) The VB program only needs the updated data files and icons. I have spreadsheets I used originally. I will put together an update.

Tut tut Denniz (or whoever wrote the original mapfinder exe).

First rule of coding: No magic numbers.

Separate interface from implementation.

If there are 3 data fields (terrain base type, terrain specific type, and terrain feature), leave them as 3 different fields.

If you need to optimise it make a simple hash which combines the three (e.g. as bit groups), but make the hash function public and don't make the code dependent upon the hash used. Both sides of the program just need to know the hash function exists and the interface for it.

Don't work around a bad design, fix the design.

Theory vs. practice. The goal wasn't to translate the combinations but to define the valid combinations. Not many water-plains-forests out there.

 

[ParadigmShifter]

Good theory makes for good implementation.

How good was the assumption you made about valid combinations? Answer: not very.

You should be immediately be suspicious of any table/dictionary where arbitrary numbers are assigned to things.

Why do you need to know which combinations are invalid? Assume all are valid or list exceptions or valid combinations in a public data file (text say) rather than hidden within the code.

Map finder shouldn't need to know rules about map generation at all. It just needs to log what it sees. The UI side needs to know which combinations are invalid but this should be separate from the implementation (and should be data - not code).

I'm available for design consultancy for a large fee of course

 

[EmperorFool]

Sure, and every class should have an interface. And all strings should be translated. And each subsystem should be decoupled from the other subsystems. And you might get a new feature every year. Or you could code up the correct method and we'd be happy to incorporate it as long as you've documented every method and provide unit tests with 100% code coverage.

It is not something that can be fixed just with the data files. It will require a change to the code to recognize additional base combinations.

Except for the above table all the values are soft-coded in the data files.

Does you mean that the only code that needs changing is in BUFFY? That would be awesome and easy to fix. Plus there are quite a few new features that I'm sure the players would enjoy. Let me know if I can help somehow.

 

[ParadigmShifter]

You don't need all that to write good quality software.

It's just basic stuff, never hard-code an assumption, never use a magic number.

Make your program data based rather than code based.

 

[Denniz]

Does you mean that the only code that needs changing is in BUFFY? That would be awesome and easy to fix. Plus there are quite a few new features that I'm sure the players would enjoy. Let me know if I can help somehow.

Should be. All the codes and groups are in the data files. Including a place for the icon for each valid plot combo. The original plan was to load that plot combo xref along with the other data but I had trouble with getting the enumerations to work from a file. I am not sure if it was related to the problem you fixed or something else. I imagine you could probably get it to work from a file with your better understanding of python.

I pretty much subscribe to theory that ParadigmShifter is peddling. I am just not so rigid about it when circumstances get in the way. Especially when I am working for free.

 

[EmperorFool]

Same here, but I also subscribe to the tenant of getting working code going quickly. I guess I was rubbed the wrong way by PS's opening ("Tut tut Denniz") and chiding wording, but maybe I just read into it. No worries.

Glad this can be worked out in the data files. I can definitely have Python use the strings (TERRAIN_GRASS) to dynamically look up the info object IDs. I'll take a look at those files soon.

 

[ParadigmShifter]

I guess I should have added this



But really it's basic stuff all coders should know.

You get more done in the long run if you follow decent coding practices because your code is easier to maintain in the long run.

 

[EmperorFool]

What I'm saying is that even though I know all this, and it sounds like Denniz does too, there are times when you don't follow it 100%. Even when I'm coding at my job I always have to balance "doing it by the book" with "this must be done by Tuesday."

 

[ParadigmShifter]

Well, never mind anyway, I meant it as a joke (the tut tut bit), and as some general advice (the coding bit - not specifically aimed at Denniz).

I know you have to compromise sometimes to get features in in a work environment.

It makes sense on projects such as this (intermittent development, long break in between fixes/releases) to plan ahead, and make the code as flexible as possible if you can.

Once you start using programming band-aids to fix things you end up with the famed "the only reason the software is stable is because all the bugs are holding hands" problem

Anyway, it was meant as a light hearted comment with some tips for any other coders reading. We've all basically said what I suggested is good programming practice anyway, so we know what we should be doing. I've seen a hell of a lot of dodgy code in my time though

I don't even use mapfinder

Anyway, that's why my user name is ParadigmShifter, because when I learnt about good programming practices and Object Oriented Design, I became a much better coder. Even though I code in C most of the time I still try and follow good programming practices.

If you want to critique my coding, by all means do so! In my spare time I'm doing a remake of Manic Miner on the Spectrum (computer from Sinclair released in 1982, was known as a Timex in the US). Not worked on it for a while though! Have a look though!

You can get an emulator here: http://www.zophar.net/sinclair/zx-spin.html

Here's the original classic version of Manic Miner from 1983: http://www.worldofspectrum.org/infoseekid.cgi?id=0003012

Here's my work in progress remake: http://www.mediafire.com/?0g5zqmntwyt

 

[Denniz]

Well, never mind anyway, I meant it as a joke (the tut tut bit), and as some general advice (the coding bit - not specifically aimed at Denniz).]

While I know you were teasing, but there was a little bit of to it as well. It is easy for folks to misunderstand posted comments.

I feel like there are a lot of details you don't/can't know about MapFinder. Especially, if you haven't used it. The general theme is good but without a better idea of the requirements and design some of your remarks were a little off target. Criticism, constructive or otherwise, can be tough to take under the circumstances.

We should just let it go. No harm, no foul.

 

[ParadigmShifter]

Hey, chill!

I really appreciate you and Emperor Fool's civ coding expertise. I know I couldn't be arsed to do it myself.

Keep up the good work.

 

[sanabas]

Theory vs. practice. The goal wasn't to translate the combinations but to define the valid combinations. Not many water-plains-forests out there.

This is the difference between proper maths geeks and programmer types.

 

[ParadigmShifter]

I'm a programmer with a degree in maths though

Good theory leads to good practice.