Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

329 Excellent

About mrcurry

  • Rank
    Gunnery Sergeant

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @SirBassi I recommend you use the recently added "ProjectileCreated" mission event handler instead. As the name suggests it will trigger whenever a projectile is created no matter which vehicle fires it. Just make sure to filter out unwanted projectiles as quickly as possible, if you got many possible types to handle use a HashMap, for few items use arrays or plain equality checks. If you need the vehicle who fired the projectile use getShotParent. For a practical example here's the init of my artillery terrain deformation example: ARDM_mainEH = addMissionEventHandler [ "ProjectileCreated", { private _projectile = _this; private _type = typeOf _projectile; private _ammoCfg = configFile >> "CfgAmmo" >> _type; if(isClass _ammoCfg) then { if( _type in ARDM_ammoMap ) then { _projectile addEventHandler [ "Explode", { params ["_projectile", "_pos", "_velocity"]; private _blastParams = ARDM_ammoMap get typeOf _projectile; _pos = ASLtoATL _pos; if(ASLtoATL _pos select 2 < 0.5) then { [_pos, _blastParams] call ARDM_fnc_doBlast; }; } ]; }; }; } ];
  2. That deffo is an appropriate workaround. Having the game by default delete the trigger seems like it could cause issues. The trigger can still be useful for defining areas or presence-arrays. And what about MP? Should only the local trigger be deleted or should all machines be affected? Seems like a can of worms better left for the mission editor to open. Info about this behaviour should be in the docs though. Curious question, can a non-repeat trigger be made to trigger again by updating it with setTriggerActivation?
  3. Depends what you're after, do you want to handle players quitting or their game crashing? If the former @sarogahtyp got you covered. If the latter those are harder to reliably catch client-side. I recommend implementing an autosave, periodically query the player for their latest info and store that. As long as the query isn't too heavy you should be able to do it often enough the player shouldn't notice any major loss of play. Edit: Obviously if you want both you may implement both. 😛
  4. I don't see how, if used as a trigger condition the trigger will activate only on the client where the player has the key. If that's what you want it's actually perfect. If you're referring to that setVehicleLock is a local argument command that's easily fixed by replacing it with: [Car1, "UNLOCKED"] remoteExec ["setVehicleLock", Car1]; Edit - also note about the 'in' command: String comparison is case-sensitive, make sure to check that 'items' return is the same as the input spelling, cause in theory @PlatinumFIVE's first attempt should work. Why? It's not that all commands should "work" in MP. (What does that even mean?) There are a million situations where you need to only affect the state of the executing machine's game. Script commands can take either local or global arguments and they have either local or global effect depending on the job they are designed to do. Local argument means the command can operate only on data simulated on, or "local to", the executing machine. Local effect means, as you probably guessed, the effect of the command only happens on the executing machine. You can find indicators for this on the top each command's BIKI page as AL/AG and EL/EG. Scripting for MP isn't black magic. If you consider who knows what, who says what and to whom do they say it you're set to succeed.
  5. Hey guys, I decided to play around with the new fancy stuff from Arma 3 v2.10 to make a little basic script to make artillery deform terrain just to check out what v2.10 can do. It started as a test / learning example to see what's what but I decided to implement the multiplayer optimizations from the setTerrainHeight biki page so should be good enough to play online with if you are so inclined. Some basic features: Applies to all configured projectiles no matter if spawned, shot from a gun, or placed. (kudos to BIS for the new Eventhandlers) Any CfgAmmo entry that explodes should be configurable to work. Let me know if it doesn't! Works in MP Script only, no additional mods required. Since this is supposed to be an example here's the basics of how it works, I'll spoiler it for those of you who just wanna get blasting: A few caveats of course (wouldn't be ArmA without them): The limiting factor to quality really is the terrain mesh resolution as alluded to in the dev diary and the biki. On maps with a small terrain cell size like Prairie Fire's "The Bra" ( 2.5 m ) the look is always going to be better than on terrains like Altis ( 7.5 m ) or Malden 2035 ( 12.5! ) were things can look edgy (no pun intended) and, small enough craters might not even register. In addition to that the current ammo config is aimed at the Prairie Fire maps (which tend to have a slight better resolution in general) and is intended to not make too big an impact on the "walkability" of the map. For other maps I recommend playing around with the width and depth values in the config to get the best look for your mission. Bonus feature: If you wish to undo all changes you can use: call ARDM_fnc_resetTerrain; Time for some pictures. Prairie Fire - The Bra example: Before and after on Altis: There are 2 files that are meant to be configurable: ARDM\ARDM_ammo.ext - Contains all configured ammunition and their impact parameters. Tweak as you like. When adding more ammo to the mix consider what the final stage ammo is called. The MLRS for example fires a "R_230mm_HE" ammo but the submunition that creates the explosion is called "R_230mm_fly" which is why that is listed in the config, not _HE. ARDM\fnc\macros.sqf - Two possible defines to play with. - MAX_ADJUST - How much the combined effect of craters is allowed to deviate from the default height map. - UPDATE_GRID_SCALE - Controls the size of each update region. If network performance becomes a problem because of this script increase this value. Tested in MP to work as advertised but if you find any issues let me know. Links: Example missions: https://www.dropbox.com/sh/j1gybz79dqikdr4/AAD4dXEgM0Y1hkwgM5mYutzla?dl=0
  6. I think trying to solve for every possible kind of cutscene technique simply isn't feasible. I use the term "cutscene" loosely since most artificial transitions, be it a simple fade to black or a full on movie, can cause issues. I mean broadly speaking you are trying to hide your UI whenever it would collide with other things that's going on on-screen. That's a pretty big problem. You could just go with a "best effort" approach and check for a combination commonly used techniques and combine that with a flag that other content creators can use to easily hide your UI on demand. Edit: A thought occured to me, not sure about it but worth investigating. Does the game's group UI actually run on IDD 46? If not see if you can find out which IDD it runs on and add your controls to that display instead. A quick BIKI search found this list: https://community.bistudio.com/wiki/Arma_3:_IDD_List
  7. Everything has a performance impact. The question is if it's noticeable. There are differences between the two methods for sure but to quantify them you'd have to run tests. At the number of sectors you are likely to see in a single mission though? Let's just say your time is probably better spent elsewhere. 😉 First make it work, then make it fast.
  8. That's cool, Rome wasn't built in a day. If you got any questions just ask. Yeah, they really became part of my toolbox way back when I realized that triggers had their own variable space just like other objects. Don't get me wrong, a scripted loop-solution is just as valid a method for solving this problem. At face value using triggers seem like a good idea 'cause a repeatable trigger inherently has many of the properties that we want. Like you noticed it does come with scope issues that needs considering and once you start thinking in MP terms there's also locality issues to consider. As far as your original script there are some minor syntax changes needed but the logic is there and should do the essentially the same, though would only work as advertised in a SP environment. At beginning of the loop you check for (_AlreadySpawned = False), this is problematic because = is the assignment operator and returns Nothing which can't be checked by the preceeding && operator. To compare booleans use == or just enter (_AlreadySpawned) since the value is a boolean. When deleting the units you need to iterate over forEach units _GarrisonGroup instead of just foreach _GarrisonGroup.
  9. You mean like an onEnterArea/onExitArea eventhandler? That's one reason of why there are triggers ^^ Now we don't have to hand-place every trigger, we can just spawn them as needed. Assuming your preferred detection area is a circle defined by _SectorTrigger's position and _SpawnDistance this should do the trick. NOTES: I've checked syntax and only cursory logic based on what you had already written. It's mostly for learning purposes. Let me know if there are issues. You didn't specify if it was for SP or MP environment so I just assumed something that works for both.
  10. Well we can't read your mind, need to see some code. 😉 How do you initialize the UI? How do you define it? If config what do you inherit from?
  11. Seems like you are using a trigger so set the trigger to be repeatable and use the ondeact to execute the removal of the group
  12. Simplest way: Define a string variable to hold your message. Iterate over the array using some loop, forEach is particularly suitable in this case. Each iteration you turn the current element into a string and add it at the end of the string from step 1. Display the string in your preferred i.e. hint. A code example: // Example array someArray = [1,2,3,4,5]; // Define string variable, in this case prefilled with some text, could also be empty "". stringToDisplay = "Result: "; { // Turn the current element '_x' into a string using the 'str' command and then add it to the variable using simple string addition. stringToDisplay = stringToDisplay + str _x; } forEach someArray; // Display the string as desired hint stringToDisplay; //Output: Result: 12345 Now if you want start introducing hints with colors, alignment and other pretty stuff hint also supports the data-type structured text instead. It's a bit more involved so I'll just leave how I do it here in this spoiler if you want take a peek.
  13. It's pretty straightforward, something like this should do: Players are given a grace-period when connecting the first time to the given session after which they are locked into their current team. Once the player's team is locked in the players UID and assigned side is stored on server in a hashmap. When players connect a function (CSR_fnc_newPlayer in the below example) queries the hashmap if they have an existing assignment and executes an appropriate response. If the player has no assignment, countdown the grace-period and lock their current team as their assigned one as per above. If the player has an assignment and it differs from their selected team immediately end the mission locally using BIS_fnc_endMission executed ONLY on their client. If the player has an assignment and its the same as their selected team we only need to give them a welcome message. As long as the hashmap is initialized and stored only during the given mission session the next time mission restarts the team assignments will automatically reset. If you need to reset a player's team assignment mid-session (could be useful if you want to make admin tools) simply delete the player's entry from the hashmap using their id from getPlayerUID. Here's an example how you would do that using in the attached example mission: SIDE_RESTRICTIONS_MAP deleteAt getPlayerUID _playerObject; Example mission: https://www.dropbox.com/sh/9dnotrclal8j3vb/AADSabn5zKc2clNDeVux4c8Ua?dl=0 The length of the grace-period can be changed in initPlayerLocal.sqf (it's the last parameter in the remoteExec call to CSR_fnc_newPlayer and is measured in seconds).
  14. mrcurry

    Briefing Link

    Conceptually it's pretty simple: 1. Add your custom sound to your mission. 2. In your briefing text use the execute-tag to run command: playSound 'yourSoundNameHere'; As for the details: 1. Just search for instructions how to add custom sounds to your mission. There are plenty of threads and video tutorials on the subject. 2. The syntax for the execute-tag is available here: https://community.bistudio.com/wiki/createDiaryRecord (click on Show text to reveal the table of supported tags)
  15. Not to mention that splitting your codebase from init.sqf to initServer et. al. helps keep your code clean and readable = easily maintainable! ^^