Search the Community

Hello once again! We are near the end of advanced scripting principles. Ifs and for loops are the last step between you and an official Skylords Reborn Advanced Scripting Degree! (jk) Let's look at them now, shall we? I will create two script files for this chapter, you can download them here. Don't forget to define the example.lua script in _scriptlist.lua! _globalvars.luaexample.lua If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content If, Elseif, Else For Loops Using Ifs in BF Scripts Using Loops in BF Scripts Next Chapter • If, Elseif, Else First, I will use if, elseif and else conditions in a _globalvars.lua script. There, we can most easily see how to work with these conditions. In Lua, using the if condition is very simple. There are three basic keywords you need to know: if - starts the if condition block, is followed by the actual condition then - defines the actions that should happen if the condition is true end - closes the if condition block Let's look at the _globalvars.lua example above. I've declared a difficulty variable and used the GetDifficulty() function to get the difficulty we are playing the map on. The GetDifficulty() function returns the numbers 1, 2 or 3 based on the difficulty. 1 - standard difficulty 2 - advanced difficulty 3 - expert difficulty Then I use the if condition to check if the difficulty is equal to one of these numbers. To compare values, we use the following characters. == - checks if the value on the left is equal to the value on the right, be sure to use double = > - checks if the value on the left is bigger than the value on the right < - checks if the value on the left is smaller than the value on the right >= - checks if the value on the left is larger or equal to the value on the right <= - checks if the value on the left is smaller or equal to the value on the right As you can see, I've used the else keywords in the code. If you want to check another condition for the same if condition, use the following keywords. elseif - starts another if condition block, if the previous if conditions return false, is followed by the new condition to check needs the then keyword after the condition else - defines the actions that will happen if ALL the above ifs and elseifs return false, does not need then keyword In my example - if the difficulty is not standard, I use the ELSEIF condition to check if the difficulty is advanced. If the difficulty is not standard or advanced, then it must be expert, so I use the ELSE keyword - no further condition needed, as the ELSE actions get executed if all the other conditions fail. If you don't want to deal with the ELSE and ELSEIF keywords, you can separate the check into three separate IF conditions. Keep in mind that you then need to end every if condition with the end keyword. • For Loops I am going to show you how to declare for loops outside of BF scripts at first. For loops are used to execute code multiple times, until you reach the loop count you specify. If you were to use for loops in general Lua scripts, you would go about it like this. So these are the keywords you need to remember. for - declares the for loop, is followed by definition how many times the loop should run do - defines the actions that should happen for every run of the loop end - ends the for loop After the for, we need to declare a variable for that loop, that we will increase by one every time the loop finishes, and the range the variable should start and end at. Like this. i = 1,2 This tells the loop to define the i variable that starts at the value of 1, and the loop will stop once the i reaches a value of 2. So the loop will run two times. first time when the loop starts at i = 1 second time when i = 2 the loop will not start a third time, as the i has reached the specified value of 2 This for loop would do absolutely nothing, but if we were to add an equation into the for loop... With this loop, it would increase our difficulty variable by 1 every time the loop runs. So in the end, if we started the map on standard difficulty, the difficulty variable would return 3 - as if we were playing expert, and it would return 5 if we were actually playing on expert. (GetDifficulty() returns 1 on standard difficulty and 3 on expert difficulty, then we add 1 for every loop -> 1+1+1 = 3 or 3+1+1 = 5 ) For now, let's just declare a variable number_of_spawners in _globalvars.lua. • Using Ifs in BF Scripts To show you how to use ifs and loops in BF scripts, I am going to create an example.lua script. I want the game to give me an outcry that the script was successfully loaded, so I add a state (remember, every script needs at least one state) with a OnOneTimeEvent that sends out an outcry. Now if we define the example.lua into _scriptlist.lua, upon map start, we should get the outcry "EXAMPLE LOADED". To actually use the ifs and for loops in the script, we will need to define them OUTSIDE OF ANY STATE. The events we declare in ifs and for loops will be added to the next state after them. I've added an if difficulty == 3 condition above my INIT state. This condition will use the difficulty variable I've declared in _globalvars.lua and check if we are playing on expert difficulty. If the condition is true, it will add the declared OnOneTimeEvent to the INIT state below the if condition. You probably didn't notice this, but I've added something special to the MissionOutcry. A "..difficulty" after the outcry text. Believe it or not, but we can actually use the variables in BF actions and conditions. The double dot (..) tells the script to add whatever comes after the double dot to the text before it. In our case, it will add the difficulty variable to the outcry text, like this. Awesome! Also notice that the event will switch the script to the EXPERT state via the GotoState. Note that, it is important in the following topic. • Using Loops in BF Scripts I've prepared a little scenario to showcase the usage of for loops. I have two fire spawners, one tagged spawn_point1 and the other spawn_point2. I want to spawn a squad next to each of them on expert difficulty. To do that, I will add the EXPERT state, to which the if condition from before switches to. And above the EXPERT state, I will define my for loop. I have two spawners, and I want to spawn one squad next to each of them. So I will declare the i = 1,2. I use the SquadSpawn action to spawn the squad and in the TargetTag, I use the good old double dot (..) to spawn the squad next to each spawner. The SquadSpawn action takes the "spawn_point" tag we specified and the for loop adds the number of the i after it. So what this for loop does is, it adds two OnOneTimeEvents with the SquadSpawn action to the EXPERT state. And the TargetTag for the first event is spawn_point1 and for the second event it is spawn_point2. Now, the number of spawners I have on the map can change as I work further on the map, for easy access to the number of spawners, I have declared the number_of_spawners variable in _globalvars.lua. We can use that variable in our for loop, now we won't need to sift through all the scripts to adjust the number of spawners we have, we can only change the variable in _globalvars.lua. Let's check our script in game. When we start the map on standard or advanced difficulty, the squads will not spawn. The EXAMPLE LOADED outcry tells us that the script works as it should, we just didn't select the expert difficulty. But when we start the map on expert (remember - we switch to the EXPERT state in our event in the first if condition), we will get a squad of Sunstriders next to each spawner, alongside the DIFFICULTY 3 outcry. YAY! Before we leave thic topic behind us, I just want to reiterate that the contents of the ifs and for loops get added to the next state that comes after them. • Next Chapter I know this chapter was a bit... ify. But you successfully got through the advanced scripting principles. Don't worry, a bit of practice and some help from your fellow map making skylords will carry you a long way. In the next chapter, we will look at the very complex topic of Warfare Patterns. Using them can be really great and easy if you know what you're doing, but they include some weird behaviours that might confuse you. Don't dread, I will be there to guide you on your Warfare Pattern jouney to victory. • Warfare Patterns • (Coming Soon)

