406 réponses à ce sujet

[Estelindis]

Thanks for all the advice.  

 

Cervantes, I see what you're saying, but I can't help but feel that there *must* be other ways to achieve what I want.  I know of several tilesets that allow one to raise water, for instance (giving a sort of waterfall effect on the "border" tiles between water 0 and water 1).  Nonetheless, I will try what you suggest.  

 

Zwerkules, I feel embarrassed!  You are doing the painstaking work that I shied away from.  I will try to concentrate harder when examining the rules and not get distracted.

 

Lord Sullivan, you're exactly right.  In fact, I did a quick "find and replace" on tcn01.set, changing Water to HighForest and Cobble to Platform, and then dumped the appropriate rules into my own set file (deleting all the castle ones).  It didn't change a thing, so I changed the rules back.  :-/

 

There *has* to be a way to fix this.  With your help and advice, I *will* find it.  I might not post back again before tomorrow, as I have a few things to do this evening apart from test this tileset, but I'll get back to you with results in time.  

[Zwerkules]

Rules where 'adjacent' and 'changed' differ are only needed for special cases. Lets say for example you have a forest with a chasm terrain and water terrain, but there are no tiles with huge waterfalls at the edge of chasms where the water meets the chasm. Now if you don't want the toolset to show a red square when someone tries to place water next to a chasm the chasm has to be changed to forest terrain.

The rule would be:

Placed=Water

PlacedHeight=0

Adjacent=Chasm

AdjacentHeight=0

Changed=Forest

ChangedHeight=0

 

They can also be useful for terrains that can't be raised like water (there may be tilesets where raised water is possible, but in most cases it is not).

Let's say someone wants to place water next to raised building terrain, but those tiles do not exist. You have three options now:

Don't make a rule that changes the raised building terrain to a different one that works next to water. This will mean the builder will see a red square in the toolset when trying to place the water.

 

Make a rule that lowers the building terrrain next to the water. If there is another raised building terrain next to the one that is going to be lowered and you have no tiles with raised buildings next to lower buildings this won't work and the builder will still see a red square around the tile when trying to place water.

 

Make a rule that changes the raised building terrain to another raised terrain type that works next to water.

 

 

Since your forest terrain can be raised unlike water terrain in most tilesets you don't need any of the rules that say that raised High Forest should change lower High Forest to raised platforms like your rule 20.

All the rules in your set file in which 'adjacent' differs from 'changed' can and should probably be removed.

[Michael DarkAngel]

Just going to throw this out there.

 

Your problem may lie in the 2.5 height transition.  I ran into this when trying to do something similar with my unfinished Gentle Hills project.  It was something I never could fix.  It seems like the game cannot cope with fractions for the height transition, unless you duplicate all of the feature/group tiles to have one version at 0 and a second version at 2.5.  I vaguely remember the feature/group tiles being placed much like your previously posted image (floating above my half height hill terrain).

 

 MDA

[Lord Sullivan]

Just going to throw this out there.

 

Your problem may lie in the 2.5 height transition.  I ran into this when trying to do something similar with my unfinished Gentle Hills project.  It was something I never could fix.  It seems like the game cannot cope with fractions for the height transition, unless you duplicate all of the feature/group tiles to have one version at 0 and a second version at 2.5.  I vaguely remember the feature/group tiles being placed much like your previously posted image (floating above my half height hill terrain).

 

 MDA

 

Yeah, just tested it by changing the entry of 2.5 to 2 and it seems to want to function correctly, but it breaks the height slightly between features/groups tiles and "Raise/Lower" tiles.

[Zwerkules]

Changing the height difference from 2.5 to 2 or 3 will also fix the 'not a valid floating point' problem. It means you'll have to change a lot of tiles, but if you don't change them now you might have to change even more tiles later if there is no other way than changing the transition to an integer.

Since the 2.5 causes more than one problem even if one problem doesn't appear in English game versions it's best if you change it.

 

Edit: I tried a lot of raised platforms at four different heights and all the features and groups worked fine for me (with the transition height being 2,5). What happens if you change the 2.5 height to 2,5? Does this give you an error message in an English version or does it work?

[Estelindis]

