twistking

When running moderately long object view distances, the wheat fields and sugar beet fields completely wreck my framerate. Those plants seem to behave like trees and are rendered to the max object view distance, which is a weird decision... Is there a way to make those plants behave like grass, or has anyone a different idea how to lessen the impact on framerate from those fields? I used hideobject to simply get rid of the plants, but that does not look good obviously. The rest of the map seems to be well optimized, so it's especially unfortunate that those fields come with such a big overhead.

Hello, how can i prevent or discourage players using enemy vehicles? When players have the ability to repair knocked out vehicles (engineer trait or repair vehicle), they can easily get aceess to strong vehicles that would more or less break the mission. What are elegant ways to discourage usage of enemy vehicles? "Locking" vehicles for players would of course work, but also feels a bit to restrictive and artificially forced. The best thing i could come up with was a trigger, that sets vehicle fuel close to empty when vehicle is damaged... Other ideas? Thanks!

thanks!

Is there a way to increase viewdistance in the coop-gamemode? It seems to use the standard setting, which is quite low. I'm quite familiar with arma mission editing and scripting, but i assume that the scenario files are encrypted and can't be easily modified. Is there some way to do it without using mods?

thanks for the answer. that's great news! i don't want to run "western sahara" if the mission does not need it, so using it as server mod is the way to go then.

@lexx Hello, so that finally some of my buddys grabbed the CDLC during the sale, we want to dive into multiplayer. For our dedicated server I wonder, if we can simply run "Western Sahara" as a mod (Western Sahara - Creator DLC Compatibility Data for Non-Owners) instead of installing a different Arma branch? We would NOT mix with other CDLC, so we would run plain old Arma 3 standard branch + "Western Sahara - Creator DLC Compatibility Data" mod + CBA_A3 + TFAR. We are mainly interested in playing custom missions. Is this possible, or should we go with the arma branch that includes the CDLC data? Having to switch branches instead of just not laoding a mod seems to be a pain in the a** for server management. Thanks!

Hello, i've got a mission where i've put randomized objects to predefined locations on the map. i've randomized the objects similar to this. radiolist = [radioplayer_a, radioplayer_b, radioplayer_c, radioplayer_d, radioplayer_e, radioplayer_f, radioplayer_g, radioplayer_h, radioplayer_i]; random_radioplayer_a = selectrandom radiolist; radiolist = radiolist - [random_radioplayer_a]; random_radioplayer_b = selectrandom radiolist; radiolist = radiolist - [random_radioplayer_b]; ... etc. i then put the "random" objects on the map on predefined locations. it works well, however the "proper" objects are assosciated with a bunch of triggers and scripts (all player proximity based for interaction), so every lcoation, you get another "set" of object and assosciated triggers/scripts. fine! my problem is, that i also would like to be able to fire the triggers/script remotely (by setting a variable or similar) by location. for example: "fire trigger/scripts that are on location a". however i do not know how to that in script. for example: if i wanted to fire all triggers/scripts from location "A" i would put "random_radioplayer_a" in the debug console. the console would give me the assosciated "proper" object. for example: "radioplayer_h". now i could manually set variables to fire all triggers assosciated with radioplayer_h. how would a script work, that would set 2 variables to true for a given location? the process would be: query "random_radioplayer_a" to get "proper" radioplayer, then somehow find variables assosciated witht hat "proper" object and set them "true". i think this might be possible with a HashMap, but i'm not sure and could not get it to work. the idea would be to have a "database" that holds sets of an object and 2 assosciated variables... idk if this makes sense?! any ideas? thanks:)

nevermind, i solved it with a lot of those if statements.

another option would be to to do something like: (pseudocode) if random_obj_A equals obj_A, set vari1A = true and set vari2A = true if random_obj_A equals obj_B, set vari1B = true and set vari2B = true if random_obj_A equals obj_C, set vari1C = true and set vari2C = true should work, but with 9 randomized objects it would be 81 of such checks... so a lot of code for a simple problem...

