-- When you see an option that does not have a platform preceeding it, that is the default
-- value for anything not specificly set per platform. So if remote_filesystem=0 and you have
-- ios_remote_file_system=1 then remote filesystem will be off for all platforms except ios
-- Any of the settings in this file can be prefixed with a platform name:
-- android, ios, osx, linux, windows, appletv, etc...
-- or left unprefixed, to set all platforms not specified. The rules apply in the order they're declared

sys_game_folder=StarterGame

-- remote_filesystem - enable Virtual File System (VFS)
-- This feature allows a remote instance of the game to run off assets
-- on the asset processor computers cache instead of deploying them the remote device
-- By default it is off and can be overridden for any platform
remote_filesystem=0
provo_remote_filesystem=0
xenia_remote_filesystem=0
android_remote_filesystem=0
appletv_remote_filesystem=0
ios_remote_filesystem=0
osx_remote_filesystem=0

-- What type of assets are we going to load?
-- We need to know this before we establish VFS because different platform assets
-- are stored in different root folders in the cache.  These correspond to the names
-- In the asset processor config file.  This value also controls what config file is read
-- when you read system_xxxx_xxxx.cfg (for example, system_windows_pc.cfg or system_android_es3.cfg)
-- by default, pc assets (in the 'pc' folder) are used, with RC being fed 'pc' as the platform
-- by default on console we use the default assets=pc for better iteration times
-- we should turn on console specifc assets only when in release and/or testing assets and/or loading performance
-- that way most people will not need to have 3 different caches taking up disk space
assets = pc
-- xenia_assets = xenia
-- provo_assets = provo
-- salem_assets = salem
android_assets = es3
appletv_assets = ios
ios_assets = ios
osx_assets = osx_gl

-- Add the IP address of your console to the white list that will connect to the asset processor here
-- You can list addresses or CIDR's. CIDR's are helpful if you are using DHCP. A CIDR looks like an ip address with
-- a /n on the end means how many bits are significant. 8bits.8bits.8bits.8bits = /32
-- Example: 192.168.1.3
-- Example: 192.168.1.3, 192.168.1.15
-- Example: 192.168.1.0/24 will allow any address starting with 192.168.1.
-- Example: 192.168.0.0/16 will allow any address starting with 192.168.
-- Example: 192.168.0.0/8 will allow any address starting with 192.
-- white_list =

-- IP address and optionaly port of the asset processor.
-- Set your PC IP here: (and uncomment the next line)
-- If you are running your asset processor on your own windows machine you
-- can find out your ip address by opening a cmd prompt and typing in ipconfig
-- remote_ip = 127.0.0.1
-- remote_port = 45643

-- Which way do you want to connect the asset processor to the game: 1=game connects to AP "connect", 0=AP connects to game "listen"
-- Note: android and IOS over USB port forwarding may need to listen instead of connect
connect_to_remote=0
windows_connect_to_remote=1
provo_connect_to_remote=1
xenia_connect_to_remote=1
salem_connect_to_remote=0
android_connect_to_remote=0
appletv_connect_to_remote=0
ios_connect_to_remote=0
osx_connect_to_remote=0

-- Should we tell the game to wait and not proceed unless we have a connection to the AP or
-- do we allow it to continue to try to connect in the background without waiting
-- Note: Certain options REQUIRE that we do not proceed unless we have a connection, and will override this option to 1 when set
-- Since remote_filesystem=1 requires a connection to proceed it will override our option to 1
wait_for_connect=0
provo_wait_for_connect=0
xenia_wait_for_connect=0
salem_wait_for_connect=0
windows_wait_for_connect=1
android_wait_for_connect=0
appletv_wait_for_connect=0
ios_wait_for_connect=0
osx_wait_for_connect=0
assetProcessor_branch_token = 0xC6BFBEE5