24 réponses à ce sujet

[Lance Botelle]

Hi There,

OK, I am working a new area using the CODI-Sigil tileset, and the best door that fits is the 06 - BCKII (plc_dc_gtdra03).

All looks good, BUT, I cannot determine why I can sometimes see "through a door" to the area on the other side of it, while at other times, the door does block the view until it is opened. (i.e. Once opened, you can see into the room or corridor ahead.)

I don't think this tileset and door combination are alone with this problem .. and, as I say, the problem appears to show itself whenever it feels like it.

1) Can somebody tell me how I may be able to positively stop the player seeing into the next room by placing a door?

2) And/or can somebody go into a little technical detail regarding what can be done to make a door/tile combi work as I expect - i.e. block the view until opened?

3) Also, can someone tell me if the following make any difference in this problem:- a ) Baking the area (testing made no difference), b ) Changing the scale of the door, c ) Changing orientation of the door ... etc.
 
EDIT: My own findings are starting to suggest that it is more to do with the DOOR, and that it depends upon which "hook" attachment point it "clings" to (if that makes sense). As experimenting with a different door that does not cover the entire hole (so one can "see" through a gap)  can be made to "block" or "not block" the view beyond subject to whether it attaches slightly to the left or slightly to the right of the door hole.
 
EDIT 2: If I alter the scale of a door (which looks ridiculous by the way), I can alter it enough to make it "block" the way ahead. So, that would suggest that if a door "covers" certain points on a tileset, then the way ahead is also blocked.
 
EDIT 3: Width and thickness of a door also make a difference ... and may be  is subject to something to do with the tile in where it is placed.
 
EDIT 4: I am totally confused ...  as it now appears to be something to do with the property "HookedObjects" on the tile with the door (not sure now), as I noticed *many* on the two tiles I had been playing with. So I cleared the tiles and placed new versions down and attached a new door (that worked previously) and the "HookedObjects" changed for each tile ... and now does not work as it did before! Anyone know more about this?  
 
EDIT 5: I have noticed that if a tile has any "HookedObjects" associated with it, remove them and it can behave differently. I removed every instance on a couple of tiles I was trying to place a door between and I can (with a certain door) get the "block" to work. Then, I can sometimes alter appearance, and scale of this door to work still, although not always.

Many Thanks,
Lance.

[andysks]

All I can add to this is something that might be relevant. I had one time a custom made door frame from dock pieces and sign posts etc in the middle of a tile. All this frame got connected with walls, extra careful so that no gaps where there. When I placed the door in the middle, a hostile creature from the other side new I was there. So, a door itself is not the problem I think. I think it's the combination of tile, door, gap etc. Maybe the gap most of all.

[rjshae]

I thought it might have something to do with the C3 collision mesh placement on the tile side, but I tried fully covering all sides of the surrounding side with the C3 mesh--making sure there was no gap--and it didn't seem to help. It's a puzzle that I'd really like to know the answer to. Perhaps it has to do with what side of the tile border the door hook point is at (even by a tiny amount)? If I knew, I could go back and rework the tiles.

 

I'm having the same issue with the current tileset I'm building. This is despite the fact that I used hook point placement from one of the standard tile sets.

 

OK, I am working a new area using the CODI-Sigil tileset, and the best door that fits is the 06 - BCKII (plc_dc_gtdra03).

 

 

Did you try the door that comes with the tile set?

[Lance Botelle]

Hi Guys,

Thanks for looking at this with me ... I am starting to think that it is something to do with the "gap" in a tileset and whether a door covers those gap points.

 

Did you try the door that comes with the tile set?

I tried looking for one, but I am not sure I have it after looking. I will search again ... and check 2das etc.
 
EDIT: I found them! And they work! Yeh! I had imported the tileset so long ago, that I had forgotten that I had not "made" door templates to use the "hub" doors that come with the tileset. Thanks fo rpointing me back to look at that rjshae! Unfortunately, they still suffer with the "leak" problem at times, so I am still interested about how to get around this problem.

EDIT 2: The bottom line with all this is that it is definitely a combination of things between the tileset and the doors. And altering the size of a door can help to cause a block. I would really like to know how to alter door/tileset code to make this less of a problem when mixing and matching doors and tilesets ... or simply understand why some combinations work and others don't!
 
