opusfmspol

I'm not experiencing this in a clean map, new mission set up.

Receiving errors in A2, but not in OA. Related to Garbage Collector: Error in expression <C_trashItFunc;};};} forEach entities "Man";{if (!alive _x) then { _dontCa> Error position: <"Man";{if (!alive _x) then { _dontCa> Error Missing ; It's using entities command to remove things. Related to SILVIE: Error in expression <1, 0]; _car setVectorUp (surfaceNormal _tempPos);_car setvariable ["SILVIE_id"> Error position: <_tempPos);_car setvariable ["SILVIE_id"> Error Missing ) File ca\modules\silvie\data\scripts\spawnVehicle.sqf, line 36 It's using surfaceNormal command in setting vector. wiki lists entities and surfaceNormal commands as OA 1.60 (won't work for A2). With the SILVIE error, vehicles still appear. But the error loops, spamming the .rpt every time a town is approached. From what I could tell Garbage Collector wasn't collecting.

From what I can tell, BIS_WF_GetFastTravelTime only gets called by Server\Functions\Server_AITeamFastTravel.sqf. So it probably only pertains to AI fast traveling. Server\Functions\AITeamMove.sqf decides whether or not to initiate Fast Travel for AI; but for Player fast travel begins in Client\GUI\GUI_MapDiaryEH.sqf. In my testing I could only get BIS_WF_GetFastTravelTime to show a message when BIS_WF_DebugMarkers = true.

Ah, my bad. It was an original A2 post and I thought you meant for A2. Yeah, I'd agree that wouldn't work for A3.

BIS_WF_GetFastTravelTime isn't a value, it's a function (script). You'll want to review these scripts to see how the BIS_WF_Constants variable FASTTRAVELSPEED is (or is not) used: Client\Functions\Client_GetFTTime.sqf This is BIS_FNC_GETFTTIME in scripts. Common\Functions\Common_GetFastTravelTime.sqf This is BIS_WF_GetFastTravelTime in scripts. The supply ratios set for towns and their supply points seem to have more to do with the Fast Travel time. FASTTRAVELSPEED also appears in these two .SQS scripts. Maybe they're from the older version of Warfare having the "classic" interface, or maybe I'm not looking in the right place; but I don't find them being called up by anything: Client\GUI\GUI_UpdateFT.sqs Client\GUI\GUI_UpdateMissionMap.sqs

For learning's sake... It was figured out. Using LOAD and GET IN waypoints has a locality issue in multiplayer. For the waypoints to work the vehicle must be created on the same machine (or instance of Arma) as the unit ordering the get in. (See this post): When the mission circumstances don't really allow for this, a scripted landing and load would be the way to go.

The scripts only run for players. Only AI leaders respawn, and their respawn is handled by Server\AI\Team\Team_Update.sqf and Server\AI\Team\Team_UpdateRespawn.sqf.

Use setVehicleInit on the units, and then processInitCommands. They're global commands, so you may have to condition the code statement to run only on the correct machine.

When a player respawns in a Warfare mission, all "killed" event handlers get removed. Warfare's "killed" event handler is then added to the unit. Check script Client\Functions\Client_PlayerRespawn.sqf. The script Client\Functions\Client_Killed.sqf is Warfare's "killed" event handler script. Adding it there might work, but adding it to the respawn script may be better.

The unit might be respawning with the old ACM still registered or running. You can see in the init script that when an ACM initializes it checks synchronized objects and registers in each unit of its detected group. If a new ACM detects an ACM already registered in any unit of the group, the new ACM shuts down. The old ACM might still be running, or it might not. In the FSM the delay time between checks is random: //Base the delay on the intensity (lower intensity means longer delays). _delay = (20 + (60 * (1 - _intensity)) + (random (240 * (1 - _intensity)))) max 1; After the random delay time the first thing it does is check to see if the team was wiped out: ({alive _x} count (units _grp)) == 0 If the team is detected as wiped out, the ACM cleans up and gets deleted. But if it doesn't detect the team wiped out it keeps running. It's a matter of the timing, what did the check find? And it takes about thirty seconds for an empty group to be deleted. Respawn might keep the group from getting deleted, but does the respawned unit still have ACM registered to it? before creating a new ACM you would want to run some checks on the old ACM to find some things out, i.e,: - Did any group members survive (old ACM remains running)? - Has the ACM gone null (ACM is gone, detected team wiped)? - Has respawn occured into the same group as before (group was not deleted)? - Is the ACM still registered in any surviving units or in the respawned unit (a new ACM would shut down)? Addressing these questions should help decide whether another ACM is needed, or whether certain actions are needed (like reregistering the old ACM in the respawned unit; or removing the old ACM registration before creating a new ACM).

I can help with that when you do. I've got some remaining errors identified and resolved, ones harder to track down which don't throw errors to the .rpt.

The shut down is part of the FSM. It's very likely designed to shut down because ACM uses the group of the unit it's synchronized to. Empty groups get deleted. The FSM would error on a null group. To avoid errors, after respawn have the server create another ACM and synch it to the player. See "Scripted ACM" under Advanced Topics: https://community.bistudio.com/wiki/Ambient_Combat_Manager Where it states: "This needs to be done within 0.5 seconds from the start of the mission, because after that synchronizations are processed and set in stone." Part of that is not correct. It should read: "This needs to be done within 0.5 seconds from the creation of the ACM, because after that its synchronizations are processed and set in stone." In the Init you can see the 0.5 second sleep before it processes the synchronized objects. You can test in editor by placing only a player unit, and a radio trigger calling up a scripted ACM. After calling my trigger, a chopper appeared around five minutes later. The scripted synchronization worked fine. In a server script after respawn:

It only checks on one structure per update, and each update occurs a little over a minute apart. At game start ACCELERATEDBUILDTIME is used to speed things up, but only to get the base started. I'm pretty certain that won't work because of how SQS behaves versus SQF. https://community.bistudio.com/wiki/SQS_syntax https://community.bistudio.com/wiki/SQS_to_SQF_conversion https://community.bistudio.com/wiki/SQF_syntax In your prior post above you tried to use slash comments ( // ) which is SQF. In SQS a semicolon ( ; ) at line start is used for comments. This is a large SQS script which does a lot of things using lots of GoTo's, and has a lot of internal variables used by the GoTo's. I imagine the reason it wasn't converted to SQF was that it functioned well and would have been a difficult and time demanding project. I would think it could be converted to an SQF script, but have never tried.

Found BIS_WF_SortByDistance, it uses Distance command rather than nearestObjects, nearEntities, nearObjects, etc., which is helpful. For the base structures, to cover the entire map use it with a copy of baseStructures array. When a custom max range is intended, the range can be passed into the call as third element (select 2):

Client\Functions\Client_PlayerRespawn.sqf has the addactions: The conditions are that BIS_WF_BuyGearInRange or BIS_WF_BuyUnitsInRange have to return true. Client\GUI\GUI_UpdateOptions.sqf shows what the conditions are for them to be true: I don't suggest simply changing any of these to "true", because then the options become available when structures don't exist, resulting in script failures. Client\Client_UpdateAvailableObjects.sqf shows what the conditions are for the "in range" variables to return not null. The command nearEntities is used to find which structures are within different ranges from the player. But nearEntities is an FPS demanding command. The larger the radius, the more drag on the processor, as it locates and has to process more entities found. Small radius like CONSTRUCTIONRANGE, CAMPRANGE, BASERANGE, hardly any lag. But if you extend its radius to cover the map you'll suffer a major (possibly unrecoverable) lag each update. I would think you would want to change the conditions here to things which do not rely on nearEntities (or nearObjects, same issue). There are varying conditions for the structures, and you'd have to consider each. Distance command doesn't have that drag, but you need the objects to get distance from. Maybe use baseStructures array, it's the maintained array of base structures on each client.

Fixed using new classnames, or fixed under the original classnames? I've been using the "Pchela1T_Fixed".

Maybe try breaking apart the one line into two: ;So if the supplies exists, update much more quickly to build these structures. if (_chance >= 100) then {_chance = 5000} if (_chance >= 100) then {if (_cost <= _supplies) then {_timeNextUpdate = time} Maybe the semicolons ( ; ) are giving it the problem.

I know what you mean, I encounter that too. But accelerating the build time won't really work. If you have the .pbo scripts, review: - Common\Config\Structures.sqf: Note the structure percentage (_p), which then gets set in the [SIDE]StructureChances array. It's the percentage chance of that structure being built each update. When used, the percentage gets modified up or down and compared to a random 100 chance; and I suppose for this reason it can be greater than 100. (Barracks are set to 400 so it's almost guaranteed one will be built during the "acceleratedBuildTime" at game start.) - Server\AI\Commander\Commander_UpdateBase.sqs: Being a server script, it only runs on the server. Check label #CheckToBuild. You'll see how the structure percentage gets modified up or down using an update ratio. But prior to that, if the percentage was 100 or higher, it was read as 5000 for the update [wow!]. So the approach you want to take is setting the structure percentage to 100 or higher when it gets destroyed. - Server\Functions\Server_StructureDestroyed.sqf: It's a "killed" event handler added to each structure built. You'll see that towards the end the server runs a block of code. What you want to do is use that section of code to set the structure's percentage to 100 or higher, and it will only happen when the "killed" event handler runs. Copy the script to your mission file and use it instead of the core script. Change this: To this: If you go through Commander_UpdateBase.sqs in depth, you'll find how the entire AI base construction sequence works. Since the server does the base building, the variable should only need to change on the server. And it shouldn't need to be changed back, keeping it there will ensure the structure gets rebuilt each time it's destroyed (supplies considered). Doing it in the "killed" event handler keeps it from affecting the assigned chance for other structures not yet built.

From your description: ".... that worked. that I opened notepad and created a file call into.sqs." "... when I change the unit's init file to this exec "intro.sqs" it only shows ...." - Make sure the exec matches the script name. - in an .sqs script, ( ; ) is the same as ( // ) in an .sqf script. It's a comment, information not relevant to the script running. - in an .sqs script, ( @ ) is the same as ( waitUntil ) in an .sqf script. It's a command, and is relevant to the script running. It tells the script to hold, but keep checking, until the camera gets committed. Then continue the script when it is committed. - If you think your game's not working correctly, take a couple minutes to "verify integrity of cache" on Steam. That should fix any corrupted file. Hope this helps. Edit ---- "... every tutorial I saw there was a @camCommitted_camera ..." "... I've added it manually." Mind the spaces, it's "@ camCommitted _camera". Maybe your script is hanging up there.

Might also consider that a dedicated server can be run on the same machine a player uses to join the mission. Some do their dedicated testing that way. There are separate instances of Arma on the same machine, one being server, one being client, each doing their own thing, on the same machine the client reaches out to join the server. (!isServer) tells all joined clients to exit the script. In SP and hosted environment the server and client are the same instance. Running dedicated and client on the same machine, they're not the same instance.

You also have to set the alliance (or at least a cease fire). But it has to occur after the mission starts since the function scripts have to compile first. In 3-sided multiplayer Warfare it's usually done by the player commander using the diplomacy panel in map. If setting it otherwise at game start, try adding this to the Warfare module init field: For an Alliance: if (isServer) then { niv = [] spawn { waituntil {!isNil "gameInitialized"}; waituntil {gameInitialized}; Sleep 5; [east,resistance,true] Call BIS_WF_SetAlliance; }; }; for a Cease Fire: if (isServer) then { niv = [] spawn { waituntil {!isNil "gameInitialized"}; waituntil {gameInitialized}; Sleep 5; [east,resistance,true] Call BIS_WF_SetCeaseFire; }; }; true will set sides friendly, false will set sides hostile. Main difference is that sides will share some intel as allies, but not under a cease fire. And if BIS_WF_UrbanWarfare was set true, players can respawn in towns belonging to allies. The BIS_WF_Common variable "alliedSides" is used to check whether the sharing occurs. It only gets set for an alliance, not a cease fire.

Double quotes ("") and semicolon (;) in the condition statement may be the culprit. Try: [_group_east_3, 1] setWaypointStatements["!alive triggerAttack", ""];

Mostly yes. There's no adding a client involved. All it's doing is having the client (player) create the vehicle so it's local to them rather than the server creating the vehicle and having it local to the server. The helo's created (added) as part of the editor unit's group. Then the original unit (local to the server) is removed, leaving only the helo (local to the client). Since waypoints are a group function, the helo retains the waypoints. Its similar, but not exactly, to something BIS did in the campaign missions. In many places, they placed a unit not involved with the campaign, which had waypoints laid out. And when a condition was satisfied in the campaign, their waypoints got copied over, leading to new paths in the mission without having to script them. I tried it, but copying didn't work because synchronization failed. But what did work was creating the heli as part of the group, then removing the original unit from the group.

Got the waypoints to work on dedicated server (A2/OA). The LOAD transport needs to be local to the client issuing the GET IN command. Both need to be local to the same machine. It's appears to be a factor of the "unitReady" command which is not documented in the wiki.

This seemed to work on a dedicated server. Notes: Instructions: in init.sqf :