meatball

Is it possible to have a mission init.sqf autodetect whether there's a HC connected and broadcast that as opposed to relying on parameters? I was thinking along the lines of something like this as the first lines of the mission init.sqf: if (!hasInterface && !isServer) then{ hcPresent = true; publicVariable "hcPresent"; } else { hcPresent = false; publicVariable "hcPresent"; }; Any reason why that wouldn't work? If it does, then you could pretty easily use the hcPresent variable to determine whether AI spawn calls run on the server or the HC.

Random question. The CBA requirement, is that just for server/headless client, or for everyone connecting/playing? And when you say 'drag and drop' is it simply a matter of dropping the whole "Unit Caching" folder in my root folder or do I need to add any lines to my root init/description/etc files.

Thanks. I've been thinking on this for the last hour or so, and I'm wondering if I can make this work without too much effort. I've got my dedicated server, and I've got a headless client setup. I've set my mission up so it has a Civilian slot for the Headless Client and set up a parameter I can select at the briefing screen that will set a global variable "HCPresent" to true or false based on that the parameter selection. I've tested it out and assuming I connect and login as admin first, the HC connects and grabs the civvie slot correctly. So, looking at everything, I now have a global variable that I can reference in game as to whether or not there's a HC connected, and I should be able to grab that HC profile name/client ID since I know the slot it's in. Since almost every AI and the caching script I have in the game is created by simple triggers spawning the AI script call, there _has to be_ a way I can configure the triggers to run only the scripts on the Headless client if it's connected, or run them on the server if it's not. I'm wondering if I duplicate every trigger and set one to have conditions of "(HCPresent==false) and isServer" and the other to have "(HCPresent==true) and (clientID==HCID)" Of course, the more I'm diving into this, the more I'm thinking it might just be easier to figure out how to integrate your script in and save myself a lot of headaches ;)

Hey Naught, I actually saw that and it looks awesome, but I don't know if it'll work in my case. Specifically I've already got caching set and ready, I just want to offload the AI processing to a HC. Plus I need to be able to count numbers of AI being cached and cache/support AI vehicles (mostly using spunFin's AI Spawn Script Pack ambientcombat and militarize scripts). Other challenge is that CBA is required. Not that I don't use CBA, I've just been trying to avoid forcing people to use any addons for my missions.

Redownloading seems to have done the trick. Thanks Fred!

Locality is killing me. I've got a script that I've written up for a task. The task involves the players meeting an enemy defector (defector47) who will join their group and follow them as they escort him to an extraction point. When they arrive at the point a friendly AI chopper should come in, land, and then once the defector is on board, (the players have to order him aboard), the defector should leave the group, the chopper should take off and then fly away. Everything works fine when the server is hosted locally, but on a dedicated server, everything works up to the point of the chopper coming in and landing, the defector getting onboard and leaving the group, but the chopper never takes back off and just sits there with the defector on board. // Create Evac Chopper and fly to extraction LZ to pick up defector. hint "Your radio crackles to life, ""This is LB-3, we are in bound to pick up the package. Be there shortly, over."""; // Define Local Variables private ["_evacH","_heli","_heliCrew","_heliGroup"]; if (isServer) then{ // Spawn Evac helicopter and fly to Evacuation Point after a short delay. _evacH = [markerPos "evacSpawn", random 360, "B_Heli_Light_01_F", west] call BIS_fnc_spawnVehicle; // Set evacuation helicopter settings. _heli = _evacH select 0; _heliCrew = _evacH select 1; _heliGroup = _evacH select 2; _heli allowDamage false; // Would suck to get shot down during evac after finishing the whole mission. evacHeli = _heli; heliGroup = _heliGroup; // Set Evac helicopter waypoints and move to evacuation LZ. wp0 = heliGroup addwaypoint [getMarkerPos "task_47B", 0]; wp0 setWaypointType "LOAD"; wp0 setWaypointSpeed "NORMAL"; wp0 setWaypointBehaviour "STEALTH"; wp0 setWaypointCombatMode "BLUE"; wp0 setWaypointStatements ["true","doStop evacHeli; evacHeli land 'LAND';"]; }; // Once chopper is down, wait for defector to get in. waitUntil {{_x in evacHeli} count [defector47] > 0}; [defector47] joinsilent grpNull; if(isServer) then{ // Once defector is in, fly to end mission marker/trigger and delete chopper/crew. wp1 = heliGroup addwaypoint [getMarkerPos "endMark", 2]; wp1 setwaypointtype "MOVE"; wp1 setWaypointCombatMode "BLUE"; wp1 setWayPointStatements ["true","{deleteVehicle _x} forEach (crew evacHeli); deleteVehicle evacHeli;"]; };

