Accessibility of a tile from other tiles

[Spixi]

Hi there,

I have a question about unit movement. As you see in the screenshot there are two parallel rails, which are not connected with each other. The unit can move to it, however. This should not be possible.

Is there any easy possibility to modify the movement, that it is only possible when there is an existing transition which connects these tiles? Are the applied terrain transitions accessible via Lua?

Writing an algorithm for this is very more difficult because the transitions also depend on the adjacent tiles of the adjacent tiles:

In this map, 1,2 and 1,3 are connected:

Code: Select all

      (1)  (2)

(1)        ^Br/
(2)   ^Br|
(3)   ^Br/

But in the following map 2,2 and 2,3 are not:

Code: Select all

     (1)  (2)  (3)

(1)            ^Br/
(2)  ^Br/ ^Br|
(3)       ^Br/

rails2.png (134.42 KiB) Viewed 2692 times

Thank you in advance for your ideas.

[zookeeper]

No, it's not really possible in any sane way. The engine is not at all designed to be able to do things based on which kind of tiles the terrain graphics system places on each hex.

If you absolutely needed to do something like that in a given scenario, then you'd have to hack it by using custom terrains or something in such a complicated manner that I don't even want to think about it.

[Spixi]

Ok.Those macros in data/core/terrain-graphics/internal-tracks.cfg are very hard stuff I don't understand. Thank you, nevertheless.

Small question: What does the preprocessor directive #meta-macro do? It is not documented in https://wiki.wesnoth.org/PreprocessorRef .

[Ravana]

Search shows it is only used in https://github.com/wesnoth/wesnoth/blob ... -macros.py , so not in general preprocessing.

Also, since it says !!! ONLY USE THIS IF YOU KNOW WHAT YOU ARE DOING !!! I doubt you need to use it.

[Spixi]

Search shows it is only used in https://github.com/wesnoth/wesnoth/blob ... -macros.py , so not in general preprocessing.

Also, since it says !!! ONLY USE THIS IF YOU KNOW WHAT YOU ARE DOING !!! I doubt you need to use it.

Thank you. I was only interested, because I tried to understand how the tile transitions work. But it seems to be just a hell of macros!

[zookeeper]

The meta-macros are just helpers for generating those big piles of variations of the same macro. Per every meta-macro, you should find (in the same file) macro definitions for all possible combinations of the lettered arguments of the meta-macro.

For example, this:

#meta-macro TERRAIN_BASE TERRAINLIST P=PROB=100 L=LAYER=-1000 F=FLAG=base B=BUILDER=IMAGE_SINGLE IMAGESTEM

Means that the above-mentioned script can generate all the actual macro definitions for all possible combinations of P, L, F and B, so one can just paste the output into that file without writing every one of those 15 possible variations by hand. But, as said, that's just a helper script for the kind of things that almost no one really ever needs to concern themselves with.

[Spixi]

The meta-macros are just helpers for generating those big piles of variations of the same macro. Per every meta-macro, you should find (in the same file) macro definitions for all possible combinations of the lettered arguments of the meta-macro.

For example, this:

#meta-macro TERRAIN_BASE TERRAINLIST P=PROB=100 L=LAYER=-1000 F=FLAG=base B=BUILDER=IMAGE_SINGLE IMAGESTEM

Means that the above-mentioned script can generate all the actual macro definitions for all possible combinations of P, L, F and B, so one can just paste the output into that file without writing every one of those 15 possible variations by hand. But, as said, that's just a helper script for the kind of things that almost no one really ever needs to concern themselves with.

Thank you. I see that tile transitions are a very difficult topic and that Python script fixed the lack of default parameters in Wesnoth's macro syntax.

I found another way, however. If I really need track vehicles in a UMC, I could rather use the Patrol Micro AI for this case.