Thanks again,

Lance.

[rjshae]

Yep, the first included door still 'leaks', but it does provide a decent fit. I just wish it had been made tintable; if that is even possible with doors...

 

The opening for the doors on the tileset I'm working is very snug, as is the C3 collision mesh, yet it still 'leaks'. (I made sure by borrowing the door frame and hook point from a similar tile in the standard castle.) I'll try shifting the door hook points toward the interior of the tiles by small amounts and see if that makes any difference.

 

Another possibility is that there is a slight gap somewhere else on the wall; perhaps the floor or the top. Or possibly the tile is crossing over into the neighbor slightly. I can't imagine they made it that sensitive to position though.

[Morbane]

after some experiments a while back with the Dark Ruins (round door), I found that the "leaking" seemed to depend on which side of the door frame the builder was holding the mouse from and un-clicking when the door was "hooked".

 

On the round doors some green 'alignment lines' appear once placed. my observations at the time noticed that the alignment of those green lines was different depending on which side I was adjusting from - which seems to support the "too close to neighbouring tiles" hypothesis you both mentioned above.

 

Just thought I would share that as that sort of tinkering seemed to insure the "blocking" and also seemed to alleviate an issue with round doors that refused to open in game.

 

 

Cheers. 

[Lance Botelle]

<SNIP>The opening for the doors on the tileset I'm working is very snug, as is the C3 collision mesh, yet it still 'leaks'. (I made sure by borrowing the door frame and hook point from a similar tile in the standard castle.) I'll try shifting the door hook points toward the interior of the tiles by small amounts and see if that makes any difference.<SNIP>

Hi rjshae,

I would really like to get to grips with this side of building some more, not to build my own, but to understand how to fix problems like this when I encounter them. For instance, I have no idea what you mean by "C3 collision mesh ... etc", so where would I learn about this sort of thing? Can you recommend any reading that would help me understand where to begin ... in very simple terms?

Thanks in advance.
 

after some experiments a while back with the Dark Ruins (round door), I found that the "leaking" seemed to depend on which side of the door frame the builder was holding the mouse from and un-clicking when the door was "hooked".

On the round doors some green 'alignment lines' appear once placed. my observations at the time noticed that the alignment of those green lines was different depending on which side I was adjusting from - which seems to support the "too close to neighbouring tiles" hypothesis you both mentioned above.

Hi Morbane,

If I recall correctly, I experimented with that round door and discovered similar issues ... and it was when I messed around with the doors thickness (similar to this time), that it helped on occasion ... as long as I had got the correct hook ... or so it seemed. The point is, however, it was all very vague and rather hit and miss, and is exactly the reason why I want to understand how this works ... or is meant to work, so that I may "load" a tileset or door into a program (?) and fix the model or numbers myself .... but I have no idea if what I just said is even close to what needs to be done.

As I ask above, do you have any recommended reading/advise on where to start ... that is easy to take on board?


Many Thanks all,
Lance.

[rjshae]

Hi rjshae,

I would really like to get to grips with this side of building some more, not to build my own, but to understand how to fix problems like this when I encounter them. For instance, I have no idea what you mean by "C3 collision mesh ... etc", so where would I learn about this sort of thing? Can you recommend any reading that would help me understand where to begin ... in very simple terms?

Thanks in advance.

 

Hi Lance,

 

In the toolset you can look at the C2 and C3 collision boxes by setting the options in the header.

 

Here's what I think I know: the C2 is typically a simple bounding box that is used to quickly compute when a collision between a creature and an object may occur; the C3 is a closer fit to the model shape that is then used to determine more exactly if a collision occurs. The C3 shape is often more complex than C2, making intersection checks computationally far more expensive. Intersecting with C2 presumably causes the program to check against C3 for an actual collision, so the C2 is mainly there for efficiency.

 

The tiles just have the C3 mesh, which lies along the walls, columns, and other blocking shapes; the C2 would just be the entire tile. In the case of placeables, I've found that both the C3 and the walk mesh are used for baking purposes, and I think the C2/C3 is probably used for line of sight checks--although this is just a guess. That's why I was thinking the C3 mesh may be associated with the view leakage.