Hello, i am aware that loadouts not initiating properly is a common problem on big and complex servers, but since i started doing loadouts by script instead of using eden, it happens frequently on our server even on very small missions. I tried using the cba enforce loadouts option, but that does not stop it from happening, but makes it so that running the loadouts scripts from the console has no effect. Without the option i can at least manually load the loadouts for each player with the console. I assume that my way of doing the laodouts in the first place is not ideal, since the problem occurs so frequrntly. Here is how i do it: On init field of playable unit: this execVM "scripts\loadout_a.sqf"; and the script would look something like this: params ["_unit"]; if (!local _unit) exitWith {}; removeAllWeapons _unit; removeAllItems _unit; removeAllAssignedItems _unit; removeUniform _unit; removeVest _unit; removeBackpack _unit; removeHeadgear _unit; removeGoggles _unit; _unit addWeapon "rhs_weap_ak74"; _unit addPrimaryWeaponItem "rhs_acc_dtk1983"; _unit addPrimaryWeaponItem "rhs_30Rnd_545x39_7N6M_AK"; _unit forceAddUniform "rhsgref_uniform_ttsko_mountain"; _unit addVest "rhs_6b5_sniper_khaki"; _unit addItemToUniform "FirstAidKit"; for "_i" from 1 to 2 do {_unit addItemToUniform "rhs_30Rnd_545x39_7N6M_AK";}; for "_i" from 1 to 4 do {_unit addItemToVest "rhs_30Rnd_545x39_7N6M_AK";}; for "_i" from 1 to 2 do {_unit addItemToVest "rhs_mag_rgd5";}; _unit addHeadgear "rhsgref_6b27m_ttsko_forest"; _unit linkItem "ItemMap"; _unit linkItem "ItemCompass"; _unit linkItem "ItemWatch"; *** Would there be a better way to do unit loadouts, that maybe works more reliably? I thought of just doing a trigger a second after mission start, that would just fire and manually reload the loadout: [p1] execVM "scripts\loadout_a.sqf"; [p2] execVM "scripts\loadout_b.sqf"; [p3] execVM "scripts\loadout_c.sqf"; but this will give an error if not all player slots are populated, since some playable objects referenced will not be existent in the mission. *** What is best practice for doing loadouts from a script in a coop environment to avoid problems with laodouts not working. Thanks a lot!

... or in other words: i understand that i want to call the loadout a little bit later, since eden-init-fields are called so early that locality issues can arise. however, if i call them at a point where locality should be settled, i will get errors for calling the loadouts for units that did not end up in the mission because of vacant slots. if i want to emulate the eden loadout functionality with code, how would i set it up? i remember that it used to work when i called the loadouts from init.sqf, but that would give the errors with vacant player slots... only because of that i tried calling the loadouts from the eden object init fields...

thanks a lot. i will definitely play around with the save/load function in eden. there is however another benefit of using code for laodout that i forgot. when running mods like rhs, you end up with hundreds (even thousands?) of items in the asset browser. i solved this with an excel document, where i have all the classnames organized, so finding what i need is actually way faster than using the editor UI. therefore i will also do more testing with code-based loadouts. two more questions: when you say JIP, that would also include players that joined the mission before mission start, correct? so it would be technically JIP even the player joined before mission start, because the server init is done server only and when client actually takes control it does a "JIP" sync where information from earlier inits is done. Is this correct? So basically everytime a playable unit changes locality to a client is technically a JIP?! "if (isServer) then { apply loadout }; // there is not yet player, so no locality other than server, and the sync will occur on JIP. Nothing more." Isn't that the same as if (!local _unit) exitWith {}; with the only difference that "if isServer" will only run once at server init, while my variant will run once at server init (when unit is still local to server) and a second time when player takes control? I think i do understand what you explained with the init order and locality, but i am still unsure what i can do witht hat knowledge to avoid the loadout failures. Running the script two times should only increase the chances of the loadout being loaded, no?

can you elaborate? i am not sure what you mean... i do not want to use the eden editor loadout editor (right click on unit -> edit loadout), because that is very tedious to do if you have a bunch of units that need custom loadouts. way faster to do it with code, where you can quickly copy/paste segments. and quicker to make small edits. i would have no issue with doing the loadout with code in the editor without calling external scripts, but i do not see why this would be different from calling a script from the same location: is there a difference between doing object init: this do a versus in object init: this execvm "script_that_does_a.sqf"

Hello, i've got a trigger with the condition: west knowsabout off01 > 0.1 and alive off01 and act: ["kill01",off01] call BIS_fnc_taskSetDestination; ["kill01","kill"] call BIS_fnc_taskSetType; My problem is that it does not work in MP when i set the trigger to "server only". SP works fine. It also works fine when i don't do "server only". I assume that the expression "west" is the problem for the dedicated server. What other argument could i use to check if any blufor unit has spotted the officer?

well, the knowsabout command and the "detected by" trigger work differently depending on the autoReporting difficulty setting. See Larrow's test mission. Not an issue in your mind?

I'd call it a bug honestly. It's not super severe, but neither can i imagine that it's deliberate, nor can i see how this is an unsolvable issue. My guess would be that it's just an oversight...

