The Drunken Lizard Pub

When I swapped my Cartography amulet for a Wis/Int one, I found that map details - specifically roads - got erased as I walked past. (They did reappear when I put the Cartography amulet back on and walked over yet again).

Is this supposed to happen? It seems a bit extreme: once you've made the map, surely it's stored?

It's an odd and annoying quirk of the way the mini-map functions. It actually constantly redraws according to your skill, so as your skill goes up, the map gets better. Unfortunately, it works in the opposite direction as well.

In a way, you shouldn't really think of it as a physical map of the area, though, since at high enough levels you start to see other interesting things on the map, like approaching enemies before they come into view on the regular screen.

That's normal behavior. If your cartography skill is lowered and you go over a place you've already been, the map will be redrawn with the lower skill level.

It's also described in the Player's Manual this way. It's correct behaviour.

Although it may be described in the manual, to call it "correct" behavior goes a bit far.

To me, its one of the most annoying aspects of the game (read that as a compliment ). But it has been discussed many times before, so I guess we're stuck with it.

I've been known to boost cartography using a hex editor so I can spend skill points elsewhere. Who says cheater's never prosper??

-->> Lhoric

obiwan wrote:Although it may be described in the manual, to call it "correct" behavior goes a bit far.

To me, its one of the most annoying aspects of the game (read that as a compliment ). But it has been discussed many times before, so I guess we're stuck with it.

Correct is a function of the developer's intent. Seems "correct" to me since it is "Working as Intended"™©

No, it was never intended like this. It's just not so easy to change, so the developer has accepted it as a feature.
This is another recent thread about the issue, with the title 'Cartography Annoyance': viewtopic.php?f=12&t=3198.

How is it not so easy to change? Wouldn't a single IF statement do the trick?

No - because nothing saves the cart level used previously. The difficulty is in storing that data without significantly increasing the memory requirements of the game (the incredible speed decrease of movement in heavily wooded maps is testament to the fact that RAM is not, in fact, totally free).
Although I think if he's actually storing the fully expanded PNG file in RAM already, he could cheat and use the alpha channel which is possibly currently taking up ram but all 0s (or 255s, depending) - though it's also possible that the PNG library for his language either doesn't support the alpha channel or has some logic where you can set it globally instead of per pixel. In which case were back to allocating another big chunk o'bytes.

(Actually, upon further research, you'd need to declare the PNG file as supporting alpha ahead of time and it would suddenly take up 30% more space, so this cheat idea of time is effectively useless).

Why the heck do you need to save the cartography level used previously? Given that the maps are static, all you need to do is the following:

Instead of:

code_that_adds_walls_to_map
code_that_adds_grass_to_map

Use:

IF current_cartography > whatever
{code_that_adds_walls_to_map}
IF current_cartography > whatever
{code_that_adds_grass_to_map}

etc., etc. That way the code that overwrites the map for that particular phyiscal feature is only called if your cartography is actually high enough to map that feature. It doesn't require modifying the code that does the mapping at all, nor changing how the data is stored at all.

Of course, we're both wildly guessing since neither of us has seen the code base, but:

It seems to me that if the code were organized as you say, BW would not have said "this is hard" and given up on fixing cartography - twice! (remember from the other thread that this was mentioned in Book I and he said he'd fix it in Book II). Certainly there are things to recommend your organization of the code, for example the simplicity of fixing cartography.

Unfortunately, I think the code is organized more like this (leaving out all the mess of finding the map areas you can see, mapping map coordinates to pixels, and actually modifying the underlying png file)

foreach ( pixel in visible_pixels ) { pick_color(cartography_skill) }

this code organization, as you can see, would be less than ideal for upgrading to fix cartography.

Naturally, I'll repeat that we're both guessing entirely how the mapping code works at all. If it is organized as you would do it, then, yes, fixing cartography would be easy.

---

On the other hand, while my resume (http://silverchat.com/~silver/silverHar ... Resume.txt) does not scream "game developer", I am cross-skilled in many languages, have done some minor hobby programming in BlitzMax, and my job duties have recently slackened enough that I would be willing to sign all the appropriate NDAs and fix this cartography issue for free, while promising not to spend more than 30% more RAM on the map than has been spent already

foreach ( pixel in visible_pixels ) { pick_color(cartography_skill) }

Then that's even easier -- you just stick a line in the pick_color function that returns the pre-existing color IF there is a pre-existing color and the cartography skill would be low enough to erase it.

Slarty wrote:foreach ( pixel in visible_pixels ) { pick_color(cartography_skill) }

Then that's even easier -- you just stick a line in the pick_color function that returns the pre-existing color IF there is a pre-existing color and the cartography skill would be low enough to erase it.

You're often not erasing colors - you're often picking colors for map features differently based on level - a door is brown at level 5 and gold at level ... something 8 or 9? anyway. road is green at some level and brown at another. water is green at some level and blue at another.
and at high levels of cartography, transitory features like NPCs and Loot Bags appear on the map, so it's not just replacing "if (erase)" with "if (erase or green (unless green is the right color))" because the color might be changing for the removal of some transitory feature. Maybe every object just has an array of 16 colors associated with it for its appearance at different cart levels, and treats "empty" the same as any other color. Certainly there are colors for both the ground and the contained objects for each square, and it also has to decide whether to reference just the ground, or the contained object differently at different levels (possibly by overlaying empty on top of ground-color - in which case emptying the square may be exactly the right thing to do in some cases).

In Any Case: we are both just guessing how the code is arranged. Consider for a moment that BW wrote the whole thing, from scratch, himself - so he's obviously neither lazy nor incompetent. Therefore a little trust when he says "it's hard" should be applied. (that's not zealotry, there is evidence he's not incompetent: or the game would be chock full of hundreds of bugs and this one wouldn't be noticed on the pile. There is evidence he's not just dodging working and that's the he wrote the game in the first place). Nor am I implying you're insulting him or calling him lazy or incompetent - I only bring it up to say "if an incompetent programmer tells you a problem is hard, they mean they don't understand it. If a lazy programmer tells you a problem is hard, they mean they just don't want to do it. If someone who is neither tells you a problem is hard, it's probably actually hard."

true enough. it's easy to be a critic.