Hello again! As I have investigated some scripts by the original BattleForge developers, I have stumbled upon template scripts! These templates are used when you want multiple scripts to have the same functionality, but with different targets, spawnpoints, respawn times etc. You define one template and use it in multiple scripts, in which you only need to declare the specified arguments. This can prevent mistakes that can happen when you copy-paste the same code multiple times, and forget to adjust the values, or introduce some typos. Here are the scripts I will create in this tutorial. spawn_template.luaspawn2.luaspawn1.lua If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content Creating a Template Script Passing Arguments Using a Template Homepage • Creating a Template Script I will create a simple script as a template to show you an example. I will create a script called spawn_template.lua (it is always best to include the "template" in the name of your template scripts). In the template script, we need to declare a function - I've called it "SpawnTemplate". A function needs to have the () brackets after its name is declared (I will tell you what these brackets are for in a little while). And we end the function with the end keyword after the closing curly bracket. Inside the function, I have created two states, each with one event. I want the script to be inactive at the start, and spawn a squad of thugs, once it is activated. And, this is it, this is a template script. It is very basic mind you, it does only one thing and with all the same parameters, so it is not very useful at the moment, we might as well have written this into a standard script. Now, let's have a look at how we can make this script actually usable... • Passing Arguments We can pass arguments to the function, that we can then use in the code! For that, we need to tell the function to expect some arguments first. We do that by writing something in the function's () brackets - I chose args (for arguments), but you can write whatever you want in there, just name it something sensible. Now, in our code, we can specify which arguments the function will expect. We can do that by writing args.ArgumentName for the arguments we want to pass to the function, like this. I have added arguments for the map flag that activates the spawning, the tag of the spawn building which needs to be alive, and the target tag, where to spawn our squad of thugs. Now the code is actually reusable! Let's look at how we can do that. • Using a Template I will create two scripts - the spawn1.lua and spawn2.lua. So my script1 folder looks like this. In these scripts, we only need to type the name of our template function, and pass it all the arguments we've specified in the template script, separated by a comma - In my case, the ActivateFlag, SpawnerTag and SpawnpointTag. You need to write these arguments between curly brackets {}, otherwise you will get an error. These are my arguments for spawn1.lua and spawn2.lua. Now, obviously our template is very simple, and copy-pasting it into multiple scripts wouldn't be much of an issue, but when you have more complex behaviour that is used in multiple scripts, having a template can really save your time, as you only need to truly debug the template script. At last, I will add the spawn1.lua and spawn2.lua scripts into _scriptlist.lua, as they don't share the name with a tagged entity, or a script group. Now, if I were to activate my map flags, for example in the _main script, I will have a squad of thugs spawn on every spawnpoint I declared, if the tagged buildings are alive. • Homepage You can return to the homepage here. • Map Editor Tutorial Homepage •

Hello there! We have went over quite a few scripting topics, and they just keep coming. In this chapter, we will look at which scripts the game loads by default, and how you can create your independent script, that is not tied to any tagged entity. If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content Default Scripts Tagged Entity or Script Group Scripts _main.lua _scriptgroups.lua _spawngroups.lua _globalvars.lua _scriptlist.lua Next Chapter • Default Scripts BattleForge automatically loads some predetermined scripts when starting the map. I have named these scripts the default scripts. The scripts the game automatically loads are: scripts that are named after a tagged entity or a script group _main.lua - this is the main script of the map, as such, every map needs to have a _main.lua script _scriptgroups.lua - you define script groups in this file _spawngroups.lua - here, you define the waves for warfare patterns _globalvars.lua - you can have global LUA variables in this file, and reference them in any other script in your map _scriptlist.lua - here you can declare your own independent scripts, that are not tied to any entity • Tagged Entity or Script Group Scripts BattleForge automatically detects scripts, that share the name with a tagged entity or a script group. For example: If you have an entity on the map tagged big_guy - you can create a script named big_guy.lua and it will automatically load upon map start. Same with script groups, if you have a script group named sg_small_guys, you can create a script named sg_small_guys.lua and it will be automatically loaded. These scripts have one downside, as they only work for as long as the entity / entities are alive. Once the entity is dead, and there is no OnRespawnEvent in the active state, the script will stop working. • _main.lua As stated above, the _main.lua script is the main script of the map. You can script general functionality in this script as it is not tied to any entity on the map. In official development, this script is mostly used for implementing difficulties or starting global timers. • _scriptgroups.lua We went over the _scriptgroups.lua file in the Script Groups, Script Areas and Script Paths chapter. We define our script groups in this file, and add any adjustments to script groups for different difficulties. Example of the script • _spawngroups.lua _spawngroups.lua is used for warfare patterns. Warfare patterns are used to easily create waves of enemies, control them and have them respawn. We will dedicate a whole chapter to warfare patterns. • _globalvars.lua Sometimes, you want to use the same value in multiple places in your script, or even in multiple scripts. You can either type the value manually everywhere, or you can declare it as a global variable - giving you access to the same value in all your scripts. We can do that through _globalvars.lua. Inside the script, you just need to name your variable and assign it a value, like this. Then, you can reference the global variables in any script. In my case - reference global_respawn_seconds to get a value of 20, or number_of_enemies to get a value of 5. _globalvars.lua makes it also very easy, if you want to change global variables based on difficulties. In my case - I can shorten the global respawn time and increase the number of enemies on higher difficulties. Here is the script, if you want to make use of this on your map. I will be covering ifs and loops in a separate chapter. _globalvars.lua • _scriptlist.lua As stated above, scripts that are tied to entites on the map only work for as long as the entity is alive. While you can design around this, it is not ideal and after a while, you might have trouble finding specific events. In _scriptlist.lua you can declare "independent" scripts. You can name them whatever you like, and these scripts will execute their events regardless of any entity on the map. We can, for example, create a script called map_start.lua, where we will handle the setup of the map - outcries, objectives and fog of war. Then, create a win_lose.lua script, where we will handle all the victory and game over events. For the game to recognize these scripts, we need to declare them in the _scriptlist.lua - so we also need to create that. Inside the _scriptlist.lua, we need to return the names of our independent scripts, like this. We will return a list of the names of our scripts in parenthesis, with the .lua extension. The names are separated by commas. You can also write this into one line, I just like to separate them into multiple lines for better readability. Generally, you want to script all specific functionality into separate scripts for clarity. Having everything in the _main script can lead to a mess of hundreds, if not thousands of lines of code, and working with the script becomes very inconvenient. Compare that to separating the functionality into individual scripts like: boss_behaviour.lua, objectives.lua, main_gate_opening.lua etc. Each script having only a couple of events, that are all tied to a specific function. I think you can see the benefit of doing this. • Next Chapter This might have been a bit complex. But these special scripts become essential as you start creating more intricate maps. The next chapter covers script group member scripts, which allow you to do some neat stuff with individuals inside a script group. • Creating Member Scripts •

