Dedmen

RPT Line 560-563. The problem is your client not responding to the signature check request of the Server. " Skipping mods and signatures due to overflow flag being set. " sounds to be exactly that. It's skipping them because of an overflow flag.. Now what is that overflow flag. My suggestion. Move all your "My Documents\Arma"" folders to your desktop or some other place so you have a backup. And let Arma recreate the files. Looks like a networking problem and I'm suspecting your basic.cfg, which is one of the few things not getting deleted when you reinstall Arma. That malformed data stuff is part of the SteamMatchmaking. Is your Steam alright?

No. But blocking everyone playing that gametype whether they are trolls or not.

Most Milsim-like Operations are using Mods anyway. And you can't join the Server if you don't have the right Mods. That already keeps most of the trolls out. And most organized Coop Operations are organized well enough that they could just set a Server password. Outright blacklisting a certain group of People is comparable with racism IMO. And we don't need that in Arma. If you really wanted to you could make a script that checks how much RPG some client has played and let the script kick him. No need for a Engine implementation. Every Milsim Operation I ever participated in (And I don't play anything else) required Mods so you couldn't join without. Communication was done over Teamspeak so you had to be on TS. And because everyone is on TS anyway it's no big deal to have a server password. Just write it into the Teamspeak channel description.

You don't need to include other Peoples Mods in your Workshop Item as a Modpack. Modpacks are Collections on Steam. You subscribe to a collection which subscribes to a bunch of Items. So no need to ask anyone about any Permission. You just put their Item into your collection. http://steamcommunity.com/sharedfiles/filedetails/?id=844418062&searchtext=australia The Feedback from the Author in the comment tells us exactly what most People think.

How do you know it was BI? Maybe it was the Original Author who took the illegal upload down. For my word on this topic: I'm the maintainer of TFAR right now. If you take a look on Steam workshop and search for "Task Force Radio" You get dozens of Uploads called "Task Force Arrowhead Radio" and you have to look closely to find out which one is legit. I'm actually completly fine with people reuploading it because they want to have a specific version in their Modpack. My Problem is just that they don't make it clear that it's not an official version. They could even ask me If I could provide seperate Items for older versions so they can use it. I would do it right away.

No fix for this. If you play in SP with TFAR 1.0 your Radio won't be replaced anymore. But besides that yeah it will break such missions.

Yes. You can debug any script in any environment where the Debugger works. which is 32/64 bit windows.

The Debugger works in multiplayer just like everywhere else. Just not with Battleye. But you will get a timeout if you break too long ^^

Currently you can only have one Instance per machine. Future holds Remote Debugging over TCP and multi-instance local stuff. I hope we won't get BE whitelisted. Future will allow to execute code on breakpoint or have SQF code conditions on breakpoints. That would allow anyone to execute any script they want. Bad stuff! Well. The Debugger is open source. I don't have time to do any more projects. But if you want to use it feel free to do so.

The debugger is essentially a Game hack. So AV warning and stuff is to be expected. But all source is public and the builds come from an external build server so it's guaranteed that only the source that's visible on Github is what ends up in the final binary. So if you're worrying about malicousness you could check every line of code yourself.

You'll see it when you start the Game with the Debugger. Most of the stuff only works with Profiling builds. But you can still get basic functionality with non-profiling builds though. But everything is optimized around profiling builds because this is a serious development tool. And a serious developer might already want profiling build to profile their scripts performance and stuff. You have to run Arma first. The Debugger get's activated after Arma goes into fullscreen.

No. And that's not really planned. I thought about making a Visual Studio Code plugin that can use the Debugger but... Not yet and not soon. If a skilled VS Code Extension maker guy thingymabob would like to do that though I'd be happy to help with the API.

That's not just Github thats everywhere. Atleast it should be. That's how we built 0.9.12. I'm not sure what the intentions were but Nkey told me to do it like that. So I did. You only need to download the pipe_x64.dll and put it into your @task_force_radio directory. I don't think the 0.9.12.zip has that in there yet.

Already fixed. Will be released with 1.0 as soon as the rest of the Todo list is done. Can't give any ETA on that tho.

1.0 branch pipe.dll won't work with TFAR 0.9.12. And 1.0 branch has it's own official x64 dll in the download already.

Btw official TFAR dll is here: https://github.com/michail-nikolaev/task-force-arma-3-radio/releases/tag/0.9.12 which is AFAIK also Battleye whitelisted

22:20:01 [CBA] (auto_load_settings_file) WARNING: Cannot load settings file. File patching disabled. Use -filePatching flag. loadSettingsFile.sqf:20 Why are you running a pbo that is for a specific purpose that you don't even use? You are running a metric ton of Mods. With config errors all over. Some like Enhanced Movement are outdated. You are running a mission with config errors all over it's description.ext Other than that I can't see anything in your RPT that may tell me why these problems are happening. But I might just be blinded by the amount of crap in there. Try to reproduce it with less Mods is all I can say. And also please don't doublepost. Some People hate that. I'm one of them. Goodbye and have a nice time handling that problem without my help.