[rjshae]

Okay, I got it to work. Woo-hoo!

 

The trick was to copy in the C3 mesh from the corresponding standard castle tile into the new tiles. Thus I copied a corner mesh (TL_SC_WWWX_01_C3) into my corner tile (WWWX), etc. After further testing I found this needs to be done in every tile that is going to be adjacent to the hidden room, so basically this means it should be done in all tiles in the set that have at least one wall.

 

For the hidden room function to work, it looks there always needs to be a C3 "curtain barrier" near the wall's tile border, in addition to the C3 mesh that maps out the interior surface of the wall. (Unless the wall is thin and they can use the same mesh.) Here's an example of the modified corner wall in blender, with the red shapes being the C3 mesh:

 

 

This means I will need to modify the Sigil and Jungle Ruins tile sets to get them to behave properly...

 

Hopefully this post made some sense.

[rjshae]

After converting the tile set, I ran a test of two rooms that share a long common barrier. At left the door is closed; at right, it is open. Seems to work okay.

 

[rjshae]

I wanted to confirm that this worked with the odd-shaped door openings in the Sigil tileset. It does:

 

 

I'll get the fixed Sigil tileset out this week.

[Lance Botelle]

Hi rjshae,
 
Excellent work!
 
I still do not fully understand how viewing the C2 and C3 help, but I did see all the lines they bring up when switched on.
 
You said, "The trick was to copy in the C3 mesh from the corresponding standard castle tile into the new tiles. Thus I copied a corner mesh (TL_SC_WWWX_01_C3) into my corner tile (WWWX), etc."
 
Here are my questions trying to help me understand - and reveal just how ignorant I really am about this side of things:-
 
1) So, if I am understanding you correctly, each "tile" for all tilesets has their own associated C3 mesh?
2) What do you actually mean by the quote above? i.e. How do you "copy a corner mesh into a corner tile"? What are you actually doing?
3) If the OC C3 mesh information files work, why didn't they get used/copied for the newer custom built ones? i.e. What went wrong in the construction/release?
4) You mention something called "blender" when you showed the walls. What is "blender" and what is it used for? Is it a free utility to allow us to work with a ) tilesets? b ) walkmeshes? c ) collision files? EDIT: I just noticed those links in your sig, so I will check those out too.
5) What files actually make up a tileset?
6) I know you are using a file from the OC to "fix" the broken tiles in the custom built tilesets, but what is the OC file actually doing to fix the problem? i.e. Does the OC file have the "blocking wall" information (like in your image above) that the custom tileset does not?
 
Your help is really appreciated here ... and if you are able to fix these "leaks" on the various tilesets out there, that would be a really neat fix/update in my opinion.
 
EDIT 2: In your link to the Blender page (which I am currently looking at), it says, "In this new release, the python code has been extensively overhauled to work with Blender 2.69 and enhancements have been made to improve the way data is imported and exported.", but I cannot see any link to download this version 2.69. Am I missing something?
 
EDIT 3: You said, "For the hidden room function to work, it looks there always needs to be a C3 "curtain barrier" near the wall's tile border." Why wouldn't curtain barriers have been added to every tile with walls then? Wouldn't such an inclusion have been essential when designing them? What possible reason would someone design a wall tile without this curtain barrier? I am just trying to understand how and why such (what appears to be to me) such a huge oversight has been made? (No pun intended .... oversight ... see through walls ... )
 
EDIT 4: OK, I have just learned that "Blender" is actually a program built by somebody else. Having followed the link in your HTML readme, it goes to a page with version 2.7 ... Are there any potential problems with trying to use the Blender MDB Import/Export Plugin (which I think I have just understood to be a plugin for the Blender program and nothing to do with a NWN2 Toolset plugin) with this latest version of Blender ... or can there be issues? i.e. Would you recommend using version 2.69 of Blender with the plugin? 

Lance.

EDIT 5: Have not been able to stop these two leaks (doors have been exaggerated to show them more easily). I thought showing the map image may help you to determine which tiles are leaking rather than me trying to explain them. Actually, this example demonstrates direction leakage!
 