Hello again! Script groups are a great tool for map makers. While they make referencing and scripting with multiple entities much easier, the script group, by default, is pretty rigid. You lose access to the individual units, or you need to create separate scripts for them, and take care that they do not clash with the script group's script. That's why the original devs implemented member scripts. These scripts offer you access to all the units inside a script group, and allow them to act almost as separate entities again, while preserving the ability to work with them as a group. If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content Setting Up a Script Group Member Script Usage Creating Member Scripts OnIdleGoHomeEvent Next Chapter • Setting Up a Script Group Before we can make a member script, we of course need a script group to create it for. In our Map Editor Tutorial map, I've prepared these units and tagged them spawn_defender1 to spawn_defender6. I will create my script group through the _scriptgroups.lua file. But feel free to use the in-editor Script Group Editor. In the _scriptgroups.lua, I've created a group called sg_spawn_defenders and assigned the spawn defenders to it . Since I want these units to respawn, I will create a script named sg_spawn_defenders.lua and add an OnRespawnEvent. Now, the units will respawn. But with a small twist - they will only respawn once ALL of the units in the script group have died. While there is nothing inherently wrong with that, and this behaviour may be desired in some cases, we usually want our spawn defenders to be more responsive. This can also lead to exploits, such as leaving one of the units alive to prevent the respawn of the remaining defenders. As you might have guessed, we will remedy this by creating a member script. • Member Script Usage Member scripts need some further setup, but when finished, they can offer vastly improved functionality and control over units in a script group. Before I get to the creation of member scripts, I will give you some examples what you can do with them. make squads in a script group respawn individually, instead of as a group make squads in a group return to their original placement after respawning make squads in a script group behave as individuals, instead of as a group - instead of copying the same script for multiple entities, you can just use a member script to have multiple units have the same behaviou • Creating Member Scripts Creating the member script is extremely easy. We will just copy the sg_spawn_defenders.lua script, and rename the copy to sg_spawn_defenders_member.lua. Please note that you NEED to name the member script as scriptgroupname_member.lua. This lets the game know, that you have created a member script for that specific script group. You also NEED the script group's original script file. Now, when we have the member script created, we need to clean up the original script. Just open the script, and since we don't want this script to do anything, just leave in an empty state - you need to have a state in the script for the game to register it. And our member script will have the OnRespawnEvent inside it. With only these few steps, we have made it so that, the units in the script group will respawn as individuals, instead of having to wait for the rest of the group to die. • OnIdleGoHomeEvent Maybe you've noticed, that in the official campaign maps, the respawned units will return to their starting positions, instead of just standing around the spawner. This is a great little detail that not only makes the camp feel more alive, and look more visually appealing when players try to destroy the camp again, it also preserves the camp defenders' strategic placement. Ideally, when designing a camp, you want to place the defenders in a strategic manner - ranged units in the back, melee units in the front, maybe have them defend a chokepoint. When the units don't return to their original starting positions, it can negatively impact the camp's balance. We can fix this issue by adding one more event into our member script - the OnIdleGoHomeEvent. This event simply tells the units to return to a "home" position when they are idle for some time. We can leave everything as-is, except the TargetTag parameter. This parameter tells us, where "home" is. We will set this to StartPos. The StartPos parameter references the entities original placement - as it was placed in the editor. This parameter only works in scripts, that are named after a tagged entity or a script group. And more importantly - also in member scripts. With this one extra event, that works almost from the box, we can see that the units will return to their originally designated positions upon respawning. In the end, you should end up with these scripts in your script1 folder. sg_spawn_defenders_member.luasg_spawn_defenders.lua_scriptgroups.lua • Next Chapter This concludes the member scripts chapter. First of our advanced topics. Just remember that you can create a fun and interesting map without ever needing member scripts. They can help the map feel better to play but are in no way necessary. In the next chapter, we will look at how we can use actual LUA language in our scripts to save ourselves a lot of time. • Using Ifs and Loops •

Hello there! Scripting groups, paths and areas are extremely useful when creating maps, I would even go as far as to say that they are necessary in most cases. Now, it is time to see what these groups, areas and paths are all about. If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content Script Groups Creation in the Editor Creation in the _scriptgroups.lua Script Areas Script Paths Next Chapter • Script Groups Let's start with the most important topic first. Script groups do what their name implies. They group individual tags under one, master tag. If you learn one thing from this chapter, let it be how to create script groups. You can use script groups in scripts the same way as you would normal tags. You can easily discern if a tag references a script group, because a script group's name starts with the prefix sg_. Naming conventions for script groups follow the same rules as tagging entities, with the addition that the name of the script group must start with the sg_ prefix. E.g. sg_fire_outpost_defenders. There are two ways of creating script groups. Through the editor, or through a script called _scriptgroups.lua. I would suggest you pick one of these and stick with it, combining them is not ideal for clarity. Let's look at both of them now. • Creation in the Editor Creating script groups in the editor is very simple and super quick. In the beginning, this should be all you need. But as time goes on, and you get more experience, you will find that doing the groups in the editor is very rigid and prevents you from using some advanced coding practices. To create a script group in the editor, we need to open the Script Group Editor in Windows -> Script Group Editor. We will also need the Entity Properties window. We can create new script group by pressing the New button in the Script Group Editor. The group's properties will be shown in the Entity Properties window. That is where you can rename the script group. Let's name it sg_fire_spawn_defenders, this group will include our spawn_defenders from the previous chapter of the tutorial. (Remember, we need to put sg_ prefix at the start of the group name!) Now, we need to insert our spawn_defender1 and spawn_defender2 squads into the script group. At the bottom of the Script Group Editor, there is a search bar, you can start typing the tags there and the editor will automatically offer you autocompletions. Select the spawn_defender1 in the offered list and press enter to insert it into the group. Do the same for spawn_defender2. There is also a very helpful feature, that will highlight tags that are not on the map in red. This is very useful if you have decided to change the tags of entities, or delete them. • Creation in the _scriptgroups.lua Creating script groups in the _scriptgroups.lua is a bit trickier, it actually requires you to follow some strict formatting. But in return, it gives you more flexibility when you need to adjust your script groups at runtime. The good thing is, once you've set up one _scriptgroups.lua, you can just copy it into other maps. To start defining our script groups, we first need to create _scriptgroups.lua, same as we would create any other script. Create the script in the script1 folder. Because of its complexity, I will give you an example _scriptgroups.lua, so you can fall back on it if anything goes wrong. _scriptgroups.lua The _scriptgroups file will return an array (think of an array as a list) of script groups to the game. Since the script groups themselves are arrays of tags, the _scriptgroups thus returns an array of arrays. This is just to confuse you, now to the example. Similar to a State, declare your script groups array - I've named mine "sgs" follow the name by the = sign and {} curly brackets. Like this. sgs = { } You will define your script groups inside the curly brackets. To create a script group, we define it the same way as our previous array - we name the script group and declare its contents (tags) between the curly brackets. Though in addition, we need to separate all the script groups by writing a comma "," after every closing bracket. sg_example1 = { "example_unit1", "example_unit2", "example_unit3", }, sg_example2 = { "example_unit4", "example_unit5", "example_unit6", }, At the bottom of the script, we just need to return our script groups array to the game. In my case, like this. return sgs You can probably see that writing dozens of script groups, each of them containing up to dozens of tags, is not exactly fast. Luckily, there is a function in Notepad++ that can make inserting tags easier, and that is Column Editor. I will just direct you to official Notepad++ tutorial on how to use that functionality. https://npp-user-manual.org/docs/editing/ I will cover creating difficulties in more detail in another tutorial. For the moment, you have the example script that includes adding entities into a script group on expert difficulty. • Script Areas Script areas are mostly used to check if an entity is inside it, or not. You can access script areas via Windows -> Scripting Tool. You might need to check the View Scripting Areas checkbox to be able to see what you are doing. To place a script area, click the Place Point button. Then, click and drag to extend the area from point to point. After the first two points are placed, you can extend the area by clicking and dragging a new point from anywhere along the line between two points. You can add as many points as you want to an area. If you need to move the points, you can do that by clicking the Select button. To remove the points, click Remove Point button and click on the points you want to delete. To use the area in scripts, we need to tag it. We do that by using the Select mode, and double-clicking any of the points of an area. That will select the whole area, and give us the ability to tag the area through the Entity Properties window. If we go back to our _main.lua script from previous chapter, we could change the TargetTag of the PlayerSquadIsInRange check. With the area clearly defined, we don't need to measure or gauge the distance ourselves. I have also changed the range to default, which seems to work best with script areas. Like this. • Script Paths The Scripting Tool also houses our next guest - scripting paths. You can place a script path the same way you do a script area, only with script paths, you extend the path by click-dragging a new point from the last point of the path. Select a script path by using the Select mode and double-clicking any of the points of the path. Scripting paths have some extra options in Entity Properties. Here, we have: Continuous - makes the path continuous, meaning if you send units along that path, they will patrol it indefinitely. Travel in Reverse - reverses the direction in which you placed the points, making units start from the last point placed. When you send units along the path, they will follow it as closely as possible. The units will first start walking towards the first point of the path, and from that, they will continue to the next point and etc. remember that units will walk to the first point placed, first. If the path is continous, the units will patrol the path indefinitely. Sending units on a script path uses a different action than SquadGoto. To send a single squad along a path, use SquadCheckpointGoto action. To send a group of units along a path, use SquadGroupCheckpointGoto action. As stated, units sent on a script path will follow the path as closely as possible. When sending a script group along a path with SquadGroupCheckpointGoto, the units will wait at each point of the path, until all the units from the group are present before continuing. This is extremely useful when sending attack waves. • Next Chapter This is the end of three, very imporant topics. It wasn't as much fun as making units move around, but these three things are practically necessary for map creation. Now, goals in BattleForge are a bit unwieldy to work with, I will tell you all about it in the next chapter. • Creating Goals •

