ToME Wiki
Background
As I see it at the moment, things are going more and more towards lua generation of things, especially with the advent of ToME 3.0. However, there are certain limitations to lua generation of various things, especially when it comes to the wilderness. -- TheFalcon
Thoughts
In some scripts I've been working on recently, and something I've noticed with certain scripts by other people: there are a few flaws with generating such things as roads, rivers, or any other features which change the terrain near the edge of the map.
For example, with a (as yet hypothetical) script to create a set of "proper" rivers. A number of functions would be called, to replace the actual terrain of parts of each wilderness square. The main problem with this is not in the difficulty of coding a full set of river shapes, but in the restrictions upon the squares themselves...
Namely, that although one can replace features when the player is actually on the square in question, if the player is in an adjacent square, there will be no change to the edges of the map. For a river script, this means that there will still appear a river, but it leads up to an edge which is the same as the underlying terrain defined by the wf_info entry. This reduces, almost crippling the visual effect of any linear feature coded which traverses more than one wilderness square.
In order for lua scripts to work properly in wilderness generation, it would therefore be necessary to call the script for an adjacent square's generation as well as simply calling the wf_info coded wilderness, or any towns. The trouble is that at the moment the script itself for wilderness generation has, AFAICT to be done through finding if the player is on the square in question. The difficulty is of course, that the player is not on the square in question, or the problem would not arise. I can see no easy way out of this.
Thus effectively, ATM, the game limits wilderness generation to square blocks, and non linear features, and this rather limits attempts at beautification. :/
Chatter/Ideas/Comments
NeilStevens: When you say you've been working on things, were you working in ToME 3?
TheFalcon: No, 2.3.x. I'll expand this more tomorrow, I've been away for a while, sorry.
[later...] Is there a difference, then, between the actual generation of the wilderness in 3.0 and that in 2.3.x? Also, will there be more "town slots" available (though I see putting in features that way as rather clumsy)?
[later still...] I looked at the CVS and it looks like nothing much has changed. I may be wrong though...
I assume there are more town slots available (i.e. as many as the module needs), though I still don't like that way of doing things.
NeilStevens: Nothing's changed in ToME 3 because modules have had the ability to include their own level generators for months.
TheFalcon: You mean completely luafy the wilderness? Including the way the edging is done? Errm, and how would I go about such a feat? o_O 
NeilStevens: You can write your own level generators. The point of it being your own level generator is that how you generate the map is entirely up to you. You can store whatever extra data you want, remember whatever you want, pre-generate neighboring maps as you wish, anything. That's my understanding anyway.
TheFalcon: Umm!! I shall experiment as soon as I can get a ready-compiled CVS version. I expect I'll just cause really horrible crashes, but anyway...
Will I have to completely sever the player from C-style mappings if I try to pre-generate neighbouring maps? That would mean (presumably) putting in lua code for actual wilderness terrain generation etc.? I can (vaguely) conceive how to go about doing so, but I'm not exactly experienced in this kind of thing.
With reference to 2.3.x, I assume that kind of change to luaing the wilderness is fairly out of the question?
NeilStevens: I just checked, and HOOK_WILD_GEN exists in ToME 2. What your limitations are in using it, I don't know, but you could probably get what you want with enough effort, heh.
TheFalcon: I'll play around a bit and see what I can do. It's not really worth my effort to do to much in this area yet though. I should really be working on getting Annals playable before I try putting in random lua scripts...
I suspect I'll wait a bit on this, but thanks for the advice anyway.
TheFalcon: I got bored with waiting... 
Through experimenting, using HOOK_WILD_GEN, it seems that it is not possible to alter the "border" grids in any way, using cave_set_feat, or cave(y,x).feat =... . Any other feature in the map can be changed, but if you try to go onto the borders or beyond, the game *will* crash. Interestingly, it is possible to light or darken the border grids, using cave(y,x).info =...
NeilStevens: Contact DG about your need for border control then, heh.
TheFalcon: I think I will. I did manage to change the corners of a wilderness area once, but that was it, and afterwards the game *Crashed* (i.e.fatal, need to reinstall crash).
[later...] I emailed DG, but no answer yet. I suspect it may take some time...
Actius: Aren't the borders obtained from the neigboring wilderness tile? Why not work on the adjacent tiles?
TheFalcon: Yes, they are obtained from there, but it will only take the C coded terrains, not any lua generated ones I add afterwards. I have since found out how to change the borders though... http://wiki.t-o-m-e.net/TheFalcon_2fWilderness_20Hack