You can now use the BuildEntityCache plugin to write your content loader .dat's and template EDT's.
You will need a Synergy server install with SourceMod/Metamod and this plugin:
https://github.com/Balimbanana/SM-Synergy/blob/master/plugins/BuildEntityCache.smx
Then run the server, leave it on some regular map like d1_trainstation_01 I recommend you do not join the server while generating, then use:
buildloader contenttag contentloadername "SourceModDirectory"
As an example, you could do Nightmare House 2 with:
buildloader nh2 nightmarehouse2 "NH"
It will print all the info it gathered on the mod and will create a content loader nightmarehouse2.dat in Synergy\synergy\content\

Now you can generate all the template EDT's by:
buildedt all contentloadername
Or individual with
buildedt contenttag mapname
For the example of Nightmare House 2, you could do:
buildedt all nightmarehouse2
This process will take a few mins or longer. It will generate all the entity caches for each map, then read that cache to generate the EDT.

At this point, when you restart your server, you should be able to changelevel to it with something like:
changelevel contenttag mapname
Or this example:
changelevel nh2 nh1remake1_v2

Now you can create a template antirush system by using:
buildantirush
it will build info on the current maps trigger_changelevel's and create a blocker and antirush coop trigger. This only works for the currently running map, then you would restart the map for the antirush to take effect.

Remember that the content loader is required on the client-side as well, so you will need to copy the file Synergy\synergy\content\nightmarehouse2.dat to your client's Synergy\synergy\content\nightmarehouse2.dat or you will get a
"Disconnect
Additional Requirements
Nightmare House 2"
when you join.

Note that these template EDT's are just a starting point to get the maps functional. If there are any doors that lock when you walk past them, you will need to edit the EDT to reflect that and add checkpoints if needed.

You *could* technically write support for any Source Mod. But certain custom entities and weapons may not work correctly if at all. Almost all of the supported mods are using weapons or npc's that are close enough to other entities currently in the game to be able to be changed.
There are some occurences when you can use edt's and SourceMod (a plugin system) in tandem to re-create functionallity.

You will need to start with a content loader .dat, one as such could be configured to:
The path is relative to Steam\steamapps\sourcemods\
So for this one, it will be searching for the folder named missionimprobable located in:
Steam\steamapps\sourcemods\missionimprobable
The tag is for the content loader system to differentiate different maps/models/materials in certain locations. You may notice that many background maps for example are called background01, the way Synergy can see the difference is using a content tag beforehand.

For supporting Steam games, the content loader is slightly different:
By using the "id" key, Synergy knows that this is a Steam released mod. For almost all Steam released mods or games there will be a root directory, then the actual mod's directory under it.
The root "Half-Life 2 DownFall" is located in Steam\steamapps\common\ but this directory mostly just contains the Source SDK Base 2013, and the binaries required to run it. The content that DownFall is, is located in a sub-directory named "downfall".
to figure out how some are set up, right click a few .dat files in Steam\steamapps\common\Synergy\synergy\content\ and open them in a text editor such as Notepad++ and read how the paths and mounting order is set up.
In some cases, you can actually play through the mod singleplayer in Synergy without any edits, or minimal edits.

To create an edt, go to your maps directory: Steam\steamapps\common\Synergy\synergy\maps then right click and create a new text document and rename it to mapname.edt where mapname is the map name you are editing.
Then start it off with:
spawnflags are made up of a bit-sum, you can find their values in synergy.fgd, halflife2.fgd and base.fgd in: Steam\steamapps\common\Synergy\bin\*.fgd
What this means is that if you want spawnflags 1 and 4, you would add them together and set the spawnflags to 5 for example.

Edits that are fairly universal, unless specifically needed to be different.
spawnflags 1 for game_text is to display for all players.

For func_areaportal's, change the targetname and set to open, developers put these in their maps to make it easier on graphics rendering by disabling drawing of textures or models past these portals. But with multiple players at different points in maps will see different area portals at the wrong time, so it is best to leave these disabled unless there is a section where all players will be moved to and a previous areaportal can be closed.

For point_viewcontrol's edt_addspawnflags 128 is for adding the All Players flag to all viewcontrols. You can also add or use: 8 - Infinite hold time, 4 - Freeze players, 32 - Make players non-solid for certain sequences, this may be required to allow props/npcs to move freely.
If you come across a viewcontrol that hangs, and doesn't do anything past that point, you may need to remove the spawnflag infinite hold time, as it may be one that has a timer to disable itself.