Welcome back! I hope you are properly refreshed and ready to get back into action. We will look into further actions and conditions we will need to complete our scenario. If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content Setting up the Scenario Pt.3 Scripting Pt.3 - Ambush Setting up the Scenario Pt.4 Scripting Pt.4 - Respawning Scripting Pt.5 - Victory and Loss Next Chapter • Setting up the Scenario Pt.3 In the previous chapter, I mentioned a surprise to the south. Since the southern path only has one Firesworn, I want to add a little ambush when the player approaches that location. Put another marker near the southern cave and name it ambush_cave. We will also want to set up the next waypoint for our Goldwagon, further to the east. Tag it target_east. • Scripting Pt.3 - Ambush Let's return to the _main script once again. Now, we need to script our cave ambush. For that we need another OnOneTimeEvent. (See how much you can get done with the simplest things.) And add PlayerSquadSpawn action to it. I want to spawn a Magma Spore - for that, I will need to know its ID. Squad ID can be found in the editor, in entity properties as Database ID. The actual ID starts with the first non-zero number after the initial number. I filled in the TargetTag, Player, SquadId and amount into the PlayerSquadSpawn action, and I am ready for testing. And our Magma Spore spawns as expected. (I have moved the cave location, so that the Spore aggroes to the approaching player units.) Finishing the Goldwagon movement is simple, we just need a OnOneTimeEvent, with a very similar condition as the first two, that sends the Goldwagon to the target_east position. • Setting up the Scenario Pt.4 In the east, I want to have an enemy base with respawning defenders. So we need to set it up. Let's add a fire spawner building, and tag it fire_spawn. You can use any building for this, including towers, but keep in mind that players are used to which buildings are the spawners. I've placed a defensive tower and a squad of Sunstriders and a Wrecker to act as defenders of this fire outpost. Now we need to tag our squads so we can respawn them. You can either tag the units one by one manually, or you can select all the squads (Sunstriders and the Wrecker) and with both of them selected, tag them spawn_defender1 and hit enter. The units will automatically be tagged as spawn_defender1 and spawn_defender2. This is very useful, particularly with larger groups. Last thing I want to do is create our final waypoint in the east and tag it target_finish. Then, I added a Thunder Wagon to act as a final obstacle before the players can win the map. I tagged him final_challenge. Now we will look at how we can respawn the outpost defenders, and script the win and lose conditions for the map. • Scripting Pt.4 - Respawning Respawning units can be done in several ways. The easiest and most correct way is through the OnRespawnEvent. You might remember that I noted that the OnRespawnEvent is a special event. That is because it needs to be inside a script, that shares the name with a tagged entity or a script group on the map (I will explain script groups later). So let's look into that. On our map, we have two squads in the fire outpost - spawn_defender1 and spawn_defender2. We need to create a script for each of them. Create a new text file in the script1 folder, and name the new file spawn_defender1.lua. BattleForge automatically detects scripts that have the same name as a tagged entity on the map -> we have an entity tagged spawn_defender1 on the map, so we can create spawn_defender1.lua script and the game will automatically load it. The game only loads some predetermined scripts that start with "_" - such as _main, _scriptgroups, _scriptlist and _spawngroups. You can have a script that isn't named after a tagged entity, in that case, you need to declare it in _scriptlist.lua, which we will look at in future chapters. Now, open the spawn_defender1.lua script, create a state in the script (name it whatever you want) and insert an OnRespawnEvent into that state via the snippets. Now we need to adjust some parameters and declare a condition for the respawn. StartDespawned - determines if the units vanish at the start of the map, so they can be respawned at a later time TargetTag - position where the unit will respawn, "StartPos" means the unit will respawn at the position it was placed in the editor RespawnDelayMinutes - delay in minutes before the unit respawns after death RespawnDelaySeconds - delay in second before the unit respawns after death HealthPercent - with how much health the unit should respawn We want our units to be at their positions at the start of the map, so we will set StartDespawned to false. The units should respawn at the location of the fire spawner, so set the TargetTag to fire_spawn. The respawn should take only a couple of seconds, so leave the RespawnDelayMinutes 0 and set RespawnDelaySeconds to 20. We want the units to be respawned at full health, so leave HealthPercent as it is. I will do some further cleanup to make the script more readable. I have deleted the OnDeathActions block, as I don't need anything to happen when the unit dies. I have also deleted the GotoState as it is not necessary. Now, the unit will respawn every 20 seconds after it died. We need to insert a condition, that only if the fire_spawn is still alive, the units should respawn, otherwise the units will respawn out of thin air. We declare such condition with BuildingIsAlive. Now, we have explicitly written that the squad will respawn only if the fire_spawn building has not been destroyed. Instead of creating a new script and writing all of this again, we can simply copy-paste the spawn_defender1.lua script, and rename it spawn_defender2.lua. This way, we have easily set up the other squad to respawn as well. • Scripting Pt.5 - Victory and Loss There is only one last thing we need to script, and those are win and lose conditions. First, we need to create a simple event, that will send the Goldwagon to the final target. We have done this a couple of times now. Now let's do the lose condition. Obviously, since we have an escort mission, we want the player to lose if enemies destroy the Goldwagon. The players lose automatically if they lose all of their monuments, you don't need to script that. For the Goldwagon, we use a simple condition EntityIsDead. This condition is found in the Conditions-Negated snippet library, as it is the negative of condition EntityIsAlive. And game over is an action PlayerGameOver. You can ignore the TargetTag parameter. For the win condition, I want the players to win if the Goldwagon approaches the final marker AND the Thunder Wagon final_challenge has been killed. When we want to check if a tagged entity is in range of other tagged entity, we use EntityIsInRange. You can probably guess what is the condition for when the Thunder Wagon is dead. To win the game, we need to declare an action PlayerGameWon. Let's do something a little bit different. Since winning the game instantly upon the completion of our objectives is a bit anticlimactic, we will set the victory on a delay. We can do that with the OnOneTimeTimerEvent. Set the delay to 5 seconds, and try to estimate where you need to put the conditions and the victory action. Your event should look like this. If you got it right, great! If not, don't worry, I will explain. When the TimerStartConditions are met, the event will start its timer and TimerStartActions will trigger. Since we want to win AFTER the timer is elapsed, we need to write our victory action into TimerElapsedActions, which get triggered when the timer elapses and if the TimerElapsedConditions are met. Now, we just need to test everything in game and... The fire outpost defenders respawn as expected. And I was unable to best the Thunder Wagon guardian and lost my Goldwagon... Only on my second try did I get a win. The bright side is that, everything works! • Next Chapter This concludes scripting basic events! With this knowledge, you should be able to create mechanically interesting, yet simple maps. Search through the available Actions and Conditions in the snippets or on the wiki. Try things out, experiment and soon you will be able to do amazing things in the editor. In the next chapter, I will go over some very, very useful information on how to create and work with script groups, script areas and script paths. • Script Groups, Script Areas and Script Paths •

