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.

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?

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 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!

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'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:)

... 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 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!

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...