horbin Posted March 30, 2015 Author Report Share Posted March 30, 2015 Darth, Check the Docs folder on the GitHub distro. Every mission can have its AI behavior modified, as well as the 'win' conditions. Summary: AI logic options; Permitted AI logic on a 'per group' basis within every mission. ["BUILDINGS", [spawnloc], [actionloc], [range] ] ["EXPLORE ", [spawnloc], [actionloc], [radius]] ["BOXPATROL", [spawnloc], [actionloc], [radius]] ["CONVOY", [spawnloc], [actionloc], [speed, FlagRTB, FlagRoads, FlagDespawn, convoyType]] ["SENTRY", [spawnloc], [actionloc], [radius]] ["PARADROP", [spawnloc], [actionloc], [speed, altitude, FlagRTB, FlagSmokes]] ["PATROLROUTE", [spawnloc], [actionloc], [behaviour, speed, [locations], FlagRTB, FlagRoads, FlagDespawn, flyHeight] ["ZOMBIE", [spawnloc], [actionloc],[]] **All loc's can be defined via 3D map specific coordinates, 2D offsets, or a town name (ie "Starvos") "EXPLORE" syntax: ["AREAPATROL",[spawnloc], [actionloc], [radius]] -spawnloc: offset or specific map location group will spawn. -actionloc: offset or specific map location at which group will begin their patrol. -radius: size of the area, in meters, for the group to patrol. Behaviour: 12 evenly spaced waypoints are generated at a 'radius' to 'actionloc'. These waypoints are then randomized and the group set to start patrolling these waypoints. Group will recycle to the 1st waypoint when the 12th waypoint is reached. "BOXPATROL" syntax: ["BOXPATROL", [spawnloc], [actionloc], [radius]] -spawnloc: offset or specific map location group will spawn -actionloc: offset or specific map location at which unit will begin their building search -radius: size of the area, in meters, for the group to patrol. Behaviour: 4 waypoints are built at the corners of a square with a diagnol of 2*'radius'. The group will proceed to the eastern most waypiont then continue in a counterclockwise pattern. "BUILDINGS": syntax: ["BUILDINGS", [spawnloc], [actionloc], [range]] -spawnloc: offset or specific map location group will spawn. -actionloc: offset or specific map location at which group will begin their patrol. -range: range from 'actionloc' that the group will look for buildings to search. Behaviour: Units within the group will wait until they are on foot. At this piont they will proceed to 'actionloc'. Upon arrival, all buildings inside of 'range' radius will be identified. A random search of these buildings will begin, and continue until 'duration' time passes. When a unit gets to a building, it will inspect all locations within the building before continuing onto another random building on its list. At this point, the group will continue onto its active waypoint (if any). Note: There is a tendancy for units to get 'stuck' on certain structures. A routine has been added to try and identify when a unit is stuck and teleport it to a nearby road segment. If no buildings are found within 'range'unit will continue to its current active waypoint (if any). "CONVOY" syntax: ["CONVOY", [spawnloc], [actionloc], [speed, FlagRTB, FlagRoads, FlagDespawn, convoyType]] -spawnloc: offset or specific map location group will spawn -actionloc: offset or specific map location at which unit will perform its drop-off or evacuation. -speed: "NORMAL", "FULL", or "LIMITED" - limited and normal will provide better 'convoy' effects -FlagRTB: true=group will return to 'spawnloc' upon completing its action at 'actionloc'. false=group will drop off its cargo, then begin a boxpatrol pattern around their drop off location. -FlagRoads: true=group's vehicles will spawn on a road, and drivers will attempt to use roads to get too 'actionloc' -FlagDespawn: true=group, its vehicles, and its occupants will despawn upon returning to 'spawnloc' -convoyType: "XFILL"= see below Behaviour: group will move from spawnloc to actionloc. At 'actionloc', if convoyType is "XFILL" an evacuation call will be made to all units within 200 meters of 'actionloc'. All units, up to the capacity of the group's vehicles will proceed to and board the vehicles. When loading is complete, vehicles will return to 'spawnloc'. If convoyType is "INSERT", then at 'actionloc', vehicles will disembark all units in their cargo. "SENTRY" syntax: ["SENTRY", [spawnloc], [actionloc], [radius]] -spawnloc: offset or specific map location group will spawn -actionloc: offset or specific map location at which unit will take up its guard position. -radius: distance from 'actionloc' that the group searchs for available buildings. Behaviour: Group will proceed to 'actionloc'. Upon arrival, group will search 'radius' for available buildings. Individual units in the group will then enter the buildings and climb to the highest points in the buildings and take up a "COMBAT" ready position. "PARADROP" syntax: ["PARADROP", [spawnloc], [actionloc], [speed, altitude, FlagRTB, FlagSmokes]] -spawnloc: offset or specific map location group will spawn -actionloc: offset or specific map location at which group (of pilots) will drop off their cargo (paratroopers) -speed: "NORMAL", "FULL" or "LIMITED" -altitude: in meters pilots will fly their vehicles -FlagRTB: true= group of pilots will return to spawn location after paradrop. false=group of pilots will loiter in drop area -FlagSmokes: true=paratroopers will drop smoke when approaching the ground. Behaviour: Group assigned will fly to actionloc and release all AI in their vehicle as 'cargo'. AI released will execute a halo type paradrop script. Driver's vehicle will spawn airborne. "PATROLROUTE" syntax:["PATROLROUTE", [spawnloc], [actionloc], [behaviour, speed, [locations], FlagRTB, FlagRoads, FlagDespawn, flyheight] -spawnloc: offset or specific map location group will spawn -actionloc: offset or specific map location at which behaviour will start. For RTB flag, this will define the AI's 'base' location. -behaviour: "CARELESS", "SAFE", "AWARE", "COMBAT", "STEALTH" - impacts AI's tendency to follow roads, and use lights. -speed: "NORMAL", "FULL" or "LIMITED" -[locations] : array of 2d locations, 3d locations, OR town names. -FlagRTB: true= group of pilots will cycle through all locations -FlagRoads: true= group will attempt to use roads to get to the locations -FlagDespawn: true= group will despawn upon reaching final location. false= group will repeast route. -flyheight: if 'air' vehicle, altitude to fly the route. Behaviour: group will patrol the locations specified, designed for longer distance, fixed location type patrols. If vehicle is of type 'air' it will spawn airborne. "ZOMBIE" syntax: ["ZOMBIE", [spawnloc], [actionloc],[]] -spawnloc: offset or specific map location group will spawn -actionloc: offset or specific map location at which behaviour will start. -options array must be blank! Behaviour: FSM AI logic disabled, AI will wonder randomly, responding to gun fire, and visible players withing 75m's of the AI. AI will attempt to approach player and attach them with its hands. Summary of Trigger conditions that can be used to define the Win and Lose conditions for each mission ["LowUnitCount", side, numAI, radius, offset] ["HighUnitCount", side, numAI, radius, ofset] ["ProxPlayer",offset, range, numPlayers] ["Detected", group#, vehicle#] ["BodyCount", numAI] ["Timer", seconds] ["AllDeadorGone"] ["Reinforce", chance, "mission"] <-- only use in Win State trigger area! Defined Trigges ["LowUnitCount", side, numAI, radius, offset] -side: "EAST","WEST","GUER","CIV","LOGIC","ANY" -numAI: number of AI of type 'side' below which make the trigger TRUE. -radius: distance the trigger searches when counting AI -offset: centroid of the trigger. Supports 2D offset, or 3D map absolute positions. Behaviour: When the number of units on a 'side' drop below 'numAI' within 'radius' of 'offset' the trigger registers TRUE. ["HighUnitCount", side, numAI, radius, ofset] Behaviour: When the number of units on a 'side' exceeds 'numAI' within 'radius' of 'offset' the trigger registers TRUE. ["ProxPlayer",offset, range, numPlayers] -offset: centroid of the trigger. Supports 2D offset, or 3D map absolute positions. -range: range from 'offset' the count is counducted. -numPlayers: the number of 'players' the number of players to count. Behaviour: When at least 'numPlayers' are detected within 'range' of 'offset' the trigger registers TRUE. ["Detected", group#, vehicle#] -group# : group that is performing the 'detection' check. 1st group is indexed at 0. -vehicle#: vehicle driver that is performing the 'detection' check. 1st driver is indexed at 0. Behaviour: If the indicated group or vehicle is actively detecting a player the trigger will register TRUE. A value of -1 will turn off the check for that type. A value of 99 will run the check for all of that type. Ex: ["Detected", -1, 99] will run the check for all vehicles, and no groups. Ex: ["Detected", 2 , 3] will run the check for the 3rd group in the mission file, and the 4th vehicle crated. Note: Unoccupied vehicles count in this check if you are trying to determine a vehicle number in a 2nd convoy group. Note: AI spawned via reinforcements or phase changes will not register this trigger. ["BodyCount", numAI] -numAI: number of AI, reguardless of side that are killed by players during mission execution. Behaviour: If the number of AI killed during mission execution exceeds 'numAI' the trigger will register TRUE. Note: AI from 'reinforcements' and phased missions will count towards this total. Note: AI killed by player vehicles will not count. ["Timer", seconds] -seconds: time in seconds Behaviour: After 'seconds' of time elapse from mission start the trigger will register TRUE. ["AllDeadorGone"] Behaviour: true when all ai associated with a mission and its phase missions have been killed or have despawned. This check is done MAP wide, so may be more useful in detecting mission state on some large area mission. Link to comment Share on other sites More sharing options...
horbin Posted March 30, 2015 Author Report Share Posted March 30, 2015 computermancer, AI difficulty is modified in the \FuMS\Themes\BaseServer.sqf. If you do not want the AI to have rocketlaunchers, this is modified within the \FuMS\Themes\GlobalSoldierData.sqf OR the SoldierData.sqf of the applicable theme (if you are using a custom soldiers for that theme). As of the last ARMA patch, the AI often 'drop' their weapon upon death. This weapon drop is occuring before the "killed" EH triggers so they can not be properly cleaned up. A fix for this is in the works for FuMS. (next release) [ // Soldier Defaults 3, // default number of rifle magazines for each AI 3, // default number of pistol magazines true, // Turns ON VCOM_Driving V1.01 = Genesis92x for all land/boat vehicle drivers //http://forums.bistudio.com/showthread.php?187450-VCOM-AI-Driving-Mod //Skill Override options: // Values here will override values for individual units defined in SoldierData. // values ranges 1.0 -0.0 0= uses GlobalSoldierData.sqf setting for each soldier. // defaults 'stock' ai based around values indicated below. // if unique AI are desired, modify these numbers in GlobalSoldierData.sqf or SoldierData.sqf as applicable. // values here OVERRIDE any value set in the other files! (value of zero = use other files values). [ .8, // aimingAccuracy .05 : target lead, bullet drop, recoil .9, // aimingShake .9 : how steady AI can hold a weapon .5, // aimingSpeed .1 : how quick AI can rotate and stabilize its aim and shoot. .9, // spotDistance .5 : affects ability to spot visually and audibly and the accuracy of the information .8, // spotTime .5 : affects how quick AI reacts to death, damage or observing an enemy. .9, // courage .1 : affects unit's subordinates morale .5, // reloadSpeed .5 :affects delay between weapon switching and reloading .8 // commanding .5 : how quickly recognized targets are shared with the AI's group. ] ], Link to comment Share on other sites More sharing options...
Darth_Rogue Posted March 30, 2015 Report Share Posted March 30, 2015 Ok I see it now. Can this be set globally so it's the same for every mission? Seems like a lot of work to have to manually edit each individual mission in each theme on every update release. Link to comment Share on other sites More sharing options...
horbin Posted March 30, 2015 Author Report Share Posted March 30, 2015 For the 'auto/rapid' kicks of the HC.....make sure your HC is actually using the .3.0.1 @EPOCH files. I was seeing what has been described earlier until I updated the files on my HC. Still looking into the issue, but I am not seeing the problem on my test server after verifying the update to the HC's files. Let me know if anyone is still seeing the disconnect/cleanup issue. Link to comment Share on other sites More sharing options...
second_coming Posted March 30, 2015 Report Share Posted March 30, 2015 As of the last ARMA patch, the AI often 'drop' their weapon upon death. This weapon drop is occuring before the "killed" EH triggers so they can not be properly cleaned up. A fix for this is in the works for FuMS. (next release)I wondered why lots of people were running round with rocket launchers recently, thankfully they have no ammo for them :) Link to comment Share on other sites More sharing options...
horbin Posted March 30, 2015 Author Report Share Posted March 30, 2015 ya, good thing the AI doesn't pre-load them :) Link to comment Share on other sites More sharing options...
horbin Posted March 30, 2015 Author Report Share Posted March 30, 2015 Darth, I do not touch the files in the Themes folder unless specifically 'noted' in the updates. Any changes admins make to the mission files, or their individual themes will require Zero changes with future updates. Just copy your stuff back into the Themes folder. All the 'heavy' lifting is done outside the Themes folder, so unless you want to add some 'new' functionality (for example zombie ai behavior) to your mission sets, no changes needed from update to update. With one exception all the themes I provide with FuMS are pure examples to try and demo some of the flexibility and high-level programming most admins with little coding experience can manage. I have not really put a lot of thought into any of the Themes packaged with FuMS... This mod is more for the 'build your own' missions specific to your player base. A couple of the Missions and one of the themes was originated by Millertime from HighTimeZ. If there is something specific you are looking to do within a mission and don't think the functionality is there, let me know. It does not take much effort at this point to fold in dynamics. Link to comment Share on other sites More sharing options...
Darth_Rogue Posted March 31, 2015 Report Share Posted March 31, 2015 Ok sounds good. I have another question. Is it possible to run a second HC for another purpose? I thought I recalled seeing where you could specify in the settings the name of the HC that FuMS connects to, but of course now that I'm looking for it I can't find it. Link to comment Share on other sites More sharing options...
horbin Posted March 31, 2015 Author Report Share Posted March 31, 2015 Yea, with v1.4 FuMS supports multiple HC's. You can specify on which HC you want certain themes to run in the \FuMS\Themes\BaseServer.sqf. Also, within the Admin tool, you can designate an HC on which to spawn a mission. -1 = theme will run on all HC's (so multiple instances of the theme) 0= theme will only run on the Main server. 1 = theme will run on just the 1st HC to connect 2 = theme will only run on the 2nd HC to connect 3 = etc, etc Note: If FuMS is enabled server side, FuMS will also run any missions set at -1 on the server! [ // ActiveThemes // A folder matching the names below needs to exist in the ..\Themes folder. // use this block to easily turn off/on your various mission sets. // -1 = all HC's. 0= Server only, 1=1st HC to connect, 2=2nd, etc. // ["StressTest",-1], ["Test",1], // Runs only on 1st HC to connect ["HeloPatrols",1], ["SEM",-1], // Runs on ALL HC's and Server (if server FuMS enabled) ["TownRaid",1], ["Small",-1], ["Aquatic",-1], ["MadScience",-1] ], Link to comment Share on other sites More sharing options...
Darth_Rogue Posted March 31, 2015 Report Share Posted March 31, 2015 I'm still getting this error with Epoch 0.3 and FuMS 1.5 21:04:44 Error position: <FuMS_FPSMinimum}; _hc publicVariableClie> 21:04:44 Error Undefined variable in expression: fums_fpsminimum 21:04:44 File FuMS\Functions\InitHeadlessClient.sqf, line 13 21:04:44 Error in expression <MS_FPSMinimum"; Spams the server RPT endlessly and no missions start. Link to comment Share on other sites More sharing options...
horbin Posted March 31, 2015 Author Report Share Posted March 31, 2015 Folks that where getting the BE kick. See the following change: BE Filter: publicvariable.txt change !="FuMS_" to !"FuMS" I have an update ready that fixes the crazed-clones and rocketlauncher issue. I am not able to duplicate the 'HC disconnect'/Failure of mission starting' reported by a few folks after the .3.0.1 release. If anyone is still having an issue with this, let me know and please post up a copy of your HC's .rpt. I'll post up the small fixes tomorrow. Link to comment Share on other sites More sharing options...
Darth_Rogue Posted March 31, 2015 Report Share Posted March 31, 2015 HC Server RPT HCServer_2015-03-30_21-09-00.zip Link to comment Share on other sites More sharing options...
Brunz Posted March 31, 2015 Report Share Posted March 31, 2015 Hi, See logs attached from HC and Server with errors. Hope it helps errorlogs.zip Link to comment Share on other sites More sharing options...
FSBRU Posted March 31, 2015 Report Share Posted March 31, 2015 In addition to logs can lay out the work.or so and we will log your swing?wrote would make for yourself.I have so many logs that month will not understand Link to comment Share on other sites More sharing options...
MillerTime Posted March 31, 2015 Report Share Posted March 31, 2015 Welcome back from vacation Link to comment Share on other sites More sharing options...
joquinn Posted March 31, 2015 Report Share Posted March 31, 2015 Great work on the mission system. Been having lots of fun with it on my test server. Noticed something after updating from an old version to 1.5. I think the options for whether to use global loot data and global soldier data in the theme are backwards. I removed the solfierdata file from the 'small' theme. I then started getting rpt errors saying there was a problem with loot but it listed soldierdata.sqf as the offending file. Not a show stopper as I have changed all my themes to use both global soldier and global loot now. Just wanted to mention it. Also on HCs: I noticed that when I changed the configs so that all themes spawn on HC 1 (I only run one currently) no missions spawned. After checking I noticed it was because the mission system thought the current HC was HC number 3. My guess is that when the HC disconnects then connects back it gets a new HC number. I can't think of a work around for this issue. I just set all my themes back to the -1 option. However this will affect future use of multiple HCs. Perhaps it would be possible to put a text string in the field with the profile name of the desired HC? Don't know. One last thing...the ability to spawn missions at totally random spots appears to be broken. All my missions now spawn in random cities instead of random locations anywhere. Tried something like ["mission',0] but that through an error in the RPT. I have probably missed something you changed as far as how to define this but can't find it ATM. Is it possible to still spawn missions at random x,y coordinates as in previous versions? If so how? ;-) Now some feature requests: 1. The ability to make a convoy style mission where the mission marker follows the convoy group rather than being statically located at the start or finish of the mission. I added this functionality to one of your earlier versions but wasn't able to keep it working through your updates. 2. The option to not spawn missions within x meters of any other mission. 3. Add a water check within x meters of any chosen mission location not designated as supposed to be on water. If it fails choose a new location and check again, etc. Sometimes a mission spawns on the shore on land but assets and AI wind up in the water. The easiest option would be to check in all four compass directions out to a distance of maybe 1.5x the mission radius. If that is too complicated make it a fixed amount (say 200 m) that can be configured via an option in the mission system configs. See DZMS from Arma2 for an example of this implemented. (In fact I used the DZMS code as an example to modify an earlier version of your mission system). It isn't perfect (can still hit lakes or water in areas with really irregular shore lines) but it works in a pinch. 4. A function that allows an array of map center positions and map radius to be defined based on map (world) name. This makes it a lot easier to add future map support without needing a different version of the mission system for every map. Admin just extends the array with data for a new map and viola! Once again great work! Keep it up! Link to comment Share on other sites More sharing options...
Darth_Rogue Posted March 31, 2015 Report Share Posted March 31, 2015 Perhaps it would be possible to put a text string in the field with the profile name of the desired HC? ^^ This = +1 Link to comment Share on other sites More sharing options...
SpiRe Posted March 31, 2015 Report Share Posted March 31, 2015 Perhaps it would be possible to put a text string in the field with the profile name of the desired HC? class Item100 { side = "LOGIC"; class Vehicles { items = 1; class Item0 { position[] = {10720.502,12.714643,11356.243}; special = "NONE"; id = 100; side = "LOGIC"; vehicle = "HeadlessClient_F"; player = "PLAY CDG"; leader = 1; skill = 0.6; text = "HC_Remini"; init = "this enableSimulation false; this allowDamage false;"; }; }; }; Or perhaps... Link to comment Share on other sites More sharing options...
joquinn Posted March 31, 2015 Report Share Posted March 31, 2015 Yes Spire. Now we just need an option to use that name as the pointer to the HC we want the missions to spawn on. Link to comment Share on other sites More sharing options...
rhammer2003 Posted March 31, 2015 Report Share Posted March 31, 2015 does anyone have a description file they could post that I could use as an example? I cant seem to get mine to work properly, I keep getting an error. Link to comment Share on other sites More sharing options...
horbin Posted March 31, 2015 Author Report Share Posted March 31, 2015 Joquinn, Noticed something after updating from an old version to 1.5. I think the options for whether to use global loot data and global soldier data in the theme are backwards. I removed the solfierdata file from the 'small' theme. I then started getting rpt errors saying there was a problem with loot but it listed soldierdata.sqf as the offending file. Not a show stopper as I have changed all my themes to use both global soldier and global loot now. Just wanted to mention it. Check the ThemeData.sqf for the offending theme. The Small theme, by default uses its own Loot and Soldier config files (lines 13,14). Set these to true to get the theme to use the global files. Removing the file was causing the error. I did have a copy/paste issue and the error message you get now talks to the 'mission SoldierData' file. Also on HCs: I noticed that when I changed the configs so that all themes spawn on HC 1 (I only run one currently) no missions spawned. After checking I noticed it was because the mission system thought the current HC was HC number 3. My guess is that when the HC disconnects then connects back it gets a new HC number. I can't think of a work around for this issue. I just set all my themes back to the -1 option. However this will affect future use of multiple HCs. Perhaps it would be possible to put a text string in the field with the profile name of the desired HC? Don't know. The HCid (in your case 3) should not be confused with the HC number used in FuMS. The number in FuMS is to permit admins to prioritize missions. So if you are using 2 HC's, the 1st HC to connect will spawn the initial missions (the ones you have set to 1) and the 2nd HC will spawn those associated with '2'. In any case the ID you are seeing for the HC is its internal OwnerID used by the server to identify it, and is separate from the numeration used by FuMS. I'm looking into trying to duplicate your bug with setting them all to 1 right now. Also, looking into providing a method to identify the HC by its 'text name'! One last thing...the ability to spawn missions at totally random spots appears to be broken. All my missions now spawn in random cities instead of random locations anywhere. Tried something like ["mission',0] but that through an error in the RPT. I have probably missed something you changed as far as how to define this but can't find it ATM. Is it possible to still spawn missions at random x,y coordinates as in previous versions? If so how? ;-) Check the 'test' theme's ThemeData for good examples for specific mission offset and fixed locations. The random location appears to be working ok atm. It may be that the only themes you have on atm are only using the 'city', 'village', 'town' keywords in the "Locations" section of the ThemeData file. Small and MadScience themes are both configured this way. I am not currently seeing issues with the other themes (SEM, Test) which use 100% random locs. Please let me know if you are still having issues and I can get with you to Trouble shoot. I got all your other inputs. All doable and will add them to my list for the next release. Note: There is already water-avoidance code in the mission spawning routines, just not 'effective' enough. Also, as you may have seen, when AI do spawn overwater they are automatically given rebreathers and dive-suits to enable them to 'swim to shore'. Only issue I have to date is when AI spawn on land and their patrol path takes them into water....then it becomes a day at the beach!!!! :( Link to comment Share on other sites More sharing options...
joquinn Posted April 1, 2015 Report Share Posted April 1, 2015 I get what you re saying now on the headless client IDs. Also kept having problems with it looking like some missions didn't spawn and then two copies of missions spawned. I also was experiencing low server fps. I discovered what I think the problem is. Check line 6 in FuMsnInit.sqf. In your code it has !(hasinterface). The description says this section is to be executed on the headless client. Except !(hasInterface) isn't enough to guarantee you are on the HC. I changed it to (!isServer && !isDedicated && !hasInterface) and I stopped getting flaky mission spawn behavior. Only one copy of each mission. It also seems that about the same time random, non named, location spawning started working again. However I also made a few other tweaks. So I'm not sure if I actually fixed the issue or if I caused the issue to begin with, then fixed it with the code above plus the other tweaks. Link to comment Share on other sites More sharing options...
horbin Posted April 1, 2015 Author Report Share Posted April 1, 2015 V 1.5a up...had to make a new github link..sorry to break the old one for folks following....github kicks my ass sometimes ;/ https://github.com/horbin/FuMS-HC-Server/tree/master v1.5a Fix to Crazed-Clones - now properly attack players Fix to AI RocketLaunchers are not properly removed upon AI death. Corrected language for error message received when attempting to read a Theme's Soldier or Loot files and they are not present. Fix to 'invalid' HC disconnects detected by server during initial HC connection. (was accomplished by waiting for the 'gender' of the HC to be defined before allowing the server to watch for the disconnect) thanks to SpiRe for the pointer- Note: This is a 'test fix'. I am having issues duplicating this error on my test server..so further input may be needed if this does not resolve the issue! SpiRe 1 Link to comment Share on other sites More sharing options...
horbin Posted April 1, 2015 Author Report Share Posted April 1, 2015 joquinn, You are correct on the FuMsnInit line. BUT by doing what you did, it will block the server from running missions. The big 'feature' to v1.5 was sever side mission support. To help folks not familiar with HC's I added this ability. This may be why you where seeing 'multiple' missions running. Some where running on the server. The option to run FuMS on the server is controlled on line 15 of the \FuMS\init.sqf file FuMS_ServerFuMSEnable = true; setting this to false will turn off FuMS's ability to spawn missions using the server as a host resource. (ie -1 will only use the HC's and not the HC's and Server!) All of this probably explains the FPS hit you where seeing. :) Link to comment Share on other sites More sharing options...
rhammer2003 Posted April 1, 2015 Report Share Posted April 1, 2015 Hi Guys, Please see my earlier message. I am looking for a working description.ext example. does anyone have one they could post that I may look at this. Mine is not working correctly, and I want to make sure I have this setup right. Thganks Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now