Search the Community

Yes, very easily. In your function you can just use spawned code and using _this you can transfer all arguments from the original call to the spawned code myFunction = { //bunch of code _this spawn { //new code that needs scheduled enviornment } } I don't know the specifics, but an alternative thing you can do is simply spawn the code rather than call myArgs spawn myFunction; In SQF the "code" type you can think of it as just a container for the code, and using spawn or call determines the scheduling behavior of the executed code

It looks like a Hold Action, though I'm not sure how they were able to use a custom key, perhaps it is a custom hold action? The code can be viewed from the function viewer

Yes this is mostly accurate, though it is not a result of long mission time, but rather a side effect. Long missions are likely to accumulate an ever-increasing number of scripts for one reason or another and due to the way the scheduler works this causes the effect above. Specifically, all spawned code is only given a 3ms window to run each frame, any further processing is halted until the next frame. On the next frame, whichever script has not executed in the longest time is resumed, thus the creation of the aforementioned infinite upper bound. See scheduler for (probably) a better explanation In this case I traded some code size for performance reasons. I wanted there to be as little processing as I could manage, and have it not affect the accuracy of the timer. Unfortunately, I did not fully grasp how the scheduler worked back then so the timer is probably even less accurate than I thought it was due to the behavior described by @ZaellixA above. Notice that the scheduler page did not exist when I made this post. Anyway, here is the reasoning for some of the choices I made: spawn and waituntil - I wanted to make sure that processing time would not affect the accuracy of the timer so eventually I came up with this. Notice that the effect is the calculation and formatting is done before the next cycle, so once the next cycle starts the only processing that needs done is display/saving variable. Otherwise the script would wait for 1 second, then do processing/formatting, then display. It's not much, but it would make the timer permanently inaccurate by a few milliseconds while those calculations are being performed custom formatting - An effort to keep the processing as lightweight as possible. It may seem inefficient at first but it is just 1 comparison then adding 1 character. I would expect this to be many times faster than the BIS function. Essentially I am taking just the functionality that I needed and throwing away everything else, I hoped the result is that less code runs overall and so would be faster

I did some digging in the config and I found that the pause menu is display ID 49 and it's name in the config is "RscDisplayInterrupt". The following works in debug console: ((findDisplay 49) displayCtrl 2) ctrlEnable false; //Disable "CONTINUE" button But when I tried putting more code around it to make it automatic, it stopped working. It seems SQF gets paused as well when the Interrupt menu opens

Like I said I don't actually know if these really are the centers that I mentioned, so I'd recommend some general testing to find out stuff about them, but if they were then your trigger code could possibly be as simple as: { private _current = _x; thisList apply {_current forgetTarget _x}; } forEach thisList; What's nice about this is it leaves the centers alone (maybe not even an issue), and since they are hidden afterward they shouldn't be able to re-spot so if done at the right time you could probably get away with just running this once

In Arma we have the concept of locality. It's easier to understand using real objects like soldiers, but additionally anything shown to a user is only shown locally (on that computer). So your call to BIS_fnc_showNotification will only show to a player, on that computer, when that line of code is run. Since you are not running the game through that computer, nothing is shown to you, and if you were able to somehow connect as the dedicated server it additionally has no interface, so nothing would be shown anyway. Luckily we have a command called remoteExec which allows us to specify that we want some code to execute on remote machines (other people's computers). Ok, all of that just to say use this instead: ["notiNewMechRec"] remoteExec ["BIS_fnc_showNotification", 0]; If you are planning to do a lot of multiplayer scripting you will need to be very familiar with all of this, but you'll get better at it as you use it more

I'm more than a year late seeing this so maybe you've already found the answer, but this is caused by race conditions created in user-scripts. The short answer is that display 46 just doesn't exist at the time that code runs, so no EH can be added. That can be easily checked with: //in any "initX" script at the very beginning with uiNamespace do { myVar = findDisplay 46; }; uiNamespace getVariable "myVar" //put in console as a Watch variable; returns displayNull which is shown as "No display" I can't give you the long answer as I am only knowledgeable enough with the initialization order to make my stuff work 😛 You may have realized this by now, but the actual important thing here and why it works is suspending the script with waitUntil allows time for the display to get created. You may already know that some commands just don't seem to work in init.sqf until it has been suspended in some way. Sleep will work just the same to create this effect. This is the exact reason why you'll see "sleep 0.001;" at the very beginning of so many of my init.sqf's

On BIS_fnc_holdActionAdd wiki page there is a thing that says "UI that shows all icons", if you put that code in a normal addAction and run it I believe I remember seeing the "progress" rings there. There's 24 if I remember correctly

