mini map hide disabled

[Legacy_henesua]

               Where is this information stored? Is it in the SET file or is it embedded in the tile itself?

I would prefer that you say SET. '> 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.
               
               

               
            

[Legacy_wyldhunt1]

               If I read Bannors comment correctly, it's in the .set. At least, his instructions on how to fix it were all about editing .set files.

BTW: Thanks for all the info everyone. Very helpful.
               
               

               

                     Modifié par wyldhunt1, 26 mars 2012 - 08:51 .
                     
                  

            

[Legacy_Zwerkules]

               

henesua wrote...

Where is this information stored? Is it in the SET file or is it embedded in the tile itself?

The path nodes, visibility nodes and door visibility nodes are all in the SET file.

The entry for a tile looks like this:
[TILE58]
Model=tdc01_i07_01
WalkMesh=msb01
TopLeft=Floor
TopLeftHeight=0
TopRight=Floor
TopRightHeight=0
BottomLeft=Floor
BottomLeftHeight=0
BottomRight=Floor
BottomRightHeight=0
Top=Fence
Right=
Bottom=Fence
Left=
MainLight1=1
MainLight2=1
SourceLight1=1
SourceLight2=1
AnimLoop1=1
AnimLoop2=1
AnimLoop3=1
Doors=1
Sounds=0
PathNode=F
Orientation=0
VisibilityNode=A
VisibilityOrientation=0
DoorVisibilityNode=A
DoorVisibilityOrientation=0
ImageMap2D=MIDC01_I07

[TILE58DOOR0]
Type=20
X=0.00
Y=0.00
Z=0.00
Orientation=-90.0

If you know which tiles you are looking for, you can simply edit the set file in a text editor and change the path/door/visibility nodes. Those are case sensitive though. Don't set a path node to 'a' when it should be 'A'. Those two path nodes are completely different ones.
               
               

               
            

[Legacy_henesua]

               Excellent. Thank you very much. Find/Replace using GREP might do the trick if I can ever find the time to do a little trial and error testing. I'm likely to be too busy to do so however for a good long time given that Arnheim is in play now. I'll bookmark this thread, and get back to it when I can.

Lastly SET files are client only yes? I assume that they are, but am hoping that I'll be surprised since I already released Arnheim's HAKs.
               
               

               
            

[Legacy_Bannor Bloodfist]

               

Zwerkules wrote...
I wasn't wondering why Bioware added visibility nodes, but why they added visibility nodes 'A' to each of those tiles in the homes tile groups. As you said, if there are no visibility nodes added, the default is the pathnode. The pathnodes for thoses tiles are all correct, but the addition of the visibility node 'A' to the tiles makes no sense to me. There are no doors or fences or anything else there which the PC should be able to look through.
Those visibility nodes cause other rooms to appear which should still be hidden. So I was wondering why Bioware added those 'A' visibility nodes to those specific tiles, not why they added visibility nodes in general.

As I am not exactly sure what tileset you are referring to, I can't directly check it.

Actually, I may have miss-spoke when I stated that Bioware did a mass add on visibility nodes.  it has been too long, too many patches for me to track it all.  I seem to remember that adding the visibility and door vis stuff was added in a patch, but I may be wrong with that memory.  Just too darned long ago.

Bioware's original tin01.set as provided by Bioware, has proper visibility nodes assigned as far as I can find.  Not every tile has visibility OR door-visibility data stored in the .set.

One thing I can absolutely tell you is that ANY .set file found in CEP has been modified, and most likely modified with tools that don't work correctly.  Not necessarily their fault and lots of folks still don't understand how a .SET file works, and why specific data may or may not be inside of it.   b085 will "fill in" data when that data is not provided, with whatever defaults are setup in it.  That may be why things are set wrong.

Many folks didn't understand that having an "A" path node would totally screw up NPC actions and can even affect the PC too if you click far enough away and expect the PC/NPC to just run to that location.  Proper pathnodes, visibility nodes help to correct that in most instances, but will not fix all of it.

Many folks STILL believe that path nodes are not necessary, and that using a default of "A" will work for any tile.  It does, sort of.  But, and the BUTT is pretty big, if all tiles are pathnode "A" but the geometry doesn't match, then any follower/npc will get blocked/locked into different spots.

Anyway, I can remember posts on the old forums where people kept suggesting to just change the pathnode to "A" and be done.  There was a lot of argument regarding that type of option.

The path nodes are a textual way of informing the engine how any given creature/npc can navigate WITHOUT having to actually read the individual tiles en-masse.  Makes for faster calculations etc. 

