UBerserker wrote:1. What gametype should be used there? Note that this is after using a custom gametype.
There is no reason to introduce a specific custom game type, unless you really need to override GameInfo functions.
In case of maps that are intended to be playable in Coop game, dependencies on a custom game type may become a headache for server admins who would like to use their favourite advanced Coop game type with rich functionality (such as enhanced kick-banning/penalty system, multiple admin groups with different subsets of available admin commands, support of voting rules for ending, optional saving inventory of died/left players, anti-flood protection, etc). Switching to other game type with UnrealShare.CoopGame-like minimalistic functionality (offered by authors of a map pack) isn't exactly what an experienced admin would want. Hacking/refactoring scripts of a map pack in order to adapt the implementation for a favourable game type can be a solution, but it requires knowledge of scripting and time.
I'm not sure if the teleport thing is good
Applying filters to Engine.Teleporter isn't good, indeed. You can make your own teleporter-like class with other base class (e.g. Engine.Triggers) and with the same implementation as Engine.Teleporter. Alternatively, it's possible to use a pair of initially disabled Engine.Teleporter actors with different tags and apply filtering to actors that would generate the corresponding events for them.
E.g.
Dispatcher1 -> 'exit_event' -> Counter1 (SP-only) -> 'exit_sp_event' -> Teleporter1
Dispatcher1 -> 'exit_event' -> Counter2 (Net-only) -> 'exit_coop_event' -> Teleporter2
When exit teleporters can be initially enabled by design, it may be possible to use more simple scheme:
Trigger1 (Net-only) -> 'exit_event' -> Teleporter1 (initially enabled)
Trigger1 (Net-only) -> 'exit_event' -> Teleporter2 (initially disabled)
Here Trigger1 is supposed to be removed in SP and toggle states of Teleporter1 and Teleporter2 in Coop.