Before we can start scripting, we need to have a script editor. While you can use any text editor to create BattleForge scripts, there are some widely used, free text editors, that make scripting incredibly easier. We will look at one popular text editor that is used to edit BattleForge scripts - Notepad++. For advanced users, I will direct you to Visual Studio Code. If you are already familiar with BattleForge scripting editors, you can skip to the next part HERE, where I explain the principles of BattleForge scripting. If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content File extensions Notepad++ Visual Studio Code Next Chapter • File Extensions First thing you will need to do, is to enable file extensions in Windows. With this option enabled, you can create a text file in your script folder and rename it with the .lua extension. Windows will ask you if you want to change the file type - just confirm, and you will have created a Lua script. To enable the file extensions, follow these instructions. Windows 10 Windows 11 • Notepad++ You can download Notepad++ HERE. It is a simpler text editor, more suited to beginners. After installation, we will need to set up the Notepad working language and the most important thing - Snippets. To set the script language in Notepad++ to Lua, go to Language -> L -> Lua in the top toolbar. Once you've done that, download the following RAR file. It includes the Snippet libraries. NotepadSnippets.rar What are Snippets? They are a collection of pre-written lines of code. You can browse through a list of them, find whatever action or condition you need and simply insert it into your script. Now that you have downloaded and extracted the snippet libraries, we might need to download the Snippet plugin. Don't worry, it's quite easy. In Notepad++ go to Plugins -> Plugins Admin... In the Available tab, search for Snippets. Select Snippets in the list by checking the small box on the left and click the Install button at the top right of the window. Now that you have installed the Snippets plugin, you can open the Snippets tab Plugins -> Snippets -> Snippets A Snippets window will appear. For now, we can only see the Templates library. We need to import our BattleForge snippets, and we do that by right-clicking the Library selection field (Templates), and selecting Import library... Then navigate to your extracted snippet library files and import them, one by one. Now, whenever you are working on BattleForge scripts, you can find the snippet you need in the corresponding library, and insert it into your script by double-clicking it in the list. • Visual Studio Code You can download Visual Studio Code HERE. VS Code is for advanced scripters with some experience. You will need at least some knowledge of BattleForge Script to use it effectively. As I don't use Visual Studio Code myself, I will direct you to Bergerb's tutorial on how to set it up HERE. Alternatively, HERE is a video tutorial for VS Code snippets by Metagross31. If you want snippets in VS Code, download this file. sr-scripting.code-snippets And put it into \AppData\Roaming\Code\User\snippets folder. • Next Chapter Now that we have our preferred script editor set up. We can move onto the script structure and basic scripting rules. • Scripting Introduction •

