-
Notifications
You must be signed in to change notification settings - Fork 1
Automapping
It is automatic mapping. Automatic explains this way: It delivers you a rule based support to automatically setup some layers, most often some standard ground layers. So the goal of AutoMapping is, that you only need to draw within one layer and everything else is setup for you. This brings some advantages:
- working speed - you need less time to setup a map.
- less errors - the main reason is to reduce the error rate. If you have setup the rules properly, there is no hidden error.
Automapping explained(Youtube)
The AutoMapping feature will check some special layer you draw in. And whenever there is a change, it will be checked if any rule matches and if so this rule gets applied at the correct position.
A rulefile is a standard map file, which can be read and written by tiled. In one rulefile there can be defined multiple rules.
Some map properties can be set to make AutoMapping more powerful:
- DeleteTiles - This map property is a boolean property: it can be true or false. If rules of this rulefile get applied at some location in your map, this map property determines if all other tiles are deleted before applying the rules.
- AutomappingRadius - This map property is a number: 1, 2, 3 ... It determines how many tiles around your changes will be checked as well for redoing the AutoMapping at live Automapping.
- NoOverlayingRules - A rule is not allowed to overlap on itself.
'''''introduced at 0.8.0'''''
A rule consists of three different things, strictly divided as in the Input-Process-Output model. The input section in this context is called rule_region. It defines a region in which the rule is processed. This region can be of any form such as a rectangle, circle and so on. To define a rule_region for a rule, you need to have a tile layer called 'RuleRegions'. Each region is described by coherent equal tiles. (It does not matter which kind of tiles are used here, just make sure they are all equal. So even transparent tiles would work, but it actually sucks, because you will mess it up!)
The processing of a rule is quite simple: For all positions in your working map it is checked if there is shape of rule_region, at which the rule applies. To see if the rule applies the set layer of the working map is compared to the ruleSet and ruleNotSet layers of your rule map. If there is a match then the rule_output is copied over from your rulefile to the working map. To decide if it is a match or not, it is necessary to describe what is desired in an exact way. It is done in the rule_condition section. The rule_condition section consists of the layers 'RuleSet' and 'RuleNotSet'. There can be multiple layers of each.
All Layers Rule_* of the rulefile will be copied over to the working map if the rule matches.
This naming convention is used:
- a working map is a map which you are working on, i.e. that will be the map of your game afterwards.
- a rulefile is a file where some rules are stored.
- a rule is the combination of a rule_region, a rule_condition and a rule_output
- a rule_region is a region defined by coherent equal tiles in a rulefile in a layer, which is called 'RuleRegions'. It describes the region, where the rule_condition and rule_output are taken from.
- a rule_condition is found in a rulefile in the layers, which are called 'RuleSet' or 'RuleNotSet'.
- a rule_output is found in a rulefile in layers, which have the prefix 'rule'.