ArmA Annoyances: Say “NO” To Randomize!

You’re probably wondering what I’m so mad about? I will tell you, it is the obligatory use of randomize.sqf scripts with Arma 3 assets. Despite numerous feedback tracker tickets and requests (1 2), new assets keep coming with own randomize.sqf scripts. These scripts are normally launched from asset init event handlers defined in CfgVehicles. For example:

Here are several points to consider:

1. These scripts are hardcoded and launched every time asset is created or a new player receives the asset and cannot be overridden
2. These scripts are launched in scheduled environment with execVM command with no handler returned. This means unknown ETA of script completion
3. Because vehicle init is executed for every JIP player as well, syncronising randomisation between clients may become difficult
4. Some scripts, like a working clock in cargo vans, spawn endless while true loop eating CPU every 5 seconds. If you consider cost of such clock vs. gameplay value, the cost would appear to be disproportionately high
5. Because of scheduled environment execution, spawned assets could be getting randomised with visible delay, making it quite noticeable and silly looking at that too

If it was for me I would have made BIS_fnc… library functions available for scripters and mission makers with various post randomisation features but left default asset spawn at bare minimum. I however doubt BIS would go down this road any time soon, so maybe there is a compromise to be reached?

The randomisation could simply be controlled with a single variable or a set of variables. I personally would have kept it simple and let one variable to globally disable randomisation because it is very easy to add randomisation if needed rather than remove it. However there could be several variables, one for vehicles, one for units, one for animals… etc.

So here some ideas I’ve been discussing with SaMatra (if you reading BIS please feel free to use for inspiration). Rather than having script files, the randomisation could be wrapped in BIS_fnc… and compiled alone with other CfgFunctions at the start. Then instead of execVM, spawn could simply be used. Added benefit is that functions could be re-used by mission makers to randomize their assets at will at any time.

As I have mentioned before, JIP players could present a problem for randomisation. So BIS added setObjectTextureGlobal command and limited randomisation to run only on the server:

What if I don’t want the randomisation? Part of the script above is essential, like hiding various elements to achieve plain look of the Offroad, but another part that deals with colours and doors should be 100% optional. So here is an idea. Introduce a description.ext parameter, for example “DoNotRandomize“. If absent or DoNotRandomize = 0; randomisation happens as usual. If DoNotRandomise = 1; randomisation is skipped. And the parameter is just a config entry that can be read with missionConfigFile command. This is how the above script would look:

100% backwards compatible. There are about 19 randomisation scripts, so in order to update them all, this line…

…has to become…

…in all scripts (skipping essential parts like in the example above). And if you have a set of variables instead, then it could even look like this:

Best bit is description.ext params are global so every one will have the same condition. So let’s just hope this will finally be put to rest.

Enjoy,
KK

EDIT: Good news, now you can switch off randomisation just like this:

_veh = “C_Offroad_01_F” createVehicle position player;
_veh setVariable [“BIS_enableRandomization”, false];