The time has finally come! Now, we are ready to get to the meat and bones of map making - scripting. Here, we will learn by example and create a very tiny scenario to ease you into creating your own scripts. To create LUA scripts, we will need the ability to edit file extensions, if you don't know how to do that - see File Extensions chapter in the Script Editors tutorial. From this topic on, I will presume that you have read, or are familiar with the previously covered topics in this tutorial. If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content Creating the Map Setting up the Scenario Pt.1 Creating _main Script Scripting Pt.1 - Intro Outcry Setting up the Scenario Pt.2 Scripting Pt.2 - Moving the Goldwagon Next Chapter • Creating the Map To start off, we will need to create a map. I will be creating a PVE 1P map, but feel free to deviate. Decide on map size Set up the teams and player kits Place and assign starting position and monument to each player Don't forget about power wells Then save the map, and update the map description. I've named my map "Map Editor Tutorial". Now we have a playable PVE map. • Setting up the Scenario Pt.1 I've decided I want to make an escort mission (yay!). There will be a Goldwagon near the player's starting monument. The goldwagon must reach safety in the east. Depending on which way the player will choose, the goldwagon will follow his decision. This is what my layout looks like. For this scenario, I will not be designing the map past T2. Since the Goldwagon needs to be friendly towards the player, hostile towards the enemy, but not under player's direct control, I've added a new player to tm_Team1 and created and assigned a new player kit to him. Then, add a Goldwagon near the starting monument and add some fire enemies to every path. I've added two Rageclaws and two Gladiatrix to the north, and one Firesworn to the south. (I will explain why later.) Assign all the fire enemies to the pk_enemy1 and tm_Enemy1 so we see them as enemies in the game. (Don't forget to assign the correct team and player kit to the Goldwagon.) I also want to have a little surprise in the south, so I've added a cave. (Image rotated for better clarity) Now that we have the starting challenges in place, we can create the first script. • Creating _main Script Every map needs to have a _main.lua script. We will need to create it ourselves. If you navigate to your map folder, you will notice we have no script folder, so we will need to create that, too. Create a folder and name it "script1". Then open that folder and create a new text file. Rename the file to _main.lua and confirm. Here is a list of scripts we will create by the end of next chapter. spawn_defender2.luaspawn_defender1.lua_main.lua Now we are ready to start scripting. • Scripting Pt.1 - Intro Outcry Let's open our _main.lua script. It is harrowingly empty at the moment. But we can quickly fix that with snippets! Under BF-Events+State+Outcries, you will find the State snippet. When you double-click it in the list, it will create a State for us, like this. Since the StateName cannot be empty, let's name the state INIT, for example. Let's save the script, PAK the map and try playing it - remember, we will find the map in the Community Maps node of the world map. If everything is set up correctly, and you didn't make any typos in the script, you will be able to start the map. Great! Now that we've checked that everything is working, we can get around to the _main script actually doing something. In the same snippet library that we have the State, we have all the types of events available to us. Let's add an OnOneTimeEvent. OnOneTimeEvent is the most basic event available. This event will only trigger once, as soon as its conditions are met. Now, I want to have an outcry at the start of the map, telling us what we need to do. For that, we will need to search for MissionOutcry in BF-Actions library and insert it into the action block of our event. Set the text to something like "Get the Goldwagon to safety in the east!" and set the DurationSeconds to about 5 seconds. (Notice I've deleted the GotoState as I don't need it for this event.) Be sure to follow the correct formatting or the script will not work, or the game will crash. With our introductory OnOneTimeEvent set up, we can save the script, save and PAK the map, and return to the game to test out our outcry. For the future, I will assume you have saved the script, map and PAKed it after every change we do. This is the general workflow of scripting. Make changes to scripts Save the scripts Save the map PAK the map Test the changes in-game Close the game and repeat And everything is working, great! Before we continue, I will give you a list of most commonly used events. OnOneTimeEvent - triggers only one time, once the conditions are met. OnIntervalEvent - evaluates the conditions every X seconds, and if the conditions are met, triggers the actions every time. The game will start the timer immediately upon map start, so depending on when the conditions are met, you might have a delay in the execution of the actions. OnEvent - evaluates the conditions every tick, and if the conditions are met, triggers the actions every time. Use carefully as it will spam the actions several times per second. OnOneTimeTimerEvent - once the conditions are met, triggers the TimerStartActions and starts a timer, upon expiration of said timer, it will evaluate the conditions in TimerElapsedConditions, if the conditions are met, triggers the TimerElapsedActions - works only one time. OnTimerEvent - very similar to OnOneTimeTimerEvent, with the exception that once the event's timer expires, the actions get executed and the timer resets if the TimerElapsedConditions are true. I have run into issues of these events sometimes just spamming the actions, instead of reseting the timer properly. OnToggleEvent - this event activates when the OnConditions are met, in that case it will trigger the OnActions Once the event is turned on, it will wait for the OffConditions to be met to trigger the OffActions. The event will switch between on and off state and trigger the on and off actions every time the conditions are met. OnRespawnEvent - this is a special event, used to respawn killed entities. It can only be used in scripts named after tagged entities or script groups - we will look at this in detail a bit later. • Setting up the Scenario Pt.2 Now, let's set everything up so we can make our Goldwagon move. Almost every action and condition in BattleForge needs a target - be it a location on the map, or an entity. We label these important targets with tags. I want the Goldwagon to move south if my units move south, and for it to move north if my units move north. Once I've picked a direction, I don't want the Goldwagon to turn back and go the other way. Since we will need to somehow check where our units are, and where to send the Goldwagon to, we will need an object with a tag. We could place a small stone at the target area, tag it and use that as our target, but for these purposes, the game has special objects called Scriptmarkers - these are visible in the editor, but invisible in the game. You will find them in the Objects category in Entity Placement. Let's place one Scriptmarker Target near the fire units to the north, and one near the Firesworn in the south. Which Scriptmarker you use, or if you decide to use any other object instead, doesn't matter. Using the correct Scriptmarkers only makes the map more organized. Now, we will need to tag the Scriptmarkers - tag the one in the north target_north and the one in the south target_south. Remember the tag naming convention! Use only lower-case letters No spaces or special characters Don't use the tag "default" Tag things in english - you might not be the only one working on the map Next, we will tag our Goldwagon - goldwagon, we need to tag it, otherwise we are unable to give it commands or reference it in scripts. Now, save the map and let's do something with these markers. • Scripting Pt.2 - Moving the Goldwagon Return to our _main script. We need to create some single fire events, that will send our Goldwagon one way, or the other, based on some conditions. OnOneTimeEvents will be best fitted for this situation. First, I don't want the Goldwagon to go the other direction, once it has chosen its path. We can do that with a simple MapFlag. Map flags are one of the most useful conditions, and are the simplest to understand. Map flags can either be true, or false. Every map flag you declare automatically starts as false and we will use that to our advantage. Also note, that map flag names should start with the mf_ prefix. Now, we have declared one condition for our events. Right now, both of these events would trigger at the start of the game (Because the map flag starts out as false), and nothing would happen, because our Action blocks are empty. So let's add an action to both events, that will set the map flag to true. With this, once we have triggered one of these events, the other event will not trigger because of our MapFlagIsFalse condition. We will need further conditions and actions to complete our events. First, I will add a SquadGoto action to both events, the Tag parameter references a squad you want to move, TargetTag parameter references the target location. Then, we will need a condition to check if the player's units are near one of the targets. I have used TeamSquadIsInRange to check for squads of a given team. I have chosen the check range so that the Goldwagon (which is also set to tm_Team1, remember) doesn't trigger the events. Since we have only one human player on the map, more appropriate condition would be PlayerSquadIsInRange - this checks for squads of a given player, regardless of their team. With this, we don't need to take the Goldwagon into consideration when going to the checkpoint. I am only presenting you the different options you can choose, but the final choice is yours. Depending on how you set up the teams, distances between the targets and starting location, TeamSquadIsInRange might be more suitable for you, especially if you have multiple human players in the same team. Let's save and PAK everything, and try our script in-game. And indeed, the Goldwagon will go the way we choose first, and if we move our units to the other side, it will not turn back, excellent! • Next Chapter This is the end of the first part of basic events. Go grab a snack, something to drink and have a little break. When you're ready, continue to the second part of the tutorial. • Scripting Basic Events Part 2 •

Welcome to the scripting introduction. Here, I will explain the basic principles of writing BattleForge scripts. This part focuses a lot on explanation of script structure and rules, if you are not interested in this, and you prefer to learn by doing - skip to the next part of the tutorial HERE. Just be aware that having solid basics can save you a ton of headaches when debugging your code. If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content Script Structure States Events Conditions Actions Commas Next Chapter • Script Structure BattleForge uses LUA scripts to influence the map when playing. These scripts are not pure Lua, they use a customized version of Lua called BattleForge Script (BF Script for short). The name of the script can be whatever you choose, just follow these pointers. Use lower case letters Don't include spaces in the name Don't put any dots or special characters in the name File extension needs to be .lua All the scripts for a map need to be located within the script1 folder. To start off, I will provide you with an example script, so you can see what I am talking about. example_script.lua BattleForge scripts are state machines. The machine (or script) contains one or more states, and can switch between the states, but only one state can be active at any time. Think of it like a machine that can make either lollipops or baskets. The machine cannot make lollipops and baskets at the same time - you need to switch it from lollipop making state into basket making state, and vice versa. Within these states, we have events. Events are functions, that will execute actions once the conditions are met. Take a while to look at the example script and try to identify the states, events, and where they begin and end. • States The states are the basic building blocks of scripts. States don't do anything by themselves, but they are containers for events. The state starts with { and ends with }; Everything between these brackets are the contents of the state. An example: State { StateName = "Example State", }; Every state needs a name - you should not include any dots or special characters, and the name should be unique to that script. (You can have multiple scripts that contain a state of the same name, but you cannot have one script with multiple states with the same name.) You declare the name between the state brackets with "StateName = "State name here",". You need at least one state in each script, but you can have as many states as you want. Just be aware that, the more complex you make the script, the harder it will be to fix if something goes wrong. The script will start in the first declared state in the script (the one at the top). Functionally, the script can only be in one state at a time, so you will need to switch between states via events. Remember: Every state needs to have a unique name. Only one state can be active at any time - meaning the script will evaluate events only from the active state. Now this might have sounded a bit robotic, but the gist of it is, within your script, you need at least one state with a unique name, and you can put events that influence the map into that state. State is the only part of the script, where you need to have a semicolon ( ; ) after the closing bracket. • Events The events are the workhorses of scripts. They control the behaviour of maps, for example: casting spells on Nightmare Shard, sending attack waves, respawning enemies, timers etc. Similar to states, the events can be named. Contrary to states, the name of the event doesn't matter - it is there so you can label the event, quickly explaining what it does. You can have multiple events with the same name. Same as states, the event's contents are declared inside the { and }; brackets. Like this: OnOneTimeEvent { EventName = "Name here", Conditions = { }, Actions = { }, GotoState = "self", }; There are a number of different events you can use in your scripts, we will go into detail about them in the next part of the tutorial. At the moment, the important thing is this. All events have conditions and actions. If the conditions are met, the actions will execute. You might have already deduced what the GotoState parameter is for. Once the conditions are met, the event will execute the actions and switch into the state declared in the GotoState. You need to write the name of the state exactly as you have declared it. Note that not all events have the GotoState parameter. The GotoState parameter is optional, you can delete it if you don't intend to switch states in that event. The events contain actions and conditions, let's look at them now. Conditions Condition is a line of code that returns either true, or false. There are too many possible conditions to list here. The best way to find out what the conditions do, is simply by looking at their names and experimenting. Condition can have one, or multiple parameters. Some are optional, some are not. You can consult the scripting reference wiki for condition parameters and descriptions. Conditions are written into condition blocks of events. You can have multiple conditions inside a condition block - meaning that ALL the conditions written need to be true, for the event to execute its actions. You can also have no conditions in a condition block - meaning the event's actions will be executed instantly, because no condition is preventing the execution. Actions Action is a line of code that determines what the event will do - spawn a squad, destroy a building, send out an attack wave etc. There are too many possible actions to list here. The best way to find out what the actions do, is simply by looking at their names and experimenting. Actions are written into action blocks of events. Same as conditions, an action can have one, or multiple parameters. Some of these can get pretty long. You can consult the scripting reference wiki for action parameters and descriptions. All the defined actions will get executed in the order they are declared when the conditions are met. So if you, for example, want to spawn a squad and send it somewhere - make sure to declare the spawn action before the goto action. • Commas Notice the commas ( , ) at the ends of most lines. These commas are not optional, they separate the different blocks of code from each other. You need to put a comma ( , ) or semicolon ( ; ) after every Closing bracket } of an event, action block, and condition block Parameter inside a condition or action Extra parameter - such as StateName, EventName, GotoState and others You need to put a semicolon ( ; ) after the closing bracket } of every state. Personally, I use commas inside an event, and semicolon after the closing bracket of an event. Look at the example below (or any other examples), and notice where the commas and semicolons are written. To reiterate, States are the only parts of the script, where you need to have a semicolon ( ; ) after the closing bracket. • Next Chapter This concludes the scripting theory. It was a bit boring, I know. But in the next chapter, we will go over how we can create a fully functional script, and influence enemy squads placed on the map. • Scripting Basic Events Part 1 •