Regardless, I just checked several different tilesets from Bioware, as the TRUE source, and their pathnodes and visibility nodes are correct, when they exist.  Not all tilesets have visibility nodes filled in at all.  A large number of the .set files have no extra data there at all, just use the pathnode, and the engine defaults to that for visibility.  Interiors are the only sets processed for door visibility to the best of my knowledge, I don't think doors are even considered in outdoor areas but I may be wrong with that.

One thing that I do know, is that if the visibility and door visibility data is NOT set, the engine defaults to pathnode.  If pathnode is set to "A", then the engine assumes that if you can see any piece of that tile, you will be able to see the entire tile's minimap.    Basically, the pathnode is the default for all 3, UNLESS manually set to be something else via the .set file.  I think the seteditor b085 "fills in" data that you may not have wished it to fill in.  that may be changeable, but I don't think anyone around still has the source code for that program.  If they did, I would have expected it to be repaired to recognize what 1.67-1.69 added to tilesets in general.

P.S.  @Zwerkules, I was not suggesting or implying anything to or at you.  I was just adding details in case others are reading this thread that do NOT understand how the whole thing works.
               
               

               
            

[Legacy_Bannor Bloodfist]

               

henesua wrote...

Excellent. Thank you very much. Find/Replace using GREP might do the trick if I can ever find the time to do a little trial and error testing. I'm likely to be too busy to do so however for a good long time given that Arnheim is in play now. I'll bookmark this thread, and get back to it when I can.

Lastly SET files are client only yes? I assume that they are, but am hoping that I'll be surprised since I already released Arnheim's HAKs.

Yes, the client must have a proper copy of the same .set file for things to work correctly.  So, it must be distributed with the tileset itself.  A server side override won't work.
               
               

               
            

[Legacy_henesua]

               Thanks for all the information, Banner. I pointed the Project Q folks to this thread. No one has been around there for awhile, but who knows someone might take a look at the set files of the tilesets they've been working on and consider some repairs.
               
               

               
            

[Legacy_Zwerkules]

               

Bannor Bloodfist wrote...

As I am not exactly sure what tileset you are referring to, I can't directly check it.

P.S.  @Zwerkules, I was not suggesting or implying anything to or at you.  I was just adding details in case others are reading this thread that do NOT understand how the whole thing works.

I'm sorry for the misunderstanding, Bannor. Since you quoted my post I had though that you thought I didn't know that visibility nodes and door visibility nodes are two different things.

The tileset that I was referring to is tin01, the Bioware city interior tileset. The groups that cause problems are all the ones named 'homes something something 2x2'. The tiles are number 175 to 190. They all have the correct path nodes (H) but they also have a visibility node (A) added to them.

I did further testing and removed the visibility nodes from the tiles and as expected this solved the problem of lots of adjacent rooms being shown on the map when the PC enters one of those tile groups - well, sort of... a little problem remains.
I made this test area:


When entering rooms 1 to 4 and  7 and 8 everything works as expected after the removal of the visibility nodes.
Only those rooms are shown when entered, none of the ones next to them. However if I enter room 5, room 7 is revealed on the map and the same happens with room 8 if I enter room 6. I have no idea why that happens.
At least only one room next to those rooms is revealed and not all of them as is the case when the tiles all have the visibility node 'A'.

Of cause all the tilesets derived from tin01, like the CEP city interior and TNO City interior have the same problem.
               
               

               

                     Modifié par Zwerkules, 27 mars 2012 - 07:23 .
                     
                  

            

[Legacy_Bannor Bloodfist]

               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?
               
               

               
            

[Legacy_Zwerkules]

               

Bannor Bloodfist wrote...

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.

Clear as mud right?

Ah, that explains why rooms 7 and 8 were shown. The tile 'behind' the open door in room 5 and 6 is revealed and that tile has a pathnode 'H', so the whole 2x2 group is revealed.
The same would have happened if there had been more rooms south of room 7 and 8, but because there are empty tiles there which have the pathnode 'T' only those two black tiles are revealed on the map.

In the other rooms the door through which the PC entered was in a wall next to a room that had already been revealed before.

So if you use those house groups on a map and have black tiles next to the walls which have a door everything will be fine as long as the visibility nodes 'A' are removed. I still can't see any reason why Bioware added those visibility nodes to those tiles. If all those tile groups where meant to be used as the sole group in one area then there'd be nothing next to those tile groups anyway (except for the black edge tiles).