Folks, it is looking like you're right.  I tried 2,5 and it gave me the error that you got for 2.5, Zwerkules.  However, when I tried 3, all the groups and features painted properly on raised terrain.  Looks like I'll have to change all my raised terrain.  It will be less work now than if I did it later, at least.

 

Thanks *so* much to everyone who took the time to examine this problem!  

[Pstemarie]

Folks, it is looking like you're right.  I tried 2,5 and it gave me the error that you got for 2.5, Zwerkules.  However, when I tried 3, all the groups and features painted properly on raised terrain.  Looks like I'll have to change all my raised terrain.  It will be less work now than if I did it later, at least.

 

Thanks *so* much to everyone who took the time to examine this problem!  

 

Maybe CM3 can simplify the task for you. Load the tiles in and have CM3 raise them to 3.0

[Estelindis]

No, PSM, the task is too selective.  It's only the border tiles that need work, and I don't believe that CM3 (wonderful though it is) has the capacity to see which bits need to be raised and which don't.  Thanks for the suggestion, though.  

 

I am getting the work done bit by bit; nearly finished the "3/4 raised" tiles.

[Shadooow]

No, PSM, the task is too selective.  It's only the border tiles that need work, and I don't believe that CM3 (wonderful though it is) has the capacity to see which bits need to be raised and which don't.  Thanks for the suggestion, though.  

 

I am getting the work done bit by bit; nearly finished the "3/4 raised" tiles.

A macro would help here, I made similar macro for the raised interior tiles I made. PM me if you want the code.

[Estelindis]

A macro would help here, I made similar macro for the raised interior tiles I made. PM me if you want the code.