Well, you asking about dostop got me thinking, so I pulled it from the wp0 statements and now it works on both locally hosted and dedicated servers with just this: wp0 setWaypointStatements ["true","evacHeli land 'LAND';"]; Must be something with the doStop command and locality I guess. Thanks for the help!

Nope, no dice. Tried it by adding the heligroup move getMarkerPos "task_47B"; right above the wp1 lines. Worked fine on a locally hosted server, didn't work on dedicated. Reason I'm using the doStop/Land combo is I've found that if I don't, often the chopper will touch down and then just fly off to the next waypoint immediately regardless of whether folks are on board or not

You positive fillHouse.sqf is in that LV folder and the LV folder is in the root folder of your mission? The engine is basically saying it doesn't see that file in that location.

I've been trying to make my missions more efficient, but have been running up against a bottleneck of all triggers, functions, scrips and AI control getting shoved into a single core of a CPU. Even with a i5-3570K and the -cpuCores=4 switch, Core 0 just loads up to 100% while my other cores do next to nothing. Other than reconfiguring my missions to have headless client support, is there any way to force scripts, functions, etc., to use different cores or is that pretty much a limitation of the engine that can't be shortcut any other way?

Yeah, according to the gitHub page, it's supposed to get dumped in the dll folder. I tried moving it into the root folder as well with the same result. As for maxMem, it's confusing to me as well as I've seen multiple people saying different things about it. I have the memory, so I figured I might as well dump as much in the maxMem switch as possible and if the engine limits it in some way, so be it. :)

Been trying to use the new version but having some issues. When I go to launch with the new tbmalloc.dll I get an error popup about the dll. Once I click OK on the error, the server actually launches, but I assume it's not using the new allocator. Here's the basic machine specs: Win7 Pro x64, i5-3570K @ 4.2Ghz, 16 GB RAM, SSD for game/OS data. I've also made sure the both the launcher (Tophe's) and arma3server.exe are set to run as administrator and set the lock pages local policy for both admin and the account I'm logged onto the machine. Finally I'm launching the latest performance binary build (233780) of A3 server with "-malloc=tbbmalloc -maxMem=8184 -nologs". Since the new allocator doesn't appear to start I'm not getting any logs to post.

Random question on this script that I've been finding. I've got things setup to cleanup immobile vehicles after 15 minutes, but what I've found is if a vehicle gets 'wrecked', but you then repair it, it still gets cleaned up after 15 minutes, regardless of whether you're in it and driving :) There a way to reset the 'immobile' timer every time it's repaired or starts moving again?

Ah, perfect, thanks! I had a waituntil already in there waiting for the singleClick so I just added in 'or !(visibleMap)' and then added an if statement right after that doing an exitwith if !visiblemap and cancelling the onMapSingleClick.

With onMapSingleClick, does anyone know if there's a way to 'escape' out of the command and drop out of it with another key stroke other than a mouse click?

Hey, quick question on an old thread. Does anyone know how to edit the script so you can 'escape' out of the mortar strike if you'd like? Once someone selects the addaction and it gets to the 'onMapSingleClick' waiting for the strike location on the map, there's no way to back out. Be nice if there was a "Press escape to cancel strike" or something at that point. Oh, a quick follow up to one of my old questions, use "R_230mm_fly" as your roundType if you want bigger booms. :)

