Jump to content

mrcurry

Member
  • Content Count

    595
  • Joined

  • Last visited

  • Medals

Community Reputation

460 Excellent

About mrcurry

  • Rank
    Gunnery Sergeant

Recent Profile Visitors

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

  1. It's been awhile since I worked with displays so maybe double check in your testing but as far as I can remember: Yes, closing the display = destroying it. All event handlers are destroyed also. Using Set is not recommended, it's a leftover from the old days of UI scripting. See the Biki page for more info. It definitely has nothing to do with the lifetime of the event handlers though.
  2. Yes. In On Act. the 'magic'-variable thisList contains the units which activated the trigger.
  3. You're not that far off. 🙂 Firstly you have a misplaced semicolon inside the parentheses. The grammar is: Semicolon ends the statement and all round brackets (i.e. parentheses) needs to be "closed" before the end of the statement. Just don't mistake round brackets () with curly brackets {}. Secondly uniformMagazines et. al. return an array of strings so your _x select 2 just gets the 3rd (yes 3rd, 0 is the 1st) character in what happens to be the mag's name. No Bueno! To fix this without string-magic you can just use: magazinesAmmo player This command gets the data in the format you expect with the added bonus of getting uniform, vest and backpack in one go while ignoring loaded mags. If you needed more nudges just ask. Edit: Dammit @Harzach! 😛
  4. 'player' script command returns the player object on the machine where it is executed. This quirk means if we're both connected to the same dedicated server the following would be true: - On my PC: name player == "mrcurry" - On your PC: name player == "trollzor45" - On the server: name player == "Error: No unit" (or "", I don't remember exactly ) Depends on the activation and condition of the trigger. Triggers are evaluated on every machine individually and the trigger's state (activated/not activated) is not synchronized. If you want something to happen at the same time for all machines you have to make sure the conditions in which they activate will occur at the same time across all machines. This will result in a synchronized activation: Trigger activation: Any player Condition: this This also (assuming a player-unit is named 'someDude' in editor): Trigger activation: Any player Condition: someDude in thisList This will not (see aforementioned quirk regarding 'player' above): Trigger activation: Any player Condition: player in thisList Hope that clears things up a bit, if not just ask away.
  5. Huh, wasn't aware of this caveat of the guard waypoint. Pretty neat and simple to setup. However I did some testing and it does seem a bit hit & miss. They'll take a full 2 minutes to react to an explosion 500 m away when there's only the explosion and no known enemy targets. While it's probably realistic, as a player sitting and waiting for them to move, that's tad long since there are no visual or audible cues from their decision making... They also won't move to where the explosion happens but rather stop nearby, and there's seem to be no search when they do arrive like with a S&D waypoint. Since I was already writing up something that acts closer to how I imagined it I'll just post that below. ----------------------------------------------------- It'd be nice if we had a mission event handler for explosions for this but as of today no such luck. So we have to jump through some hoops. Note that from the game's perspective those are 2 very different actions to monitor. That means you have to attack this from two directions. Handle vehicles exploding Handle player detonating an explosive Handle vehicles exploding Add event handlers to all vehicles (including spawned vehicles) Create initServer.sqf in your mission root and fill it with: Handle player detonating an explosive Add event handlers for when a player placed explosive explodes. Create initPlayerLocal.sqf in your mission root and fill it with:
  6. The simplest way, assuming a pre-placed unit with the variable name "someDude" and a pre-placed helo with variable name "daChoppa" Sync your trigger to the task set state module and in condition of the trigger put "someDude in crew daChoppa;"
  7. mrcurry

    lock it AddAction

    Apologies for the late response but after a bout of covid and a work trip I finally got around to wrapping this module up. My idea was to have a system that manages the loadout actions themselves via the server. You as the mission maker then decide what each of those loadouts do by just configuring the system and providing the script files for each loadout. The system expects loadouts as .sqf script files, this means you can define them as something static like an export from the virtual arsenal or a more dynamic thing like giving the player a random hat or switching gear based on mission progress, it's all up to you. Link to archive containing source, an example mission and installation instructions here. Below is some pictures on what it can look like in game. Icons, formatting and colors is fully configurable as well as some other general settings like apply on respawn etc. Tested on a hosted and dedicated server so should work but I haven't tested fully with a lot of players, let me know if there's any issues.
  8. Well in the code you shown you're only checking all the conditions once, 30 s after script start, if you want it to check multiple times you have to loop the check with a while, for or multiple waitUntil's. Also, 250 units at one time, maybe my perspective is skewed but "that's a whole 'nother company"... Are your (server's) frames ok?
  9. Not sure what you mean. You should just need to change the parameter-list (inside the [ ]) by changing/adding the extra parameters in your trigger's On Act code. Ofc you need to know what to change it to, for that you can check this link for reference. If you need more help show your existing code/setup.
  10. mrcurry

    lock it AddAction

    Well you just reverse the addition so... Subtraction 🙂 But then you need to know which role they have taken. For that you can use setVariable on the player object and assign them a string i.e. "AT" (it can be anything as long as its unique but descriptive is probably better). You do this when they pick any role. Then just before that just retrieve their assigned role (their string) using getVariable and check which variable needs to be subtracted. Remember to account for the first time they pick a role. Personally I'd use a hashmap to build a store of active numbers and a store of loudouts using the players role as key. It's a more advanced technique with some locality traps but it'd be easier to manage if you wish to reuse the system or add more roles in the future. If you wish I could build something for you ( it'd be a fun puzzle to solve 😛) but I fully understand if you don't.
  11. They are spawning at the exact same position. Here's the full parameters for BIS_fnc_spawnGroup: [position, side, toSpawn, relPositions, ranks, skillRange, ammoRange, randomControls, azimuth, precisePos, maxVehicles] call BIS_fnc_spawnGroup Try setting the precisePos to false, check the wiki for what the other parameters expect.
  12. mrcurry

    lock it AddAction

    I'd just use a counter for number of active troopers and a constant for max allowed. A naive solution looks a bit like this peudocode: // On server TAG_activeTroopsAT = 0 TAG_const_maxAT = 2 // In the action addAction [ ... { If TAG_activeTroopsAT < TAG_const_maxAT then { missionNamespace setVariable [ "TAG_activeTroopsAT", TAG_activeTroopsAT + 1, true]; // update the value and transmit the new value [] execVM "AutoRifleman.sqf"; } Else { Hint "not available"; } } ] An idea for a more reliable method would involve remote exec to server and letting the server do the comparison and return result to the client but I ain't typing that on my phone 😛
  13. Perfectly valid for testing for release since its also the metric most players are likely to use. For small snippets of code you can use the performance test button in the debug console. For larger, more complex code you can also take the diag_tickTime before and after the relevant code to get total time spent. Just keep in mind pauses (e.g. sleep, waitUntil) or "call and continue" commands (e.g. spawn, exec, execVM) when you make your measurements.
  14. Never "feel" performance, if you think you have a performance-issue check the numbers. When you measure the impact of your suspected thief you must do so in a controlled environment where the only difference is your suspect. Is the difference noticeable? If the answer is No then don't fix that which ain't broke 😉 If Yes, what does those numbers tell you? Is it worth the change? As for your code it does have a few issues which likely are causing you syntax errors or messages being logged in the .rpt-files (which btw can degrade performance if it happens a lot in a short timespan) reinfGRP and _reinfGRP are not the same variable. If you need them to point to the same group then you need to execute: private _reinfGRP = reinfGRP after creating the group. Event handler code is not executed in the same scope as where the event handler is added. This means the _u1-14 variables are undefined inside the event handler, this is likely printing some errors in your logs as well. This also means your "commandGetOut" calls will never do anything. If you are already getting the correct behavior you can just remove the event handler all together. Generally Events/Event handlers are considered more performant than script and for 2 main reasons: The engine handles the triggering of the Event when it happens in the simulation, no need to check the conditions continuously. Handler-code only runs once a particular Event happens (e.g. "Object #1234 was killed"), in the meantime they are just stored in memory ready to be accessed. In essence Event handlers are just "listeners" for events, they do not check the conditions for those events themselves. Since the engine is already spending a lot (in CPU terms) of time handling things like "people dying from bullets" and all the other stuff, it doesn't take a lot of extra work for it to also shout "Hey this guy is dead". At that point the "listeners" wake up and do their thing (bury the body, boobytrap the body or do unspeakable things to the body). In actuality an event handler doesn't "listen" but rather it gets registered to a list (usually). When the Event happens in the simulation the game gets the list of all registered Handlers and calls them one by one (in a predetermined order). If you want to know more (though not directly related to the game) you can check out the Observer-pattern wikipedia page. Be aware though that Event handlers aren't a magical "fix-performance"-button. You need to understand what they do so you can use them in situations where they excel.
×