In this part of the tutorial, we will go over how to create your first map, save it and make it playable. It may seem like a pretty lengthy post for something so simple, but I just wanted to make the tutorial foolproof and cover some additional, not well known things. In reality, this step in the map creation takes about one or two minutes. If you encounter any issues, don't hesitate to ask in Skylords Reborn Map Making Discord. • Content Creating a Map Saving the Map Making the Map Playable Map Name and Description Team Setup and Player Kits Starting Location Starting Monument PAKing the Map PvP Maps Next Chapter • Creating a Map Now that we have the editor open, let's create our first map, shall we? In the top left of the editor window, click on File -> New... Now we can select the size of our map. To start with, we'll go with the smaller 256x256 map. • Saving the Map Now that we are greeted by an empty map, let's first try saving our map. (this step is optional, you can save the map at a later stage) Since we haven't done anything with the map yet, we'll need to save the map as. You can either open the File tab, or press Ctrl+Shift+S keys (notice the shortcuts next to the actions in the File tab) In the future, you can save the map after every edit you make with the Ctrl+S shortcut - this will be your best friend. You can save the map wherever you want on your computer, but the default save location is best. The reason is that the editor will pak our map into that same folder, so we have everything together. Be sure to follow the naming convention (see quote below). Unfortunately, the map editor is full of traps for map makers that crash the editor. I will try to point out any known crash or corruption causing issues as I go along (you can also check the FAQ). SAVE AS OFTEN AS YOU CAN - EVEN AFTER ONLY A COUPLE OF CHANGES • Making the Map Playable To actually see the map in the game, we first need to go through several steps: Update map name and description Setup teams and player kits Place and assign starting location for each player Place and assign starting monument for each player Let's look at the individual steps now. • Map Name and Description Now that we have saved our map, we can add an in-game map name and description. Open Map Settings -> Edit Map Description In here, we need to fill in the in-game map name and description (shown on loading screen and in map selection) for all languages. You don't need to actually translate the name and description, I used Google Translate for this example, but you can leave everything in English. Then click OK - you will get a pop-up that the map description has been successfully updated. • Team Setup and Player Kits After we've saved the map name and description, it's time to decide what type of map we'll be making - PvE / PvP and how many players. We do that by going into Map Settings -> Team Setup & Player Kits. In here, we can select if we want the map to be PvE or PvP, and how many players there should be. We can adjust the fog of war (FOW) settings for the players. And set the individual players starting power and void power (AI doesn't work with power, so there is no need to set the starting power for the NPC enemies). Ideally, choose one of the available presets! Fiddling with the teams can prevent the map from being playable. You can add more players to the teams, just don't change the team order. (Tip: Usual sweet spot for player starting power and void is 200 / 200) If you want to fiddle with the settings, you can manually add more teams with the New Team button. And add Computer players to a team selected in the list with the New Player button. Adjusting the teams and players manually comes with some risk though. Be sure to be familiar enough with the basics before experimenting with teams. For each player, you also need a player kit - that is actually what determines which players control which entities. These can be created with the New button under the Player Kit section. Let's go with the PvE 2P preset, so we can have a friend to play the map with us. After we are done making changes, click the Save button at the bottom of the window. • Starting Location Now it is time to set the player's starting position. For that, we'll need to open our first tool - Entity Placement. We can find it under Windows -> Entity Placement or Shift + E shortcut. A new window will open up - for now, we'll need the Misc tab and under the root folder, we can select the Starting Point. Now we'll have this little object following our cursor around, we can place it by left-clicking the mouse. Congratulations! You've placed your first object on the map. But we still need to make it functional. For that, we will need another tool - Entity Properties. Open it again through the Windows tab. With the Entity Properties window open, you will notice that it is completely empty. Also, that you cannot click the Starting Point you just placed, you will instead place another one. That is because we are in the Entity Placement mode, and we need to get to the Selection mode. You can do that by pressing the blue "0" button in the editor toolbar, or by pressing the Q shortcut (remember this shortcut, it will be your second-best friend). If you need to delete any extra placed Starting Point, use the Ctrl + Z shortcut for now (already on our third-best friend, let's stop counting for now). Now that we are in the proper entity selecting mode, let's select the Starting Point we just placed by clicking on it. The Entity Properties window will now show some information about the selected object. We need to assign the correct Player Kit to the Starting Point. Do that by clicking None and selecting the pk_kit1. Why pk_kit1? If you look into the Team Setup & Player Kits, you will see that the pk_kit1 is assigned to our Human pl_Player1. You might remember that I mentioned that the player kit is actually what determines who controls what squad/building. Setting up the first Starting Point is a good time to make a quick-save (Ctrl + S). Instead of selecting the Starting Point from Entity Placement again, you can select our first starting point, press Ctrl + C to copy the object and then Ctrl + V to paste the object to the location of the cursor. Under normal circumstances, copy-pasting entities preserves their team setup and their player kits. But due to the nature of the Starting Points, the player kit gets reset to None - a player cannot have multiple starting locations. So let's select our new Starting Point and assign it to our Player2 (pk_kit2). You don't need to place and assign Starting Points for the computer players. Setting up the second Starting Point is another good time to save the map. • Starting Monument We could actually see the map in-game and play it at this point, but without any structures or monuments, the player will lose instantly at the start of the map - so let's fix that! In the Entity Placement, go into the Token Slots tab and select TokenNormal. This is a standard monument. All the monuments are functionally the same, the only difference is visual - so pick whichever you want. Place one monument near Player1 Starting Point (or right under it) and another near the Player2 Starting Point. Now, we will need to assign the players to the monuments - simply click them with the Selection tool active (Q) and set it up in the Entity Properties window, same as we did for the player Starting Points. This is another great spot to save the map - by now you certainly get the message. Awesome! • PAKing the Map Saving the map is not the same as PAKing it. The editor works with .map files - that is what you save with Ctrl + S. But the game only sees a PAKed version of the map. When PAKing, the editor takes all the files associated with the map - the .map file and the map's folder - and merges them into a new file (think of WinRAR or WinZip). This PAK file can be seen by the game as the final map. Lucky for us, the editor can PAK the map - simply go to File -> PAK Map If everything is set up correctly, you will get a pop-up saying the map PAKing was successful. The PAKed map can be found in Documents/BattleForge/map folder. Now we can start the game, go to the User Generated Maps node (remember, we made a 2P PvE map) and search for the map name that you set in the Map Description step. We can actually start our map now and have a look around, exciting! Notice that when playing solo - the monument we set for the other player is missing. That is because the game automatically deletes all entities set to a human player that is not present at the start of the map. • PvP Maps Creating a PvP map is just as simple. Set up the Map Description and in the Team Setup & Player Kits step - choose whichever PvP preset you want. Place the starting positions and monuments for all the players and PAK the map. You will find your PvP maps in the Sparring Grounds node. We will not be going into further detail about PvP maps in this tutorial. • Next Chapter Now you have everything you need to get to map making. In the next chapter, we'll talk about placing and working with entities. • Working with Entities •

