FAForever Forums
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Login
    1. Home
    2. IndexLibrorum
    Offline
    • Profile
    • Following 0
    • Followers 1
    • Topics 3
    • Posts 353
    • Groups 2

    IndexLibrorum

    @IndexLibrorum

    Global Moderator
    310
    Reputation
    105
    Profile views
    353
    Posts
    1
    Followers
    0
    Following
    Joined
    Last Online
    Website github.com/IndexLibrorumProhibitorum

    IndexLibrorum Unfollow Follow
    FAF Association Members Global Moderator

    Best posts made by IndexLibrorum

    • Index Librorum's Maps, assorted projects, and Gaea tutorials

      I'm Index Librorum (aka Prohibitorum), and this is a showroom for my maps and other projects.

      For most of these maps, the terrain, map-wide assets, and stratum masks are made using Quadspinner's Gaea. For questions related to my workflow, contact me on discord or here on the forums. (though discord will get you a reply significantly faster)

      Gaea tutorials

      All tutorials may also be found on the FAF wiki.

      • Basic introduction to Gaea and how to use the program to create a heightmap for FAF maps
      • Producing terrain masks in Gaea
      • Texturing in Gaea

      All projects:

      Project Mesa, Project Situs Impactae, Project Praetensus, (Adaptive) Project Dust, Project Tabula, and Project Luminary, Adaptive project Luminary Maxima, Project Albus, Project Vortex, Project Fluxus, Project Mesa HD, Project Tumulus.

      Maps overview.png
      Unless otherwise mentioned, all maps shown here are in the vault.

      Latest Project:

      Tumulus.png

      This newly discovered garden world would be a great place to start a new farming colony, commander. Secure it for us! // Licensed under CC BY-NC-SA 4.0. This map is AI compatible.

      Click here for more information on Project Tumulus.

      posted in Mapping
      IndexLibrorumI
      IndexLibrorum
    • RE: The End of FAF

      A long post, I'll try not to get too wordy. (Edit: I failed)

      FAF in decline: your core argument

      Thing's don't grow forever, and gaming communities have a tendency to stagnate and decrease over time. FAF has not been different, but is special in that we continue to have a large core of active players. I agree with you that we need to do our best to keep that going. I disagree with most of your suggestions on how that should be done.

      Your core argument, that the rest of the post is based on, is your belief that competition and connection issues are not the largest cause of players leaving, but that many people are not happy with how the game is being run. You specifically mention moderation as a problem.

      I think you are in an environment where you hear a lot of grumbling of likeminded players that has given you that impression. I think that impression is wrong. A significant majority of games in FAF are PvE games: skirmishes against AI or Co-ops. Almost none of these players are affected by moderators, because these games do not spawn tickets. Similarly, the vast majority of the playerbase (PvE and PvP alike) isn't active in the discord or the forums, and never hear from a moderator. If those people leave, it is because of them losing interest, finding another game, or having issues with FAF.

      I will try and get the relevant statistics for you.

      Selfish moderation

      I'd start with saying that reviewing tickets for games that a mod has themselves not played in is inherently non-selfish, given it requiring quite a bit of volunteered time. However, I will understand your point as specifically about particular moderator policies, and having issues with particular individual moderators.

      This is does not mean every moderator is selfish but I feel it necessary to call out moderators who became moderators because "their reports weren't doing anything" or because they wanted a certain policy enforced harder

      If you want to call out specific moderators, then be specific and call them out. I've recently mentioned in my post here that "I signed up to the modteam about half a year ago to help clear the massive backlog of reports we had, because I was annoyed by how my reports seemingly had no effect.". I'm assuming this is what you are referring to.

      I'm struggling to see how "I want to join the moderator team to help clear the backlog" is in any way selfish. Are you misunderstanding what I mean when I said "my reports had no effect"? I do not mean that my reports didn't have the effect that I wanted, it means that the reports were never addressed. I had one or two reports in the system that hadn't been looked at in more than half a year. I joined the moderator team to solve that issue. And we have, the backlog is now clear. Most tickets are now seen by a mod within 24 hours. None of this is selfish.

      These moderators often lack seniority and understanding of the game but most importantly they do not represent the high level community because they have never played with them.

      Some info about how the modteam works.
      • We do not consider seniority relevant: all the mods generally have an equal voice, with the exception of Teamlead/Headmod Giebmasse.
      • None of the mods specifically represent a particular part of the community.
      • Changes in rules, or discussions on how rules are applied, are internally discussed without regard for seniority or community status and require consensus within the team. For some changes this is easy because most mods agree. With others this requires several weeks of discussion. In the end, no moderator policy is enacted by any single mod.
      • If a player receives a ban, they can appeal it by email to [email protected]. Appeals are received and handled by Giebmasse, and where necessary internally discussed with the whole modteam. The moderator who initially handled the ban does not have a stronger voice in this discussion than any other member of the team.
      • If a mod is not sure about a decision, they check with the team for a second opinion. This happens frequently.

      Because of these points, it is very very difficult for any given mod to take action on anything without the rest of the team approving it. For the 2100 tickets that I've cleared in the past 6 months, I can think of maybe 3-5 situations in which an action was overturned. This also means that:

      banning and censoring players who use words that individual moderators do not like

      is simply not how things works.

      Unpopular policies

      Three policies in particular are called out:

      • Base Ctrl-K
      • Censorship (Or as the mods call it: moderating verbal abuse and basic civility)
      • Username changes

      Base Ctrl-K

      General background info:

      The position of the moderator team is that killing your whole base is griefing. If you believe the game is over, you may vote for a recall. If your team disagrees and you really do not want to continue a game because you're tilted or believe the game is lost, you can leave the game. This is with the understanding that this is infrequent: players that leave in the middle of a game consistently might be considered griefing as well, although this is mostly applied for people that leave very early. We prefer people leaving over the verbal abuse and toxicity we sometimes get reports for when tilted players stay, though.

      The reason why we have this rule (and this rule is, as far as I know, ancient), is that destroying your whole base forces your team to lose. When you start a game, you agree to play a game. This means that you play it until one team has won. If you cannot convince your team that the game is lost, by starting a recall vote, then your team clearly signals that you are wrong and/or they want to continue to play. It is not your right to decide for the rest of the team that they need to stop playing.

      This is most common at the high level but can happen in lower level games.

      This is incorrect. Base Ctrl-K happens at all levels of play.

      Players mainly base control k to stop someone from playing on when the game is clearly lost and everyone wants to play the next game but someone is refusing to recall.

      See above. The recall system works on a vote system, and only in small teams is it possible to have 'one' (1) player that can block the recall. If you think this system needs to be changed to that it's easier to recall, write a forum post about it; it doesn't have to be a thesis. You'll likely have my support.

      Regardless if you disagree with me the problem with this moderation policy is that the vast majority of the high level community is perfectly fine with base control k. ... In the high level community almost no one reports for base ctrl k or flaming because in general these things do no bother us.

      And if you play games exclusively with people who are in favour of others Base Ctrl-K'ing, you won't hear a peep from the moderators. We do not go through games from high rated players to look for offenses: we only act when we have received a report. Similarly, we generally discard reports by players who have not taken part in the game themselves. We have in the past had players that were looking for offenses of specific players by going through their replays, and we do not accept that behaviour. However, when you play with people who do not agree with you base Ctrl-K'ing when you decide you're done playing, then you will have to take their opinions into account. Which means following the official FAF rules.

      high level community believes it should be legal and they are completely ignored by the moderation team which has greatly angered players and has caused several to quit.

      Rules can be changed if there's enough support for them. I do not remember seeing a forumpost about wanting to change this rule, but I may be wrong.

      Censorship (basic expectations of civility)

      We have, since forever, community rules. These rules include rules on speech. I do not believe that a basic level of civility is beyond what we may expect from our community. These rules are widely supported: from the top of my head I estimate that about a quarter to a third of reports we receive are for verbal abuse. People say some genuinely vile stuff when angry, and people rightfully expect that the moderators take action on it.

      These rules are also enforced in our discord. Arguments, disagreements, and being angry with other players are all a part of having a large community, and do not need moderator action. However, we expect players to be civil to each other. We take action against bullying of new players, against slurs, against racism, against homophobic language, against death threats and wishing death upon players or their family. These examples happen often and frequently: we get tickets several times a week. Exactly what language is acceptable and what isn't remains an ongoing topic of debate. There are no clear lines here, because every person has their own idea on what counts as verbal abuse. Similarly, the opinions in the moderator team vary widely. We have found a balance that we believe is fair.

      As with all things private, we do not care about private conversations. We do not look for offense wherever we can find it: we only moderate games that are reported to us, and moderate the public community channels. These channels include Aeolus and the official FAF discord. What you say and do outside of these channels is not our concern. The public channels, however, are a place for ALL players, which means we maintain a certain standard; within them you are expected to follow the community rules.

      These rules are not new, and are not particular to FAF. Every single large gaming community has these or similar rules.

      The username rule update

      The discussion regarding these changes is ongoing. See the relevant thread for our arguments and viewpoints. We are still taking in feedback and continue to discuss the matter internally.

      None of the feedback was ignored, several changes have been made.

      Response to suggestions on changes to the mod team

      Higher standards for the acceptance of moderators.
      I propose that Moderators have at least 1500 games at least 5 years of experience and for new moderators to have had at least 100 games in the past year before they are accepted. A possible minimum rating could also be discussed.

      New moderators are added to the team very rarely. Their admission is voted on, and their background is vetted for previous bans and offenses. I do not believe stricter guidelines are necessary, but don't have a strong opinion on this. 5 years experience seems excessive however, especially given the median account 'age' likely being much lower than that.

      I also call for some form of immunities for high level members of the community as well as senior players that are not as high rated but have thousands of games.

      I do not believe that we will ever implement changes that favour one group of players over the other, for the simple reason that seniority does not give you a pass to be a dick. If you wish to be immune to the general FAF rules, you may host your private games with people that are similarly not in favour of specific rules.

      When you play with the larger community, you will be expected to follow the rules of the larger community.

      Lastly I call for the ability to hold some kind of referendum to fire unpopular moderators.
      The premise that a moderator can do whatever they want with no accountability must change.

      Your premise is wrong: there is no situation in which a moderator can do whatever they want. As explained, no single moderator acts alone. Neither does a moderator have immunity: the team lead is at any point in time able to remove a moderator from the team. Possibly (I am unsure of this) the board is as well.

      Firing based on popularity is also not likely to ever become a thing, for obvious reasons: people mostly interact with moderators when they get a ban. People who get a ban are most often unhappy with the ban. This means moderators get unpopular.

      Moderation, and moderation policies, are not about popularity, they are about being necessary and/or right. I believe this is one of the reasons why the discussion about the rename policies has been so ineffective: one side is arguing the change is not popular, while the other side is arguing that the change is necessary. They are two different conversations.


      I'll see about finding the data on new players, active games, number of mod tickets, and bans handed out over time. I think it'll be useful.

      posted in General Discussion
      IndexLibrorumI
      IndexLibrorum
    • RE: Index Librorum's Maps, assorted projects, and Gaea tutorials

      Tabula.png

      Well this is embarrassing. We were supposed to drop on the other side of this plateau... Looks like the enemy is already setting up bases there too. Kindly remove them so we can pretend this mistake never happened.

      Project Tabula is a 20x20km map, although the main playing area is closer to 15x15km. Eight commanders may be spawned on top of a large plateau, which has a partial collapse in the middle effectively creating three main lanes. Access to the terrain beyond the plateau is blocked; although planes may use the airspace, units can not be dropped outside the plateau.

      This is the first of my maps that uses clouds. Feedback on this feature in particular is highly appreciated.

      The map is licensed under CC. BY-NC-SA 4.0 and is compatible with AI.

      image.png
      image.png
      image.png
      image.png

      posted in Mapping
      IndexLibrorumI
      IndexLibrorum
    • RE: Index Librorum's Maps, assorted projects, and Gaea tutorials

      Gaea tutorial: A basic introduction to mapping with Gaea

      The various map projects I've made have all been made possible by Quadspinner's Gaea, a terrain design application for VFX and games. Gaea is an industry standard and a great tool to significantly speed up creating or increasing the complexity of masks, heightmaps, and decals. Because of FAF's peculiarities and the fact that the game is more than a decade old, the process of producing these assets using Gaea is a bit involved. Being the shiny beacon of enlightenment that I am, in this tutorial series I will explain my process for creating all the relevant map assets in gaea (see figure 1). This specific tutorial will discuss the basics of Gaea and how it can be used to create the main heightmap for your terrain.

      2c3a4033-9450-4b1d-90da-d68c32d1d617-image.png

      Figure 1: a breakdown of the map Project Luminary to show all the assets generated in Gaea. Note: some of the stratum textures are stock-FAF textures and were not created in Gaea, but are here included to illustrate the different components of the map.

      Prerequisites

      This tutorial assumes you've got a basic understanding of image editing and FAF mapping. Additionally, while this specific tutorial will explain some of the basics of visual node based programming, the technique Gaea uses to create the assets, it is recommended that you take some time to familiarize yourself with the concept and Gaea in particular. This 6-minute video is highly recommended, as is giving the general documentation for gaea a read. Using this node system may look daunting at first, but is very intuitive and easy to learn.

      Required tools

      Required for this tutorial is a copy of Gaea (the indie version is free to use and more than sufficient for maps up to 20km), which can be downloaded here. Additionally, an image editor such as Photoshop or Gimp is required, though the free to use online photoshop-clone Photopea works fine too. Finally, you need to have installed the FAF map editor.

      Footnotes marked as '[0]' where needed. Notes are added to the bottom of the tutorial.

      When specific nodes are referenced, they are highlighted like this: Node. Specific parameters for these nodes are written like this: Slope, 30, 90, 0, to specify a Slope node with Parameters 30 (min), 90 (Max), and 0 (Falloff).

      Introducing Gaea

      Gaea is a graph-based application for creating terrain and focussed on providing techniques to simulate realistic erosion. To create these terrains, different nodes are linked to eachother. Nodes affect or combine with other nodes to create complex shapes and structures. While working in Gaea, you will navigate between several panels.

      The workspace

      As of June 2023, a typical workspace in Gaea might look like Figure 2. The workspace can be configured to your preferences, with different panels moved or scaled. The largest part of the screen is taken up by the viewports and the graph surface. The viewport shows you the terrain and masks, the view of which can be rotated, scaled, and panned. Optionally, you can press the 2D button in the viewport toolbar to show the second, top-down, viewport. Below the viewports, you will see the graph surface, where your nodes and their connections are displayed. Clicking on a node will show the contents of that node in the viewports.

      ! Tip: you can lock the viewport to show one specific node by selecting the node and pressing F on the keyboard. The node will be marked with a small green circle on the bottom right of the node to indicate the viewport is locked on that node. This is very useful when you are adjusting parameters of nodes earlier in the chain, but want to see the result on a specific node later in the chain. Press F again while selecting the node to unlock the viewport.

      9dd641bc-e438-41d7-9e69-d0721349a7af-image.png

      Figure 2: Typical workspace of Gaea. Colored accents added to highlight the different panels. Red: Main toolbar. Orange: Toolkit containing various nodes. Yellow: Viewport, 2D viewport, and viewport toolbar. Green: Graph surface. Blue: Properties panel.

      The toolbox contains all the nodes you can put onto the graph surface. Nodes are grouped by type, and have a specific colour to signify which group they belong to.
      Clicking on a node will also reveal the properties panel for that node. Here, you can adjust the effect or contents of the specific node.

      Above all the other panels is the main toolbar, which contains a few important things to discuss. First, the viewport resolution can be selected in this panel. It is generally recommended to select the resolution that you will be exporting your heightmap in. Gaea recalculates the terrain and parameters of the nodes every time you switch resolution, and the resolution can drastically affect how the terrain is shaped. Aside from the obvious increase in fine details, you might find that elements have changed shapes or moved when comparing different resolutions.

      ! As the terrain changes based on the resolution it is rendered in, creating high-resolution map-wide decals might result in some mismatch between the heightmap and the decals. A method to prevent this will be discussed in the tutorial on map-wide assets.

      ResolutionDifferences.png

      Figure 3: Showing the differences between the viewport at 0.5k, 1k, and 2k resolution. Note the increase in fine details.

      Another important section of the main toolbar is the save button. Attached to the save button is a smaller button labeled with (+). This button will create a version-copy of your project: if a project is named 'Project Luminary V1', clicking this button will create a new savefile labelled "Project Luminary V1001". The next time you click the button, the new savefile will be labelled "Project Luminary V1002". I cannot stress enough how important it is to regularly create a new version. Since before I started using Gaea, the undo and redo buttons have been rather dysfunctional. Maintaining a recent version of your project will ensure you do not lose large sections of your work when you inevitably have to undo changes that the undo-button refuses to process. Note that the save-files Gaea creates are very small: do not hesitate to create new savefiles.

      Nodes and graphs

      As mentioned, nodes are sorted by type and colored accordingly. Generally, basic nodes that create a type of terrain are green. Nodes that transform or adjust other nodes are generally light blue or teal. Nodes that apply erosion or aggressively 'damage' terrain are light or dark orange. A different, darker shade of orange is reserved for Data nodes, which are nodes that can be used to mask or select parts of the terrain based on certain parameters. When creating textures, the purple nodes will allow you to work with colour.

      Nodes often have one or more inputs, and one or more outputs. A Combine node, for example has three inputs and two outputs. Hovering over the little dot marking the node's in- or output will show the name of the port and indicate whether or not a connection is required for the node to function. Ports that need a connection have the same colour as the node-type, while optional ports are grey. Additionally, many ports have a designated input for masks. Adding a node (A) to the mask-input of another node (B) allows you to restrict the effect of node (B) to the specific area determined by node (A). Connections to a mask-input are always coloured purple, to indicate the type of connection.

      Nodes that are improperly connected will have a red-dotted border and display the text "error". A node that has not been rendered yet will show as a blue-dotted bordered node. Clicking on this node (and, if required, un-locking any previously locked nodes from the viewport) will prompt Gaea to calculate the effect of the node and display its contents. Nodes that are selected will be marked with a blue glow. The node will then turn into a solid-bordered node, or if failed, be marked with an error.

      ! Sometimes, Gaea runs into an error that it refuses to get unstuck from. In most cases, it suffices to select the whole graph and press the 'Force a Refresh' button at the right bottom corner of the graph surface. If this does not resolve the issue, double check your connections (a common mistake is to connect to a secondary input rather than a primary input) or restart Gaea.

      0d35f143-328e-4ad1-a921-75d2f7227a5b-image.png

      Figure 4: A properly connected and selected node, an unrendered node, and a node that was rendered but produced an error. Note how the first node has three inputs, one of which is a mask, and one output.

      Node parameters

      Each node has a particular set of parameters that can be adjusted to change the result of the node. Some of these have obvious effects: the Height parameter for the Constant node affects the height of the flat plane that the node generates. Common parameters include Scale and Seed. Seed in particular is a very powerful parameter common to nearly all nodes: changing the seed value randomizes the noise used to generate the effect of the node, which changes the outcome significantly (see figure 5). Other parameters are less intuitive, and require some experimenting to understand how the node is affected.

      DifferentSeeds.png

      Figure 5: Four copies of a mountain node with identical settings but different seeds.

      Creating a heightmap for FAF

      Creating your first terrain

      Primitives

      Whether you have a design in mind or are hoping to combine nodes until something presentable falls out, you're going to want to start out with one of the primitives. This category of node is coloured green and serves as the basic building blocks for your terrain. Half of this category consists of 'plain' primitives: the Constant node produces a flat plane, the Gradient node produces a ramp or a cone. Different types of noise generators are included as well, such as Gabor, LineNoise, Voronoi, and Multifractal.

      Primitives.png

      Figure 6: A selection of primitive nodes: Constant, Gradient, Gabor, and MultiFractal.

      Geo primitives

      The other half of this categories includes more complex presets of common terrain features. Among these Geo Primitives you will find nodes such as Badlands, Crater, Mountain, Canyon, Dunes, and Island (figure 7). Many of these advanced nodes can be recreated by combining 'plain' primitives, but as they are rather complex it is often easier to use the Geo primitives.

      GeoPrimitives.png

      Figure 7: A selection of geoprimitive nodes: Badlands, Dunes, Crater, and Canyon.

      Adjustments Nodes

      To start adding things together, you'll need some nodes from the next main category: the adjustments nodes. The Combine node does what it says on the tin: you can combine two different nodes into one using different blending modes and strengths. Figure 8 shows the result of blending the Badlands node and Crater node from figure 7 together using four different blendmodes.

      Combine.png

      Figure 8: Blending Crater and Badlands using the blending modes Embed, Subtract, Divide, and Insert.

      The other be scaled, rotated, and repositioned using the Transform command, while the Clamp node gives you good control over the global height of the terrain.
      In my map Project Mesa, for example, I created the basis for the various pillars using a Gradient, Radial node, which I then repositioned and rescaled using the Transform node, and merged with the main terrain using a Combine, Embed node.

      Erosion Nodes

      Once the basic design of your map has been established, you might want to take a look at the various Erosion nodes. These nodes create rugged looking terrain, simulating decay over time from exposure to the elements. They can be applied to separate elements if you are combining multiple elements into one whole, be limited to specific areas using masks, or can be applied to the whole terrain at once. The Wizard node is a powerful erosion node with many presets that will be adequate in most situations (figure 9).

      I want to caution against using Erosion excessively; units in FAF do not like rough terrain: it messes with pathing and blocks shots. While erosion adds lots of detail to a map, consider that the main areas that units fight on should be smooth and relatively flat whenever possible. Naturally, this is of no concern in areas that are limited to air or navy only.

      Erosion.png

      Figure 9: A mountain and three variants with progressively stronger and more aggressive erosion (Wizard) applied. Note the formation of fine details, debris, and lots of sediment.

      Modifier parameters

      The properties panel of all nodes contains a set of buttons at the bottom right that allow for common modifications to nodes. Several of these modifications have their own nodes with the same effect: the Clmp and Clip buttons imitate the Clamp node, and the Blur button functions as the Blur node.

      Aside from these modifications, there are two more settings that are very useful. Be pressing the '>' button, two further options appear. The Influence parameter allows you to reduce the overal effect of the node. The Drop to Floor checkbox lowers the contents of the node to the lowest possible limit, which can be very useful after combining several layers together.

      b0a0e2b8-2721-47ba-8ada-0277be718c85-image.png

      Figure 10: This panel containing modifier parameters is present on all nodes and allows for adjustments without having to add more nodes. The Drop to Floor checkbox is not visible by default and will only show up when pressing the chevron to the left of the buttons.

      Using nodes as masks

      Using greyscale values to create terrain

      So far, we've discussed how nodes can be used to create the terrain for your map. To understand how nodes can also be used to create masks to select specific parts of the terrain, we need to quickly discuss what it is these nodes are creating.

      In games such as FAF, a greyscale image creates the terrain. Every pixel of the image has a greyscale value, which ranges from 0, complete black, to 256, complete white. The value of each pixel corresponds to the height of that pixel when it is used to render the terrain. A full white pixel is at maximum height, while a black pixel is at the minimum height. Any values between 0 and 256 correspond to a height somewhere in between the minimum and the maximum.

      Gaea similarly translates greyscale pixels to terrain. By default, the viewport renders the resulting 3D terrain for you, but by changing the display mode we can visualize the flat greyscale image. Right clicking on any node and select Show as, Mask, or by selecting a node and pressing T, will change how the viewport renders that node. You will now see the greyscale pixels for your heightmap.

      It might be that the greyscale value is still overlaid on the 3D model, rather than shown as a flat plane. This is because Gaea always shows two layers: the node and the underlay. The underlay is the geometry that Gaea projects the contents of a node on top of. This is generally selected automatically, but similarly to how you can freeze a node into the viewport by pressing F, a node can be chosen to serve as underlay frozen by pressing G. To visualize the greyscale image as on a flat plane, you can create a Constant, 0% height node and select that as underlay.

      If the image is dark and you would like more contrast to see the different structures, you may press the Show raw data button and the Enhanced view button on the right side of the view port (figure 11).

      Since the greyscale value of each pixel is a number, we can easily make selections based on these values. The Data category of nodes contains a lot of nodes that we need to do such selections. The Height node lets you make selections based on the height of the terrain, which corresponds to the higher greyscale value. Similarly, Slope allows you to make selections of pixels that are at a certain angle, by calculating the relationship of a pixel with its neighbours.

      For a more extensive introduction to Data nodes to create masks, please see the Gaea tutorial on Masking.

      Masks.png

      Figure 11: The 3D image, and the corresponding greyscale representation of the raw data for the heightmap. The three greyscale images show the heightmap projected on the 3D model, on a flat plane, and on a flat plane with Enhanced view enabled.

      Using greyscale values to select

      The greyscale values can also serve to create selections: effects of nodes can be limited to only areas that are white, and not be applied to areas that are black. Greyscale values between white and black correspond to a percentage of the effect being applied. As all nodes contain essentially nothing more than a greyscale image, the outputs of nearly all nodes can be used to make such selections.

      By using masks, you get infinitely more control over how nodes are applied. One example might be limiting where erosion is applied. In the fourth panel of figure 10, the erosion is applied to the whole mountain. As an example, we will now limit the erosion to only half of the mountain.

      To do this, we first set up our mountain and apply the Wizard erosion node. Then, we create our mask. The mask that we need to limit the erosion to only half of the mountain is a mask that is half white, and half black. Only in the white regions will the erosion effect be applied. To create a full white heightmap, we could take the Constant node and set it to 100% height. Using a Transform node, we could then move the Constant node halfway off of the workspace. As there is no information on the now empty half of the heightmap, these pixels will be black. The results is a heightmap that is white in one half of the image, and black on the other half. When we then use the output of this Transform node and chain it as the mask-input of the Wizard node, we get the result we intend (figure 12).

      Masks2 copy.png

      Figure 12: The erosion effect is applied to half of the mountain using a mask. Panel 2 and 3 both show the same node, but the display mode differs. The bottom panel shows the Graph to create this effect. The Fold node shown was used to slightly alter the result of Mountain node, and does not affect the process of making a mask.

      Naturally, this specific effect is not something that would work well for a FAF map, but clearly illustrates the principle of using masks.

      Other nodes

      There are several other useful nodes that you might use to create more advanced materials for your map. These include the Normal Map node, which can be used to create map-wide normal map decals, or the Light node, which can be used to create map-wide shadow decals. As these nodes are more complex, they will be discussed in detail in another tutorial.

      Creating symmetry

      As Gaea is designed to create realistic and natural terrain, it does not create symmetric terrain by default. In contrast, competitive FAF maps require symmetry to ensure no team has an advantage over the other. Luckily, by combining a few nodes we can create seamless symmetry for all kinds of terrain.

      Symmetry of basic terrain

      The most simple way to create a symmetric heightmap is done by using the Flip and Combine nodes. The Flip node allows for three different types of mirroring: Horizontal, Vertical, and Both. By combining the flipped copy with the original, you get symmetry.

      Mirroring.png

      Figure 13: An example of how the Flip node can be used to create three different kinds of symmetry: Horizontal, Vertical, and Both. Combine, Add, 100% was used in these examples.

      Rendering your height mask

      When you've completed your terrain, you can export it for importing into the FAF editor. To do this, take the last node in your graph and mark that node for export by selecting the node and pressing F3, or by right clicking it and selecting Mark for Export. The marked nodes will now show up under the Build tab in the top right. Adjust the relevant settings:

      • Change the filetype of all masks to .raw
      • Method should be left on Normal Build
      • Resolution should be set to the size corresponding to your map's heightmap (257px for a 5km map, 513px for a 10km map, 1025px for a 20km map).
      • Colorspace should be left on sRGB
      • Range should be left on Raw, although alternatively this may be set to Remapped to rescale the whole terrain if it proves to be too tall for the FAF editor, see below.
      • Baked Cache may be left on Use

      After selecting where Gaea should dump the generated files, you can render the files by pressing Start Build.

      Rescaling height

      If, upon importing the heightmap into the FAF map editor, you realize that there is an issue with the vertical scale, you may want to adjust your heightmap. There are a few easy ways of achieving this. The Clamp node lets you scale the whole heightmap proportionally. Connect this node to the last node of your graph and adjust as necessary. Similarly, under the modifier parameters (those little buttons at the bottom right of a node's parameter panel) you will find the Raise modifier, a circle containing an X. This parameter behaves nearly identical to the Clamp node. Lastly, by setting the Range setting under the build menu to Remapped, and setting the maximum value to some fraction of 1, you can rescale the terrain.

      Some trial and error is likely required to find the right scale.

      Common errors and checklist

      If you are running into problems with importing your heightmap to the FAF editor, please check the following:

      • Verify you are using the correct resolution
      • Verify you exported the heightmap in the .raw file format.
      • Try changing the Baked Cache setting to None and re-render.

      If Gaea is producing errors and you cannot get it to work, please check the following:

      • Verify that the offending node is properly connected. Remove connections and try again. Nine times out of ten you accidently connected a non-primary output to the next node that cannot use that particular type of data, or connected one node to the a secondary input of the second node.
      • Force refresh the complete graph.
      • Replace the bugged node.
      • Restart Gaea.

      If Gaea refuses to render your heightmap, attempt the following:

      • Add a Transform node to the end of the graph, and mark that node for export. Some nodes are known not to produce an output, but the Transform node is known to behave as expected.

      Remaining questions

      If you are left with questions or need help, your best bet is to check with people in the FAF discord Mapping-General channel. Alternatively, you may send me a PM on discord, or leave a message on this forum.

      posted in Mapping
      IndexLibrorumI
      IndexLibrorum
    • RE: Index Librorum's Maps, assorted projects, and Gaea tutorials

      albus.png

      "Under pale moon,
      Across the snow
      ...
      Did we not lose, a hundred times?
      Did we not win, a hundred times?"

      Hello. It has been a while.

      Project Albus is my first snow-type map, featuring large ice and snow covered flats. This 15x15 km map supports up to 8 players and consists of 5 lanes. The center lane is rather wide, while the lanes in the corners have several areas that serve as chokes. While the two large mountains serve as a barrier separating the main and the side lanes, the mountains can be crossed by small groups of units, albeit with some difficulty; You'll have to remain vigilant against enterprising enemies trying to raid through them.

      This map was a real pleasure to create, and uses several new techniques and tricks. First and foremost is the use of asymmetry: you'll notice that the ice floe in the corner ponds are different between the two map halves. To ensure that this difference in terrain does not affect gameplay, the two ponds have been made inaccessible using terrain types. Units will not be able to access this part of the map, air units excepted.

      Experiments with asymmetric texturing have worked out rather well, and textures have been applied in a more organic manner. While the main playable area has identical terrain, textures are not applied symmetrically, creating a sense of natural distribution of the snow and ice. Additionally, some experiments with creating texture masks in Gaea have led to some improvements, and I believe the quality of the masks has increased significantly compared to my previous maps.

      Future iterations of Adaptive Project Albus are pending on feedback, and might lead to an adjustment of mexes and reclaim. As per usual, any feedback is welcome either in this thread, or via discord directed to Prohibitorum.

      The map is licensed under CC BY-NC-SA 4.0 and is compatible with AI.

      da6c1b7e-f13e-4d89-b1f0-2a1d584de84e-image.png
      d5ee98d8-00b0-4b9c-85fc-384535004014-image.png
      61df4009-279f-45ae-8e34-52fd6178dfdc-image.png
      30b376da-5bfc-4e95-92a8-0d94e063fc63-image.png

      posted in Mapping
      IndexLibrorumI
      IndexLibrorum
    • RE: 'Princess Burke' Mapping tournament

      @jip Thanks everyone! Cool to get first prize. Thanks to Jip for organizing this, and to our lovely judges for the grading and feedback.

      I've contacted Jip and received the license for Gaea. Had some ideas for new maps on the backburner, time to get them going!

      posted in Tournaments
      IndexLibrorumI
      IndexLibrorum
    • RE: Index Librorum's Maps, assorted projects, and Gaea tutorials

      Several interesting updates!

      Project Mesa HD

      Project Mesa was the first map I ever made. It was also the first project I made in Gaea. Consequently, on both the map-making side and the Gaea side there was a lot of room for improvement.

      So improvements were made! Released under the new name 'Project Mesa HD', the new map features several fixes to the terrain (which mostly focus on flattening and scaling the map to solve height-related issues), some changes to the mex layout, better reclaim, and much improved use of decals. Pictures at the end of the post.

      I have one or two areas left that I can work on to further improve the visuals of this map and may update again in the future, but for now you can find Project Mesa HD in the mapping vault and in this month's 4v4 matchmaking queue.

      A github repository for project Mesa assets and project files

      I have released a github repository which contains a growing set of decals and textures related to the Project Mesa HD map. The textures and decals will soon become part of the main FAF repository, and thus become available for everyone to use through the FAF editor.

      Along with these new mapping assets, I have included the Gaea project files that were used to create the map and assets. If you're interested in working with Gaea, you may want to have a look at how I've created this map and the decals.


      Topdown.jpg

      sideview.jpg

      decal2.jpg

      decal1.jpg

      decal3.jpg

      posted in Mapping
      IndexLibrorumI
      IndexLibrorum
    • RE: 'Brigadier Fletcher' Mapping tournament

      Congratulations to the winners!
      Thanks for Jip for hosting and our esteemed judges for the grading.

      The feedback is very on point and I agree with pretty much all the feedback Project Vortex got. Unlike previous projects, I never really fell in love with this map, and it shows in how rough it is in places. Was a good challenge nonetheless.

      I'll be back for first place next time 😁

      posted in Tournaments
      IndexLibrorumI
      IndexLibrorum
    • Offering a draw should not result in rating changes

      I would like to suggest that any game that is ended as a draw using the draw button should not award or subtract rating points from any of the players.

      Recently, it has become much more common to have at least one player disconnect at some point during a game. These issues have been reported and are no doubt worked on. In the mean time however, it has become clear that we lack a way to declare that a game should be ended or unranked because of problems of one kind or another.

      Currently, when you use the draw button, the game understands this to mean that both teams are equal. As a consequence, the lower rated team gets assigned points, and the higher rated team loses points. However, unlike games like Chess, it is (near) impossible for a FAF match to end up in a genuine draw. For this reason, this logic does not make sense and the button's function should be changed.

      I imagine the the easiest option to fix this issue is to either set the game as unranked, or award a default 0 points to all players, once a draw has been accepted. Alternatively, a new button specifically made to unrank a game could perhaps be implemented. I do not know how to code however, and I am sure that smarter people than me have better ideas.

      It has been frustrating to have more than half of my games be spoiled by connection issues, and to lose points on top of that after accepting a draw is just not a great experience. Please make this change.

      posted in Suggestions
      IndexLibrorumI
      IndexLibrorum
    • RE: What is the biggest issue that plagues FAF in your opinion?

      Lack of communication between different dev/balance/content teams and community, instability of connections, client being buggy and slow.

      The fact that the game is still being actively maintained needs to be praised, though. It's not common to see this kind of activity in a decade old game.

      posted in General Discussion
      IndexLibrorumI
      IndexLibrorum

    Latest posts made by IndexLibrorum

    • RE: Are autotargetting SMLs legal?

      @taxesaretheft You don't need to use distribute orders, you can just queue up normal attack orders.

      posted in General Discussion
      IndexLibrorumI
      IndexLibrorum
    • RE: WD #3 - Ridiculous Balance Ideas

      @snoog Allow fatboy to print SACUs

      posted in Weekly Discussions
      IndexLibrorumI
      IndexLibrorum
    • RE: WD #3 - Ridiculous Balance Ideas

      Now that's necroposting.

      The idea of having a customizable experimental is pretty funny though.

      posted in Weekly Discussions
      IndexLibrorumI
      IndexLibrorum
    • RE: Are autotargetting SMLs legal?

      Expensive and inefficient way to use TML's, but then again it's Astro so not unexpected.

      posted in General Discussion
      IndexLibrorumI
      IndexLibrorum
    • RE: Rematch request button/option in matchmaking games

      @stormlantern Certainly if a match was made once, the same match directly after would be 'valid' enough?

      I can see problems when the same two teams play a long series of games against eachother, but realistically you'll get 2-3 matches before people have to leave or want to do something else. I can't imagine that would really cause any issues.

      posted in Suggestions
      IndexLibrorumI
      IndexLibrorum
    • RE: Brick torpedo damage

      @boony said in Brick torpedo damage:

      Sure, you can kill an enemy earlier. That is not the point! Why would you want other units to become obsolete once you arrive at T3, especially subs that have nothing to do with land units?

      All units become obsolete compared to their higher tier counterpart if you only look at DPS and Health per cost. This is not unique to subs and bricks.

      posted in Balance Discussion
      IndexLibrorumI
      IndexLibrorum
    • RE: MapGen 3v3 SHOWDOWN

      Which rating will count? Global?

      posted in Tournaments
      IndexLibrorumI
      IndexLibrorum
    • RE: LAND WAR T3 modded game Tournament

      Do you have a particular time in mind?

      posted in Tournaments
      IndexLibrorumI
      IndexLibrorum
    • RE: Firey Explosions mod FAF

      @nuggets That's more a @MadMax thing, since it's related to mods and maps 😛

      posted in Modding & Tools
      IndexLibrorumI
      IndexLibrorum
    • RE: Community Game Night! - Feedback

      I've not been able to join due to issues with timezones. Now the amount of players from Japan can be counted on one mutilated hand, but I bet there's a bunch of Australians who feel similarly left out. Might wanna do another timezone too next time?

      posted in General Discussion
      IndexLibrorumI
      IndexLibrorum