2019-06-03T22:08:00Z

Thexa4: /* HL2 Skies */

{{MappingDocumentation}}
__NOTOC__

This is a list of skyboxes in Empires with their corresponding recommended light settings.

=== <big>skybox/sky92</big> ===
*'''light_environment:'''
**Pitch: -20
**BrightnessHDR: 255 193 141 300
**AmbientHDR: 107 113 55 85
**SunSpreadAngle: 2
*'''shadow_control:'''
**Y Z X: 20 180 0
**Shadow Color: 140 138 100
**Maximum Distance: 800
*'''env_tonemap_controller:'''
**ExposureMin 0
**ExposureMax 1.3
**BloomScale .6
*'''env_sun:'''
**Pitch: -5
**Sun color: 249 216 147
*'''env_fog_controller:'''
**Primary Fog Color: 180 85 1
**Secondary Fog Color: 80 50 20
**Fog Start: 8000
**Fog End: 20000
**Interpolate time: 10
**Far Z Clip Plane: 20000

=== HL2 Skies ===
See: https://developer.valvesoftware.com/wiki/Sky_List#Half-Life_2

Skyboxes

2019-06-03T19:45:24Z

Thexa4:

Skyboxes

2019-06-03T19:44:36Z

Thexa4: /* Sky92 */

{{MappingDocumentation}}
__NOTOC__

=== <big>skybox/sky92</big> ===
*'''light_environment:'''
**Pitch: -20
**BrightnessHDR: 255 193 141 300
**AmbientHDR: 107 113 55 85
**SunSpreadAngle: 2
*'''shadow_control:'''
**Y Z X: 20 180 0
**Shadow Color: 140 138 100
**Maximum Distance: 800
*'''env_tonemap_controller:'''
**ExposureMin 0
**ExposureMax 1.3
**BloomScale .6
*'''env_sun:'''
**Pitch: -5
**Sun color: 249 216 147
*'''env_fog_controller:'''
**Primary Fog Color: 180 85 1
**Secondary Fog Color: 80 50 20
**Fog Start: 8000
**Fog End: 20000
**Interpolate time: 10
**Far Z Clip Plane: 20000

Skyboxes

2019-06-03T19:38:06Z

Thexa4: Created page with "{{MappingDocumentation}} __NOTOC__"

{{MappingDocumentation}}
__NOTOC__

Template:MappingDocumentation

2019-06-03T19:37:40Z

Thexa4:

{| width="100%" cellspacing="0" cellpadding="2" style="float: left; border: 0px solid #c6c9ff; background-color: #f0f0ff;" align="left"
|-
|Empires Mapping Documentation
|-
| [[Mapping|Mapping Overiew]] | [[Configuring Hammer for Empires|Hammer Configuration]] | [[Entity Index]] | [[Basic Mapping]] | [[Setting Up Map Resources|Setup Resources]] | [[Mapping Tutorials|Tutorials]] | [[Useful FGD Modifications]] | [[Bots and NPCs]] | [[Dimensions]] | [[Skyboxes]]
|-
|}

Empires Mod FAQ

2019-06-03T09:48:47Z

Thexa4: /* Why does my game keep crashing on Linux? */

{{Sitenav|Empires Mod FAQ}}

== What is the best way to describe Empires Mod? ==
Empires Mod is a Half-Life 2 [[Total Conversion]] that is best described as an [[RTS]]/[[FPS]] [[hybrid]]; a blending of the two genres. Players may take to the front lines on foot, fighting their opponents directly, or command their faction in an [[RTS]]-like manner, placing structures and assigning orders to the other players.

