Well, if you examine the geometry of each of those "rooms", once you can see any part of any of the 4 tiles, you have openings into all of the other three. There are no separating walls that fully meet the tile edges in the center of the "room".
Now, as to your "little problem remains" I expect it is just an engine limitation.
The way I understand how the engine displays things, if ANY piece of a tile is visible, then the ENTIRE tile is visible, regardless of clutter, walls etc. The engine only handles tiles as a complete, single object, most especially with regards to mini-maps. If ANY part of a tile is visible, then the ENTIRE tile is visible. I don't recall the exact numbers involved (distance) but I think it is 9 full tiles surrounding a PC. The one in the center where the PC stands, and every tile surrounding them, up to one tile away. This can be further expanded by adjusting fog distance, but I believe the defaults for minimaps are just the 9 tiles. To BLOCK that view, a full width wall must be in place in any given tile. That blocks seeing things further out from that tile's outside edges.
It is a bit confusing, as when you paint a single tile, the game actually re-paints all 9. You know this, but like me, I think you likely forget it at times. It is not visibly obvious in toolset, unless you actually check all outside edges of the single tile you paint. You should notice that they change, maybe not all of them, but just cycling through a variation on that single tile, will likely change the tiles surrounding it. This is a random paint where the engine grabs any tile that will "fit" with the constraints of the actual tile you are changing.
This is typically much easier to see in outdoor areas, and most outdoor tilesets have more variants for any given tile, so that when you paint one, you can get various combinations on the surrounding tiles.
Anyway, I think there are just limits on what you can expect to happen.
I do agree that having the visibility node set to "A" is not really needed, but I think the idea behind those "groups/homes" was so that the builder can create a 2x2 area, and paint just a single group, connect the door to an outside entrance and be done. They truly were not originally intended to be used as multiple groups in the same area. You CAN use them that way, but I really don't believe that was the intention.
I know that folks are limited in area counts, most especially PW's where they wish to reduce total counts on numbers of areas. So, many folks will paint multiple functioning sections in a single area. Each one intended to be a separate entry/exit back to outside world. However, the game assumes that any single area is just that, a single building so to speak. So, if you can view one section, you can view up to whatever the range is around it.
Going back to the 9 tiles changing and viewable at all times, if you paint TWO of those rooms next to each other, the game assumes (original intention) them to be a single reachable area, as if connected etc. It doesn't realize that you have intended them to be totally separate. Only viewable when entered from a separate outside entrance. IE, Tom's House, Bill's House, Chad's House and Thumbalina's house, all with separate doorways on the exterior area they connect from.
So, if your entrance to Tom's house is on far left hand section of a 16x16 grid, and Bill's House is on far right hand section of that same grid, you would "think" that the are separate areas you are connecting to. But you as the builder, combined their space to be "hidden/connected to" the same "area" (My_Mod_Interior).
Whenever the PC enters any of those "buildings" they enter via the doorway (normally anyway) but that doorway is the center of a 3x3 grid (9 tiles). So, any tile next to that doorway tile, will be visible.
Note that this has been this way since, well, since the beginning of NWN. Bioware was not worried about area counts, PW usage etc, the engine was not initially designed for that purpose. There are bits that can be modified to allow for PW usage, but they are modifications on the base engine itself. That base engine always assumes that the player can see all 9 tiles surrounding where it stands UNLESS that player is standing inside a single tile that has a high wall on each of the outside edges of the single tile he/she is standing on. Those walls must extend full tile width/length. They can not have lower sections etc, or open doorways. If a door is there and the door is open, then the player can "see" the tile in that direction as well, up to the 9 tile limit. They can be expanded to see farther, but the 9 tile grid is the minimum.
It is an issue, and as you have found, using a vis node of "A" makes it even a bit more problematic, BUT it was intended so that any PC that opened the door into (translated into) that "area" could see the entire space regardless.
You can't really pack single "areas" inside of another "area" as the engine doesn't know the difference. It looks at the parent as the entire area, once visited, any section that the player has seen will ALWAYS be visible.
There are ways to script a hide of the mini-maps, but I don't think anyone has ever found a way around the 9 tile min view distance for anything. I know that this has been discussed MANY times in the past, on the old forums, via IRC chats, emails etc, but so far, no one has found a way around this.
One option would be to generate a blank minimap and assign that to each tile in the .set, or at least to the "groups" sections of the .set. You could do this using the same minimap for all of the "homes" groups, and likely a few of the others that do not auto-connect a corridor to themselves when painted. Using the same minimap would also save some space in the hak.
For minimaps, you really do NOT need a minimap on such a small room anyway. It is a waste. And I can see no harm in not having a true minimap for those groups.
OTHER groups in that set would require normal minimaps though. So, you can't just do a global replace, you would have to manually edit the entries for each of those groups.
The way Bioware numbered/named the tiles will help somewhat, q/r etc. but it would require you to check each group, figure out each tile, and manually change the minimap for those tiles that are used in those types of groups.
The set was intended to provide the builder with two choices and they are essentially exclusive choices... build single already created groups, OR use the terrain bits, build a larger area and paint the various connecting groups. The various groups are not really set up in such a way as to determine easily, what is what. They are all linked in groups section, and some WILL connect to corridors, others will not.
For the ones that will NOT connect to a corridor, those groups could have their minimaps changed to a blank one, but for those that DO connect to corridors, then you really do need minimaps for them.
There are various other sets out there that have this same "issue". All of them are interiors of some sort, but not all interiors have "single area" groups created for them.
Clear as mud right?
Retour en haut
If it is the tiles them selves, then that probably creates a distribution problem. I assume that the solution needs to show up in the client, and not just the server. However if this was a server only fix, that would be easy to implement.
