[messages] [Module Design] Problem: Numbered Grids revert to default values

Rommel14 pfell.688 at gmail.com
Wed Jul 9 17:28:54 CEST 2014


Hello and thanks for the reply.

Yes, I have a Rectangular Grid inside a Zone, as some pieces must be
sent to areas inside the Zone but outside the grid, subsequently
reporting their status as such.  While I don't absolutely have to list
the vertical axis first with a letter and horizontal second with a
descending number, it makes Property / Marker assignment and Prototype
construction easier and more intuitive to remember.  

As for your explanation, let me see if I have this correct:

1) If I have a Grid inside a Zone, and that Zone is in the middle of the
Map, then setting up the grid to start at L-00 is a losing proposition
from the beginning, especially if you want the vertical axis first and
descending numbers, as the interface freaks out in this case.

2) Because all grid numbering on the Map is calculated from the upper
left-hand corner of the Map, there is no way to know what
letters/numbers you will really see in the aforementioned Grid/Zone
without going into the visual editor, because what you enter into the
grid numbering menu is not what you will get.

3) The only way to create custom numbering in a zone-embedded grid is to
repeatedly go back and forth between the grid numbering menu and the
visual editor, inputing "offset" combinations of numbering until you
happen across the correct combination of letters/numbers that displays
the correct grid numbers on the map.

If my understanding above is correct, then grid numbering seems even
more broken than I first thought and makes no sense at all.

Why should the module programmer be required to go back and forth
multiple times entering non-intuitive information into the interface to
create an "adapter" for a data model that has already been built?  This
seems to defy the fundimental tenants of good interface/program design. 
Wouldn't it make more sense for the "conversion" of the input to happen
behind the scenes as part of the code?  Also, if changing the default
numbering scheme (switching which axis is first, using descending
numbering, etc.) freaks out the program, doesn't that constitute a bug,
especially if it's been this way since at least 3.1.17?  At the very
least, shouldn't the ability to change the axis/numbering direction
options be removed temporarily if it's going to cause significant issues
with module data?

I'm sorry, folks, but this is really disappointing.  I have several
modules based on zone-embedded grids and reworking all these modules is
going to take hours.  Had I known that grid numbering was this
convoluted and non-intuitive, I would have developed a work-around well
before now.  As it is, I have many long nights ahead of me.

Brent, is there something that I'm missing in all this as to why grid
numbering must be configured this way?  This has been a really
frustrating experinece, but I'm willing to admit that I don't have all
the facts.

Read this topic online here:

More information about the messages mailing list