On further modifications of the terrain system
Moderator: Forum Moderators
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
I don't see a reason to change how snow hills work. It's a hybrid terrain, but not a dual-layer one.SkeletonCrew wrote:I think this loses the ability to really define the move and defense rating which might not be an good idea. I'm not sure what's the best way to define snow hills for example is it easier to define snow on hills or hills on snow?Eleazar wrote:In all the terrains we have (or that i can imaging) the top layer is the controlling layer. In the terrain.cfg, the bridge definition would declare that a unit gets best def/mov no matter what is underneath. A village would might generally have best def, worst mov. A forest might ignore what's underneath for mov/def.
What i'm suggesting needn't change hybrid terrains, but could leverage it in a different way.
I'm not really interested in making new kinds of terrain (i.e. different move-types) but simply in making terrain look different, or in the case of hybrid terrains, switching out the lower component.mog wrote:All in all I really like the concept of independent overlay terrains, but we really have to be careful not to complicate the game. Maybe we should start implementing layers for the terrain wml first. This is a prequisite for the other stuff, mostly independent from it and really useful by itself.
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
-> What i might be working on
Attempting Lucidity
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
I think overlays only need to exist for the terrain-graphics.cfg and the base and combined in the terrain.cfg. Thus the overlays don't need mvt/def ratio since it's stated in the combined terrain.mog wrote:So we would basically have three types of terrain:Eleazar wrote:In all the terrains we have (or that i can imaging) the top layer is the controlling layer. In the terrain.cfg, the bridge definition would declare that a unit gets best def/mov no matter what is underneath. A village would might generally have best def, worst mov. A forest might ignore what's underneath for mov/def.
- Base terrains: defined in terrain.cfg, uses base layer only. (e.g. grassland, water, roads)
- Combined terrains: defined in terrain.cfg, uses both layers for graphics.
- Overlay terrains: always placed upon a base terrain. movement/defence alias rules can reference base terrain. (e.g. Bridges, maybe forests)
I'm not sure whether that's a good idea, IMHO the terrain system should only be used for terrains, WML already has the option to add these scenery items. Also if we would allow that the amount of terrains in the editor would explode.mog wrote:One could do without combined terrains, but they can be used for commonly used terrains (forests/villages). So one doesn't have place terrain twice for most of the terrains. They could also be implemented in the editor only by aliasing one base and one overlay terrain.
But for terrain-graphics.cfg wouldn't it be easier to access the separate layers directly eg letter_base and letter_overlay so the macro's are easier to define and you don't need to write down all the *'s every time?mog wrote:I already suggestes some syntax in this thread. Briefly:SkeletonCrew wrote: I agree that this might be really nice to have. I'm not sure what's the best way to access the individual layer parts, but maybe mog has a suggestion.
Match first layer: Abc*
Match second layer: +Xyz*
Match both layers: Abc*+Xyz*
This would keep backward compatibility for the most part, and if the maps use the proposed "Abcd+Xyzz" format it would be the most intuitive choice.
(The delimiter char can be anything not yet in use of course)
Well, as I said: *If* we want to do something like this, it should be for a later stage, after the WML work is done.SkeletonCrew wrote: I think overlays only need to exist for the terrain-graphics.cfg and the base and combined in the terrain.cfg. Thus the overlays don't need mvt/def ratio since it's stated in the combined terrain.
[...]
I'm not sure whether that's a good idea, IMHO the terrain system should only be used for terrains, WML already has the option to add these scenery items. Also if we would allow that the amount of terrains in the editor would explode.
And the editor would certainly need some changes to manage the additional terrains. On the other hand, placing scenery items via WML is quite tedious, especially ones that have no gameplay value but only add flavour to the maps.
I'm sure that having them in the editor would make maps more varied.
On the contrary. If there were two attributes for base and overlay terrain, one would have to rewrite most macros (and consequently, most terrain wml) to support both parameters, even though one of them would be almost always empty.SkeletonCrew wrote: But for terrain-graphics.cfg wouldn't it be easier to access the separate layers directly eg letter_base and letter_overlay so the macro's are easier to define and you don't need to write down all the *'s every time?
And you don't need the "*"s. They were only for example. Abc, +Xyz and Abc+Xyz would be equally possible. The only annoyance would be that you need to add the "+" for all overlay terrain, but compared to the alternatives, it's a minor issue.
Aurë entuluva!
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
I'll have a look at campgen soon to see whether it supports this.mog wrote:And the editor would certainly need some changes to manage the additional terrains. On the other hand, placing scenery items via WML is quite tedious, especially ones that have no gameplay value but only add flavour to the maps.
I'm sure that having them in the editor would make maps more varied.
Oke, then I think it can be done quite easy, I'll look into it after 1.3.1 has been released. I want to give the current system a little bit more test coverage before I start to change it.mog wrote:And you don't need the "*"s. They were only for example. Abc, +Xyz and Abc+Xyz would be equally possible. The only annoyance would be that you need to add the "+" for all overlay terrain, but compared to the alternatives, it's a minor issue.
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
SkeletonCrew wrote:I just noticed a small problem with the + and WML a + can only work between double quotes... I think I'll use the ^ as separator instead.
???
Out of curiosity what part of the code prevents the use of '+' in the terrain WML?
"you can already do that with WML"
Fight Creeeping Biggerism!
http://www.wesnoth.org/forum/viewtopic. ... 760#131760
http://www.wesnoth.org/forum/viewtopic. ... 1358#11358
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
The part that changes the following WML (see commit 15655)Darth Fool wrote:SkeletonCrew wrote:I just noticed a small problem with the + and WML a + can only work between double quotes... I think I'll use the ^ as separator instead.
???
Out of curiosity what part of the code prevents the use of '+' in the terrain WML?
mvt_alias=+,Uu,Ql
to this WML as seen by the terrain code
mvt_alias=,Uu,Ql
It might be possible to fix this problem, but I've no idea how much code depends on this 'feature'. For strings it makes sense eg "foo" + "bar" = "foobar" but with other things not. So I'd rather avoid the + and thus the problem.
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
I'll start with this somewhere next week, so here's a final proposal:
Terrain strings can be made out of 2 parts separated by a caret(^) these parts will be the same as the currently implanted terrain strings. If the second layer is not used it's not required to enter that layer. All terrains have a first layer.
The matching rules will be the following:
The * matches the following characters on a layer and if no layer separator is used it will match the following layers as well, so A* is the same as A*^*. This way backwards compatibility will work, also if we later decide that 3 layers are required.
eg
The code will internally use 2 u32's so the matching filters can still be pretty much the same as they're now which will help the processing speed of the matching routines. Also if a third layer is required the code can easily be changed for the third layer.
Terrain strings can be made out of 2 parts separated by a caret(^) these parts will be the same as the currently implanted terrain strings. If the second layer is not used it's not required to enter that layer. All terrains have a first layer.
The matching rules will be the following:
The * matches the following characters on a layer and if no layer separator is used it will match the following layers as well, so A* is the same as A*^*. This way backwards compatibility will work, also if we later decide that 3 layers are required.
eg
Code: Select all
A* matches Abcd but also Abcd^Abcd
A*^* matches Abcd but also Abcd^Abcd
A*^ matches Abcd but *not* Abcd^Abcd
A*^Abcd does not match Abcd but matches Abcd^Abcd
^* invalid since it will only match terrains with a second layer
Just to make sure:
will be possible? Because this is the main usecase.
Otherwise it looks good.
Code: Select all
*^Abcd matches Abcd^Abcd and Xyz^Abcd
Otherwise it looks good.
Aurë entuluva!
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
Yesmog wrote:Just to make sure:will be possible? Because this is the main usecase.Code: Select all
*^Abcd matches Abcd^Abcd and Xyz^Abcd
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
I added support for the layers, not much tested yet
It enlarges the glitch that terrains at the edge of the screen don't get drawn properly. The top row no longer draws overlays eg villages and forest only have a base terrain. Since this problem is next on my todo list anyway I don't bother with it too much right now.
It uses a 64 bit datatype which might not be supported by all compilers so I added a compatibility header but can't test that since my compiler supports 64 bit integers.
It enlarges the glitch that terrains at the edge of the screen don't get drawn properly. The top row no longer draws overlays eg villages and forest only have a base terrain. Since this problem is next on my todo list anyway I don't bother with it too much right now.
It uses a 64 bit datatype which might not be supported by all compilers so I added a compatibility header but can't test that since my compiler supports 64 bit integers.
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
very cool
i'll be all over testing this after i finish unpacking. (i moved last weekend.)
i'll be all over testing this after i finish unpacking. (i moved last weekend.)
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
-> What i might be working on
Attempting Lucidity
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
Yes. Otherwise we could only use the features of the layer system for new terrain. Which would make it quite useless as we couldn't cleanly generalize the terrain in base/overlay. And the WML would become more complex instead of simpler.SkeletonCrew wrote:Does porting mean that existing terrains get new names, since that would break compatibility.
I made a rough port of the terrain files, and apart from the bugs you mentioned it works extremely well. I made villages, forests and bridges overlays and it really makes the WML much simpler (especially the TERRAIN_ADJECENT lines).
Aurë entuluva!