What I mean by that is .... If I start the module where the START LOCATION is in the current image, then both these doors "leak" the way ahead. If, however, I place the START LOCATION outside the other door (on the LEFT HAND side of the image below), then NEITHER door leaks and I CANNOT see into the chambers ahead! Can you explain that to me? Can that be easily fixed too?




Ingame images of area views when approaching SAME DOORS from different directions:-

When approached from the LEFT hand side ... all is well:-



When approached from the RIGHT hand side ... all is NOT well:-

[rjshae]

1) So, if I am understanding you correctly, each "tile" for all tilesets has their own associated C3 mesh?

 

Yes. All tiles (other than a roof or open floor) normally have a C3 mesh.

 

2) What do you actually mean by the quote above? i.e. How do you "copy a corner mesh into a corner tile"? What are you actually doing?

 

I imported a MDB tile model from the Standard Castle set (those that begin with TL_SC) into Blender, stripped off every object other than the one that ends with C3, and saved it to a different file name. You could call it, say, WWWX_C3. I then open the WWWX tile MDB file from the new tile set, import the saved C3 mesh, and join ('j') the new mesh with the existing C3 mesh. The result is exported back out to the new WWWX MDB file.

 

Hopefully that made sense. It's probably easier to see what I mean visually from within Blender.

 

Fortunately, I only needed to use three of the C3 meshes from the Standard Castle set to update all the new tiles: wall, wall with door, column. The Sigil set had oddly shaped doors, so I also modified the 'wall with door' C3 mesh to fit its opening. After that it was just a matter of importing a tile, importing the necessary C3 mesh(es), copying the C3 mesh(es) as needed and rotating into position, joining the C3s, then exporting tile.

 

It just took a couple of hours work for the full set.

 

3) If the OC C3 mesh information files work, why didn't they get used/copied for the newer custom built ones? i.e. What went wrong in the construction/release?

 

Some of the tiles were built with walls that were further away from the sides. These are nice from a game-play perspective, but it looks like there is a fixed distance from the edges after which the room hiding effect doesn't work. (Maybe the game coders did it that way for compute efficiency?) Anyway, I wasn't aware of this restriction, and it looks like other tile builders might not have been either.

 

4) You mention something called "blender" when you showed the walls. What is "blender" and what is it used for? Is it a free utility to allow us to work with a ) tilesets? b ) walkmeshes? c ) collision files? EDIT: I just noticed those links in your sig, so I will check those out too.

 

Blender is open source software that is used for 3D modelling. It's a pretty powerful tool, but it has a definite learning curve. The MDB import/export scripts allow you to merge NWN2 MDB files into Blender, make changes, then export them back out to MDB format.

 

5) What files actually make up a tileset?

 

There are a set of model files with a name like TL_XX_YYYY_##.MDB, where XX is the tileset identifier, YYYY is the tile type, and ## is the variant. There's one model file for every tile in a set, and they are located under data\models in the NWN2 install directory. Tiles also have texture files; typically 3 for the floor, three for the wall, three for the ceiling, sometimes two more for the black areas, plus other textures for special additions.

 

6) I know you are using a file from the OC to "fix" the broken tiles in the custom built tilesets, but what is the OC file actually doing to fix the problem? i.e. Does the OC file have the "blocking wall" information (like in your image above) that the custom tileset does not?

 

I think it's just the proximity of the C3 mesh to the edge of the tiles. All of the OC tiles have a C3 mesh "curtain" near the edge--even the caves set, which has pretty irregular sides. I guess they built into the engine a check for mesh surfaces at a certain distance from the sides. It may work the same for placeables, with the C3 mesh being checked when it lies near the C2 mesh.

 

...but I cannot see any link to download this version 2.69. Am I missing something?

 

If you are looking at the Nexus, you need to click on the Files icon.

 

What possible reason would someone design a wall tile without this curtain barrier?

 

It's not really essential as such; it's just needed to hide enclosed rooms. Modders may not have known. I had to experiment before I found out--there was no information on it available with a web search, that I could find.

 

Would you recommend using version 2.69 of Blender with the plugin?

 