I _think_ I might have pinned down the problem with empty vehicles popping up. First, definitely use the new files that spunFin listed above as they fix some other bugs. But I was still seeing empty vehicles popped up. I narrowed it down that it appeared the vehicles were spawning, but crews were not being created for them, so they'd just sit there empty and the cache script would bypass them for cleanup because they'd not have any crew in them. What _seems_ to have fixed it for me was a minor tweak to one of the functions. In LV_fnc_fullLandVehicle.sqf there are two 'sleep 2;' commands on lines 58 and 60. If you comment those out (put two backslashes in front of the line) it seems to fix the non crew problem for me. That block should look like this: _vehicle allowDamage false; //sleep 2; if(((vectorUp _vehicle) select 2) != 0)then{ _vehicle setvectorup [0,0,0]; }; //sleep 2; _vehicle allowDamage true; At least in all my testing so far I haven't noticed any empty vehicles showing up, but if some other folks having the issue want to try it and see if it fixes it, I'd be interested to know if it works for you as well. My completely uneducated guess is between the vehicle being spawned and a crew being spawned that 4 second delay causes a hiccup when other vehicles are being created as well and a vehicle or two just gets bypassed for crew creation...

Yep, same here. I know Arma can spawn multiple threads and use other cores for other functions like file/geometry loads (neither of which has much of an impact on a server at all once the mission is loaded), but scripting is single threaded/cored, so all of your scripts get crammed into a single core along with AI control, triggers, etc.

So, does -cpuCores=# do anything really useful then?

Mine are all set on markers as well, let me test using a dummy object or game logic and see if that fixes it. ---------- Post added at 21:21 ---------- Previous post was at 20:30 ---------- Alright, well I just tested using both a GameLogic object and a dummy object (a pencil) as the center points for my militarize script and I'm still getting empty vehicles. On the plus side, I think I have a possible explanation. I believe it has something to do with crews for vehicles and how vehicles are removed when the cache runs deleteVehicle. I don't believe the vehicles that are created are considered part of the group/ID of militarize units that are spawned. Because of that, there's a need in the simplecache 'cleanup script' to check every 'unit' in the group to see if the objects vehicle name is the same as the object name: if(vehicle _x != _x)then{deleteVehicle (vehicle _x);}; If vehicle _x and _x are not equal, it means the unit is actually sitting inside another vehicle and the two will have different names, so it then deletes the vehicle that _x is sitting in. This could possibly be causing empty vehicles to be left behind. Perhaps when the vehicle is originally created, for some reason it never gets a crew, so when the cleanup check runs, there are no units in the group that ever get checked that are in the vehicle, so it will never get deleted. It's basically orphaned out and just left there until a player hops in. To be honest, I've no idea if that's really the issue, or how to fix it if it is, but maybe it'll help someone else figure it out.

I've actually been trying to track down something with simpleCache as well. I've found is that if a militarize area that gets cached includes vehicles, everything will de-spawn correctly. But when the militarized area respawns as players move within range it will respawn the correct number of units but will spawn some un-crewed vehicles as well. These vehicles don't appear to be getting added to the proper group because if you then move back out of range, all infantry and crewed vehicles will despawn, but the spawned un-crewed vehicles will not. This leaves a bunch of empty and open enemy vehicles just sitting there for the taking. I'm trying to figure out where the problem is, but haven't been able to pinpoint it yet.

Is it me, or do the Engineers / Repair Specialists not have the capability to repair vehicles, even with a toolkit in inventory, with the base game?

Love the script so far, but have 2 quick questions. 1) Is there any way possible to limit it so only certain classes (Engineer and/or Repair Specialist) can do repairs? 2) I see the "if (isDedicated) exitWith {};" in the script that will drop out if on a dedicated server. What's the reason for the script not working on dedicated servers? Is it something that can be fixed?

One way to troubleshoot is to uncomment the two hints in the simpleCache script. Should be lines 79 and 90 where you can hint when groups are created and deleted.

I don't use Real Weather script, I use randomWeather (which I wrote :)) and have had no problems with it. I figured it out with some help from spunFin as well. Basically it wasn't the caching, it was Ambient Combat and the LV_fnc_removeAC call using Style 2 (Kill the units). It was killing all the crew in a vehicle when it was called, but not deleting/destroying the vehicle. So if the players happened upon the vehicle they had a brand new enemy vehicle sitting there. I simply changed the LV_fnc_killAfterDelay.sqf to read as follows: //ARMA3Alpha function LV_fnc_killAfterDelay v0.1 - by SPUn / lostvar //kills unit after random delay, used by LV_fnc_removeAC.sqf private ["_unit","_delay"]; _unit = _this select 0; _delay = _this select 1; sleep random _delay; if(vehicle _unit != _unit)then{(vehicle _unit) setDamage 1;}; sleep 1; _unit setDamage 1; Seems to blow up the vehicles just about all of the time.