Ask the CBA guys. They are doing all the Hotkey work. I think Arma doesn't really support this currently. AFAIK only way you can bind joystick keys is via user Actions but they are crap to use for Addon Makers. There is a finite amount of them and handling that is not as easy as just using the CBA key system. Maybe BI will someday add a Eventhandler for keypresses that also works for joystick keys. Game Master Module with UID doesn't work. You have to bind it to the Logic. In Editor under Systems -> Logic Entities -> Virtual Entities place a Zeus logic. Then you can slot in that logic slot and use Zeus from there with working 3D sound.

To your Mp questions 1. Exactly. Only the server will get a correct return Value. 2. Check CBA's code for namespaces https://github.com/CBATeam/CBA_A3/blob/master/addons/common/fnc_createNamespace.sqf So apparently Localtions are really only local. They are using an empty vehicle for Globals. 3. I'm not sure. Test it. But I think this will onl... This will not even work but I guess you mean publicVariable "_event"; and no.. you can't publicVar local variables. But I guess you just meant publicVariabling the object. I don't think that broadcasting the variable bound to an object will broadcast the objects variable. Just setVariable ["",value,true] for that. 4. Possible. But better have features that not everyone needs than missing some features 5. yes 6. Event probably not... Maybe. But Clients may want to register handlers to other clients events.

Igneous01 IGNeous01 IGN It really looks like it's the same just with slightly worse performance and that you have to include extra scripts instead of using the Game provided ones. BUT! the IGN system is MP compatible. From what i can see from the wiki the BIS scriptedEH's don't support remoteExec and stuff Scratch that. The IGN System has functions for Server and Client handlers but I couldn't find any remoteExec or BIS_fnc_mp or publicVariable EH. From what i can see it only executes the handlers locally no matter what you do. Well you can run a spawn loop on every client to wait for the event to have the raised variable set to true. Also I didn't know about spawning the Helipads.. If he just want's to store variables he can use a Location instead which should have lower performance impact. This Framework seems pretty useless to me. But after rewriting most of it and cleaning everything up and adding MP functionality it may be very useful to some people.

As far as I can see these are not Events based on Code Conditions checked every Frame. You basically Add an Event and then raise it manually in a Trigger or something. It's basically a Signal-Slot system. See this from the functions_docs // thread 1 only tracks player death _thread_1 = spawn { waitUntil {!alive player}; [eventUnitDead, player] call IGN_fnc_raiseEvent; // this can be called at the same time as the other one! }; After a short look at the code my conclusion: Practical for some missionmakers. Code looks like its 2 years old. Performance very much not optimal. (call compile string in a couple places :/ and very old not using new engine possibilities) But probably not seriously bad. I wouldn't use it. If i need to execute a function at an event I would just call that function. If i need to execute multiple functions I would just call these functions.

Anyone here who is running x64 Dev branch and can test the 0.9.12 x64 pipe.dll for me? I added it to the Release on Github (https://github.com/michail-nikolaev/task-force-arma-3-radio/releases/tag/0.9.12) This is a build from the 1.0 pipe.dll but it should work for 0.9.12.

I only voted Yes for Server Monetiziation because especially in the Life and Exile community (It's always nice to call them out :D) I feel like the Audience is very young and young people are not very inclined to donate to the Server owners for doing their work. Though young people are even more inclined for giving money to have a small benefit which is exactly the Market for Mobile games for example Clash of Clans. They make millions of kids paying money to be better than other kids. This makes it way easier for Server owners to get their cost back in. But of cause I feel like it's also being misused by many Server owners that know that kids are more inclined to pay, Targeting their monetization to get all the money they can get. Making a profitable business out of it instead of just covering the costs. Monetizing Servers is fine for me if it doesn't get out of hand. For example to get a reserved Slot in case the Server is full or something. Of cause that money should then be used to get a better Server with more Slots, which most Servers probably won't do. But if you allow people to take money there will always be People misusing it. Arma is a Game for some. But for most People it's more of a Hobby. Of cause I would like to get some money for my Hobby, but thats what Donations are for. I can see Modders wanting a small Fee for big Servers that use their Mods like Infistar does. Because big Servers mostly have the money to spent (As long as server monetization is allowed). But Modders taking money from the Players is wrong IMO and I don't think its possible anyway. And don't say Modders are left behind because they are not allowed to monetize their work. Just put a Donation Link up and say "Please help me keep working on these Mods as a Hobby" I also got some Money for Modding around. Just People that appreciate my work and want to Donate something. If you don't have People appreciating your work enough to help you a bit you are doing something wrong. Sometimes People just don't think about it, so write a small notice on the Download page or in the Readme. No one would get angry about that. Have to agree. I hosted Servers for about 30 People with just $15 a month. Of cause it skales upwards but if you are too dumb to choose what you need it's not the Players fault. A community I'm playing with is paying 70€ a month for their 10 members. Thats just overkill. In Todays day and age you have a choice.

No the ID cannot be removed. BI doesn't offer a better solution. You can check the config entry of that radio for the tf_parent entry. It contains the base classname. ex. (configFile >> "CfgWeapons" >> "tf_anprc152_3" >> "tf_parent") -> "tf_anprc152" you can use the TFAR_fnc_isRadio function to check if a classname is a Radio.

Arma Discord is always a good place. There are always people ready to scream at you for writing Bad code and telling you what exactly is wrong and why. But thats only very good for smaller code snippets. No one has time to look at multi hundred line files or whole frameworks.