I use it with 2.69, and I haven't tried it with 2.70 yet. But it should work, unless they made a revision to the API that breaks something. It definitely won't work with old versions of Blender, such as 2.5X, because of changes to the way mesh data is stored and manipulated. But there is an old version of the import tool that works with those releases.

 

Are there any potential problems with trying to use the Blender MDB Import/Export Plugin

 

There are a few minor issues and peculiarities, which I keep trying to address with patch updates. The latest version of the plug-in scripts is 2.6.2.2. For the most part it is working decently well--good enough that I can use it productively with placeables and tiles. It just doesn't work with doors or any other models that have animated parts. (I'm not quite sure why--it has something to do with the way that the .gr2 animation files are built.) Known issues and some useful tips are listed in the README file that comes with the download, or from the NW Vault.

 

I can't see your images right now, so I'll need to check back later. All I can suggest at present is trying it again when I finish updating Sigil set and see if the problem persists.

[Lance Botelle]

1) So, if I am understanding you correctly, each "tile" for all tilesets has their own associated C3 mesh?
 
Yes. All tiles (other than a roof or open floor) normally have a C3 mesh.
 
2) What do you actually mean by the quote above? i.e. How do you "copy a corner mesh into a corner tile"? What are you actually doing?
 
I imported a MDB tile model from the Standard Castle set (those that begin with TL_SC) into Blender, stripped off every object other than the one that ends with C3, and saved it to a different file name. You could call it, say, WWWX_C3. I then open the WWWX tile MDB file from the new tile set, import the saved C3 mesh, and join ('j') the new mesh with the existing C3 mesh. The result is exported back out to the new WWWX MDB file.
 
Hopefully that made sense. It's probably easier to see what I mean visually from within Blender.
 
Fortunately, I only needed to use three of the C3 meshes from the Standard Castle set to update all the new tiles: wall, wall with door, column. The Sigil set had oddly shaped doors, so I also modified the 'wall with door' C3 mesh to fit its opening. After that it was just a matter of importing a tile, importing the necessary C3 mesh(es), copying the C3 mesh(es) as needed and rotating into position, joining the C3s, then exporting tile.
 
It just took a couple of hours work for the full set.
 
3) If the OC C3 mesh information files work, why didn't they get used/copied for the newer custom built ones? i.e. What went wrong in the construction/release?
 
Some of the tiles were built with walls that were further away from the sides. These are nice from a game-play perspective, but it looks like there is a fixed distance from the edges after which the room hiding effect doesn't work. (Maybe the game coders did it that way for compute efficiency?) Anyway, I wasn't aware of this restriction, and it looks like other tile builders might not have been either.
 
4) You mention something called "blender" when you showed the walls. What is "blender" and what is it used for? Is it a free utility to allow us to work with a ) tilesets? b ) walkmeshes? c ) collision files? EDIT: I just noticed those links in your sig, so I will check those out too.
 
Blender is open source software that is used for 3D modelling. It's a pretty powerful tool, but it has a definite learning curve. The MDB import/export scripts allow you to merge NWN2 MDB files into Blender, make changes, then export them back out to MDB format.
 
5) What files actually make up a tileset?
 
There are a set of model files with a name like TL_XX_YYYY_##.MDB, where XX is the tileset identifier, YYYY is the tile type, and ## is the variant. There's one model file for every tile in a set, and they are located under data\models in the NWN2 install directory. Tiles also have texture files; typically 3 for the floor, three for the wall, three for the ceiling, sometimes two more for the black areas, plus other textures for special additions.
 
6) I know you are using a file from the OC to "fix" the broken tiles in the custom built tilesets, but what is the OC file actually doing to fix the problem? i.e. Does the OC file have the "blocking wall" information (like in your image above) that the custom tileset does not?
 
I think it's just the proximity of the C3 mesh to the edge of the tiles. All of the OC tiles have a C3 mesh "curtain" near the edge--even the caves set, which has pretty irregular sides. I guess they built into the engine a check for mesh surfaces at a certain distance from the sides. It may work the same for placeables, with the C3 mesh being checked when it lies near the C2 mesh.
 
...but I cannot see any link to download this version 2.69. Am I missing something?
 
If you are looking at the Nexus, you need to click on the Files icon.
 
What possible reason would someone design a wall tile without this curtain barrier?
 