== What games are similar to Empires Mod? ==
A similar ancestor mod from Half-Life 1 is [http://www.unknownworlds.com/ns/ Natural Selection]. Like Empires Mod, NS has building and a very strategical play style. However, its theme is very different and it lacks vehicles.

Also similar are basically any sci-fi [[RTS]] games like Red Alert, Total Annihilation, Warzone 2100, etc. Noticable inspirations can be found in Empires Mod, such as the research tech tree and vehicle customization (Warzone 2100). Also very similar is Battlezone 2, with it's FPS and RTS hybrid.

== How much does the mod cost? ==
It's completely free for [http://store.steampowered.com/app/17740/ Download].

== Who is currently developing the mod? ==
A complete team listing can be found on the [http://empiresmod.com/static-html/team.html Empires Mod Team page].

== Where can I join an Empires Mod Clan? ==
We have a [[Clan Listing]]. This will grow in the coming months so if you don't find a clan you like there, check again in a few weeks or why not start your own!

== Why can't I find any aircraft? ==
Empires won't include [[Aircraft|aircraft]].

== Why is the game unstable at times? ==
We are still actively developing this game. As a result, some issues still exist. The development team is rather small and are doing this all for free, so these things take time. Please be patient and report any issues you may find on the official [http://forums.empiresmod.com/index.php?forums/6/ Forums].

== Where can I download some custom maps? ==
At the moment there is no specific custom map centre for Empires Mod, keep an eye on the mapping section of the [http://forums.empiresmod.com/index.php?forums/8/ Forums], as well as the [[Maps]] section here on the wiki. There is also [http://forums.empiresmod.com/index.php?threads/18454/ This] user created map pack with most of the common custom maps.

==Why does my game keep crashing on Linux?==

=== Fedora ===
Due to issues with Steam, Empires will not run unless there is a 32-bit version of libbsd installed.

=== Debian ===
Be sure to have 32bit libc installed.

== Where can I find out even more about Empires Mod? ==
Have a look at [http://empiresmod.com/docs/ the Manual], or visit the [http://forums.empiresmod.com/ Forums]. You can also ask in the main [https://discord.gg/UH6Sc6B Empires Mod Discord].

Empires Mod FAQ

2019-06-03T09:39:40Z

Thexa4: /* Why does my game keep crashing on Linux? */

{{Sitenav|Empires Mod FAQ}}

== What is the best way to describe Empires Mod? ==
Empires Mod is a Half-Life 2 [[Total Conversion]] that is best described as an [[RTS]]/[[FPS]] [[hybrid]]; a blending of the two genres. Players may take to the front lines on foot, fighting their opponents directly, or command their faction in an [[RTS]]-like manner, placing structures and assigning orders to the other players.

== What games are similar to Empires Mod? ==
A similar ancestor mod from Half-Life 1 is [http://www.unknownworlds.com/ns/ Natural Selection]. Like Empires Mod, NS has building and a very strategical play style. However, its theme is very different and it lacks vehicles.

Also similar are basically any sci-fi [[RTS]] games like Red Alert, Total Annihilation, Warzone 2100, etc. Noticable inspirations can be found in Empires Mod, such as the research tech tree and vehicle customization (Warzone 2100). Also very similar is Battlezone 2, with it's FPS and RTS hybrid.

== How much does the mod cost? ==
It's completely free for [http://store.steampowered.com/app/17740/ Download].

== Who is currently developing the mod? ==
A complete team listing can be found on the [http://empiresmod.com/static-html/team.html Empires Mod Team page].

== Where can I join an Empires Mod Clan? ==
We have a [[Clan Listing]]. This will grow in the coming months so if you don't find a clan you like there, check again in a few weeks or why not start your own!

== Why can't I find any aircraft? ==
Empires won't include [[Aircraft|aircraft]].

== Why is the game unstable at times? ==
We are still actively developing this game. As a result, some issues still exist. The development team is rather small and are doing this all for free, so these things take time. Please be patient and report any issues you may find on the official [http://forums.empiresmod.com/index.php?forums/6/ Forums].

== Where can I download some custom maps? ==
At the moment there is no specific custom map centre for Empires Mod, keep an eye on the mapping section of the [http://forums.empiresmod.com/index.php?forums/8/ Forums], as well as the [[Maps]] section here on the wiki. There is also [http://forums.empiresmod.com/index.php?threads/18454/ This] user created map pack with most of the common custom maps.

==Why does my game keep crashing on Linux?==

=== Fedora ===
Due to issues with Steam, Empires will not run unless there is a 32-bit version of libbsd installed.

== Where can I find out even more about Empires Mod? ==
Have a look at [http://empiresmod.com/docs/ the Manual], or visit the [http://forums.empiresmod.com/ Forums]. You can also ask in the main [https://discord.gg/UH6Sc6B Empires Mod Discord].

Version/2.26.x

2019-06-02T14:57:24Z

Thexa4: /* Bugfixes */

== 2.26.8 ==
=== Features ===
* "Damage to Heat"(Armor) will no longer overheat vehicle. (After this change, only the heat induced directly by enemy weaponry can overheat your vehicle, like Plasma weaponry.)

=== Bugfixes ===
* Fixed crash in vehicle hud.

=== Scripts/Game Balance===
*Absorbent Armor
**Damage to Heat Absorbed -0.2 -> -0.13 (Will reduce less heat when taking damage)
*Imperial APC
**Seats 8->7
**Cost 80->150
*NF APC
**Seats 8->7
**Cost 80->140
**Base Weight 579->569
*TOW Guided ML
**Guiding Range 6000->5500
*Salvo ML
**Damage 36->46
**Clip Size 5->4 (Missiles per salvo)
**Explosion Radius 100->125
*Advanced Salvo ML
**Damage 35->42
**Clip Size 6->5
**Explosion Radius 100->150
*Scout
**ExplosiveArtResist 0.15->0.35 (180mm/203mm/HE arty)
*Rifleman
**ExplosiveArtResist 0.15->0.35
*Grenadier
**ExplosiveArtResist 0.4->0.6
*Engineer
**ExplosiveArtResist 0.15->0.35

*NF Shotgun
**FalloffEnd 3000->3250 (Same as BE Shotgun)
*NF & BE Shotgun
**CycleTime 0.9->0.85
**JumpingSpread 0.3->0.06
**JumpingSpreadModifier 0.15->0.07
**'''Below shotgun changes can be ignored. They don't really affect gameplay but are changed to remove the potential of unwanted behaviors. They are written for logging purpose.'''
**JumpingSpreadMax 0.151->0.08
**StandingSpreadMax 0.061->0.06
**DuckingSpreadMax 0.041->0.06
**ProneSpreadMax 0.0351->0.06
**StandingSpreadIncrement 0.0022->0.001

== 2.26.7 ==
=== Features ===
* Renamed Imperial Tank to Imperial Medium Tank.
* Added key prompts to spawning related messages.

=== Bugfixes ===
* Fixed loading navmeshes from VPK files.
* Script consistency check disabled itself on second map load.

=== Scripts/Game Balance===
* ''' <big>Most CN/ML damage increased by 2% (rounded)</big> '''
** 1~2 more damage.
**Exceptions:
***Artillery Cannons
***Nuke
***Standard weapons

*Imperial AFV
** Gains 2 more degrees of front-side turret depression (can aim lower)
*Reactive Armor
**Health 120 -> 125
*Deflective Armor
**BioArtResist 0 -> 0.1 (Bio Cannon) (This is to fix an inconsistency)
*Absorbent Armor
**APBulletResist 0.15 -> 0.1 (5% less resist against vehicle MG)
**BulletExplosive 0.15 -> 0.1 (5% less resist against vehicle MG)
**Damage to Heat Absorbed -0.3 -> -0.2 (Will reduce less heat when taking damage)
*Capacitive Armor
**Health 160 -> 170
*Guided ML
**Guiding Range 5500->5000
*TOW Guided ML
**Guiding Range 6500->6000
*Homing ML
**Lock Range Modifier 0.0003 -> 0.0005 (At 5000 range, it would take 1 more second than now to lock-on)
*Improved Homing ML
**Lock Range Modifier 0.00029 -> 0.00045(At 5000 range, it would take 0.8 more second than now to lock-on)
*Salvo Homing ML
**Lock Range Modifier 0.0004 -> 0.0005(At 5000 range, it would take 0.5 more second than now to lock-on)
*Upgraded ML
**Heat 8.5->9.5
**Reload Time 4->5
*Heavy-duty ML
**Reload Time 4.5->5.5

== 2.26.6 ==
=== Bugfixes ===
* Updated main menu layout.
* Fix crash when executing npc_create on server console.
* Attempt to reduce water rendering issues.
* More autobalance fixes.

== 2.26.5 ==
=== Features ===
* Added Patreon button to main menu.

=== Scripts/Game Balance ===
*Building Carcass Removal Time
**Barrack 25->15
**Radar 20->10
**Repair Pad 25->20
**Vehicle Factory 25->20

=== Bugfixes ===
* Discord button now becomes gray when hovered over.
* Autobalance fixes.
* Fixed a bug that could crash the commander.
* Fixed a bug that would crash the game when quitting.
* Fixed a bug that could crash the server when making an engineer buildable.

== 2.26.4 ==
=== Features ===
* Added discord link to main menu.

=== Game Balance ===
* Rifleman dig-in skill
** Stamina consumption doubled : 25% of damage -> 50% of damage '''(damage reduction remains at 25%)'''

=== Bugfixes ===
* Added emp_sv_official_portoverride <port> configuration variable to allow fix official gameserver status detection.

== 2.26.3 ==
=== Bugfixes ===
* Fix that recycling < 1 res per tick does not display message.
* Fixed coordinate calculation.
* Fixed a big performance issue for players playing from a hard disk instead of an SSD.
* Fixed a problem where the client could crash due to turret gibs.

== 2.26.2 ==
=== Features ===
* Recycling unbuilt building now gives 85% refund instead of 33%*(building hp percentage), recycle time is also reduced to half.
* Recycling built building now gives 50% refund instead of 50%*(building hp percentage)
* You can now recycle a building regardless of its current hp. (previously you couldn't recycle a building if it has less than 20 hp)
* Recycling unbuilt building now takes 1/2 time.
* Unbuilt building carcass time halved.
* Unbuilt building takes 25% more damage.
* Grenadier bots are now more accurate and have less pitch spread.

=== Bugfixes ===
* New models now have collision meshes.
* Game no longer crashes when you exit the game.
* Fixed crash bug when changing resolution while playing.
* Should now gain XP if the server you're playing on becomes official while playing.

== 2.26.1 ==
=== Features ===
* Going out of stamina no longer makes you exhausted.
* Sprinting can only be started if you have at least one bar of stamina left.
* Jumping is only possible if you have at least 3 bars of stamina left.
* Sprinting stops if you have zero stamina and automatically resumes once you have one bar.
* Grenadier [[NPC]]s are less likely to clump together.
* Riflemen [[NPC]]s will ignore hits that are made at a very long distance.

=== Scripts ===
* Walls cost increased from 18 to 20.

=== Bugfixes ===
* Faster official gameserver detection.
* New grenadiers are now available in Hammer as well.
* sv_emp_vehicle_fadeout is now limited to 500 seconds.
* emp_sv_vehicle_fadeout_time_partial is now limited to 100 seconds.
* More lake trees now have collisions.

[[Category:Patch_Notes]]

Workflow

2019-05-30T22:31:48Z

Thexa4: /* Merging Requests Into Alpha */

This page describes the workflow from a concept until release. Try to follow this when developing a new feature or releasing a new Empires version.

If you're working on something that impacts user experience or gamedesign, please look at the [[Guiding Principles]]

== Creating an Issue ==

To ensure we don't duplicate effort and to allow team members to see what we're working on we add a short description of the thing we're trying to fix / achieve to an issue on the internal [https://git.empiresmod.com/empires_assets/empires_build/issues issue tracker].

An issue is a new feature, known bug, known exploit or anything that requires developer work/discussion.

When adding an issue, try to stick to formulating it as a [https://www.mountaingoatsoftware.com/agile/user-stories user story]. This makes it easier to evaluate whether a proposed change actually fixes the issue. To help discoverability you can add relevant tags.

If you plan on working on the issue yourself, be sure to assign yourself to it. For more information on how you can effectively use issues you can refer to the [https://docs.gitlab.com/ce/user/project/issues/index.html official issue documentation].

== Cloning the Relevant Repository ==
''If you've already performed this step in the past you can ignore this section''

# Make sure you have an account on the internal [https://git.empiresmod.com gitlab] and have received the appropriate permissions.
# Make sure you have [[Adding Public Key to Gitlab | added your public key]] to your acccount.
# Clone <code>git@git.empiresmod.com:empires_assets/empires_build.git</code> in a location of your choosing. Make sure you have at least 30gb free space.
# Double click the <code>setup.bat</code> file on Windows or the <code>setup</code> file on Linux and wait for the process to finish.
# Double click the <code>preview.bat</code> file on Windows or the <code>preview</code> file on Linux and wait for the process to finish.
# You should now have a development version of Empires you can run in your preview folder.

== C++ development setup ==

To get started with C++ development you just need to checkout [https://git.empiresmod.com/empires_code/empires_main empires_main] and copy the file from steam (Steam\steamapps\common\Empires\empires) to empires_main/mp/game/empires. For more details on Visual Studio setup check the README in the repo.

If you also want to make changes to [https://git.empiresmod.com/empires_assets/assets_base assets_base] and [https://git.empiresmod.com/empires_public/empires_scripts empires_scripts] and test them with your C++ changes, you can best checkout those repos next to the empires_main repo and then edit empires_main/mp/game/empires/gameinfo.txt

SearchPaths {
game+mod |gameinfo_path|../../../../assets_base // <<--- Add this
game+mod |gameinfo_path|../../../../empires_scripts // <<--- Add this
game+mod |gameinfo_path|custom/*

== Creating a New Branch ==
# Figure out which repository you should be editing. The <code>repos</code> folder contains a list of all the repositories you have access to.
# Figure out if the issue you're working on should be categorized as a bugfix or as a feature. Bugfixes are changes which don't change the intended behavior of the game but purely fix a previous mistake. The rest are features.
# [https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging Create a new branch] named <code>bugfix/your-description</code> or <code>feature/your-description</code> based on the master or develop branch. (Not all repositories have a develop branch, use master in that case)
# Start working on this branch and regularly commit your changes. You can create a new preview for testing by clicking the preview script again. This will include the changes you just made.

== Creating a Merge Request ==
# Push your changes to the remote server. In the console output you'll see a link you can visit to create a new merge request. If there is no link you can also manually go to the project in [https://git.empiresmod.com gitlab] and click on the New Merge Request button under the Merge Request tab.
# Give the merge request a descriptive title and mention the issue number in the description as follows: <code>#123</code>
# If your changes are not yet done or they don't yet pass all the build tests it's recommended to prefix the name of your merge request with <code>WIP: </code>. This is a signal to reviewers that they should wait a bit until they spend time reviewing the change.
# Try to describe in the description field what you had to change and why.
# Configure the merge request to delete the source branch when it is merged. If you don't know how to do this you can skip this step.

== Reviewing a Merge Request ==
# Start with a code review. A code review is meant to improve code quality and distributes knowledge about the codebase between team members. Code review is not meant to catch errors / bugs although it's not a problem if it does. Try to review the code on the following areas:
#* Feature Completion (Does this change actually address the issue referenced)
#* Side Effects (Does this change only impact the issue or does it negatively influence other features)
#* Readability and Maintenance (The codebase is now 10+ years old and will probably have to be used for a long time, make sure we don't reduce our [https://en.wikipedia.org/wiki/Velocity_%28software_development%29 velocity])
#* Consistency (Does the code look the same as the surrounding code and does it solve problems in the same way as we do elsewhere)
#* Performance (If we can improve performance without impacting Readability and Maintenance or other side effects we should probably do so. When in doubt, measure the performance using [https://msdn.microsoft.com/en-us/library/ms182372.aspx profiling]).
#* Simplicity (Simpler code is usually better, even when it reduces performance)
#* [https://en.wikipedia.org/wiki/Code_reuse Reuse] of Existing Code (A lot of our code looks copy pasted, we can reuse a lot more than we currently do. Try to review whether there is code that can be reused)
#* Source Files (Make sure we have source files for all compiled assets that are in the merge request)
# Test the code. Check out the code and create a preview to test with on a local listen server.
# If everything works as intended add a thumbs up smiley as a response.

== Merging Requests Into Alpha ==
You generally want to merge bugfixes as fast as possible. If you plan on releasing another point release (2.14.3 -> 2.14.4) you should probably wait with merging new features. Merging new features usually results in more bugs so queuing them for the next minor release (2.14.3 -> 2.15.1) is advised.

Once the Continuous Integration has been run after the merge you can press the play button on the empires_build [https://git.empiresmod.com/empires_assets/empires_build/pipelines Pipelines] tab for the newly created version. After that has finished the alpha branch on Steam should have the latest development build. If you don't have the alpha branch on steam, please ask for the password on the dev chat.

== Preparing a Beta Release ==
# Update the version in the alpha branch. Never release the game twice with the same version number, it'll cause weird issues if people try to connect to servers with the wrong version.
# Add the changes in this release to the [[Changelog]].
# Push the new release to alpha.
# Create a new merge request from alpha to beta. Make sure to uncheck the box that removes the source branch.
# Test the alpha with some developers. If you encounter issues, fix them before releasing to beta.

== Preparing a Full Release ==
# Merge the pull request from alpha to beta
# Schedule a beta test and a beta server.
## Post the beta test on [https://forums.empiresmod.com the forum]
## Post the beta test on [https://reddit.com/r/Empires reddit]
# If you encounter issues, prepare a new Beta Release with a new version number until you're ready to release it.

== Releasing a New Version ==
# On the Steam Partner page:
## Publish the latest beta to the default channel for the server
## Publish the latest beta to the default channel for the client
## Update the dedicated server version for the client
## Publish the store changes for the server
## Publish the store changes for the client
# Restart the Lobby.
# Publish the changelog as a [http://steamcommunity.com/games/empires/announcements/create steam announcement]
# Publish the changelog to [https://reddit.com/r/Empires Reddit]
# Publish the changelog to [https://forums.empiresmod.com the forum]
# Publish the changelog to [http://www.moddb.com/mods/empires Moddb]
# Publish the changelog to [https://discord.gg/UH6Sc6B Discord]

Workflow

2019-05-30T22:16:15Z

Thexa4: /* Releasing a New Version */

This page describes the workflow from a concept until release. Try to follow this when developing a new feature or releasing a new Empires version.

If you're working on something that impacts user experience or gamedesign, please look at the [[Guiding Principles]]

== Creating an Issue ==

To ensure we don't duplicate effort and to allow team members to see what we're working on we add a short description of the thing we're trying to fix / achieve to an issue on the internal [https://git.empiresmod.com/empires_assets/empires_build/issues issue tracker].

An issue is a new feature, known bug, known exploit or anything that requires developer work/discussion.

When adding an issue, try to stick to formulating it as a [https://www.mountaingoatsoftware.com/agile/user-stories user story]. This makes it easier to evaluate whether a proposed change actually fixes the issue. To help discoverability you can add relevant tags.

If you plan on working on the issue yourself, be sure to assign yourself to it. For more information on how you can effectively use issues you can refer to the [https://docs.gitlab.com/ce/user/project/issues/index.html official issue documentation].

== Cloning the Relevant Repository ==
''If you've already performed this step in the past you can ignore this section''

# Make sure you have an account on the internal [https://git.empiresmod.com gitlab] and have received the appropriate permissions.
# Make sure you have [[Adding Public Key to Gitlab | added your public key]] to your acccount.
# Clone <code>git@git.empiresmod.com:empires_assets/empires_build.git</code> in a location of your choosing. Make sure you have at least 30gb free space.
# Double click the <code>setup.bat</code> file on Windows or the <code>setup</code> file on Linux and wait for the process to finish.
# Double click the <code>preview.bat</code> file on Windows or the <code>preview</code> file on Linux and wait for the process to finish.
# You should now have a development version of Empires you can run in your preview folder.

== C++ development setup ==

To get started with C++ development you just need to checkout [https://git.empiresmod.com/empires_code/empires_main empires_main] and copy the file from steam (Steam\steamapps\common\Empires\empires) to empires_main/mp/game/empires. For more details on Visual Studio setup check the README in the repo.

If you also want to make changes to [https://git.empiresmod.com/empires_assets/assets_base assets_base] and [https://git.empiresmod.com/empires_public/empires_scripts empires_scripts] and test them with your C++ changes, you can best checkout those repos next to the empires_main repo and then edit empires_main/mp/game/empires/gameinfo.txt

SearchPaths {
game+mod |gameinfo_path|../../../../assets_base // <<--- Add this
game+mod |gameinfo_path|../../../../empires_scripts // <<--- Add this
game+mod |gameinfo_path|custom/*

== Creating a New Branch ==
# Figure out which repository you should be editing. The <code>repos</code> folder contains a list of all the repositories you have access to.
# Figure out if the issue you're working on should be categorized as a bugfix or as a feature. Bugfixes are changes which don't change the intended behavior of the game but purely fix a previous mistake. The rest are features.
# [https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging Create a new branch] named <code>bugfix/your-description</code> or <code>feature/your-description</code> based on the master or develop branch. (Not all repositories have a develop branch, use master in that case)
# Start working on this branch and regularly commit your changes. You can create a new preview for testing by clicking the preview script again. This will include the changes you just made.

== Creating a Merge Request ==
# Push your changes to the remote server. In the console output you'll see a link you can visit to create a new merge request. If there is no link you can also manually go to the project in [https://git.empiresmod.com gitlab] and click on the New Merge Request button under the Merge Request tab.
# Give the merge request a descriptive title and mention the issue number in the description as follows: <code>#123</code>
# If your changes are not yet done or they don't yet pass all the build tests it's recommended to prefix the name of your merge request with <code>WIP: </code>. This is a signal to reviewers that they should wait a bit until they spend time reviewing the change.
# Try to describe in the description field what you had to change and why.
# Configure the merge request to delete the source branch when it is merged. If you don't know how to do this you can skip this step.

== Reviewing a Merge Request ==
# Start with a code review. A code review is meant to improve code quality and distributes knowledge about the codebase between team members. Code review is not meant to catch errors / bugs although it's not a problem if it does. Try to review the code on the following areas:
#* Feature Completion (Does this change actually address the issue referenced)
#* Side Effects (Does this change only impact the issue or does it negatively influence other features)
#* Readability and Maintenance (The codebase is now 10+ years old and will probably have to be used for a long time, make sure we don't reduce our [https://en.wikipedia.org/wiki/Velocity_%28software_development%29 velocity])
#* Consistency (Does the code look the same as the surrounding code and does it solve problems in the same way as we do elsewhere)
#* Performance (If we can improve performance without impacting Readability and Maintenance or other side effects we should probably do so. When in doubt, measure the performance using [https://msdn.microsoft.com/en-us/library/ms182372.aspx profiling]).
#* Simplicity (Simpler code is usually better, even when it reduces performance)
#* [https://en.wikipedia.org/wiki/Code_reuse Reuse] of Existing Code (A lot of our code looks copy pasted, we can reuse a lot more than we currently do. Try to review whether there is code that can be reused)
#* Source Files (Make sure we have source files for all compiled assets that are in the merge request)
# Test the code. Check out the code and create a preview to test with on a local listen server.
# If everything works as intended add a thumbs up smiley as a response.

== Merging Requests Into Alpha ==
You generally want to merge bugfixes as fast as possible. If you plan on releasing another point release (2.14.3 -> 2.14.4) you should probably wait with merging new features. Merging new features usually results in more bugs so queuing them for the next minor release (2.14.3 -> 2.15.1) is advised.

Once the Continuous Integration has been run after the merge you can press the play button on the empires_build [https://git.empiresmod.com/empires_assets/empires_build/pipelines Pipelines] tab for the newly created version. After that has finished the alpha branch on Steam should have the latest development build. If you don't have the alpha branch on steam, please ask for the password on Hipchat.

== Preparing a Beta Release ==
# Update the version in the alpha branch. Never release the game twice with the same version number, it'll cause weird issues if people try to connect to servers with the wrong version.
# Add the changes in this release to the [[Changelog]].
# Push the new release to alpha.
# Create a new merge request from alpha to beta. Make sure to uncheck the box that removes the source branch.
# Test the alpha with some developers. If you encounter issues, fix them before releasing to beta.

== Preparing a Full Release ==
# Merge the pull request from alpha to beta
# Schedule a beta test and a beta server.
## Post the beta test on [https://forums.empiresmod.com the forum]
## Post the beta test on [https://reddit.com/r/Empires reddit]
# If you encounter issues, prepare a new Beta Release with a new version number until you're ready to release it.

== Releasing a New Version ==
# On the Steam Partner page:
## Publish the latest beta to the default channel for the server
## Publish the latest beta to the default channel for the client
## Update the dedicated server version for the client
## Publish the store changes for the server
## Publish the store changes for the client
# Restart the Lobby.
# Publish the changelog as a [http://steamcommunity.com/games/empires/announcements/create steam announcement]
# Publish the changelog to [https://reddit.com/r/Empires Reddit]
# Publish the changelog to [https://forums.empiresmod.com the forum]
# Publish the changelog to [http://www.moddb.com/mods/empires Moddb]
# Publish the changelog to [https://discord.gg/UH6Sc6B Discord]

Workflow

2019-05-30T21:47:57Z

Thexa4: /* Releasing a New Version */

This page describes the workflow from a concept until release. Try to follow this when developing a new feature or releasing a new Empires version.

If you're working on something that impacts user experience or gamedesign, please look at the [[Guiding Principles]]

== Creating an Issue ==

To ensure we don't duplicate effort and to allow team members to see what we're working on we add a short description of the thing we're trying to fix / achieve to an issue on the internal [https://git.empiresmod.com/empires_assets/empires_build/issues issue tracker].

An issue is a new feature, known bug, known exploit or anything that requires developer work/discussion.

When adding an issue, try to stick to formulating it as a [https://www.mountaingoatsoftware.com/agile/user-stories user story]. This makes it easier to evaluate whether a proposed change actually fixes the issue. To help discoverability you can add relevant tags.

If you plan on working on the issue yourself, be sure to assign yourself to it. For more information on how you can effectively use issues you can refer to the [https://docs.gitlab.com/ce/user/project/issues/index.html official issue documentation].

== Cloning the Relevant Repository ==
''If you've already performed this step in the past you can ignore this section''

# Make sure you have an account on the internal [https://git.empiresmod.com gitlab] and have received the appropriate permissions.
# Make sure you have [[Adding Public Key to Gitlab | added your public key]] to your acccount.
# Clone <code>git@git.empiresmod.com:empires_assets/empires_build.git</code> in a location of your choosing. Make sure you have at least 30gb free space.
# Double click the <code>setup.bat</code> file on Windows or the <code>setup</code> file on Linux and wait for the process to finish.
# Double click the <code>preview.bat</code> file on Windows or the <code>preview</code> file on Linux and wait for the process to finish.
# You should now have a development version of Empires you can run in your preview folder.

== C++ development setup ==

To get started with C++ development you just need to checkout [https://git.empiresmod.com/empires_code/empires_main empires_main] and copy the file from steam (Steam\steamapps\common\Empires\empires) to empires_main/mp/game/empires. For more details on Visual Studio setup check the README in the repo.

If you also want to make changes to [https://git.empiresmod.com/empires_assets/assets_base assets_base] and [https://git.empiresmod.com/empires_public/empires_scripts empires_scripts] and test them with your C++ changes, you can best checkout those repos next to the empires_main repo and then edit empires_main/mp/game/empires/gameinfo.txt

SearchPaths {
game+mod |gameinfo_path|../../../../assets_base // <<--- Add this
game+mod |gameinfo_path|../../../../empires_scripts // <<--- Add this
game+mod |gameinfo_path|custom/*

== Creating a New Branch ==
# Figure out which repository you should be editing. The <code>repos</code> folder contains a list of all the repositories you have access to.
# Figure out if the issue you're working on should be categorized as a bugfix or as a feature. Bugfixes are changes which don't change the intended behavior of the game but purely fix a previous mistake. The rest are features.
# [https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging Create a new branch] named <code>bugfix/your-description</code> or <code>feature/your-description</code> based on the master or develop branch. (Not all repositories have a develop branch, use master in that case)
# Start working on this branch and regularly commit your changes. You can create a new preview for testing by clicking the preview script again. This will include the changes you just made.

== Creating a Merge Request ==
# Push your changes to the remote server. In the console output you'll see a link you can visit to create a new merge request. If there is no link you can also manually go to the project in [https://git.empiresmod.com gitlab] and click on the New Merge Request button under the Merge Request tab.
# Give the merge request a descriptive title and mention the issue number in the description as follows: <code>#123</code>
# If your changes are not yet done or they don't yet pass all the build tests it's recommended to prefix the name of your merge request with <code>WIP: </code>. This is a signal to reviewers that they should wait a bit until they spend time reviewing the change.
# Try to describe in the description field what you had to change and why.
# Configure the merge request to delete the source branch when it is merged. If you don't know how to do this you can skip this step.

== Reviewing a Merge Request ==
# Start with a code review. A code review is meant to improve code quality and distributes knowledge about the codebase between team members. Code review is not meant to catch errors / bugs although it's not a problem if it does. Try to review the code on the following areas:
#* Feature Completion (Does this change actually address the issue referenced)
#* Side Effects (Does this change only impact the issue or does it negatively influence other features)
#* Readability and Maintenance (The codebase is now 10+ years old and will probably have to be used for a long time, make sure we don't reduce our [https://en.wikipedia.org/wiki/Velocity_%28software_development%29 velocity])
#* Consistency (Does the code look the same as the surrounding code and does it solve problems in the same way as we do elsewhere)
#* Performance (If we can improve performance without impacting Readability and Maintenance or other side effects we should probably do so. When in doubt, measure the performance using [https://msdn.microsoft.com/en-us/library/ms182372.aspx profiling]).
#* Simplicity (Simpler code is usually better, even when it reduces performance)
#* [https://en.wikipedia.org/wiki/Code_reuse Reuse] of Existing Code (A lot of our code looks copy pasted, we can reuse a lot more than we currently do. Try to review whether there is code that can be reused)
#* Source Files (Make sure we have source files for all compiled assets that are in the merge request)
# Test the code. Check out the code and create a preview to test with on a local listen server.
# If everything works as intended add a thumbs up smiley as a response.

== Merging Requests Into Alpha ==
You generally want to merge bugfixes as fast as possible. If you plan on releasing another point release (2.14.3 -> 2.14.4) you should probably wait with merging new features. Merging new features usually results in more bugs so queuing them for the next minor release (2.14.3 -> 2.15.1) is advised.

Once the Continuous Integration has been run after the merge you can press the play button on the empires_build [https://git.empiresmod.com/empires_assets/empires_build/pipelines Pipelines] tab for the newly created version. After that has finished the alpha branch on Steam should have the latest development build. If you don't have the alpha branch on steam, please ask for the password on Hipchat.

== Preparing a Beta Release ==
# Update the version in the alpha branch. Never release the game twice with the same version number, it'll cause weird issues if people try to connect to servers with the wrong version.
# Add the changes in this release to the [[Changelog]].
# Push the new release to alpha.
# Create a new merge request from alpha to beta. Make sure to uncheck the box that removes the source branch.
# Test the alpha with some developers. If you encounter issues, fix them before releasing to beta.

== Preparing a Full Release ==
# Merge the pull request from alpha to beta
# Schedule a beta test and a beta server.
## Post the beta test on [https://forums.empiresmod.com the forum]
## Post the beta test on [https://reddit.com/r/Empires reddit]
# If you encounter issues, prepare a new Beta Release with a new version number until you're ready to release it.

== Releasing a New Version ==
# On the Steam Partner page:
## Publish the latest beta to the default channel for the server
## Publish the latest beta to the default channel for the client
## Update the dedicated server version for the client
## Publish the store changes for the server
## Publish the store changes for the client
# Publish the changelog as a [http://steamcommunity.com/games/empires/announcements/create steam announcement]
# Publish the changelog to [https://reddit.com/r/Empires Reddit]
# Publish the changelog to [https://forums.empiresmod.com the forum]
# Publish the changelog to [http://www.moddb.com/mods/empires Moddb]
# Publish the changelog to [https://discord.gg/UH6Sc6B Discord]

Workflow

2019-05-30T21:47:34Z

Thexa4: /* Releasing a New Version */

This page describes the workflow from a concept until release. Try to follow this when developing a new feature or releasing a new Empires version.

If you're working on something that impacts user experience or gamedesign, please look at the [[Guiding Principles]]

== Creating an Issue ==

To ensure we don't duplicate effort and to allow team members to see what we're working on we add a short description of the thing we're trying to fix / achieve to an issue on the internal [https://git.empiresmod.com/empires_assets/empires_build/issues issue tracker].

An issue is a new feature, known bug, known exploit or anything that requires developer work/discussion.

When adding an issue, try to stick to formulating it as a [https://www.mountaingoatsoftware.com/agile/user-stories user story]. This makes it easier to evaluate whether a proposed change actually fixes the issue. To help discoverability you can add relevant tags.

If you plan on working on the issue yourself, be sure to assign yourself to it. For more information on how you can effectively use issues you can refer to the [https://docs.gitlab.com/ce/user/project/issues/index.html official issue documentation].

== Cloning the Relevant Repository ==
''If you've already performed this step in the past you can ignore this section''

# Make sure you have an account on the internal [https://git.empiresmod.com gitlab] and have received the appropriate permissions.
# Make sure you have [[Adding Public Key to Gitlab | added your public key]] to your acccount.
# Clone <code>git@git.empiresmod.com:empires_assets/empires_build.git</code> in a location of your choosing. Make sure you have at least 30gb free space.
# Double click the <code>setup.bat</code> file on Windows or the <code>setup</code> file on Linux and wait for the process to finish.
# Double click the <code>preview.bat</code> file on Windows or the <code>preview</code> file on Linux and wait for the process to finish.
# You should now have a development version of Empires you can run in your preview folder.

== C++ development setup ==

To get started with C++ development you just need to checkout [https://git.empiresmod.com/empires_code/empires_main empires_main] and copy the file from steam (Steam\steamapps\common\Empires\empires) to empires_main/mp/game/empires. For more details on Visual Studio setup check the README in the repo.

If you also want to make changes to [https://git.empiresmod.com/empires_assets/assets_base assets_base] and [https://git.empiresmod.com/empires_public/empires_scripts empires_scripts] and test them with your C++ changes, you can best checkout those repos next to the empires_main repo and then edit empires_main/mp/game/empires/gameinfo.txt

SearchPaths {
game+mod |gameinfo_path|../../../../assets_base // <<--- Add this
game+mod |gameinfo_path|../../../../empires_scripts // <<--- Add this
game+mod |gameinfo_path|custom/*

== Creating a New Branch ==
# Figure out which repository you should be editing. The <code>repos</code> folder contains a list of all the repositories you have access to.
# Figure out if the issue you're working on should be categorized as a bugfix or as a feature. Bugfixes are changes which don't change the intended behavior of the game but purely fix a previous mistake. The rest are features.
# [https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging Create a new branch] named <code>bugfix/your-description</code> or <code>feature/your-description</code> based on the master or develop branch. (Not all repositories have a develop branch, use master in that case)
# Start working on this branch and regularly commit your changes. You can create a new preview for testing by clicking the preview script again. This will include the changes you just made.

== Creating a Merge Request ==
# Push your changes to the remote server. In the console output you'll see a link you can visit to create a new merge request. If there is no link you can also manually go to the project in [https://git.empiresmod.com gitlab] and click on the New Merge Request button under the Merge Request tab.
# Give the merge request a descriptive title and mention the issue number in the description as follows: <code>#123</code>
# If your changes are not yet done or they don't yet pass all the build tests it's recommended to prefix the name of your merge request with <code>WIP: </code>. This is a signal to reviewers that they should wait a bit until they spend time reviewing the change.
# Try to describe in the description field what you had to change and why.
# Configure the merge request to delete the source branch when it is merged. If you don't know how to do this you can skip this step.

== Reviewing a Merge Request ==
# Start with a code review. A code review is meant to improve code quality and distributes knowledge about the codebase between team members. Code review is not meant to catch errors / bugs although it's not a problem if it does. Try to review the code on the following areas:
#* Feature Completion (Does this change actually address the issue referenced)
#* Side Effects (Does this change only impact the issue or does it negatively influence other features)
#* Readability and Maintenance (The codebase is now 10+ years old and will probably have to be used for a long time, make sure we don't reduce our [https://en.wikipedia.org/wiki/Velocity_%28software_development%29 velocity])
#* Consistency (Does the code look the same as the surrounding code and does it solve problems in the same way as we do elsewhere)
#* Performance (If we can improve performance without impacting Readability and Maintenance or other side effects we should probably do so. When in doubt, measure the performance using [https://msdn.microsoft.com/en-us/library/ms182372.aspx profiling]).
#* Simplicity (Simpler code is usually better, even when it reduces performance)
#* [https://en.wikipedia.org/wiki/Code_reuse Reuse] of Existing Code (A lot of our code looks copy pasted, we can reuse a lot more than we currently do. Try to review whether there is code that can be reused)
#* Source Files (Make sure we have source files for all compiled assets that are in the merge request)
# Test the code. Check out the code and create a preview to test with on a local listen server.
# If everything works as intended add a thumbs up smiley as a response.

== Merging Requests Into Alpha ==
You generally want to merge bugfixes as fast as possible. If you plan on releasing another point release (2.14.3 -> 2.14.4) you should probably wait with merging new features. Merging new features usually results in more bugs so queuing them for the next minor release (2.14.3 -> 2.15.1) is advised.

Once the Continuous Integration has been run after the merge you can press the play button on the empires_build [https://git.empiresmod.com/empires_assets/empires_build/pipelines Pipelines] tab for the newly created version. After that has finished the alpha branch on Steam should have the latest development build. If you don't have the alpha branch on steam, please ask for the password on Hipchat.

== Preparing a Beta Release ==
# Update the version in the alpha branch. Never release the game twice with the same version number, it'll cause weird issues if people try to connect to servers with the wrong version.
# Add the changes in this release to the [[Changelog]].
# Push the new release to alpha.
# Create a new merge request from alpha to beta. Make sure to uncheck the box that removes the source branch.
# Test the alpha with some developers. If you encounter issues, fix them before releasing to beta.

== Preparing a Full Release ==
# Merge the pull request from alpha to beta
# Schedule a beta test and a beta server.
## Post the beta test on [https://forums.empiresmod.com the forum]
## Post the beta test on [https://reddit.com/r/Empires reddit]
# If you encounter issues, prepare a new Beta Release with a new version number until you're ready to release it.

== Releasing a New Version ==
# On the Steam Partner page:
## Publish the latest beta to the default channel for the server
## Publish the latest beta to the default channel for the client
## Update the dedicated server version for the client
## Publish the store changes for the server
## Publish the store changes for the client
# Publish the changelog as a [http://steamcommunity.com/games/empires/announcements/create steam announcement]
# Publish the changelog to [https://reddit.com/r/Empires Reddit]
# Publish the changelog to [https://forums.empiresmod.com the forum]
# Publish the changelog to [http://www.moddb.com/mods/empires Moddb]

Version/2.26.x

2019-05-25T00:10:01Z

Thexa4: /* Bugfixes */

== 2.26.7 ==
=== Features ===
* Renamed Imperial Tank to Imperial Medium Tank.
* Added key prompts to spawning related messages.

=== Bugfixes ===
* Fixed loading navmeshes from VPK files.
* Script consistency check disabled itself on second map load.

=== Scripts/Game Balance===
* ''' <big>Most CN/ML damage increased by 2% (rounded)</big> '''
** 1~2 more damage.
**Exceptions:
***Artillery Cannons
***Nuke
***Standard weapons

*Imperial AFV
** Gains 2 more degrees of front-side turret depression (can aim lower)
*Reactive Armor
**Health 120 -> 125
*Deflective Armor
**BioArtResist 0 -> 0.1 (Bio Cannon) (This is to fix an inconsistency)
*Absorbent Armor
**APBulletResist 0.15 -> 0.1 (5% less resist against vehicle MG)
**BulletExplosive 0.15 -> 0.1 (5% less resist against vehicle MG)
**Damage to Heat Absorbed -0.3 -> -0.2 (Will reduce less heat when taking damage)
*Capacitive Armor
**Health 160 -> 170
*Guided ML
**Guiding Range 5500->5000
*TOW Guided ML
**Guiding Range 6500->6000
*Homing ML
**Lock Range Modifier 0.0003 -> 0.0005 (At 5000 range, it would take 1 more second than now to lock-on)
*Improved Homing ML
**Lock Range Modifier 0.00029 -> 0.00045(At 5000 range, it would take 0.8 more second than now to lock-on)
*Salvo Homing ML
**Lock Range Modifier 0.0004 -> 0.0005(At 5000 range, it would take 0.5 more second than now to lock-on)
*Upgraded ML
**Heat 8.5->9.5
**Reload Time 4->5
*Heavy-duty ML
**Reload Time 4.5->5.5

== 2.26.6 ==
=== Bugfixes ===
* Updated main menu layout.
* Fix crash when executing npc_create on server console.
* Attempt to reduce water rendering issues.
* More autobalance fixes.

== 2.26.5 ==
=== Features ===
* Added Patreon button to main menu.

=== Scripts/Game Balance ===
*Building Carcass Removal Time
**Barrack 25->15
**Radar 20->10
**Repair Pad 25->20
**Vehicle Factory 25->20

=== Bugfixes ===
* Discord button now becomes gray when hovered over.
* Autobalance fixes.
* Fixed a bug that could crash the commander.
* Fixed a bug that would crash the game when quitting.
* Fixed a bug that could crash the server when making an engineer buildable.

== 2.26.4 ==
=== Features ===
* Added discord link to main menu.

=== Game Balance ===
* Rifleman dig-in skill
** Stamina consumption doubled : 25% of damage -> 50% of damage '''(damage reduction remains at 25%)'''

=== Bugfixes ===
* Added emp_sv_official_portoverride <port> configuration variable to allow fix official gameserver status detection.

== 2.26.3 ==
=== Bugfixes ===
* Fix that recycling < 1 res per tick does not display message.
* Fixed coordinate calculation.
* Fixed a big performance issue for players playing from a hard disk instead of an SSD.
* Fixed a problem where the client could crash due to turret gibs.

== 2.26.2 ==
=== Features ===
* Recycling unbuilt building now gives 85% refund instead of 33%*(building hp percentage), recycle time is also reduced to half.
* Recycling built building now gives 50% refund instead of 50%*(building hp percentage)
* You can now recycle a building regardless of its current hp. (previously you couldn't recycle a building if it has less than 20 hp)
* Recycling unbuilt building now takes 1/2 time.
* Unbuilt building carcass time halved.
* Unbuilt building takes 25% more damage.
* Grenadier bots are now more accurate and have less pitch spread.

=== Bugfixes ===
* New models now have collision meshes.
* Game no longer crashes when you exit the game.
* Fixed crash bug when changing resolution while playing.
* Should now gain XP if the server you're playing on becomes official while playing.

== 2.26.1 ==
=== Features ===
* Going out of stamina no longer makes you exhausted.
* Sprinting can only be started if you have at least one bar of stamina left.
* Jumping is only possible if you have at least 3 bars of stamina left.
* Sprinting stops if you have zero stamina and automatically resumes once you have one bar.
* Grenadier [[NPC]]s are less likely to clump together.
* Riflemen [[NPC]]s will ignore hits that are made at a very long distance.

=== Scripts ===
* Walls cost increased from 18 to 20.

=== Bugfixes ===
* Faster official gameserver detection.
* New grenadiers are now available in Hammer as well.
* sv_emp_vehicle_fadeout is now limited to 500 seconds.
* emp_sv_vehicle_fadeout_time_partial is now limited to 100 seconds.
* More lake trees now have collisions.

[[Category:Patch_Notes]]

Maps

2019-05-22T18:17:52Z

Thexa4: /* Community */

{{Sitenav|Maps}}

A few different maps are currently in existence, each offering different terrain, objectives, and play styles. If you know of any more maps, please add them. If you are interested in creating maps, see the [[Mapping]] page.

== Gameplay Types ==
Different [[Gameplay Types]] are available to offer a different set of challenges and are dependent on the map in question.

== Official Maps ==
The following maps are officially included in the current distribution of Empires. They are listed under headings according to the group who created them.

=== Development Team ===
* [[Map:emp_canyon|emp_canyon]]
* [[Map:emp_crossroads|emp_crossroads]]
* [[Map:emp_duststorm|emp_duststorm]]
* [[Map:emp_escort|emp_escort]]
* [[Map:emp_glycencity|emp_glycencity]]
* [[Map:emp_isle|emp_isle]]
* [[Map:emp_money|emp_money]]
* [[Map:emp_streetsoffire|emp_streetsoffire]]
* [[Map:emp_urbanchaos|emp_urbanchaos]]

=== Community ===
* [[Map:emp_arid|emp_arid]] by Silk
* [[Map:emp_bush|emp_bush]] by Silk
* [[Map:emp_chain|emp_chain]] by Silk
* [[Map:emp_coast|emp_coast]] by [[User:Tysn|Tysn]]
* [[Map:emp_cyclopean|emp_cyclopean]] by halbalbador
* [[Map:emp_district402|con_district402]]
* [[Map:emp_eastborough|con_eastborough]] by complete_lamer
* [[Map:emp_midbridge|emp_midbridge]] by Pastori
* [[Map:emp_mvalley|emp_mvalley]] by R_yell
* [[Map:emp_palmbay|emp_palmbay]] by Keef
* [[Map:emp_Slaughtered|emp_Slaughtered]] by =HELLION=

== Custom Maps ==

These maps are created by the Empires community. Some will be of a high enough standard to become official maps.

* [[Map:emp_atoll|emp_atoll_b2]] by John Shandy`
* [[Map:emp_badland|emp_badland]] by Gobanzo Mon
* [[Map:emp_beachfront|emp_beachfront_b2]] by Thomasfn
* [[Map:emp_blackmountain|emp_blackmountain]] by Omneh
* [[Map:emp_blah|emp_blah4]] by Mayama
* [[Map:emp_break|emp_break_poc]] by Blizzerd
* [[Map:emp_cdr_canyon|emp_cdr_canyon]]
* [[Map:emp_delta|emp_delta_rc3a]] by Metal Smith
* [[Map:emp_downfall|emp_downfall]] by Silk
* [[Map:emp_drygulch|emp_drygulch_a6]] by flasche
* [[Map:emp_dune|emp_dune_ob1]] by ''unknown''
* [[Map:emp_flat|emp_flat]] by Silk
* [[Map:emp_forest|emp_forest_ob]] by Simon - ''Recompiled and updated by Omneh''
* [[Map:emp_frozensummit|emp_frozensummit_b2]] by John Shandy`
* [[Map:emp_fuel|emp_fuel_a3_2013]] by ''unknown''
* [[Map:emp_gauntlet|emp_gauntlet]]
* [[Map:emp_glacial|emp_glacial_b2]] by ''unknown''
* [[Map:emp_hazard|emp_hazard_rc6]] by Blight
* [[Map:emp_homeland|emp_homeland_b9]] by Flounder
* [[Map:emp_iceberg|emp_iceberg]] by D.D.D. Destroyer
* [[Map:emp_insurrection|emp_insurrection_rc4]] by Omneh
* [[Map:emp_king|emp_king_r5]] by Chris0132'
* [[Map:emp_massacred|emp_massacred_rc1]] by Varbles
* [[Map:emp_megahill_jam|emp_megahill_jam_b5]] by [LoDw]Keef & DrummerX
* [[Map:emp_mesa|emp_mesa_d6]] by Mayama
* [[Map:emp_moors|emp_moors_b1]] by [LoDw]Keef
* [[Map:emp_plunge|emp_plunge_ob2_2013]] by ''unknown''
* [[Map:emp_provinggrounds|emp_provinggrounds_b2]] by flasche, John Shandy` & [LoDw]Keef
* [[Map:emp_raiders|emp_raiders_b1]] by ''unknown''
* [[Map:emp_rainbowroad|emp_rainbowroad_b2]] by John Shandy`
* [[Map:emp_research|emp_research_1_2]] by Jimather
* [[Map:emp_shadows|emp_shadows_rc10a]] by Cyber-Kun and Stu
* [[Map:emp_silo|emp_silo_rc3]] by Omneh
* [[Map:emp_smokies|emp_smokies_rc2]] by Cyber-Kun
* [[Map:emp_snowbound|emp_snowbound_cl6]] by Jimather - ''recompiled and updated by TheCreeper and D.D.D. Destroyer''
* [[Map:emp_snowstorm|emp_snowstorm_rc6]] by ''unknown''
* [[Map:emp_temple|emp_temple_b3a]] by Mayama
* [[Map:emp_theinternetisforporn|emp_theinternetisforporn4]] by LordDz
* [[Map:emp_traders|emp_traders_a8]] by Coffeeburrito
* [[Map:emp_tropicvendetta|emp_tropicvendetta]] by [[User:John Shandy`|John Shandy`]] and [LoDw]Keef
* [[Map:emp_vehicletraining|emp_vehicletraining_ob2]] by Silk
* [[Map:emp_ward|emp_ward_rc2]] by Silk

[[Category:Maps|Maps]]

Version/2.26.x

2019-05-20T23:52:30Z

Thexa4: /* 2.26.7 */

== 2.26.7 ==
=== Features ===
* Renamed Imperial Tank to Imperial Medium Tank.
* Added key prompts to spawning related messages.

=== Bugfixes ===
* Fixed loading navmeshes from VPK files.

== 2.26.6 ==
=== Bugfixes ===
* Updated main menu layout.
* Fix crash when executing npc_create on server console.
* Attempt to reduce water rendering issues.
* More autobalance fixes.

== 2.26.5 ==
=== Features ===
* Added Patreon button to main menu.

=== Scripts/Game Balance ===
*Building Carcass Removal Time
**Barrack 25->15
**Radar 20->10
**Repair Pad 25->20
**Vehicle Factory 25->20

=== Bugfixes ===
* Discord button now becomes gray when hovered over.
* Autobalance fixes.
* Fixed a bug that could crash the commander.
* Fixed a bug that would crash the game when quitting.
* Fixed a bug that could crash the server when making an engineer buildable.

== 2.26.4 ==
=== Features ===
* Added discord link to main menu.

=== Game Balance ===
* Rifleman dig-in skill
** Stamina consumption doubled : 25% of damage -> 50% of damage '''(damage reduction remains at 25%)'''

=== Bugfixes ===
* Added emp_sv_official_portoverride <port> configuration variable to allow fix official gameserver status detection.

== 2.26.3 ==
=== Bugfixes ===
* Fix that recycling < 1 res per tick does not display message.
* Fixed coordinate calculation.
* Fixed a big performance issue for players playing from a hard disk instead of an SSD.
* Fixed a problem where the client could crash due to turret gibs.

== 2.26.2 ==
=== Features ===
* Recycling unbuilt building now gives 85% refund instead of 33%*(building hp percentage), recycle time is also reduced to half.
* Recycling built building now gives 50% refund instead of 50%*(building hp percentage)
* You can now recycle a building regardless of its current hp. (previously you couldn't recycle a building if it has less than 20 hp)
* Recycling unbuilt building now takes 1/2 time.
* Unbuilt building carcass time halved.
* Unbuilt building takes 25% more damage.
* Grenadier bots are now more accurate and have less pitch spread.

=== Bugfixes ===
* New models now have collision meshes.
* Game no longer crashes when you exit the game.
* Fixed crash bug when changing resolution while playing.
* Should now gain XP if the server you're playing on becomes official while playing.

== 2.26.1 ==
=== Features ===
* Going out of stamina no longer makes you exhausted.
* Sprinting can only be started if you have at least one bar of stamina left.
* Jumping is only possible if you have at least 3 bars of stamina left.
* Sprinting stops if you have zero stamina and automatically resumes once you have one bar.
* Grenadier [[NPC]]s are less likely to clump together.
* Riflemen [[NPC]]s will ignore hits that are made at a very long distance.

=== Scripts ===
* Walls cost increased from 18 to 20.

=== Bugfixes ===
* Faster official gameserver detection.
* New grenadiers are now available in Hammer as well.
* sv_emp_vehicle_fadeout is now limited to 500 seconds.
* emp_sv_vehicle_fadeout_time_partial is now limited to 100 seconds.
* More lake trees now have collisions.

[[Category:Patch_Notes]]

Reference Material

2019-05-20T22:49:32Z

Thexa4: /* Story */

== Story ==
* [[The Story]]
* [https://wiki.empiresmod.com/File:Map2.jpg World Map]

== NF ==
Northern Faction is slightly behind the Brenodi Empire in terms of production capacity so tends to use slightly older manufacturing techniques to make their (future tech) products. This results in slightly bulkier (and often surdier) designs which look slightly less user friendly.

=== Architecture ===
* https://en.wikipedia.org/wiki/Brutalist_architecture
* https://en.wikipedia.org/wiki/Stalinist_architecture
* https://www.google.com/search?tbm=isch&q=brutalist%20architecture&tbs=imgo:1

=== Color ===
* #860000: https://duckduckgo.com/?q=%23860000&t=ffsb&atb=v49-7__&ia=answer

== BE ==

Brenodi Empire has a fully formed industry resulting in more polished, user friendly products. This typically shows in products without sharp edges, compact and futuristic looking designs. This usually results in products being more advanced but more brittle.

=== Architecture ===
* https://en.wikipedia.org/wiki/High-tech_architecture
* https://en.wikipedia.org/wiki/Blobitecture
* https://en.wikipedia.org/wiki/Neo-futurism
* https://duckduckgo.com/?q=glass+architecture&iar=images&iax=images&ia=images
* For (old) palaces etc: https://www.google.com/search?q=victorian+architecture&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiOoZHbvKriAhVFposKHZJNBtoQ_AUIDigB&biw=1920&bih=969#imgrc=kFHc2p5aaO27PM

== Game Design General ==
* http://www.gamasutra.com/blogs/DanFelder/20150521/243962/Design_101_Complexity_vs_Depth.php
* http://www.gamasutra.com/blogs/FlavioCreasso/20151014/256145/Reverse_Engineering_Toxic_Behaviour.php

== Command & Control ==
* How military command works: http://www.au.af.mil/au/awc/awcgate/army/cmd-hdbk.pdf

== Voice ==
http://mary.dfki.de:59125/

== UX ==
* https://www.raphkoster.com/2015/06/29/game-design-ux-design/

=== GAP Acessiblity Heuristic ===
* https://www.researchgate.net/publication/308084122_Heuristic_Evaluation_for_Gameful_Design
* http://dlx.b-ok.org/genesis/1376000/3a1aa6e5164dd5d49cdc368a13deeb1e/_as/[Regina_Bernhaupt_(eds.)]_Game_User_Experience_Eva(b-ok.org).pdf (page 196), https://www.springer.com/us/book/9783319159843

# Goals
## Overall goal: The player is presented clear goals (e.g. overriding goals) early enough or is able to create her own goals and is able to understand and identify them
## Short-time goals: There can be multiple goals on each level (short-term and long-term goals), so that there are more strategies to win. Furthermore the player knows how to reach the goal without getting stuck
# Motivation
## The player is receiving meaningful rewards. The acquisition of skills (personal and in-game skills) can also be a reward
## The game does not stagnate and the player feels the progress
## The game and the outcome are perceived as being fair
## The game itself is replayable and the player enjoys playing it
## The game play does not require the player to fulfil boring tasks
## Challenges are positive game experiences and encourage the user to continue playing
## The first-time experience is encouraging
# Challenge
## The game is paced to apply pressure to but does not frustrate the player
## Challenge, strategy and pace are in balance
## The artificial intelligence is reasonable, visible to the player, consistent with the player’s expectations and yet unpredictable
## There are variable difficulty levels for a greater challenge
## The challenge of the game is adapted to the acquired skills. The difficulty level varies so the player experiences greater challenges as she develops mastery
## Challenging tasks are not required to be completed more than once (e.g. when dying after completing a hard task)
## The game is easy to learn, but hard to master
# Learning
## The player is given space to make mistakes, but the failure conditions must be understandable
## The learning curve is shortened. The user’s expectations are met and the player has enough information to get immediately started (or at least after reading the instruction once)
## General help displaying the game’s fundamentals exists and is a meaningful addition to the game and provides useful assistance before and during the game
## Tutorials and adjustable levels are able to involve the player quickly (learning) and provided upon request throughout the entire game
# Control
## The player feels that she is in control. That includes the control over the character as well as the impact onto the game world. It is clear what’s happening in the game
## The player can impact the game world and make changes
## The player is able to skip non-playable and repeating content if not required by the game play
## The game mechanics feel natural and have correct weight and momentum. Furthermore they are appropriate for the situation the player is facing
## The player is able to save the game in different states (applies to non arcade-like games) and is able to easily turn the game off and on
## The player is able to respond to threats and opportunities
# Consistency
## Changes the player makes to the game world are persistent and noticeable
## The game is consistent and responds to the user’s action in a predictable manner. This includes consistency between the game elements and the overarching settings as well as the story
# Game Story
## The meaningful game story supports the game play and is discovered as part of the game play
## The story suspends disbelief and is perceived as a single vision, i.e. the story is planned through to the end
## The game emotionally transports the player into a level of personal involvement (e.g. scare, threat, thrill, reward, punishment)
# Feedback
## The acoustic and visual effects arouse interest and provide meaningful feedback at the right time
## Feedback creates a challenging and exciting interaction and involves the player by creating emotions
## The feedback is given immediately to the player’s action
## The player is able to identify game elements such as avatars, enemies, obstacles, power ups, threats or opportunities (orthogonal unit differentiation)
## The player knows where she is on the mini-map if there is one and does not have to memorize the level design
## The player does not have to memorize resources like bullets, life, score, points and ammunition
# Visual appearance
## In-game objects are standing out (contrast, texture, colour, brightness), even for players with bad eyesight or colour blindness and cannot easily be misinterpreted
## The objects look like what they are for (affordance)
# Interaction
## Input methods are easy to manage and have an appropriate level of sensitivity and responsiveness
## Alternative methods of interaction are available and intuitive. When existing interaction methods are employed, they are adhering to standards
## The first player action is obvious and results in immediate positive feedback
# Customization
## The game allows for an appropriate level of customization concerning different aspects (e.g. audio and video settings, etc.)
## The input methods allow customization concerning the mappings. The customization is persistent
# Menu and interface elements (HUD)
## The interface is consistent in control, colour, typography and dialog design (e.g. large blocks of text are avoided, no abbreviations) and as non-intrusive as possible
## The menu is intuitive and the meanings are obvious and perceived as a part of the game
## The visual representation (i.e. the view) allows the user to have a clear, unobstructed view of the area and of all visual information that is tied to the location
## Relevant information is displayed and the critical information stands out. Irrelevant information is left out. The user is provided enough information to recognize her status and to make proper decisions
## If standard interface elements are used (buttons, scroll bars, pop-up menus), they are adhering to common game interface design guidelines

Reference Material

2019-05-20T16:16:33Z

Thexa4: /* Architecture */

== Story ==
* [[The Story]]

== NF ==
Northern Faction is slightly behind the Brenodi Empire in terms of production capacity so tends to use slightly older manufacturing techniques to make their (future tech) products. This results in slightly bulkier (and often surdier) designs which look slightly less user friendly.

=== Architecture ===
* https://en.wikipedia.org/wiki/Brutalist_architecture
* https://en.wikipedia.org/wiki/Stalinist_architecture
* https://www.google.com/search?tbm=isch&q=brutalist%20architecture&tbs=imgo:1

=== Color ===
* #860000: https://duckduckgo.com/?q=%23860000&t=ffsb&atb=v49-7__&ia=answer

== BE ==

Brenodi Empire has a fully formed industry resulting in more polished, user friendly products. This typically shows in products without sharp edges, compact and futuristic looking designs. This usually results in products being more advanced but more brittle.

=== Architecture ===
* https://en.wikipedia.org/wiki/High-tech_architecture
* https://en.wikipedia.org/wiki/Blobitecture
* https://en.wikipedia.org/wiki/Neo-futurism
* https://duckduckgo.com/?q=glass+architecture&iar=images&iax=images&ia=images
* For (old) palaces etc: https://www.google.com/search?q=victorian+architecture&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiOoZHbvKriAhVFposKHZJNBtoQ_AUIDigB&biw=1920&bih=969#imgrc=kFHc2p5aaO27PM

== Game Design General ==
* http://www.gamasutra.com/blogs/DanFelder/20150521/243962/Design_101_Complexity_vs_Depth.php
* http://www.gamasutra.com/blogs/FlavioCreasso/20151014/256145/Reverse_Engineering_Toxic_Behaviour.php

== Command & Control ==
* How military command works: http://www.au.af.mil/au/awc/awcgate/army/cmd-hdbk.pdf

== Voice ==
http://mary.dfki.de:59125/

== UX ==
* https://www.raphkoster.com/2015/06/29/game-design-ux-design/

=== GAP Acessiblity Heuristic ===
* https://www.researchgate.net/publication/308084122_Heuristic_Evaluation_for_Gameful_Design
* http://dlx.b-ok.org/genesis/1376000/3a1aa6e5164dd5d49cdc368a13deeb1e/_as/[Regina_Bernhaupt_(eds.)]_Game_User_Experience_Eva(b-ok.org).pdf (page 196), https://www.springer.com/us/book/9783319159843

# Goals
## Overall goal: The player is presented clear goals (e.g. overriding goals) early enough or is able to create her own goals and is able to understand and identify them
## Short-time goals: There can be multiple goals on each level (short-term and long-term goals), so that there are more strategies to win. Furthermore the player knows how to reach the goal without getting stuck
# Motivation
## The player is receiving meaningful rewards. The acquisition of skills (personal and in-game skills) can also be a reward
## The game does not stagnate and the player feels the progress
## The game and the outcome are perceived as being fair
## The game itself is replayable and the player enjoys playing it
## The game play does not require the player to fulfil boring tasks
## Challenges are positive game experiences and encourage the user to continue playing
## The first-time experience is encouraging
# Challenge
## The game is paced to apply pressure to but does not frustrate the player
## Challenge, strategy and pace are in balance
## The artificial intelligence is reasonable, visible to the player, consistent with the player’s expectations and yet unpredictable
## There are variable difficulty levels for a greater challenge
## The challenge of the game is adapted to the acquired skills. The difficulty level varies so the player experiences greater challenges as she develops mastery
## Challenging tasks are not required to be completed more than once (e.g. when dying after completing a hard task)
## The game is easy to learn, but hard to master
# Learning
## The player is given space to make mistakes, but the failure conditions must be understandable
## The learning curve is shortened. The user’s expectations are met and the player has enough information to get immediately started (or at least after reading the instruction once)
## General help displaying the game’s fundamentals exists and is a meaningful addition to the game and provides useful assistance before and during the game
## Tutorials and adjustable levels are able to involve the player quickly (learning) and provided upon request throughout the entire game
# Control
## The player feels that she is in control. That includes the control over the character as well as the impact onto the game world. It is clear what’s happening in the game
## The player can impact the game world and make changes
## The player is able to skip non-playable and repeating content if not required by the game play
## The game mechanics feel natural and have correct weight and momentum. Furthermore they are appropriate for the situation the player is facing
## The player is able to save the game in different states (applies to non arcade-like games) and is able to easily turn the game off and on
## The player is able to respond to threats and opportunities
# Consistency
## Changes the player makes to the game world are persistent and noticeable
## The game is consistent and responds to the user’s action in a predictable manner. This includes consistency between the game elements and the overarching settings as well as the story
# Game Story
## The meaningful game story supports the game play and is discovered as part of the game play
## The story suspends disbelief and is perceived as a single vision, i.e. the story is planned through to the end
## The game emotionally transports the player into a level of personal involvement (e.g. scare, threat, thrill, reward, punishment)
# Feedback
## The acoustic and visual effects arouse interest and provide meaningful feedback at the right time
## Feedback creates a challenging and exciting interaction and involves the player by creating emotions
## The feedback is given immediately to the player’s action
## The player is able to identify game elements such as avatars, enemies, obstacles, power ups, threats or opportunities (orthogonal unit differentiation)
## The player knows where she is on the mini-map if there is one and does not have to memorize the level design
## The player does not have to memorize resources like bullets, life, score, points and ammunition
# Visual appearance
## In-game objects are standing out (contrast, texture, colour, brightness), even for players with bad eyesight or colour blindness and cannot easily be misinterpreted
## The objects look like what they are for (affordance)
# Interaction
## Input methods are easy to manage and have an appropriate level of sensitivity and responsiveness
## Alternative methods of interaction are available and intuitive. When existing interaction methods are employed, they are adhering to standards
## The first player action is obvious and results in immediate positive feedback
# Customization
## The game allows for an appropriate level of customization concerning different aspects (e.g. audio and video settings, etc.)
## The input methods allow customization concerning the mappings. The customization is persistent
# Menu and interface elements (HUD)
## The interface is consistent in control, colour, typography and dialog design (e.g. large blocks of text are avoided, no abbreviations) and as non-intrusive as possible
## The menu is intuitive and the meanings are obvious and perceived as a part of the game
## The visual representation (i.e. the view) allows the user to have a clear, unobstructed view of the area and of all visual information that is tied to the location
## Relevant information is displayed and the critical information stands out. Irrelevant information is left out. The user is provided enough information to recognize her status and to make proper decisions
## If standard interface elements are used (buttons, scroll bars, pop-up menus), they are adhering to common game interface design guidelines