Mmmmrmmm, tempted, but I really feel like the canopy of trees beneath the platforms needs to be handled by a human.  (I was really pleased when people said they couldn't see the raise, as that was my aim.)  Thanks, though!  

[OldMansBeard]

No, PSM, the task is too selective.  It's only the border tiles that need work, and I don't believe that CM3 (wonderful though it is) has the capacity to see which bits need to be raised and which don't.  Thanks for the suggestion, though.  

 

I am getting the work done bit by bit; nearly finished the "3/4 raised" tiles.

 

I could put a special tweak into CM3 for you, if you like, Can tell me how you know which parts to raise and which parts not? If you can explain it to me, I can explain it to CM3

[Estelindis]

 

I could put a special tweak into CM3 for you, if you like, Can tell me how you know which parts to raise and which parts not? If you can explain it to me, I can explain it to CM3

Woooo, fancy!  Well, to be honest, it sounds like more trouble for you than the trouble it would save me (especially since I've done a third of the work by now), but at the same time it presents an interesting exercise for me to describe the process accurately to you.  

 

Compared with a standard, flat tile, I want the treetops to rise according to the slope of the black plane beneath.  In the flat tile, they are not all exactly the same height above the black plane; there is some variation.  This just means that the ones at the raised corners/edges get raised by the amount as the corner of the black plane rises, the ones in the middle by about half as much, etc.  It doesn't have to be totally consistent, as long as no part of visible foliage dips beneath the black plane.  As well as this, the corresponding branches for four pieces of foliage need to be raised in a consistent way.  (Only four pieces of foliage are "supported" by branches; you know which has a branch by which foliage has the top part of the branch beneath it.)  

 

The result of changing the slope of the black plane, and also raising the foliage and branches in a corresponding manner, can be seen in the "plain" forest tiles (r01_01, r02_01, r02_02, and r04_01; didn't get around to the diagonals yet, which has turned out to be a good thing!).  In fact, to make things easier, I save the geometry from these plain tiles as scenes.  Then, when I'm raising parts of the tiles with platforms, I delete the existing foliage, low branches, and black plane, and merge in these items from the appropriate scene.  Then all that needs to be done is to raise the appropriate parts of the walkmesh, platform, and related geometry (decorative details for platforms, supporting trees if present).  If there are supporting trees, I need to make sure that they don't overlap with any foliage down below (so a bit of foliage might need to be deleted).  For that matter, the lowest verts of the tree trunk and branches, the lowest "circle" of verts from the objects textured with the gradiant texture "thf02_bark03," need to be below the black plane (but not very far below, as that would cancel out the effect of the gradiant texture, melding into darkness).  

 

I have quickly made a couple of pictures to help in my description.  The pictures compare a flat half-and-half platform/forest tile to one that is half raised (the raise division being perpendicular to the platform-forest division).  

 

 

 

To make the changes needed for the second tile, I would raise the rightmost edge (x coordinate 500) by 50 (my new raise is 3(00)), raise the foliage and branch bits at that edge by 50, those around x300 by 40, x100 by 30, etc.  Then the rightmost platform and its various accoutrements (i.e platform, trim, rail, and rail top) would be raised by 50.  The corresponding faces of walkmesh would be raised by 50 as well.

 

That's the best I can do to explain it at the moment.  It just seems reasonably finicky and not too hard for me to manage it myself.  I must add, though, that I appreciate your kindness in making the offer.  If it turns out that it will be easy for you to add this to CM3, then colour me surprised and very impressed!  

[Lord Sullivan]

Excellent! I still suggest you look over your rules once you're done. Just to make sure.

[OldMansBeard]

I think I can see a way to do it. At least, for the ground mesh, walkmesh and trees. Not sure about the platforms yet. I'll play around with the idea this evening, It's quite an interesting problem - I'd like to find some sort of solution. Of course, it might take me longer to get there than you doing it by hand.

 

(edit - update) I think it's working for ground, wok, trunks, branches and foliage. I've only tested it for the _r tiles in the alpha hak, though.

[Estelindis]

OMB, that's amazing.    All my raise tiles are prefixed with r, except for the few "a" tiles that are raised walkway, so you got nearly everything.  Had plenty of things to distract me this afternoon and evening, but was honestly expecting to get back to the tile raising tomorrow and finish it off in a few hours.  Very impressed with your ability to make CM3 do pretty much anything you want it to.  

[Shadooow]

To make the changes needed for the second tile, I would raise the rightmost edge (x coordinate 500) by 50 (my new raise is 3(00)), raise the foliage and branch bits at that edge by 50, those around x300 by 40, x100 by 30, etc.  Then the rightmost platform and its various accoutrements (i.e platform, trim, rail, and rail top) would be raised by 50.  The corresponding faces of walkmesh would be raised by 50 as well.

This is exactly what my macro (MAX Script you can run in gMAX 3DMax) does (to be precise, my macro changes each vertice, but it can be easily adjusted to raise/lower objects as a whole). So I really dont understand why you refused my offer and then encouraged OldsManBear to make this into CM3 where I feel this feature doesn't suit. Because once you want to raise by X once per Y and once you want to raise only corners and this is better to do in MAX rather than in external tool and then recheck the outcome... but whatever

[Estelindis]

This is exactly what my macro (MAX Script you can run in gMAX 3DMax) does (to be precise, my macro changes each vertice, but it can be easily adjusted to raise/lower objects as a whole). So I really dont understand why you refused my offer and then encouraged OldsManBear to make this into CM3 where I feel this feature doesn't suit. Because once you want to raise by X once per Y and once you want to raise only corners and this is better to do in MAX rather than in external tool and then recheck the outcome... but whatever

 

I meant absolutely no offence; I just understood what you said in a different way.  Either way, I didn't think it could be done.  However, after OMB asked me to explain what would need to be done, I felt that it would be an interesting exercise to put it into words (and a couple of pictures), even though I expected the result to be OMB telling me that it would be harder for him to add this to CM3 than it would be for me to just finish the work manually.  The fact that you've now said that your macro could do what needs to be done, and that OMB posted again saying that he could make most of the changes via CM3, shows me that I was really wrong in my estimation of how difficult this would be via software.  I guess my slightly different response to you both really comes from the fact that, even though I thought the software solution wouldn't work, I know OMB well enough to know that he'd enjoy trying to make it work regardless.  

 

Does that make sense?  I really didn't mean to annoy you and would genuinely be glad to try out that macro, now that I understand its capabilities better than before.

[OldMansBeard]

Este, I've played about some more, and I've realised there's a simple way to do it in 3dsMax. Doesn't need any extra software at all

• Select all the objects on the tile (except walkways)
• Apply a FFD 2x2x2 XForm
• Select the top and bottom control points for the relevant corner(s)
• raise them 50cm
• Reset XForm

What this does, is to distort all the meshes slighly but in a consistent way, so that ground, walkmesh, foliage and branches move together. As the twist is only a few degrees (50cm across 1000cm is less than 3 degrees) the distortions are almost imperceptible in the finished tile but it does the job.

[Estelindis]

Oh my gosh, OMB, you're right!  The really embarrassing thing is that I used that modifier a couple of days ago to achieve a different transformation on another model, but it never occurred to me to use it for the raise.  D'oh!    Thanks.

[Bannor Bloodfist]

A macro would help here, I made similar macro for the raised interior tiles I made. PM me if you want the code.

 

Hmmm... not sure, but I thought this forum allowed a code bracket set to allow you to post things directly here?  Something like this might prove useful to many folks. 

 

Just a suggestion.

 

Now, back to my dark hole which is where I should likely stay anyway.

[Bannor Bloodfist]

Este, I've played about some more, and I've realised there's a simple way to do it in 3dsMax. Doesn't need any extra software at all

• Select all the objects on the tile (except walkways)
• Apply a FFD 2x2x2 XForm
• Select the top and bottom control points for the relevant corner(s)
• raise them 50cm
• Reset XForm

What this does, is to distort all the meshes slighly but in a consistent way, so that ground, walkmesh, foliage and branches move together. As the twist is only a few degrees (50cm across 1000cm is less than 3 degrees) the distortions are almost imperceptible in the finished tile but it does the job.

 

That sounds like a useful routine for something like this.  Not sure if I would ever actually find a real use myself, but it is interesting nevertheless.  Thank  you for sharing  your mathematical genius with us.

[Bannor Bloodfist]

Oh my gosh, OMB, you're right!  The really embarrassing thing is that I used that modifier a couple of days ago to achieve a different transformation on another model, but it never occurred to me to use it for the raise.  D'oh!    Thanks.

 

Not entirely sure if I can really help much with this set, other than to possibly offer some sort of testing for you at some point.  Let me know if you wish me to play around with the set some.

[Estelindis]

Thanks, Bannor.    I have a bit more non-NWN stuff on the plate over the next couple of days, but when I finish all the raised terrain stuff I'll ask you to have a little look at it.

 

Eventually, I must get around to making more groups and features for this set, even though terrains and crossers are my "first love."  I feel like they help to make tilesets more versatile.  At the same time, though, the tileset needs more groups and features than what it has at present...

[Estelindis]

Long-overdue update: http://1drv.ms/1tXxsWc  Alternatively, try the project link in my sig.

 

The update consists of the following:

• Bugfixed raise/lower.
• Staircase feature (planning a few more versions of this, to work with the walkway crosser instead).
• Mountain and mountaintop terrains, based (with permission!) on Lord Rosenkrantz's Rocky Mountain raise/lower.
• Edge tiles for everything in the set so far.

Please let me know, in particular, if you come across any edge tiles that aren't working properly - but, really, any bug reports are fine (though they may well be of bugs that I already know about and already mean to fix).

 

Some notes on the new terrains (for which my thanks go out to Lord Rosenkrantz)!  Mountains paint onto High Forest.  However, because I have to start them quite low (the black plane beneath the trees sits at -600), they ultimately don't go up very high.  To get a second level, and some proper height, one needs to paint the Mountaintop terrain into the middle of the Mountains: that is, the Mountaintop terrain has to be completely surrounded by the Mountain terrain.  The idea is to work past the limitations that only allow one type of raise/lower: Mountaintop is raise/lower for the Mountain terrain.  The problem, of course, is that one can't have infinite layers of this pseudo raise/lower.  However, I don't think that the camera and draw distance of the game would actually allow many more layers to show themselves fully (each one is 2200 high), so this isn't too bad.

 

 

 

[Carcerian]

Thank you so very much!

 

(Due to friend's inquiry recently asked Estelindis if was still working on/had update for High Elven City only a few days ago, so definitely appreciate the quick response, and knows people will love having as an option now)

 

As a suggestion have you considered making an entry on NeverwinterVault.Org ?