It's not really essential as such; it's just needed to hide enclosed rooms. Modders may not have known. I had to experiment before I found out--there was no information on it available with a web search, that I could find.
 
Would you recommend using version 2.69 of Blender with the plugin?
 
I use it with 2.69, and I haven't tried it with 2.70 yet. But it should work, unless they made a revision to the API that breaks something. It definitely won't work with old versions of Blender, such as 2.5X, because of changes to the way mesh data is stored and manipulated. But there is an old version of the import tool that works with those releases.
 
Are there any potential problems with trying to use the Blender MDB Import/Export Plugin
 
There are a few minor issues and peculiarities, which I keep trying to address with patch updates. The latest version of the plug-in scripts is 2.6.2.2. For the most part it is working decently well--good enough that I can use it productively with placeables and tiles. It just doesn't work with doors or any other models that have animated parts. (I'm not quite sure why--it has something to do with the way that the .gr2 animation files are built.) Known issues and some useful tips are listed in the README file that comes with the download, or from the NW Vault.
 
I can't see your images right now, so I'll need to check back later. All I can suggest at present is trying it again when I finish updating Sigil set and see if the problem persists.

Well done rjshae,

 

A very informative post ... Excellent and much thanks!

I can see this would involve a large learning curve than would probably warrant at this stage, and so I am extremely grateful that you have spent the time you have making these fixes. Very welcome indeed!

I will definitely try your modifications out, and if you do manage to fix all these issues, then I imagine you will have others who would definitely want to have the fixes too.

You are now, without doubt, the official tileset fixer in my book. Well done!

 

EDIT: Do let me know when you get the chance to see my images and if you can make sense of the "direction" leak problem. Most strange I thought, but great if you can explain and fix it.

Lance.

[rjshae]

Well done rjshae,

 

A very informative post ... Excellent and much thanks!

I can see this would involve a large learning curve than would probably warrant at this stage, and so I am extremely grateful that you have spent the time you have making these fixes. Very welcome indeed!

I will definitely try your modifications out, and if you do manage to fix all these issues, then I imagine you will have others who would definitely want to have the fixes too.

You are now, without doubt, the official tileset fixer in my book. Well done!

 

EDIT: Do let me know when you get the chance to see my images and if you can make sense of the "direction" leak problem. Most strange I thought, but great if you can explain and fix it.

Lance.

 

Thank you, Lance. Yes there's a learning curve, but to me it's not that hard to get into Blender--I'd say it takes about a week of practice to learn enough to be useful. Most of the operations I use required picking up maybe 15-20 commands, most of which I discovered with web searches. The slowest part was just getting used to the interface; it still seems pretty clunky to me.

[rjshae]

What I mean by that is .... If I start the module where the START LOCATION is in the current image, then both these doors "leak" the way ahead. If, however, I place the START LOCATION outside the other door (on the LEFT HAND side of the image below), then NEITHER door leaks and I CANNOT see into the chambers ahead! Can you explain that to me? Can that be easily fixed too?

 

I can only guess that it works that way because they are different tiles with different C3 mesh arrangements; the door on the right of the first pic looks like a DDXX tile while the left door tile appears to be a DDWW. But I'm not sure what it is about the mesh arrangements that causes only the first to fail.

 

Once I'm done, I'll try to reproduce your layout with the modified tileset and see if they both work. Hopefully it does. If not, it's back to the drawing board.

[Lance Botelle]

I can only guess that it works that way because they are different tiles with different C3 mesh arrangements; the door on the right of the first pic looks like a DDXX tile while the left door tile appears to be a DDWW. But I'm not sure what it is about the mesh arrangements that causes only the first to fail.
 
Once I'm done, I'll try to reproduce your layout with the modified tileset and see if they both work. Hopefully it does. If not, it's back to the drawing board.

Thanks rjshae,

Appreciated ... Hopefully, you will get to the bottom of this then ...

Lance.

[rjshae]

Here's the updated tileset:

 

• CODI-RWS-Sigil_2.2.zip

 

I checked it on my test areas and a mockup of the area shown above. The room concealment seems to be working just as it should, regardless of where I put the start location. Please give it a try and see if it works okay. If you find no problems, I'll post it to the Nexus/Vault. Thanks.

