Jump to content

Dedmen

BI Developer
  • Content Count

    2910
  • Joined

  • Last visited

  • Medals

Everything posted by Dedmen

  1. Dedmen

    X-Cam-Taunus Version 1.1

    Probably a ACRE problem. Please report at https://github.com/IDI-Systems/acre2/issues
  2. Dedmen

    Enhanced Movement

    Could you maybe open-source your Mod on Github or show me a way on how to contribute? I found out your onEachFrame eventhandler is a major performance hog taking about 4ms per Frame (thats about the difference between 50 to 60 fps). Calling: ["BABE_MAINLOOP","oneachframe"] call BIS_fnc_removeStackedEventHandler; instantly increases my FPS from 57 to 68. I'd like to improve your performance but i didn't find a way on how to contribute. I can contact you on Steam if wanted.
  3. Already posted this in the forum before ["unit", { //current unit changed (Curator took control of unit) if (player != (_this select 0)) then { player setVariable ["TFAR_controlledUnit",(_this select 0), true];//This tells other players that our position is different } else { player setVariable ["TFAR_controlledUnit",nil, true]; }; TFAR_currentUnit = (_this select 0); }] call CBA_fnc_addPlayerEventHandler; That into init.sqf and done.
  4. You have to use the correct base class CUP_B_LR_Transport_GB_W is inheriting from. You can use the ingame config Browser to check that. then you use class parentClass; class CUP_B_LR_Transport_GB_W : parentClass { tf_hasLRradio = 1; // 1 = true, 0 = false }; Are you trying to enable speakers for a vehicle that already has a radio? Because it would be obvious that it doesn't work for a vehicle that doesn't have a radio. To get quicker help feel free to join our discord https://github.com/michail-nikolaev/task-force-arma-3-radio/issues/1116 Just message me in the scriptingsupport channel. Live support is easier than here on the forum.
  5. Both your config and script are actually correct... To check if the config setting on the vehicle is correctly applied you can sit in the vehicle and call "player call TFAR_fnc_vehicleLr" If vehicle doesn't have an LR Radio this will return an empty array. Meaning something with your config is not alright.
  6. https://github.com/michail-nikolaev/task-force-arma-3-radio/blob/master/arma3/%40task_force_radio/addons/task_force_radio/functions/cba_settings.sqf#L9 This is where the setting is defined. So its actually default 9 right now. Players can set that in their own settings. Under Options -> Game Options -> Addon options. the second 9 in the array is the default value. It is already set back to 7 for the 1.0 release.
  7. CBA settings is not really a conversion. We had to do it because the userconfig had to be removed for security reasons. And without CBA settings there wouldn't be a way to set serverside settings without script addons. For set frequencies to apply you also need to enable same frequencies for Side. Set that in CBA's serverSide or MissionSide Settings and force the setting. Just talked about the frequencies problem with a guy a few hours ago. His scripts weren't working correctly but when he set the serverSide CBA Settings everything was fine.
  8. as of TFAR 0.9.10 this is disabled by default. Code: if (tf_no_auto_long_range_radio or {backpack TFAR_currentUnit == "B_Parachute"} or {player call TFAR_fnc_isForcedCurator}) exitWith {}; any of these is true equals no backpack replacement. Check with the Debug console or any other means that the Variable tf_no_auto_long_range_radio is really set to true when ingame.
  9. There is a known Problem when using a button without Modifier for the LR Radio. Arma hotkey handling is not as nice as I'd like it to be.
  10. tf_same_sw_frequencies_for_side_server is only used when tf_same_sw_frequencies_for_side is undefined and tf_same_sw_frequencies_for_side_server is defined. Which is never the case. tf_same_sw_frequencies_for_side Is always defined and the _server variable is never set. Its old leftover code thats not used anymore.
  11. The rest of the script just stays CBA less. For your set frequencies to apply you have to have tf_same_sw_frequencies_for_side set to true. My workaround is very wonky. It is way safer to just use CBA as it is intended: https://github.com/CBATeam/CBA_A3/wiki/Settings-System#basics You can define settings mission wide or Server wide. And now that i learned that CBA overwrites settings after missionStart i also know some module settings won't work. So you have to set them the CBA inteded way. You can also go to Settings -> (forgot the name) in 3DEN and set it there for the mission but remember to set everything you wanna change to forced.
  12. Back to the problem with settings not applied.. It's actually correct but not really reproducible. Settings get overwritten by CBA after postInit. Problem is.. Sometimes init.sqf runs before that sometimes after. The correct way is to use the CBA_settings_fnc_set for settings that are using the CBA framework. see this: ["TF_no_auto_long_range_radio", true, true,"mission"] call CBA_settings_fnc_set; ["TF_give_personal_radio_to_regular_soldier", false, true,"mission"] call CBA_settings_fnc_set; ["TF_give_microdagr_to_soldier", true, true,"mission"] call CBA_settings_fnc_set; ["TF_same_sw_frequencies_for_side", false, true,"mission"] call CBA_settings_fnc_set; ["TF_same_lr_frequencies_for_side", false, true,"mission"] call CBA_settings_fnc_set; ["TF_same_dd_frequencies_for_side", false, true,"mission"] call CBA_settings_fnc_set; The first parameter is the name of the setting(Variable) the second parameter is the value and the third parameter has to always stay true. The settings listed are all the CBA_Settings variables. All other variables can still be set the old way you are used to. A quick fix would be to put this to the end of your variable set scripts: ["TF_no_auto_long_range_radio", TF_no_auto_long_range_radio, true,"mission"] call CBA_settings_fnc_set; ["TF_give_personal_radio_to_regular_soldier", TF_give_personal_radio_to_regular_soldier, true,"mission"] call CBA_settings_fnc_set; ["TF_give_microdagr_to_soldier", TF_give_microdagr_to_soldier, true,"mission"] call CBA_settings_fnc_set; ["TF_same_sw_frequencies_for_side", TF_same_sw_frequencies_for_side, true,"mission"] call CBA_settings_fnc_set; ["TF_same_lr_frequencies_for_side", TF_same_lr_frequencies_for_side, true,"mission"] call CBA_settings_fnc_set; ["TF_same_dd_frequencies_for_side", TF_same_dd_frequencies_for_side, true,"mission"] call CBA_settings_fnc_set; This makes sure the variables you just set will stay set. I'm sorry for not knowing that before but the CBA_Settings documentation didn't say a single word about that. If you are running the scripts serverside Only you have to add ,"server" as last argument to CBA_settings_fnc_set. This is a ugly workaround and may not work all the time.. It is prefered to use the CBA Server side settings https://github.com/CBATeam/CBA_A3/wiki/Settings-System#basics
  13. You can set an array of frequencies in the TFAR Frequencies Module. These frequencies will be the default frequencies by every group thats synchronized with the module. But you have to sync it to every group you want to start with these frequencies. And only sync it to one unit per group else you'll get error messages about multiple frequency modules assigned.
  14. Problem is we can't reproduce any of those problems. I just tested with TF_no_auto_long_range_radio and everything works as expected. Mission Module overwrites server-side settings. Init.sqf script overwrites module and server settings. And i get what i specified. It would be far easier if anyone could provide us with a repro mission so we can see where the problem lies. Just saying something doesn't work isn't helping anyone. I also tested the frequency Module and it worked fine. I didn't test script for frequencies but as the script does exactly the same as the module i expect it to work.
  15. We didn't change anything on that variable. It only moved to CBA Settings which is set before init.sqf but can be overwritten in init.sqf
  16. Okey good to know. We already have a report about that here https://github.com/michail-nikolaev/task-force-arma-3-radio/issues/1058 But that guy didn't reply. Would be nice if you could join our Discord and provide a test mission for us so we can reproduce the Problem. It's already on my todo list for the next few days but you could make my work easier ;)
  17. That is a known problem when using keys without modifiers for LR radios. Someone already made a supposed solution for that but it brought other problems that made that fix not that good. We are definitely aiming to fix that. Our keyHandling functions all end with "hack" so you can imagine how wonky our implementation is. Fixing spectator is planned. We just got a request from another player two days ago about that. For progress check https://github.com/michail-nikolaev/task-force-arma-3-radio/issues/1151 Its not enough to copy the plugins you also have to copy the radio-sounds folder. If you are using the workshop version just run the plugin installer and it should handle everything. tf_freq_west_lr are only generated when the serverSide variable doesn't exist. Meaning if you code runs client-side only, the server will overwrite your setting. So as long as you place it in init.sqf instead of initPlayerLocal.sqf it should be fine. Also dont use "#include" there. That will break your mission when 1.0 comes out. Use "call compile preprocessFileLineNumbers" which will error out on 1.0 but not kill your arma.
  18. Can you define "A few versions back" in more detail?
  19. It already is Implemented in the main Mod version 1.0. But I don't know when the 1.0 release will be. Intercom is highly requested and planned for an upcoming release. But I am not sure if it will make it into 1.0. You could change the radio range via script which is effectively jamming if you set the range to 0. player setVariable ["tf_receivingDistanceMultiplicator",0.0]; Sets the effective receiving distance to 0. Meaning player can't receive anything. Not sure about sending. You could also change the players encryption code that way nobody will hear him when transmitting. Join discord for more help. There are plans to implement this post 1.0. You can check progress here https://github.com/michail-nikolaev/task-force-arma-3-radio/issues/902 Please join our discord at https://discord.gg/8emCVsz to get live support ;)
  20. 1.0 Adds the possibility to disable Full-Duplex mode and use Half-Duplex only instead. https://github.com/michail-nikolaev/task-force-arma-3-radio/pull/1148
  21. you can use player setVariable ["tf_receivingDistanceMultiplicator",2.0]; to give him twice the normal receiving distance. or even higher numbers. I don't really understand the terrain interception coefficient so i can't really tell you much about that.
  22. Can you please contact me on our discord https://discord.gg/8emCVsz and provide me with a repro mission for that problem? I can't reproduce that in my tests. I though i experienced the same issue while fixing the issue that dead players could hear Zeus. I thought it was connected to that. Thats why i answered you earlier with a hotfix i made as a look into the code didn't show me any compatability for Curators using the Remote Control module, so i thought it was really broken but appears it isn't. But even now on the current 0.9.12 release i cant reproduce that with a unit synced to a curator module. (The units variable name entered in the curator module) I'm not a mission builder maybe I'm doing it wrong. Or maybe I'm doing it just right and everything else doesn't work. I don't know. Please contact me as quickly as you can as that maybe issue is currently holding off the release to the Steam workshop. Or it would be nice if some more people using 0.9.12 can contact me and confirm that issue or not.
  23. Please join our Slack or Discord at https://github.com/michail-nikolaev/task-force-arma-3-radio/issues/1116 I can't reproduce your problem by downloading the 0.9.12 release from github and using the ts3_plugin installer. If you need a quick fix you can also download just the Teamspeak plugins on the Github release (https://github.com/michail-nikolaev/task-force-arma-3-radio/releases/tag/0.9.12) If you dont want to run 1.0 you can also add this to your init.sqf ["unit", { //current unit changed (Curator took control of unit) if (TFAR_currentUnit != (_this select 0)) then { TFAR_currentUnit setVariable ["tf_controlled_unit",(_this select 0)]; } else { TFAR_currentUnit setVariable ["tf_controlled_unit",nil]; }; }] call CBA_fnc_addPlayerEventHandler;
  24. If you are using a zeus module assigned to a unit. TFAR only uses the position of that original unit. If you are assigning the module to a zeus logic (Logic entities) then it uses the player you are currently controlling. But that didn't change in 0.9.12. The only thing we changed was that the positions of curators were not transmitted when a player was dead. So a dead player could hear alive Curators. Edit: I just pushed a build that should fix that, Its available at our github as a Pre-Release. Would welcome if you could help us test it.
  25. Please update to 0.9.12 userconfig in arma root doesnt matter if you dont enable filePatching The latest version is 0.9.12 only available on our github currently. https://github.com/michail-nikolaev/task-force-arma-3-radio/releases Load TFAR on the server with the -mod parameter and set the TFAR enforce usage module in your mission and configure it correctly.
×