...
| Info |
|---|
| The SET file specifically indexes everything tiles by tile index, not by name. |
...
Not all custom content has edgetiles. Not all tileset types can have fully functional edgetiles. And tilesets using edgetiles have a pattern of repeating tiles out from their edge that some builders do not like.
When edgetiles are used, they are indexed in a separate file from the SET file.
...
Edge tiles using the original content naming convention usually have row Z set aside for edgetiles. If you follow that convention, it will make finding edgetiles in your tileset hak HAK easier.
Edge tiles are not a requirement, and don't make sense in some situations.
...
Sourcelights are generally directional lights with a specific causative feature, like a torch or lantern or campfire on the tile. Sourcelights are also partially controllable with environment settings.
Sourcelights can also be bound to tile animations, so they can turn on and off by day and night settings, as well as activate and deactivate settings. For example, the forest tileset has torches and campfires that can turn on/off, allowing one tile to be used as multiple variants.
...
Including your own non-functional door dummies can help future SET file writers get the proper door positions.
Walkmesh and Walkmesh Rules
This is a separate mesh not seen by the clients. It guides units through the tile while within the tile's bounds.
...
There are many rules which apply to walkmesh construction, which can be very confusing:1)
Rule #1: A walkmesh should be very simple
. A mesh polycount of 100 is a good limit.
...
To compile correct AABB structures for more complex walkmesh, use a 3D editor program that is at least 64 bit.2)
Rule #2: A walkmesh cannot have more than eight faces associated with any given vertex
...
Most non-walkable face types do not count toward that limit, though you should still keep them to a minimum of 8 per vertex for future builders that might change your walkmesh surface types.3)
Rule #3: A walkmesh walkable portion must be single-planar non-complex
...
You cannot have multi-level walkable portions that actually work correctly. Any vertex from any face cannot therefore overlap any other walkable face. Non-walkable faces do not have this rule.
If you make multi-level walkable space in GMax, you will likely crash the exporter. In other programs, it may allows you to build the AABB structure, but units using that mesh will jump from level to level randomly.4)
Rule #4: A walkmesh walkable portion must point upward
. Downward facing walkable portions can crash GMax exporter, and will lead to jerking and hopping of players in the game.
...
| Info |
|---|
| Merricksdad uses surfacemat 21 "barebones", which prevents walking, blocks the camera, but allows a player to target the ceiling with spells and pathing. |
...
Rule #5: Walkmesh must be a single model node
. Supplying more than one AABB node in a model will have a lot of undesired consequences.
...
All previous rules still apply. No overlap of walkable faces and vertices. Only 8 faces per vertex. Etc.6)
Rule #6: Avoid straight vertical edges
. Straight vertical edges breaks the no-overlap rule. Even when one of the vertices are part of a non-walkable mesh, this can still crash the toolset or engine.
Any time you have a height change in the walkmesh, offset it on the XY plane at least 1 cm. on each axis.
Rule #7: Position at zero
7) A walkmesh should have its origin (aka pivot) set to the tile center (aka 0,0,0), sharing the exact position of the aurorabase node.
...
If the tile is a raised tile, this rule still applies.
Rule #8: No tile edge gaps
8) A walkmesh meant to allow travel off the tile must have an edge at exactly +/- 5 meters from the center of the tile. No decimal variation should be permitted.
...
In custom content, the A-node was also used as a method to force transparent textures to render above dynamic content, such as player models and visual effects. This allowed transparent walkable water, glass windows, and display cases.
During early EE versions, the A-node stopped working. It did not return until preview version 8193.35 [2070a8b9].
The new A-node functionality is similar to the old version with all the same uses. It allows stuff like static object glass transparency, transparent foliage, and water that does not block legsleg visibility.
To set up an A-node, simply make a dummy node with the same name as the aurorabase, suffixed with "a". Parent to the aurorabase dummy node.
Any mesh parented by the A-node will be rendered in the dynamic drawing phase after static meshes. This improves transparency ordering. It does require more processor time.
Note that visual effect particles are still blocked by A-node transparent objects except where those textures have Alpha layer = 0, and where the shader uses the "discard" command to open a hole in the texture.
| Info |
|---|
Meshes that fall under the A-Node in hierarchy will not respond to tilefade or keyholing due to draw order. |
Tile Water Options
Water on tiles can be either walkable or not walkable, as determined by the walkmesh.
...
Understanding SET File Parts
Path Nodes
Path nodes help help units move through the tile from another tile to another tile. These are used instead of the walkmesh on the tile, allowing distance pathing to see the tile as a single simple node in a route.
...
Shown below is an early river system subset by Merricksdad.
|
|
Notice in the river subset above, the river does not need to cross the tile at the tile edge center. It can be offset. However, in producing tiles like that, you then need extra tiles to snake the river across the tile, such as those shown with bridges.
...