[Lance Botelle]

Here's the updated tileset:

• CODI-RWS-Sigil_2.2.zip

I checked it on my test areas and a mockup of the area shown above. The room concealment seems to be working just as it should, regardless of where I put the start location. Please give it a try and see if it works okay. If you find no problems, I'll post it to the Nexus/Vault. Thanks.

 

Hi rjshae,

Great stuff! I will test this straight away and let you know the results in a few minutes.

EDIT: Just checking a few 2da bits of info:-

It looks like you have added some Tiles.2da lines .... I will check the other 2das out as well, but if you can let me know what lines you have added/altered, it may make it easier to make sure I have all the correct alterations for my 2da files. i.e. They have a lot of other tileset info and it is easier to add/alter those ones than start again.  Don't worry about telling me this now, as I can see there have been a number of alterations, which would make it easier if I just replaced all my lines. However, if you could just let me know which 2das are "critical" and I will definitely need to change. As far as I can see at the moment, it is just the Tiles.2da alterations I need to make. (Other references to this tileset resources look the same as I already have.)

By the way, over 3 years ago, when I first downloaded the RWS all in one, I posted this on my blog:- http://worldofalthea...all-in-one.html It mentions some missing files from the all-in-one, which I have now added as an additional "fix" hak to run alongside the main all-in-one hak. I don't think it impacts the SIGIL set, but did not know if it was any help in some way (as it is from this hak I have access to the original SIGIL set).

However, I do understand that you have altered some of those files in the original all in one hak and added some new material, so I may simply run your hak as an additional "higher priority" hak to run alongside the current haks to fix those problems that exist with the current hak. I know this may seem a "long winded" approach, but by keeping existing haks in place, people can see the original resources and alterations made. Ideally, the absolute BEST approach, is if you were able to download the current/latest (very old now) all-in-one RWS hak (that my blog links to) and incorporate all the fixes I noted, and your own into one NEW UBER FIXED RWS all-in-one tileset (fixing all leaks), which I could use instead all my combination of haks.  I could then use that hak and people would then need only have that.
 
What do you think? Not really required or worth considering?
 
By the way, I MUCH PREFER your organised naming conventions, as I can see (mostly) how certain files are associated with the certain tileset by your convention. e.g. I can see there was an "arch.dds" file (from my original all-in-one set, that, without further investigation, I would not have known which tileset in was actually from) that you have renamed to "codi_arch.dds", which now makes it clear that that DDS was related to the CODI/SIGIL part of the all-in-one set, which obviously contains many different sets.
 
FIRST TEST RESULTS: Well, for some reason, when I test your tilesets, on an imported erf of my basic area, everone works fine ... good so far. However, when I then try the same thing in my module (with combined/additional versions of your tilesets and 2das combined with mine), I still get the issue. Note: I get all your new tiles for the set and all looks good, but the leaks remain. So, I will look a little closer to see if I can work out where there is a difference and come back soon as I can.