So, i finally found time to do more testing. I tested your solution and it worked in Singleplayer, but did not work on dedicated server with veteran difficulty (can't remember if i also tested dedicated with low difficuly, but i think now it's safe to assume that the detected trigger uses "knowsabout" internally and also suffers from the locality issue with autoReporting turned off. see @Larrow's post above). I did not know that you can put conditions in the activation field even. Thanks. Ok. i see about the tasks. I guess i'll just be more relaxed about firing the task-functions from clients. I somehow feared the system may break if it gets spammed from many clients at the same time. I did never experience that though to eb fair, so it was just me being overly cautious... One somehow related question arises: If i'm more relaxed about running triggers with global effects locally, would it be good practice to delete or somehow deactivate the trigger for all other clients after it fired? Let's take for example the detected trigger that will only activate locally because of the "knowsabout" issue. This will trigger some task functions with global effects. Now all other clients and server will have the tasks updated nicely, but on their machine the trigger is still checking for the conditions to be met. Would it make sense to "remotexec deletevehicle" the trigger somehow (if that is even possible)?

thanks for checking again. i also ran your mission again and it did not work. the task did not complete and the system chat message did not change. i then restartet the mission with "regular" difficulty preset (before i had custom, which on our server is basically just veteran with "tactical ping" activated) and it worked. so somehow the knowsabout locality issue is dependant on game difficulty?! this game is driving me mad!

Ah, i see. So "west" knowsabout x would only work when the actual entity doing the spotting "in the name of west" would be local to the server, which a player is not. So "west" is not truly local to the dedicated server... while "east" would be local in my case, because the whole faction consists of server owned AI. Regarding the "server only" trigger i thought it was "cleaner" to run all the task-functions on the server only, so there is no network spam when all clients trigger the task-updates. Maybe i'm overthinking this? Also i try to run everything "server only" where it is feasible to save the calculations from the clients again maybe overoptimizing? Your suggestion with the detected-by trigger is indeed more practical. I think i did not do it that way initially because the premade trigger conditions don't allow to specify detected by whom exactly. But for this missions, it's enough to specify by which side he was detected, so it's fine. I was also assuming that the detected trigger also uses "knowsabout" internally and would therefor have the same locality limitations...

Hello, just got a super simple question about calling scripts: Right now i define loadouts of vehicles, ammoboxes etc. by naming the object in eden and then have all the manipulations in the initServer.sqf (apc addStuffCargoGlobal...) I realized it would be easier to have a script file for each object and call that from the initServer.sqf. How would i call it and how would the ammobox referenced within the script-file (i'm still unsure about "this" vs "_this" f.e.). Thanks!

works like a charm. thank you!

if i check for knowsabout locally, how can i tell the server that the trigger has fired locally? i was thinking of: condition: west knowsabout off01 > 0.1 or spotted01 == 1 act: spotted01 = 1; publicVariable "spotted01"; then the "server-only" trigger would check for spotted01 and alive off01 and call all the task-related functions. ********** is this "ok" to do so?

@Larrow the mystery continues: I now did some test on dedicated and found that any knowsabout would return 0 when called from server and return the actual value when called locally (debug console): i tested with "west" and the actual unit name (p1 in my case). p1 reveal off01 executed on server will fire the trigger and execute the task functions without error. when run on server only the knowsabout values will differ between server and client. so after "reveal" on server, the server will report "4" on p1 knowsabout off01, while called locally it will give the value that was determined by how often you click "t". i conclude that on my setup knowsabout values are not properly synced between client and server. are you sure it worked for you when running on dedi? i'm running cba mod and the rhs modpack, but i doubt that those would have such a big effect. i also tested your test missions on dedicated and i experienced the same. as a workaround until the problem is fully solved, i thought i could just run a trigger locally that checks the conditions and on activation sets a variable globally. can i use remoteExec to do "spotted01 = true", or is there another way to broadcast a variable?

@pierremgi@Larrow thanks for the replies! 🙏 this is crazy. i've set up my mission similar to larrow's test, with the only difference that the trigger in question is linked to a "task description" module, which is linked to the original task module (i think it's a leftover from when i did the whole task tree with modules only. i like modules). the officer is placed and named in eden, same as with larrow's test. (to be absolutely clear: i have the task module placed, that creates the task. i have the trigger that fires the two functions. but i have also linked a task description module to the trigger and task module. so on activation the trigger fires the two functions from the activation field and the third by activating the modul. now that i think of it, it is maybe weird to mix function and module workflow... but hey... it worked in SP) when i have time i will test, if it helps to delete the "task description" module and fire the task derscription by function in the same trigger with "task destination" and "task type". this would kinda make it a bug in the task framework, however to be fair, i'm probably the only one mixing syncing modules and calling functions in the same mission...

Hello, is there a nice and simple way for a trigger to check if any player (or any character of a side) has left a trigger area? Use would be to check if players in a MP scenario begin to leave the staging area... Of course it can be done by creating multiple "is present" trigger areas around the spawn site, but there must be a better way, no?