forts моды на строительство
Forts моды на строительство
Forts uses Lua to configure the game. By writing your own Lua scripts you can change and add to Forts. Lua is a powerful and easy to learn scripting language. You can pick up a lot by reading the scripts included in Forts, but to get a more structured introduction I recommend the tutorials found at lua-users:
The first 8 tutorials are enough to do everything needed to mod Forts effectively.
You can use any text editor to edit Lua scripts, such as Notepad, which comes with Windows. Something more sophisticated such as Notepad++ [notepad-plus-plus.org] or Sublime Text [www.sublimetext.com] will make life easier, however. To support localisation into some non-English languages the editor will need to support UTF-16 Unicode encoding.
Forts’ data can be browsed as ordinary files. You can find it by right clicking on Forts in Steam, then properties, then local files. You will see the data directory there.
The data is divided into subdirectories according to their purpose. For example there is a directory for devices, weapons and materials. You can browse these folders to learn about how the game is set up. The game looks for specific plain text Lua files in order to get the parameters and asset filenames it needs to load and run the game.
The scripts most important to modding include:
Each weapon entry has a value called FileName. This points to a Lua file with detailed data about the appearance and behavior of the weapon. It sets the effects used while firing, reloading, being destroyed etc. It also has a value called Projectile. This value references the SaveName of an entry in the Projectiles table of the projectile_list.lua file, and so specifies which projectile to create when the weapon fires. Devices are similar to weapons but don’t need parameters relating to firing. Materials have all of their configuration data in building_materials.lua, and their appearance is in the Sprites table, including damage levels.
You can browse this material, device, weapon and projectile data to see what parameters, texture files and effects are needed to make up the game. There is quite a lot, but everything is named well and you can ask us if something doesn’t make sense. Understanding the game configuration is essential for modding the game correctly.
In the data directory you’ll see a folder called ‘mods’. If you browse that you’ll see subdirectories. Each of these is a mod. If you browse some of these mods (such as weapon_pack) you’ll see some folders and Lua files that are the same as in the base data directory.
The way mods work in Forts is that the base Lua file is loaded first, and then for each of the mods that are active, the game looks for the same Lua file in the mod’s directory and loads that on top of what’s been loaded already. So each mod can change the variables and tables of the base game. They can also change images, projectiles, and effects. They can add completely new items, disable existing items, or remove them altogether.
If you are changing a variable it is often better to multiply it by a factor, or add or subtract, instead of setting an absolute value. We make balancing changes from time to time, and an absolute change may be off the mark afterwards.
Warning: never make changes to the base game files or included mod folders. Doing so will change your experience, make the game unstable, and cause desyncs in multiplayer and when watching older replays. If you need to revert a change you can right click on Forts in Steam, then properties, then local files. Select Verify Integrity of Game Files.
Let’s take a simple example of setting gravity to zero. The value that controls gravity is in db/constants.lua, in the table called Physics, and the variable is Gravity. By default this is 981, the value of acceleration under Earth’s gravity in game units per second per second.
The first step is to create a folder under mods, let’s call it zerog. Then we create a subdirectory called db, and within that a blank text file called constants.lua. It should look like the original file containing the variable we want to mod, but under our own mod directory instead.
Now we can’t use the same format in the base constants.lua file, because that would wipe all the other values in the Physics table. Instead we can reference a value within the table like so:
(in file mods/zerog/db/constants.lua)
You also need to create a mod.lua file in mods/zerog and add the following lines:
Run Forts and go to Sandbox. Start a map and go to the Player tab. You should see under the Physics category the name of the mod folder. Select that, start the Sandbox and watch things float about. Congratulations! You’ve made your first mod.
As you know we’ve already made a zero gravity mod, and the mod name is zerogravity. We found that setting the gravity to zero wasn’t the only change needed. We also reduced the drag so ships could move faster and the maximum angle at which a strut will accept a device, and changed a few other things. You might also find that making a mod requires more changes than you anticipated.
Because there can be any number of mods active, the data being modified is not necessarily what is in the base game. The base file is loaded, then the first mod, then the next mod, and so on. Each mod is applied to the changes made by the mods before it.
The order that mods are applied in is influenced by the optional Priority value in the mod.lua file. Lower values are applied first. Higher values are applied last, and so tend to have the final say. The expected range is 1 to 10, and the default is 5. If two mods have the same priority the order is alphabetical according to the mod name (or Workshop published id).
If a mod should make a change to every item, it should have a high value for Priority so it is applied last. The fast-build mod, for example, has a building_material.lua file which iterates the material items, including any that came from mods applied before it, and adjusts their build and scrap time like so:
Also, don’t be dependent on the data being untouched. If you want your new weapon to appear in a particular location you need to look for the position of the weapon you want it to appear after and insert it after that. Examples can be found in the weapon_pack mod. The Rocket is positioned after the EMP Rocket:
This function is called once all mods have been applied, so you can do processing, calculations and call functions you’ve written yourself which may not be possible during normal script loading call. Keep in mind that earlier mods may have defined this function, so to prevent blocking them you should chain your calls. Make sure you save the previous function in a uniquely named variable, or else you could overwrite a previous mod’s value. For example, by incorporating the name of your mod. You can use it like so, where mymod is the name of your mod:
The critical file in this mod is devices/device_list.lua. The first part of this script creates new sprites based on the included textures, found in ui/textures/HUD. The DetailSprite and ButtonSprite helper functions are defined in data/ui/uihelper.lua, and the Sprites table is read by the game to create any sprites defined by the configuration script. The ‘path’ variable is set by the game to the relative or absolute path of the mod (in the case of a subscribed mod), allowing it to reference new texture assets stored in the mod’s directory. You don’t need to understand exactly how this works, but if you keep your texture files in the same location and update the names it should work.
Moving down a bit, you’ll see where the new device is added to the Devices table.
You can open devices/sandbags_large.lua to see what detailed parameters are set. This is where you would make the device behave different to other devices. You can look at the devices included with the game and the weapon_pack mod to see what variables to change and what values would be appropriate. It’s a good idea to play around with the values to see what feels good, rather than just using the first values that occur to you. Testing with friends helps to get feedback.
In the middle of the file you’ll see a new Sprites table, which sets the single-frame sprite of the sandbag to the included texture /devices/SandbagsLarge.tga. Note the use of the path variable again. The following forward slash is important as it’s not included in the path variable.
Further down you’ll see the Root table, which configures how multiple sprites fit together to make a single device. This can be a complex set of nested tables for a weapon, as there are multiple parts and a pivot where the gun rotates. This structure specifies where projectiles and beams are emitted from by creating a «Hardpoint0» child node (with no Sprite value set). If you want to create a new weapon it’s best to copy an existing one and experiment with Root until you understand how it works. The Angle, Pivot and PivotOffset values determine how child nodes are positioned relative to the parent. UserData is set to the percentage of construction at which the node will appear (or disappear on scrap).
The other gameplay related change the Large Sandbags mod does is reduce the damage the 20mm cannon does to it. You’ll find this in mods\weapon_pack\weapons\projectile_list.lua. This is a mod of a mod (or a nested mod). It’s changing the way the weapon_pack works because the damage multiplier versus a device is associated with the projectile. It is set like this:
Devices (and weapons) can have one or more upgrades, with optional prerequisites (see the Prerequisites section below). This is achieved by adding an Upgrades table to the device in device_list.lua (or weapon_list.lua for weapons).
The entries in this table set the SaveName and cost of the upgrade, and can also set a button sprite for the context menu. Although the detail sprite of the device will be shown on rollover, when there are multiple upgrades custom buttons are recommended so the player can tell them apart easily.
The ButtonSprite helper function can be used to make the button sprite so it has disabled, rollover and pressed states. The built-in textures with path ui/textures/context/HUD-Buttons-Blank-*.tga can be copied and edited to create new buttons.
Upgrades can be disabled at start by setting Enabled = false, and later enabled by mission or mod script by using the EnableDeviceUpgrade or EnableWeaponUpgrade functions.
If you are modding an existing device then make sure to insert your upgrades rather than setting the table from scratch, to prevent the loss of the existing upgrades, or those added by other mods.
By default materials and devices can be built if the player has enough resources. It’s possible, however, to add a requirement to build a certain device or a combination of devices first. This is how the ‘tech’ buildings operate to restrict construction.
Both materials and devices (which includes weapons) have the same syntax for the Prerequisites variable. If it is left as nil, then it can always be built.
If assigned to a string then at least one device with that SaveName must be built before the material or device can be constructed:
There is an obsolete method of setting an alternative required device, but we recommend you use the more flexible syntax below. In the following example the item can be built if the workshop or the armoury has been built.
You can also set up a list of combinations of device SaveNames for complex requirements. If any one of the combinations is satisfied then the item can be built. In the following example, the item can be built if the workshop and the upgrade centre is built, or the factory alone is built. This list of combinations can be as long as you like.
Device upgrades can have their own prerequisites set in the same way. If the upgrade’s Prerequisite variable is not set then it defaults to the prerequisites of the target device of the upgrade.
Right clicking on a strut will bring up a context menu, including a number of buttons with material icons. These buttons can be used to convert the strut into a different material. By default this list of materials is set to the contents of the DefaultConversions table in the base building_materials.lua file:
This list can be modified like anything, but it’s also possible to customise it for a specific material by setting the Conversions table. It’s best to merge any new materials with the DefaultConversions table, to keep the changes introduced by other mods. To allow a material to be convertible to a portal in the context menu, for example:
In order for this to work the material to be included must have the Context variable set to the name of a valid sprite. The ButtonSprite function from ui/uihelper.lua must be provided with a path in order for it to find the textures within the mod’s ui/textures folder:
You can add custom effects to your mods such as explosions, muzzle flashes, and projectile trails. These can including new textures and sound effects, or instead use existing assets from the game. Reference these new effects from your other scripts using the file’s name relative to your mod’s ‘path’, for example in a device script:
Effect scripts take the following general format, for example:
The following effect types are available:
Creates a single textured quad that can move, rotate, scale and blend between two colours. See example above.
Creates a series of bursts made up of sprites with rules about how they are positioned, sized and rotated depending on the direction they are emitted.
Creates a textured streamer which follows the position of the effect.
Makes the camera move rapidly depending on how close it is to the effect.
In Forts all languages are implemented as mods. You can inspect the base string tables in the Forts/data/mods/language-* folders to see what files are available for modding. In order to change or extend string tables for your mod you need to mod these language mods. Using the Large Sandbags mod as a reference again, you will see the following folder structure (with English expanded as an example):
If you opened mods/language-English/devices/strings.lua, you will see:
This shows how the strings describing the new device are merged into the sub-string table called Device. The string ids, like «sandbags_large», and «sandbags_largeTip2», are automatically generated from each device SaveName to look for the strings to show.
If you are replacing an existing string, you can just overwrite it, as in the Scattershot commander string.lua example:
A few features were introduced with the Moonshot DLC that are not available in the base game. If you wish to make use of these features then your mod becomes dependent on Moonshot, and can only be activated when the host of the game has it installed (which is always you in single player games). These mods are displayed with a blue Moonshot icon in the mod selection screen.
When you make a Moonshot dependent mod, you must add a flag to your mod.lua file so the game can quickly identify it as such. You may get an error message if you try to publish a mod that depends on moonshot and does not have this flag:
The features and their associated keywords which trigger dependency are outlined below. Note that if these words are found anywhere in the appropriate file it will become dependent, even if it’s out of place or in a comment.
The keyword Portal in building_materials.lua triggers dependency. This allows a material to teleport projectiles and beams when two such struts are linked by the player.
The keyword MaxBursts in a weapon script, or weapon_list.lua will trigger dependency. When used in a weapon script (e.g. machinegun.lua) the weapon will self destruct after firing that many times. This is used on the Moonshot only Buzzsaw weapon.
The keyword RayDamage in the projectile_list.lua file will trigger dependency. This is used in combination with a few other variables to create damage in a straight line when a projectile collides with a strut. The buzzsaw projectile, for example:
The keyword FieldRadius in the projectile_list.lua will trigger dependency. This is used in combination with a few other variables to create a field for various purposes. It is used to implement smoke and to attract projectiles to the magnabeam point of impact. For example, the smoke projectile uses it like so:
The options for FieldType are:
By adding a script.lua file in their root folder, mods can have arbitrary Lua script executed based on events triggered by the game, including projectile impacts, destruction of devices and weapons, ownership changes and user input. There are also events for the initial load, physics frame, display frame, and restart. Functions can also be scheduled to execute at a specific time in the future. They behave identically to mission scripts, but are not tied to a specific map.
In response to these events the mod script can perform a host of changes to the game state, create effects, or show controls on the screen. It can also track any state it wishes in the ‘data’ table, which will automatically be serialised for the purpose of replays and players joining a battle.
The details of this dynamic mod scripting can be found at the Forts Scripting API Reference [www.earthworkgames.com] page, which is generated directly from the Forts source code with mark up to provide descriptions.
To make your mod easy to find on the Steam Workshop and in the game’s mod selection screen, we recommend you put it into a category. This is set in the (optional) mod.lua file you put in the mod’s base folder. This will apply a tag to the item in the Workshop, useful for searching for those of interest. In the game it will put the mod into a branch of a tree view which can be collapsed for quick browsing.
An example mod.lua would be
If mod.lua is missing, the Category variable is not specified, or it’s invalid then the mod is placed in the Misc category. Valid categories are:
Once you are happy with how your mod is working locally, you can upload it to the Steam Workshop. Before you do this you need to create a preview.jpg file in the mod’s folder which will represent it in Forts and on Steam Workshop. The size isn’t so important, but the aspect ratio should be 16:9 so it appears correctly in Forts. The map previews are 1024*576, for example. This is fine for mods too.
Now to publish the mod, go to the main menu and then enter the Workshop menu. Go to the Upload tab and select the mod you’ve been working on. Click on the Upload button, and then Yes. After a short while it will open the new item in the workshop. You should be subscribed to it automatically, and you should make it either hidden or visible to friends only for testing. To make sure the mod will work for others, you should get a friend to subscribe to it and run the game with it. Otherwise you should rename your mod folder and run the Workshop version of the mod. This will bring to light any asset path problems that had been missed during development. Change the folder name of you mod back to edit and update once the problems are fixed.
You can force a Workshop mod on in your custom map, in the same way as a built-in mod. In your map’s mission script, add or edit the Mods table to include the published file id. For example, to make sure Large Sandbags are available in your map:
To make it easier to understand, you could write it like this instead:
Forts моды на строительство
All bfc mods
At the moment there are:
— BFC v1
— BFC v1 Complete Pack
— BFC v2
Other bfc related mods will be added in this collection.
IMPORTANT:
I’m the creator of BFCs mods and this is the original collection, any other collection with only these is a copy and they should be deleted.
Now you can use this mod in multiplayer matches as well 😀
——————————.
A BFC v1 pack with 4 differents stupid BFCs.
This pack include:
— Artillery BFC
— Disposable BFC (It blows up always)
— Surprise BFC (It’s a surpise its shot)
— Minigun BFC (spam BFC bullets)
Подпишитесь, чтобы загрузить
(WIP)Super Forts Mod v0.4.1
In this universe many have witnessed the destruction of their homes, families, and lives
and have begun to question the violence of the various faction leaders. Some decided
to try running from it all; Some decided there was no hope and just gave up, but some
decided to resist. Many of the resistance groups agreed that their best option was to
create giant fortresses to act as bases of operation; and what they created
was beyond anyone’s expectations.
Your job is to create a super fleet to put down these resistance groups.
What is this mod for?
This mods goal is give your giant fleet a challenge in the mid-late game.
What does this mod add?
This mod adds new super fort factions(Only 3 faction variants right now).
A super fort is a large non-mobile structures with lots of weapons and
armor that can only be taken down by a large fleet.
Each super fort also comes with a super weapon to give extra challenge.
What will come in the future?
-More super fort variants
-More super weapons.
Remember to tell me what you think about the mod and what additions/changes you
think would help make this mod better.
Particularly I would like to hear what you think about the difficulty of the super forts.