SECOND TEST RESULTS: OK, I found out why my first test failed, and it was because the info on this page on the Vault (http://nwvault.ign.c...ls.Detail&id=56) misled me about hakpak priorities, which says this under the section entitled "Multiple Hakpaks": "If you had three haks numbered 0, 1 and 2, then the hakpak listed as number 2 would be the highest priority. So, if hakpak number 2 had the same resource as hakpak number 0 or hakpak number 1, then the resource from hakpak number 2 would be the one used." But, just now I read this a little further down as I was about to make this post: "Hakpak Issues: * Note: The priority system is broken as of v1.04. The toolset should be taking hakpak number 0 as the highest priority. This is the way the game engine reads it, so when you want to run your module you need to move your haks to the opposite order."So, I guess that explains all, as the leaks all stop. Yeh!

I'll say it again, Many Thanks rjshae!

What do you reckon about checking out some of the other tilesets from the RWS range?

By the way, you have not only fixed the leak problem, but exceeded my expectations by giving more tile combinations to work with. This is really a great set to work with now.

 

By the way, I have not yet checked every tile combination, but those I have currently used, do work.

 
Lance.

[rjshae]

Hi Lance,

 

The only updates I made in this (2.2) release were to the tile MDB files and I added back in six textures for the doors that had been renamed as part of Kamal_'s tileset project. Thhe latter is where the renamed texture files came from.

 

With regards to the issue with your module, it might be that you need to do a bake with the new tiles in place.

[Lance Botelle]

Hi Lance,
 
The only updates I made in this (2.2) release were to the tile MDB files and I added back in six textures for the doors that had been renamed as part of Kamal_'s tileset project. Thhe latter is where the renamed texture files came from.
 
With regards to the issue with your module, it might be that you need to do a bake with the new tiles in place.

Hi rjshae,

I found there were quite a few renamed textures from the original hak I was using. So, are you saying that the original textures (in their former name format) would be recognised (picked up and used) if I removed them from your own hak? I thought you may have been referencing them from some of the files you "fixed".

I could probably test that myself easily enough, but just wanted to make sure I understood what you meant.
 

Hi, after a quick test I discovered that the naming format you had used is vital for your fix (had lots of pretty missing textures all over the place if I tried using the original textures) and so I will simply leave your hak as the priority. OK, it means about 25 MB of duplication, but that is nothing nowadays ... and I would rather see the changes made (even in naming content) than remove files and potentially confuse myself (if not other builders) if you see what I mean.

 

Kamal's tileset project ... perhaps I should take a look at that as well then ... the problem is trying to keep all the relevant data up to date to ensure everything works as it should.

 

EDIT: I just noticed you fixes also fixed a walkmesh issue with one of the corners! Yeh!

 

Lance.

[rjshae]

Hi Lance,

 

The renamed textures in Kamal_'s tileset allow you to use a much greater variety of textures with the tiles. I adopted those so that he wouldn't need to keep re-doing my tiles every time I did an update. Unfortunately, because of the .gr2 file requirements, the door models have to keep using the original texture names, which is why I added those back in.

[Lance Botelle]

Hi Lance,
 
The renamed textures in Kamal_'s tileset allow you to use a much greater variety of textures with the tiles. I adopted those so that he wouldn't need to keep re-doing my tiles every time I did an update. Unfortunately, because of the .gr2 file requirements, the door models have to keep using the original texture names, which is why I added those back in.

Hi rjshae,

Ah, so I can change some of the textures with your fixes, even extra bonus then. Doors ... fair enough ... although the ability you have given to change the tile to accept a "normal" door shape opens up a few more options anyway, so that's great.

Lance.

[rjshae]

One issue I've discovered is that the back of the stair up tiles may still leak. I didn't add the curtain mesh to the backs of those because of the proximity of the door to the tile edge. But on another tile set, it still leaks even when I add the mesh and fit it to the upper door. Its unfortunate, but I think you can avoid it by making sure there is a roof tile behind the stair up tiles. I.e. putting a roof tile behind the side  where the steps up end.

 

Ideally, the absolute BEST approach, is if you were able to download the current/latest (very old now) all-in-one RWS hak (that my blog links to) and incorporate all the fixes I noted, and your own into one NEW UBER FIXED RWS all-in-one tileset (fixing all leaks), which I could use instead all my combination of haks.  I could then use that hak and people would then need only have that.

 

It sounds good. However, I still have a few requested updates in the pipe to some of the other RWS tile sets. I'll try to apply this fix where needed.

[Lance Botelle]

One issue I've discovered is that the back of the stair up tiles may still leak. I didn't add the curtain mesh to the backs of those because of the proximity of the door to the tile edge. But on another tile set, it still leaks even when I add the mesh and fit it to the upper door. Its unfortunate, but I think you can avoid it by making sure there is a roof tile behind the stair up tiles. I.e. putting a roof tile behind the side  where the steps up end. <QUOTE SNIPPED> 
 
It sounds good. However, I still have a few requested updates in the pipe to some of the other RWS tile sets. I'll try to apply this fix where needed.

Hi rjshae,

Thanks for the heads up on the potential stair leak. At the moment, I cannot thank you enough for the repairs you have already made. They are so much better already.

Do keep me updated on any tile fixes you continue to make so that I can keep on top of them myself. And if you do get time to do an uber fix, then I would certainly be interested there too.

Lance.