Just wanted to drop in again to say instead of checking if the unit is alive every time, just check until it dies then remove the event handler if (alive _target) { //do EH code } else { _target removeEventHandler [_thisEvent, _thisEventHandler]; }; A side note, it definitely sounds like this is for MP so make sure you remoteExec since event handlers have local effects

I would imagine that the actual firing of the event handler runs unscheduled, in other words my thinking is that all events are run until done (blocking everything else including frame rendering). So if that is the case then all events should happen in 1 frame and you will be more or less completely safe from automatic fire mixing up the code. Something that could happen however is player throws a grenade, then shoots somebody at the exact time the grenade explodes, but in that case I think there would be a different _projectile etc either way it should be easy to fix that if it causes a problem

I believe I have made all the changes necessary for this to be working in multiplayer. You will always be able to "get latest" on Github. Here are the changes I've made: Made use of the Functions Library to hold the system's code Replaced most, if not all command calls with remoteExec'd version while keeping in mind locality during runtime Split up the Event Script init.sqf into initPlayerLocal.sqf and initServer.sqf (not strictly required, it just helped me debug) Tested in all game environments (single-player, local multiplayer, dedicated server multiplayer) I want this to work in all environments (single-player, locally hosted multiplayer, and dedicated server multiplayer) so please let me know if there is any part of the system that is not working. Remember your locality, because it gets exponentially more difficult when you're in a multiplayer environment. Keep in mind that I am only going to fix stuff related to this revive system (I am not going to debug your mission). I cannot be solely responsible to fix problems in user-edits for the same reason; of course you can still ask me, but I'm not going to give it the same level of effort as an issue in the base code I set the player revive action to 2 seconds during testing and I forgot to change it back, so in fn_addPlayerHoldRevive.sqf make sure you set the 2 back to it's default of 14, or whatever number you'd like to use. I will probably fix this in subsequent commits I will update the original post with a clear message at the beginning that the latest version can be found on Github Enjoy!

Yes you think it works in theory, now let's see what happens when we put a bunch of humans into the equation... It's better to solve the human problem with code if possible

Just be aware with this method that if the group should still use the vehicle at all, you will need to addVehicle to the group again. For a player-led group this is most likely pointless, but for AI-led groups, which I assume you are supporting with this, it is the difference between them never using "their" vehicle again or not Also, was thinking about this. If this is a revive system then you probably have a HandleDamage EH somewhere, in that EH code is probably the best place for this, rather than a GetOutMan EH on a per-unit basis, supposedly leaveVehicle can have a group as input but I have had issues recently on another project with some of these commands working as described on the wiki, unfortunately I did not document this, but with apply this is still a one-liner: (units _unit) apply { _x leaveVehicle (vehicle _x) }

In your "Turn on" addAction you have the condition "!alive _target", but in the turn off action code you setDamage 0. You should setDamage 1 and then I think the light should be "dead" and the action will show

The problem is _pos isn't accessible in the control event handler scope. If you replace it with [0,0,0] it will work as you think it does. So, you can save _pos into a variable that is independent of scope, like a namespace variable, then recall it in the control Event Handler to get it working. But there are more problems than just that. The way you've set this up, you will be adding a new event handler every time you click on the map, which you don't want to do, so adding the control event handler needs to be taken out of the OnClick event. Another problem is you are using onMapSingleClick, which is the old way of doing this and could be overwritten, when you should be using the mission event handler for this. Lastly, you are passing your code as strings, this isn't a huge problem, it just makes everything generally harder and offers no benefits (that I know of) So here is what I would use, with the above problems fixed: addMissionEventHandler ["MapSingleClick", { player setVariable ["ClickedMapPos", _this # 1]; }]; ((findDisplay 12) displayCtrl 51) ctrlAddEventHandler ["Draw",{ _pos = player getVariable "ClickedMapPos"; if (!isNil "_pos") then { (_this select 0) drawLine [getpos player, _pos, [1,1,1,1]]; }; }];

This was a weird one, took me a long time to figure out what was going on. First I tried retyping everything, which worked. Then I tried focusing on "_x allowDamage false" because that's where the error is happening. I went letter by letter and replaced every one, still getting the error. Then I noticed that if you are navigating the text via arrow keys, once you get to "e" in allowDamage, then you have to hit the arrow 3 times before the cursor advances to the space. Interesting...by default I "show all symbols" in notepad++ but I don't see any control characters...Finally the answer came to me. I changed the encoding to ANSI: { if !( isPlayer _x ) then { _x allowDamage false; }; } forEach units group this; So the short answer is retyping everything would have worked, or just retyping the contents of the Then code block, even more specifically just highlighting the "e[space]" in allowDamage false and retyping "e[space]" There is a long answer, but we really don't want to go into it, trust me. So the even shorter answer: Encoding is a bitch

I'm not able to reproduce what you describe with: _var = configFile >> "CfgVehicles" >> "B_AssaultPack_blk"; I tried this both in debug console and init.sqf. No backpacks spawned Makes me think you're using some custom scripts. Of course, the bug could be there, not necessarily in code you wrote. Can you tell me where _currentVehicleClass comes from? I bet if you trace this backward you will eventually find somewhere that an object is created near a player. I don't understand how you traced the issue to that specific line, it doesn't contain any creation commands, and doesn't have player anywhere. So even if something did get created, how would it spawn near a player?

Dropping in to say that instead of working, (wfh, am I right?), I've just pushed a fix to the github repo for #1 & #2 from dreadpirate's post, which were really the same problem. It's quick n dirty, but it works Also added something I realized was missing: Self-revive + SAMPLE addAction showing how to use the new code block Going to start working on making this MP compatible pretty soon, unless I think up any more features this urgently(in my opinion) needs Keep those bug reports coming, if there are any more

It would be much preferred to not have to download anything to look at people's code, there are many ways to do this. First of all just including it with your post with the code tag, don't forget to use a spoiler tag if the code is long. There are various code-sharing sites as well. Then of course there is Github, probably the best option

Not necessarily; While I built and tested this in singleplayer, I would want this to work in an MP environment, although I'll be the first to admit that I've never really practiced MP-safe scripting. That said, this will likely not work in MP at the moment, without some edits to the way certain commands are called. But that's not to say there are not advantages to this over the vanilla system because there are a few: Apparently vanilla system only works for players? This gives you the ability to have NPC units revivable and gives them the ability to perform the reviving on others or the player Of course, this all works in singleplayer already, without needing any changes, although there is at least 1 bug in there somewhere to fix. I think the vanilla system only works in MP This is a completely open system, all code is available to see and edit, perform enhancements and add new features, or just give my code a harsh critique Infinite flexibility as a consequence of the above item; while the vanilla system gives you some options right out of the box and this does not, you have infinite freedom in how the system will operate. If you can dream it, and code it, then you can do it

I have made several changes from the original post. You will always be able to get the latest updates from Github. The post below will still serve as a learning tool, but if you intend on using this system in your missions, you should get the updated version Hello! I am back again with something pretty fun today. First, the setup. I have been playing a lot of Arma lately and, naturally, with how involved I was in scripting and this forum years ago I eventually found my way back here. So I've been playing various scenarios that the community has made and, while generally really good, something that always bothers me is the lack of a revive system, or a bad one. So let's make one; and give it away to the community as a nice base to work with. The goal here is simple; provide an easy, low-code, feature-rich system that can be customized and/or expanded upon. Simply put, if the code wasn't required, it's not here(with some tolerance to fun stuff that I actually did add anyway). For those of you that like to "try before you buy" so to speak, I have recorded and uploaded a video to show you what you're about to be getting into: Stop. Here is your only warning: This ain't your grandaddy's forum post. It's definitely the longest I've ever posted here, possibly the longest forum post I've ever made, on top of that, I'd even expect some of the highly-knowledgeable among us to sit with this for some time and digest it. So go refill your drink, take those last bites of dinner, and buckle in Initially I was going to just do a code snippet, like I used to do way back when, with BIS_fnc_holdActionAdd, a command that I had not known about before and might not have known about were it not for my bad habit of trying to answer every question on this forum. It has a really nice effect in my opinion, and is featured heavily in the "Old Man" scenario. Anyway, I should begin To start, we have 2 options for the actual reviving part of the revive system, which I call a "holding" type or a "click-and-wait" type. I am a much bigger fan of the "holding" revive, so I will quickly go over the "click-and-wait" type so we can move on. This might be obvious, but this type uses a basic addAction for functionality: To use this, just pass the unit via call or spawn. For example, let's give all players in a particular mission the ability to revive each other: { _x call addPlayerClickRevive } forEach allPlayers; Don't worry about unitSetReviveState, because I'm going to go over that in just a bit. But look, our "click-and-wait" revive system is done! Letsmoveonplease Next up, the pièce de résistance, the "holding" type revive. I like this one much more because of the effect. Either way, we're starting the same, create a function that will just add a revive action to units: And look, there's that unitSetReviveState again. I guess I should post that before anyone gets their pitchforks out. It is just a wrapper for a few commands that give the effect of a unit being dead because I got tired of typing the same commands over and over: Now, those eagle-eyed among you probably noticed that none of this works unless the unit is in a particular lifeState. But how do you get into the "incapacitated" life state? Whenever I shoot something it just dies?? Well, ironically because this post gained some popularity recently, we are going to use the exact same thing, the "HandleDamage" event handler. By the way, I started working on this just days before that post got necro'd 😉. I'll let you read the documentation and the previously mentioned post on your own time, so for now just trust me that this does work: "Now wait just a minute, Dread, I don't have any friends to play Arma with and it's just me and my AI squad all the time" Well don't you worry because that is up next. This is a full-featured revive system after all. Here is a function that will order a supplied unit to revive a supplied body; the unit will run over to the dying unit, perform the same animations the player does, and the unit will rise again to continue being cannon fodder to Opfor (looking at you, player). The second code block is simply a wrapper for "addAction" syntax so I didn't need to mangle the first function due to weird arguments from addAction: So there you have it, I have now given you all the pieces you need for a revive system. How you script them together is up to you...Alright, look, since I am a really nice guy, I'll also give you some sample stuff that will just work right out of the box. This bit of code will add revive icons to all dying units, and even switch it to a healing icon when someone is reviving: Look I know I said: But I also said: And this is one of those things Next up, this piece of code will add a revive action for each nearby (50 meters by default) dying guy to all AI squadmates. If the unit goes further than 50 meters away, the action is also cleaned up (removed). This is a safeguard, because one of the biggest annoyances I've found so far with existing revive systems is that while it is possible to order AI squadmates to use actions (6 in the command menu), like reviving, it is actually kind of finnicky to get the option to show up, you basically have to order the unit to stand right next to/on top of whatever to use the action and by the time you get it working you might as well have just done it yourself. Bonus tip, there is a sleep 0.01 that is strictly there to allow the thread to suspend so any other scripts you have can run, because I'm a really nice guy, remember? So yeah here it is: Normally I hate nesting so many scopes, but in this case I'll allow it because it's so dang useful Lastly, here's some example stuff (in order). How to "kill" a unit without actually killing a unit (shoutout to the discord #scripting for giving me a simple solution). Make AI go from unit to unit reviving everybody (from the video)(hardcoded...figure it out yourself). How to actually add the revive system to a unit (literally just call addRevive and pass in the unit). And the coup de grace, a loop that will automatically order the squadmate to revive the player should he "die"(also hardcoded) : Well now, if you've made it this far then you must be really interested, here's the whole script (+ GitHub mirror) : Enjoy! I truly can't wait to see what you make with this, please send me a link or pm

This shouldn't be repeating at all, you only put that code in the group leader init correct?

it's a good idea to put extremely long code inside a

I keep erasing what I typed because I'm not happy with how it's starting out. Maybe if I just list the pros/cons of either you'll get it: call (Unscheduled environment) Blocks the thread until the code completes Can return values easily Can easily destroy FPS However, they can't slow each other down like too many spawns can Cannot use sleep/waitUntil spawn (scheduled environment) Does not block the thread (code keeps going and spawned code essentially splits off and executes) Can't return values/need workarounds to return values All spawned code gets 3ms to run per frame, can't affect FPS However if there are too many spawns with too much processing, logically it will take all of them longer to run because they have to wait for their turn Can use commands like sleep, waitUntil Can convert an unscheduled environment to a scheduled environment To reiterate the point directly above, scheduled environments "pass along" their scheduled-ness to lower scopes. Essentially, you can turn any environment into a scheduled environment However, a scheduled environment can never "turn into" an unscheduled environment (in the same way): //inside init.sqf (a scheduled enviornment) example = { sleep 1; hint "this is not an unscheduled enviornment"; }; call example;

I can't tell what you're asking with this language. You could be asking: Is it possible for them to do the above? - Yes, probably, if server A people know what they are doing Are they allowed to do the above? Yes, or no. It depends I do not know what bohemia's TOS is regarding scripting. They could have a clause somewhere that basically says "all code written with scripting belongs to bohemia". I doubt it, but if so, then it would only depend on their decision to take legal action If not, then developer A owns the work. However, if developer A has been paid for the code, ie received some kind of benefit in, exchange for it's ownership; then developer A obviously does not own the code anymore and the server would be allowed to do anything they wanted with it, even just delete it, and developer A would very likely have an extremely difficult time winning a legal case in any country