Welcome fellow Skylords, to the official map editor tutorial! Split into several parts, this tutorial will guide you on how to work with the BattleForge Map Editor. By the end, you will be able to create your own maps, script them, and publish them to the Community Maps section of the game. Some of the topics might seem pretty lenghty. Truth is I only wanted to be thorough when making this tutorial, as the BF Map Editor has many little quirks, and any of them may prevent you from playing your map. Don't be discouraged though, I will point out any known issues as I go along, and once you get more experience with the editor, you will find your best practises. To begin, we'll need to start the map editor. • Starting the Editor Map editor is automatically installed with the game and is located in your Battleforge installation folder - look for pluginbasededitor.exe Simply double click the exe, wait for the editor to load and congratulations! You have just launched the editor and are ready to make some awesome maps! Below is a list of tutorials we will go over, in order. • Tutorials In-Depth Tutorials These tutorials are meant to be followed in order, and are aimed at complete beginners. However they sometimes contain little details that are not widely known about the editor, so these can contain some new information even for a more experienced user. As the scripting tutorials go along, the topics covered in them get more complex. Map Work Creating a Map Working with Entities Sculpting the Terrain and Blocking Texturing the Terrain Adjusting the Playable Area and Minimap Publishing a Map Scripting Script Editors Scripting Introduction Scripting Basic Events Part 1 Scripting Basic Events Part 2 Script Groups, Script Areas and Script Paths Creating Goals Default Script Files Member Scripts and Camp Respawns Using Ifs and Loops Warfare Patterns (Coming Soon) Extra Tutorials These tutorials discuss topics that are not necessary for map creation, but can make work easier or elevate the map to another level. Importing a Heightmap Map Patches (Coming Soon) Sound Tool (Coming Soon) Creating Cutscenes (Coming Soon) Unit Aggro (Coming Soon) Template Scripts • FAQ Before we begin with the tutorial itself, here are some frequently asked questions. Note that you can always ask questions in official Skylords Reborn Map Making Discord. Q. Why cannot I see the map in the game? A. Make sure that you: set up the teams and player kits, ideally, using the available presets create and save the map description place and assign a starting position and monument for each player PAK the map look in the correct place in game - for PvE maps only - open the Community maps node, for PvP or PvPvE maps open the Sparring node Q. Can I create my own entities? Such as an XL Mauler or S sized Emberstrike? A. Unfortunately, no. BUT you can "modify" entities via the scripting tool. It is very basic and easiest is adding passive abilities. If you want to add active abilities, you also need to manually script the unit to use those abilities and where to target them, which is another problem altogether. Q. My map keeps crashing when I want to play it, what do I do? A. If you get an error message (it might be a bit tough to actually open the error message window) try to read it, it usually gives you a pointer to a script that is causing the issue, and what the issue might be. If the map crashes without an error, check for any typos in your code, or if you accidentaly put an Action into Condition block, or vise versa. If you still cannot figure it out, turn to our map making discord: Skylords Reborn Map Making Q: How can I make a unit have Boss Immunities? A. Use EntityAbilityAdd {Tag = "tag", AbilityId = 1473, ApplyToFigures = false}, With ApplyToFigures = default or true the unit will be immune to certain spells (like mind control) but still can be paralysed and frozen. Q. What are the things that can crash the editor or corrupt my map? A. Several: Cutscene editor - crashes, prevents map saving While the tool is functional, it is heavily advised to leave creating cutscenes as the absolute last part of map development. Switching maps and then changing tags of entities - crash With frequent saving, this, as any other crash, will be only a mild inconvenience. Working on a map that is not saved - crash It is best to save your map as soon as possible, the editor cannot handle working on an unsaved map for longer period of time and you will lose all your work. Selecting quest_pve_soullight object under Leveldesign folder (DBID 254) - crash Simply selecting the object in Entity Placement is enough to crash your editor. Hiding entities via Entity List - occasional crash Sometimes the editor crashes when hiding entities, it seems to mostly happen for the first couple of times you use it, just save often and you'll be fine.

Error message: WillHcX#6352 (original reporter): We were destroying fire camps to let rogan kayle go to Jorne / Brannoc. It crashed after viridya said : "Now you shall pay" before she dies and then it crashed if i remember well We did not block Rogan on his way

DESCRIPTION: On Ascension map 2 on advanced and expert difficutly there is a possibility an outcry from Viridya gets looped endless. She'll say "The giant king shall fall!" (mf_OCViridyaTeleporting03) all couple of seconds, quite annoying after a while. Looking through the scripts told me when, as long as the endfight isn't triggered (mf_EndfightStart) the Viridyas try count (mv_ViridyaTryCounter) will infinitly increase with each try she starts to escape the map (to kill Jorne in map 1). After the third try starts mf_ViridyaTryCounter will be greater than 2 and set mf_OCViridyaTeleporting03 on repeat to true which triggers the annoying outcry. REPRODUCIBILITY: As long as the endfight (have to figure out what actualy triggers it) isn't triggered, this should occur every single time. SCREENSHOT: None. LOG: None unfortunatly. ADDITIONAL INFORMATION: I've got a simple fix right here which prevents repeatingly setting the outcry flag as true. Note: This will stop any outcries to be played after the 3rd attempt starts. viridyatry.lua line 128: Original: Edited replacement:

DESCRIPTION: Rogan Kayle (aka. Maddie in the scripts) gets stuck at Scriptmarker Target "TargetMaddie". REPRODUCIBILITY: Happens when Gate 7 & 8 are activated prematurely (before - I think - either the last spawn building is destroyed or Gate 2 and 4 were activated). SCREENSHOTS: Struck Rogan: Gate 7 & 8: REPLAY: 20200926_001416_11304_PvE_04p_Titans.pmv ADDITIONAL INFORMATION: Not the cleanest of fixes, but the best I came up with is bf1>map>pve>11304_pve_04p_titans>script1>gates.lua>line:104 replace OnOneTimeEvent with new OnOneTimeEvent: OnOneTimeEvent({ Conditions = { MapFlagIsTrue({ Name = "mf_Gate07Open" }), MapFlagIsTrue({ Name = "mf_Gate08Open" }), EntityIsInRange({ -- new check to prevent premature trigger Name = "Maddie", TargetTag = "TargetMaddie", Range = 10 }) }, Actions = { SquadGroupCheckpointGoto({ Group = "sg_Civilians", TargetTag = "sg_CivilistEndstation", Run = default }), SquadCheckpointGoto({ Tag = "Maddie", TargetTag = "sg_MaddieEndstation", Run = default }) } })