Jump to content

opusfmspol

Member
  • Content Count

    508
  • Joined

  • Last visited

  • Medals

Everything posted by opusfmspol

  1. opusfmspol

    Construction Interface Script?

    Maybe a Zeus module could be used. I've tinkered with it enough to limit radius and height but didn't go any further than that. Whether it could be limited enough to correctly imitate A2 COIN, I can't say.
  2. opusfmspol

    You've played to much Arma when:

    . . . when you code using classnames without looking them up to verify, and no resulting errors. . . . when watching an Arma video, the person who did the recording opens their map, and you click the screen to try moving the map.
  3. opusfmspol

    Spawn (custom) compositions

    If not already, for debugging purposes, use -showScriptErrors in startup params and do not use -noLogs. - Using -showScriptErrors gives a black error box on screen when an error occurs. Let's you know when there is an error encountered which is quite helpful. - Not using -noLogs will catch errors in the .rpt log and lets you review the encountered error. But using -noLogs prevents the .rpt from logging errors. The problem is here . . . "Land_TentDome_F" is missing a string quote ( " ) at its end, and there is a comma ( , ) after last item of the array. One would think it should have errored on those. and here . . . createVehicle command needs a string classname to create. You made _objType an array. createVehicle can't do anything with it. One would think it should have given a "type array, expected string" error on that. An array could be used, but it really is simpler to create three objects in a row from string. A problem is that the sleep script shows "obj2" and "obj3" are variables already in use. You would need to decide what variables to use to reference the additional created objects, and how to position them when obj1 is setPos.
  4. opusfmspol

    scripting with modules

    Wouldn't it be better to have placed triggers run a single script that spawns the modules at the location? What's the purpose of using BIS_fnc_locations? Do those modules even use it? I do know using "CityCenter" with BIS_fnc_Locations is rather disappointing.
  5. opusfmspol

    BIS_fnc_spawnGroup; Question.

    Don't Call Compile "New Name", that will error. BIS_fnc_SpawnGroup returns the group created, not the unit, i.e: _group = [<< params >> ] call BIS_fnc_SpawnGroup; Use Units command to select the unit from the group, i.e.: _unit = (Units _group) select 0; If you want the unit available to other scripts, define it as a global variable rather than a local one, i.e.: NewUnit = (Units _group) select 0; If you want other machines to use the unit in scripts, broadcast it as a public variable, i.e.: PublicVariable "NewUnit"; Waypoints are a group function. Use the group, not the unit, i.e.: _wp1 = _group addWaypoint [getmarkerpos "owp2", 0]; Hope this helps.
  6. opusfmspol

    setMarkerAlpha for one side

    Not correct, you can adjust local alpha on editor markers. To my understanding, all markers are local and the difference between createMarker and createMarkerLocal, and their other associated commands, is that the markerLocal commands won't propagate across the network, whereas the other command does propagate to all machines. I just tested this to verify: If you have two machines - - Place a Blufor and Opfor unit on map, player and playable. Name one unit bob and the other bill. - Place two flag markers on map, "flag1" and "flag2". - Place a Radio Alpha trigger, with OnActivation: if (player == bob) then {"flag1" setMarkerAlphaLocal 0;}; - Launch in multiplayer and join on both machines, go to map and view the markers. Markers appear on both machines. - Call the radio trigger. Flag1 marker disappears on Bob's machine but not on Bill's machine. Check your trigger OnActivation and onDeactivation codes. You probably want something like: if (!isDedicated && hasInterface) then {if (side player == West && getMarkerType "bluMZ_1" != "") then {"bluMZ_1" setMarkerAlphaLocal 1;};}; and, if (!isDedicated && hasInterface) then {if (side player == West && getMarkerType "bluMZ_1" != "") then {"bluMZ_1" setMarkerAlphaLocal 0;};};
  7. Might check in directory Steam\Steamapps\common\ , and verify that the Arma 2 folder is named "Arma 2" (space included). The folder being renamed can cause that to happen. Also in Arma 2\addons folder should be a missions.pbo and missions_ew.pbo. Missions.pbo has the A2 campaign.
  8. Variable = params call BIS_fnc_spawnGroup; Variable is the returned group. Use the variable in triggers and for waypoints.
  9. Trigger Activation See Any Group Member
  10. Store the action ID. You want it stored so the action can be checked and properly removed. Add action: if (_vehicle getVariable ["actionVarName",-1] < 0) then { Private _actionID = _vehicle addAction ["Action Name", {_actionCode}]; _vehicle setVariable ["actionVarName",_actionID]; }; . . . . . . . . Remove action: Private _actionID = _vehicle getVariable ["actionVarName",-1]; if (_actionId >= 0) then { _vehicle removeAction _actionID; _vehicle setVariable ["actionVarName",-1]; }; . . . . . . . . Storing actionID should be included in addAction and removeAction pages, imo. These type questions pop up frequently.
  11. Don't know about "faceType" or "genericNames", but my understanding of "identityTypes" is that it holds tags used in randomization, so when units are placed they get random faces, glasses and voices, but within the confines of their given tags. cfgFaces has various faces tagged with identityTypes "Head_NATO"; cfgGlasses has various glasses tagged with identityTypes "G_NATO_default"; and cfgVoice has voices tagged with "LanguageENG_F". So if a placed unit inherits from B_Soldier_base_F and has no identityTypes array defined, it uses those inherited tags to randomly choose face, glasses and voice. When there are multiple tags of a kind, it broadens the randomization range. If a unit class has "identityTypes[]={};" it gets no randomization, it uses defined identity. That's my understanding. If I'm wrong, somebody please correct.
  12. opusfmspol

    Best way to have conversation

    If using the Conversations system, you don't have to use separate files but it helps with organizing. You can pack everything for different conversations into single files, i.e. one .bikb for topic, one .fsm for AI., one handler .sqf for players, etc. Then you only have to add one kbtopic to all speakers at mission start. But as the mission expands with more and more conversations, the files become larger and difficult to search through. So I would say, small missions with maybe a few conversations, you could pack all into single files, but with larger missions having various conversations, you will want to consider breaking the conversations out into files named for their topics.
  13. Since no response, One option is to go into the missions.pbo and review the SOM folders (SecOps Manager). It has a kb folder and fsms folder. Would also need to go into the languagemissions.pbo to find the stringtables used by SOM. Has everything but the gunship run stuff, the Gunship Run stuff is in missions_e.pbo and languagemissions_e.pbo. That's where I learned how the conversation system works, by doing customized SecOps and SecOps supports. While working on that, the posts by Jezuro, HateDread and EvilEcho helped much with understanding how the SOM kb system was set up and functioned. In the end I had dialogues of my own going on. But they're not set up any different than what SOM has, so I suggest looking there. Locality is important. kbTell needs to be done where the unit is local. kbWasSaid is also local, it fails when checking a remote unit, so sleep is used in that instance. SOM is run by server, which does HQ kbTells. It uses public variable event handler on variable "BIS_SOM_codeBurst" to have the players do their kbTells. The artillery support includes use of addaction kbTell calls. Hope it helps.
  14. opusfmspol

    Trigger activates when in vehicle

    You should just have to condition the "not" apart from the "In". if !(don1 In v1) then {<code>}; if (alive don1 && {!(don1 In v1)}) then {<code>}; // Edit - sorry, jumped the gun without reading entirely. If a team do the units as pointed out above, but still condition the two apart like Pierremgi has.
  15. Can anyone explain when the use of forceEnd command would be required? Does it have a use in A3 or has it become deprecated with BIS_fnc_endMission, BIS_fnc_endMissionServer and BIS_fnc_forceEnd (which oddly enough, doesn't use forceEnd command at all)? The wiki description is rather fuzzy, saying it "sets the flag which tells engine that the mission end was forced", but no explanation of how the flag impacts mission ending. Wiki shows it has local effect, but seems to do nothing in editor. Placed in an "END#x" or "LOSE" trigger, it's the trigger type that seems to force the ending, not the command. Remove the forceEnd command and mission still ends when condition is met. I'd like to understand its proper use, if it has one. Searching has not been enlightening this time around.
  16. opusfmspol

    synchronizeObjectsAdd

    The High Command module doesn't monitor for changes in synchronizations. Some modules do I suspect, but it's one that doesn't. You could reinitialize by running its "hc.sqf" script again, but then it creates a new instance of the "hc_local.sqf" running on each connected machine. Each would end up with multiple instances of the same script running. You'd want to terminate each one's old instance for the new instance, or better yet not have a new instance run if their old instance still works proper following HC reinit. The HC module initializes by an eventhandler rather than function. The eventhandler execVM's the HC script. What I've done in the past (A2) was copied the HC module scripts to mission folder, and changed the scripts in mission folder to suit the need. Then placed a regular Game Logic on map and have it run revised HC eventhandler code, running the mission scripts instead of the core scripts. Basically the game logic acts as a surrogate HC, to run the scripts from mission folder instead of core. In that way I could get HC's Radio Waypoints and F5 "assign missions" menu to work in Warfare. Just tested, and this method does still work with A3, syncing HC Subordinate modules to the Game Logic. If you should choose that route, look for where the BIS_fnc_MP call is made to execVM hc_local.sqf on each machine. - Not running a new instance on clients: You'd want to control the call, only having it occur on first initialization, not on subsequent ones. - Or, running a new instance on clients: You'd have to work out a way to terminate the old instance on clients. Somehow find a way to capture and store each script handle, and issue them a terminate command when the new instance is going to run. But running a game logic as surrogate with mission scripts, you'll have much freedom to make the different HC scripts work as you intend.
  17. Yes, but since isPlayer could occasionally give a bad false return, (_x In allPlayers) might be better.
  18. "BIS_fnc_Init" is still true in A3 after functions compile, so yeah should work, but classnames would have to be changed to whatever the A3 proxies are.
  19. Agreed. The OFP and Arma labels were apparently intended to help clarify, but in fact make it have to be somewhat deciphered: ModeClass: class Mode. Must be declared (or inherited) for each class. MuzzleClass: class Muzzle. Must be declared (or inherited) for each class. OFPModeClass: class Mode. Must be declared (or inherited) for each class. Generally moved to Arma's cfgMagazines Class and often renamed, else simply renamed. ArmaModeClass: class Mode. Must be declared (or inherited) for each class. Introduced from OFP:E and beyond.
  20. Yes. And 0 is returned if setVariable hasn't been done.
  21. thisTrigger is refence to the trigger itself in triggerStatements. No need to give the trigger a name unless needed for reference elsewhere. If you want the set variable unique to one trigger, give one trigger a name and there use thisTrigger setVariable [ ] and thisTrigger getVariable [ ]. In all the other triggers put <trigger name> getVariable [ ], using reference to that one trigger's name. Or, if you need the set variable unique to each trigger individually, no need to name the triggers. in each trigger use thisTrigger setVariable [ ] and thisTrigger getVariable [ ].
  22. Have encountered the same before. The colon : causes the issue (insert puns here). Using setVehicleVarName resolved it for me. With colon : , preprocessor mad, but with vehicleVarName, preprocessor happy.
  23. opusfmspol

    Locality issues

    6thSense.eu - Locality Helped me much with understanding locality, but it was just a start. There's so much more, and I can't hit it all, others might chime in to help. But here's my experience. When scripting for MP you must always, with every script, keep in mind which machines will be running that particular script. Server? Client? Both? or maybe even a Headless Client? You have to keep your head wrapped around that. Argument local: When reviewing script commands and you find the argument is an object, and the command is "Argument Local" (e.g. setFuel), it means is that the object (in this case a vehicle) has to be local to the machine issuing the command, whether server or client. With AI, they might be local to the server or not. AI are usually local to the server, right?... one might think. But with a driver who is AI subordinate to a player leader, the vehicle is local to the player leader machine. This is where one would use local command: "if (local vehicle1) then {vehicle1 setFuel fuelAmount};" Effect Local: The local command is "argument global", and what that means is the object must exist on all machines. There is a command createVehicleLocal which has only local effect, i.e the vehicle would exist only on the machine that runs the command. Hint and addAction are also local effect. It means the hint only occurs on, or the action only exists on, the machine running the command. If you want it to occur on all player machines, the command has to be run on those machines. That would mean the script is spawned, called or execVM'd by the target machines, or Public Variable Event Handler is used, or remoteExec (allows suspension) or remoteExecCall (does not allow suspension) are used to target them. Headless and Dedicated: But AI can also belong to a headless client, which is a player and yet not a player. It's a machine run to offload AI functions, so the server can run faster doing basic processes while the headless handles its AI functions. In essence it's like having another proxy server, yet the headless client AI leader is registered as a player and it's AI subordinates are local to the headless client machine. Headless client has no user interface (UI), neither does a dedicated server. So to exclude those two and only target real player client machines, one can use "if (hasInterface) then { . . . };" Dedicated server has no player. Player is objNull on a dedicated server. This is why when scripting for MP you should avoid using player command in any server or common scripts. Using it in client or headless scripts is fine. But if a dedicated server runs a server or common script which issues a player command expecting a return, it could error and maybe even terminate the script. Effect Global and Editor Triggers/Waypoints: When you see a command that has "effect global" (e.g. createVehicle), it means you will usually only want that command to run on only one machine. Because the result will propagate over to all machines. This is important to keep in mind with Editor triggers and waypoints. They will exist on all machines that load the mission. Many times people post "Why am I getting (_x number of vehicles) created when a (trigger/waypoint) goes off?" First response: "Is it an editor (trigger/waypoint)?" - - "yes." (been there, done that). Usual fix is to localize the condition so only the server runs the global effect command, or a specific client machine if that's what is better for the mission. Instead of just "this", condition would be "this && isServer", or "this && local TeamLeader1". In MP you'll have problems with synced LOAD and GETIN waypoints when the vehicle and troops are not local to the same machines. I suspect (not confirmed) it might be that the two waypoints use the unitReady command on each other. My tests with unitReady command have shown that the command is "local argument". It only returns a correct true/false on the machine where the unit is local. On any other machine, where the unit is not local, it always returns "true". And that causes unexpected results when a mission event, like deployment or extraction, relies on it. Finally, with waypoints, I had an MP problem and ran a test one time, which found that only the machine where the group leader was local did the condition check, but the waypoint expression was run on all machines when the condition returned true. It had the standard placement condition. However I can't say whether that was a local mission issue or not, I don't believe it was. I've kept that in mind ever since. I would invite others to test whether it's true or not. So this final observation, take with a grain of salt. --- Edit: Reviewed that particular mission again, and recalled the waypoint had not used standard placement condition as first thought. Extraneous code was run in a waypoint condition field ahead of the returned waypoint condition "true". But the extraneous code only occurred on one machine, where it was expected to occur on all. To find out why not, diag_log's were added. The WP condition diag_log only logged on the machine where the leader was local. The WP expression diag_log was logged on all. That's when I figured that waypoint conditions are only checked on the machine where the group leader is local.
  24. opusfmspol

    Local Variable in Global Space

    Thanks very much Larrow, I've been unaware of that. Got some uses for it too, now that I know.
×