The way outputs are set up is:
OutputName "target,input,parameter,delay,timesfired"

There are occasions when you will want to use a func_areaportal, if there is a sequence where players are not able to return, you can make invisible walls (if there aren't already some in the map), then set the specific area portal's targetname to something you can reference and close once all players are past it, which could help with performance on some maps.

I would recommend you read some edt's to figure out how some sequences are set up.

The way you can edit or delete entities are as follows:
edit {classname "entityclassname" values {} }
delete {classname "entityclassname"}
This will edit all entities of that classname, regardless of targetname.

delete {targetname "entity"}
This will delete all entities with the targetname "entity".
edit {targetname "entity" values {} }
This will edit all entities with the targetname "entity" and change their values to whichever you define. Just keep in mind, if you try to edit an output using the edit system, it may remove all outputs from that entity of that type, and add only one of the outputs you define. If you were to try to do:
This will override any other OnPlayerPickup outputs and while it looks like it would add these two outputs, the only one it will actually do is the last one. This can be confusing at first, because when someone picks up the crowbar, everyone will get one, but you will not respawn with one because that output is skipped.
This is why it is best to set it up as an AddOutput in a logic_auto so it won't override any outputs and you can add as many as you need.

edit {classname "entityclassname" origin "0 0 0" values {} }
This will edit a specific classname, at a specific origin, note that this origin is specific to the 8th decimal place (0.00000000), but you don't need to include any of the 0's past what is defined, so if something is at "250.12880000 120.00000000 0.00100000" you would only have to enter: "250.1288 120 0.001" for the origin.
You can get exact origins by either EEDT or by looking in the ent cache for the map.
To use the ent cache, first start the map to generate it, then look in Synergy\synergy\maps\ent_cache
Now find the map in question, which will be named contenttag_mapname.ent Open it with Notepad++ or a similar program and you will find a full list of entities with their exact origins.

I use this for adding outputs to triggers that don't have targetnames with something like:
Followed by adding an output of either OnTrigger or OnStartTouch in a logic_auto to do what I need it to.

For custom npc's you would change their classname to generic_actor, or possibly another npc that is close to what they need to be able to do, then probably set up some damage filters and/or ai_relationship's to make their disposition/role to be correct.

For custom weapons you would change their classnames to weapons that are already in the game. With some exceptions, you can get the weapons to look and sound correct, possibly requiring you to edit their weapon scripts to reflect how it *should* function.
Just remember that the weapon scripts that you can edit don't include much of the actual functionallity of the weapon, just certain traits.

Take for example, in 1187 (which support has not been released) there is a weapon_knife, one of many custom weapons in that mod. You can change the classname to weapon_crowbar in an edt with the line:
Now it may spawn in the game using the correct model, but the weapon script will be using the default weapon_crowbar. So now you would have to go to the sourcemods directory, 1187, scripts, and create a duplicate of weapon_knife.txt and name it weapon_crowbar.txt which will override what the crowbar looks and sounds like.

An example of a custom npc, in the same mod (1187), take npc_john. You would have to change the classname to generic_actor, or they may possibly still function as an npc_citizen with:
Things to take in to account, if using the npc_citizen is the spawnflags needed to be assigned depending on what the npc does. In this example, npc_john is mostly for exposition in the first areas, then they join you later on to fight some enemies, so you need to set the spawnflags to ensure that they don't attempt to join the players squad until later on.

You can find spawnflags and other keys/values in Steam\steamapps\common\Synergy\bin\*.fgd npc_citizen can be found in halflife2.fgd, just note that the citizen also includes the BaseNPC spawnflags (which is in base.fgd), so you may need to check in both sections for the spawnflags you need. To ensure that they don't join the squad, you would set their spawnflags to 1048576, but for some scripted npc's you will also need the spawnflag to not give way to players (or they could get stuck), the spawnflag for that is 16384, the way that spawnflags works is a bit-sum of all active flags, so you would add 16384 to 1048576 and that would allow them to have both do not give way, and don't join player squad, done as:
Then to configure them to be commandable later on when they join you, it will be time to use the input: SetCommandable
Most of this makes more sense if you have Hammer experience. Synergy's Hammer is located in Steam\steamapps\common\Synergy\bin\Hammer.exe
You search for the point in which John is supposed to be commandable, which in the example I have, it would be a trigger_once with the targetname: johntrigger (found in Hammer). So you need to add an output to give John an input of SetCommandable, which could be done with:

These are entities specific to Synergy, and are all useful in their own ways.

Classname
Controls what players spawn with, description in Synergy.fgd:
"Entity that will give the player any equipment specified by it's key values (in the form of 'entity_classname' 'number_of_items'). This entity replaces the functionality of the game_player_equip."
Does not require an origin or angle. Can be enabled or disabled to control when players should or should not spawn with equipment.
Inputs:
EquipPlayer - "Equip the activator of this input with the items contained in this entity, even if disabled. Activator must be a player."
EquipAllPlayers - "Equip every living player with the items contained in this entity, even if this entity is disabled."

Classname
Synergy.fgd description: "This is where players will initially spawn. Can be enabled and disabled to move player spawns throughout a level." Can also use info_spawn_manager to control spawns instead of enable/disable inputs.
Inputs:
Enable - Enables spawn point.
Disable - Disables spawn point.
SetParent - Parents this entity to another entity (similar to welding in GMod), you can also set the parent when you first spawn it with the "parentname" key and set the value to a target's name.
This is particularly useful for elevators, to ensure that players don't spawn at whichever floor it was first created at regardless of what floor the elevator is at.

Classname
Synergy.fgd description: "Use this entity to force a spawn location / checkpoint and to update players if they are behind."
Inputs:
RespawnPlayers - "Respawns dead players."
TeleportPlayers - "Teleport players immediately to the specified info_teleport_destination entity, regardless of free move area." With a parameter of the info_teleport_destination, such as:
Which would teleport all players to origin "0 0 0" and set their angles to "0 90 0".
SetCheckPoint - "Set the named info_player_coop as the current checkpoint entity." Example:
ClearCheckPoint - "Clear the current checkpoint entity." Can be used to disable spawns, but you would probably use in conjunction with a global IsVehicleMap to stop players from spawning on eachother.

Classname
Actually an entity in the base Source engine, but there are extended settings available for Synergy.
You can use this to configure a logic_auto to spawn or set up an area when transitioning back from another map. As an example from Below The Ice Mod Support:
You don't want to set the initial state of the global because it may be overwritten on the transition back. Now on the map to be transitioned back from, you would set up, in this example on "memory":
You can find many other options in Hammer, test some out. There are settings for things like invulnerability, which you would use for certain sections that players should not die or enable/disable mega physcannon.

Classname
An entity to control a few options such as which map to change to if players get a game over. Or the main use, IsVehicleMap 0 or 1. You can set this in-game as well by an input such as:
You would use this for if you reach the end of a vehicle section or need to enable/disable spawns. While it is on, players will always respawn at the active checkpoint, unless there isn't one set, in which case players will not respawn.
This was created in order to ensure that players spawn next to a vehicle spawn point and players won't be stranded out in the middle of nowhere with no vehicle.

Classname
Synergy.fgd description: "Vehicle Spawn Entity keeps a vehicle for every player, with options to relocate vehicles upon certain conditions."
You will want to read the entity keys and values in Synergy.fgd.
Something to note, the VehicleType is what classname the vehicle will spawn with.
1 - prop_vehicle_jeep For the base jeep, you can use this to spawn other vehicles as well, but their functionallity will essentially be just the base jeep and will not allow for additional seats.
2 - prop_vehicle_airboat For the base airboat.
3 - prop_vehicle_jeep_episodic For things like the Jalopy with funcitonallity to allow Alyx to get in the side-seat.
4 - prop_vehicle_mp For the multi-seat vehicles such as the 2 seater jeep, the 7 seat van, or the 8 seat truck.
Key: RespawnVehicle - 0 or 1, "Respawn vehicles if the players die." will also remove the vehicle if the player dies, so that vehicle areas don't get cluttered.
Key: StartGunEnabled - 0 or 1, not actually listed in the Synergy.fgd, but this controls whether the vehicle should spawn with a turret or not.
Key: model - The vehicle model to use, for the 2 seater jeep you could use: "models\vehicles\buggy_p2.mdl"
Key: VehicleScript - Sets what vehicle script should be used by the spawned vehicle, generally this will be: "scripts/vehicles/jeep_test.txt" or "scripts/vehicles/airboat.txt".
Examples:
Airboat spawn
2 seater Jeep spawn
Jalopy spawn (anything past 8 jalopy's seems to create a huge strain on servers.) Ep2 Required.

Classname
Used to create a wall, usually for anti-rush and the end of maps. Can be created in two separate ways:
The differences is that as a syn_transition_wall, it is a player clip, so most npc's, props, and vehicles can still travel through it.
As a prop_dynamic, it is solid to all entities, useful for vehicle sections or stopping props from moving through.

Classname
A trigger volume with multiple settings and functions. Contains all the functionallity of trigger_multiple as well.
In this example, when the first player touches the trigger, a shortcut will be opened. The OnTrigger output will be fired every 3 seconds as set by the "wait" key. When the player value is met, which in this case is 50% of all living players, the OnPlayersIn output will be fired, which you can use to do things such as TeleportPlayersNotTouching, which is a smoother teleport than things like TeleportPlayers from the info_spawn_manager, or point_teleport's.
The "usehud" key is useful for creating an invisible sequence that can really polish a scripted area.
A good example can be found in the Synergy HL2 edt's like d1_trainstation_05:
By default usehud is 0, so if it is not defined, it is assumed 0, and this trigger is invisible to players. It requires all players to be inside to trigger the OnPlayersIn outputs. This allows players to continue walking about the lab and they won't be locked out of the teleport room. But if all players eventually enter the teleport room, the lab door will close behind the last player.
Something to note with this trigger, if you wish to use the OnPlayersIn output, you must define CountType "#" and PlayerValue "number" or it will show infinite players required.
The values for CountType are:
0 - Number of players.
1 - Percentage.
So if CountType is 0 and Player Value is 2, then two players must be inside the trigger regardless of how many players are on the server to fire the OnPlayersIn output.

Classname
Synergy.fgd description: "Fires various outputs based on the current difficulty setting and number of active players. For difficulty-based events. Avoid using player-count tests soon after the map loads, all players may not be accommodated for due to loading."
Has many outputs based on difficulty (the "skill" cvar), and player counts. You can set it up to for example, add more max npc's from a spawner to increase the difficulty for multiple players on a specific difficulty, or enable/disable other spawn points depending on difficulty settings.
Inputs:
CheckSkill - "Fires all applicable outputs based on the current difficulty and number of players." You could use this just before entering a big battle area.

When testing triggers, you may have noticed the model "*1" or other number, these are precached models and they will be different for each map. You can set the model using a targetname of another trigger with the key:
edt_getbspmodelfor_targetname "trigger targetname"
Then for testing I usually will change the classname from trigger_coop, or other types of triggers to:
"func_button" What this will do is make the trigger visible in-game, and you can check if all the positions and/or angles are correct, then change it back to a trigger_coop or other type of trigger to test.

You can now also use the keys with, for example:
edt_getbspmodelfor_classname "trigger_once"
edt_getbspmodelfor_origin "0 0 0"
Which would get the model of specifically trigger_once at origin "0 0 0" in this example. What this does is it allows you to get the model of a trigger that does not have a targetname.

The fastest way to run through precached models in-game I have found is going to an open area on the map, in console use "sv_cheats 1" then use:
ent_create func_button model *1
Increment the 1 until you find a useable trigger volume, get the number you ended up with and add it to the edt.
Synergy will crash if you try to spawn a model outside of the precached numbers. This number is completely different from map to map. Some maps will only have 10 precached models, others can have over 400. You just have to try it out until you find what you are looking for.

Hammer is the Source engine map editor, and it makes it much easier to make Mod Support's if you are able to view the map with all its entities.
You can find Hammer for most Source mods in:
Steam\steamapps\common\gamename\bin\

Base map files have the file extension .vmf you should try to get the source non-compiled .vmf from the author of the mod before going ahead and decompiling the maps.
I don't see it as too bad of a problem to decompile anyways though because you won't be recompiling it, or redistributing it. These decompiled maps are specifically for viewing to figure out how to set up sequences for multiple players.
You *can* make Mod Support without using Hammer or decompiling maps, but it will take longer, you can use the commands:
getpos - will show you where you are and what angles you are facing, just note that the z coordinate is from your eye position, not your feet.
ent_show_response_criteria - will show the type of entity such as func_button, func_door, etc and their targetname.

You can decompile .bsp maps with BSPSrc https://github.com/ata4/bspsrc/releases
Extract it, then run bspsrc.bat you should be able to leave all the settings at default, then either click Add and find the .bsp('s) that you want to decompile, or drag and drop a .bsp on the main window. I would recommend that you create a folder inside Steam\steamapps\common\Synergy\bin\modname to make it easier to find specific mods.
Now, so long as it successfully decompiled the map(s), you can open them in Hammer.

When you first open Hammer, there are a couple things you will want to set, by default Hammer will render in Wireframe, so you will need to change it as such:
In the main top left window, which you can resize, is the main one you will most likely be using. To control it, while your mouse is over the panel, Press Z and you can move around the world with your mouse and WASD. Press Z again to unlock the mouse. Find entities that you want to edit, and double click to view their properties.
Something else to note, you cannot edit prop_static's.
Here is an example of something that you will need to edit on most maps. The spawn items.
Most spawn items will be spawned in via a point_template with the input of ForceSpawn from a logic_auto OnNewGame output.
You will need to delete both of these entities to make sure that there are no errors on map start and players don't see additional equipment around.
In EDT, you could write using the positions or the targetnames. If the targetname is available, you should use that instead of getting the exact position.
You could also get the position by the bottom right corner, but it may be missing the decimals or by EEDT which gives exact decimal positions.
Then you could write it as:

Normally I will delete the info_player_start in order to create a configurable spawn point.
You can get the position by selecting that green info_player_start in the Hammer screen shot, then get the angles, which in this case is "0 90 0" and write in the EDT:
I rounded the positions in this case because 1 or 2 doesn't make much of a difference, unless you are trying to get something exactly right.

You can create entities in Hammer by either clicking the entity tool, or pressing Shift+E, then click where you want something to spawn in the map. By default this will create an info_player_coop:
After creating an entity, you will want to select the Selection Tool before making any changes, or it will just create more entities.
You can then change the classname to whatever entity you want, you can either do it by the dropdown menu, or typing in the box, something like: weapon_mp5k
Now you can move the entity in multiple ways, while the entity is selected, press X to get this grid:
Then you can move it by dragging and dropping the white squares for smaller movements, or drag and drop the center of the entity, and it will snap to a grid.

This is a system with Synergy's Hammer that allows for editing maps, then running -edt instead of fully compiling and Hammer will generate an edt of the changes you made.
There are some problems with this, if any brushes or certain entities were edited, Hammer will fail to generate the edt. I generally use this for getting specific locations of entities if needed then manually write the edt.
The way this has to be set up is after decompiling the map, or getting the original .vmf, you must make a copy of it and add _edt at the end of the file name, so something like:
d1_trainstation_06_d.vmf
Would need a copy called:
d1_trainstation_06_d_edt.vmf
The _d part of it denotes that it was a decompiled version, but doesn't really matter much.
Then when you go to open it in Hammer, make sure you open the _edt version.
Then after making your changes, Press F9 and go to the "Expert" option at the bottom and set it up as follows:
Make sure to add -edt to the parameters as above.
When you press "Go!", it should give you this window:
Note that the positions include decimals, but in the main window, at the bottom right, there are no decimals. This is important because EDT requires exact coordinates.

You may notice that some custom models and settings are not visible for certain mods that use custom ones. To enable the functionallity, you need to add it to the mount list for Hammer (separate from Synergy content mounting).
Taking Mission Improbable as an example, this is what you would see by default:

You can change mounting with gameinfo.txt located in:
Steam\steamapps\Common\Synergy\synergy\gameinfo.txt
By default it will look like:
What you need to do is add on the blank line below
"[Add any additional content for Hammer to mount here]" is:
Then when you restart Hammer, if the path is correct, you will have the content mounted and see:

To showcase a mod, you will want to take screenshots of interesting landscapes, sequences, custom weapons/entities, etc.
What you are going to want to do to get the best screenshots is create a config in:
Steam\steamapps\common\Synergy\synergy\cfg\
called something like ssmode.cfg then open it in a text editor like Notepad or Notepad++ and put in:
Special thanks to DaftMink for the toggle set up.
So when you start up Synergy, put in your console: exec ssmode. Then you can press ] which you can change to whichever key you want, and it will disable/enable showing weapons and your hud, making it ideal for good screen shots.

Making map images requires a few extra steps. First you will need to run Synergy in a 5:4 or 4:3 resolution, I usually use 1280 x 1024 in my startup line:
-windowed -noborder -w 1280 -h 1024
Then use the same ssmode method above, take only one screenshot per map. Make sure it captures what the map is about, something unique to that map, so when someone looks through their map list, they can figure out what map it is without having to start it first.

Now you will need VTFEdit or something similar to create vtf's of the screenshots.
You can get VTFEdit from: http://nemesis.thewavelength.net/index.php?c=178
Once you open a the screenshot of the map image you want, these are the options I use:
Then don't set any of the Flags, or change any other settings. Go to File > Save As... and save it to:
Steam\steamapps\common\Synergy\synergy\workshop\modname\materials\vgui\maps\menu_thumb_mapname
Where modname is the mod you are creating support for, and mapname is the maps name.

Do this for every map.
Now that you have vtf's of each map image, you need to create a .vmt to tell Synergy what it is and how to render it. You can either create a .vmt with the same name as each map one by one with the contents of:
and have to change the mapname in each one to reflect which map it is for, or you could use a quick PowerShell script I wrote:
Just open PowerShell ISE (Integrated Scripting Environment). You can find it in the start menu, just search PowerShell and be sure to select the ISE one. Paste the script in the top white panel, then select the bottom panel and change directory (using the command cd) to:
Steam\steamapps\common\Synergy\synergy\workshop\modname\materials\vgui\maps
With whichever first part of the path relates to you, which could be C:\Program Files (x86)\Steam
or D:\SteamLibrary\steamapps etc.
Then run it, and it will automatically create all the vmt's you need for all the map images.
To test it, you could copy Synergy\synergy\workshop\modname to Synergy\synergy\custom\modname
Then start up Synergy and if the map names are all correct, and in the correct directory, you should be able to see the map images over each of the maps in Create Server.

To start, you will need to create a directory inside your workshop directory, if you haven't already.
It will be located in:
Steam\steamapps\common\Synergy\synergy\workshop\modnamesupport
The way the sub-directories will be set up is as if modnamesupport is Synergy\synergy.
So you will need to create the directories called content, maps, materials. Inside content, you put in your content loader .dat file, inside maps, you put in your .edt's, and inside materials, put in your map images, there are other sub-directories listed in the map images section.

Now you will want to get a cover picture for the Mod Support, you should be able to find one on the store page for the mod, or on RunThinkShootLive, or ModDB. In some cases, the best cover picture is the main title in-game, take a screen shot of it, then add under the title: Mod Support
Place the picture in the workshop folder.
You should not include any content from the actual mod unless you have permission from the creator.

Now, in-game go to Workshop, then click "Open Workshop Publisher" and enter for example:
The reason you have to set it to Item Replacement, is because of Synergy's mounting system for content .dat files. Item Replacement is set up so that it is always active as soon as Synergy starts up, Add-on's are set up so that you will only use that content while it should be active, such as in a server that uses that content.
Basically the content .dat file must be loaded at all times and right when Synergy starts up in order for it to mount correctly.

There isn't much point in putting a description in to start, because you don't have as many options anyways. But you can use that section for updates.

Once you select the "Content Directory" press "Pack Content to VPK", a command window will open, then close shortly after (depending on the size of the support). Then you must press Browse and select the VPK file, it won't add it automatically.

Once it has finished uploading, it should open in your in-game web browser, and allow you to add more screen shots and a full description. Then you should test it by subscribing to it and restarting Synergy and if it is in working order, go to the visibility option on the workshop page and make it public.

Workshop Errors:
(25) seems to relate to attempting to attach a preview image in an unsupported format, or if the preview picture is too large. Save your preview images as .jpg and it should work.

"Unknown Error Item Deleted" usually has to do with a failed pack, or attempting to upload from a directory other than Synergy\synergy\workshop Make sure you put all your workshop items in there, along with your preview picture. Example could be:
Synergy\synergy\workshop\myworkshopaddon\
Synergy\synergy\workshop\mypreviewpicture.jpg