TOPARMA / ArmA3_Wasteland.Chernarus

TOP A3Wasteland Chernarus - Conquest format
http://www.toparma.com
GNU Affero General Public License v3.0
5 stars 14 forks source link

Random cargo spawning changes #18

Closed shizweak closed 9 years ago

shizweak commented 9 years ago

@l0dac, @Motavar

I've spent a considerable amount of time on a branch which contains some major changes to the way random items and weapons are defined and spawned through out the mission and would like to get your thoughts/feedback on this.

At the moment, as you both may have seen - there are weapon and item classes sprawled through out several functions such as random box spawning code, mission crate code, supply truck code, etc..

Working through all these files and searching for class names to find anything I've missed was becoming a pain, not to mention if another mod was added to the mix later down the track containing new weapons - you would then have to go find all these functions and edit their internals just to get the new weapons spawning. The new proposed method would be as simple as modifying the two arrays with any new weapon or item classes, and then assigning them to cargo groups.

The work I've commited so far (I've still got more to do) moves the configuration of random cargo spawning into two new server variables (defined in serverVars), one for weapons (randomCargoWeapons) and another for items (randomCargoItems). These two arrays define a unique list of weapons/items along with their assigned cargo groups which are then made available to be randomly picked from and spawned into the cargo space of a vehicle/container/crate

Cargo groups are completely configurable by the mission maintainers, and new ones can be added or others removed without breaking or changing the internal functions. With that being said, there are two new functions I've introduced to make use of the new server variables one called addRandomCargoWeapons and another called addRandomCargoItems - these can be used to essentially fill any object containg cargo space with a random assortment of weapons or items.

Here is a quick example on how it works.

First an excerpt from "randomCargoWeapons", note each weapon in this example will spawn with 2 magazines, 2 random but compatible attachments and 2 random but compatible alternate muzzle magazines (parameters in that order) - you can change the default values to whatever you see fit (e.g. you might want LMGs to only spawn with 1 magazine and no attachments):

[["rhs_weap_m4a1", 2, 2, 2], ["box_west_basic"]],
[["rhs_weap_ak74m_gp25", 2, 2, 2], ["box_east_basic"]],

The first inner array contains the aforementioned weapon configuration, however this can also be a string defining a weapon class and it will be spawned with no magazines or attachments if randomly selected. The second inner array is a list of cargo groups it belongs to.

So if I were to create a box _box = createVehicle ['Box_East_WpsSpecial_F'] then clear its default cargo with clear{Magazine,Weapon,Item}CargoGlobal then call the new addRandomCargoWeapons function like so [_box, 'box_east_basic', 10, false] call addRandomCargoWeapons it would compile an array of weapons with the cargo type 'box_east_basic' and then randomly select 10 items from it. The last argument allows you to turn on or off duplicates, e.g. in this example it will only spawn 1 weapon, as duplicates are false - if set to true, it would spawn 10 of the same weapon (obviously only in this example, as I've only defined one weapon for the cargo group).

This function can be called on any vehicle with cargo space, (box, car, truck, etc) and multiple times with different cargo types to fill it with a variety of random gear (e.g. supply truck mission could add several cargo groups of random gear into it).

End result/goal

In my opinion, this solves several problems:

a) Moves all server based weapon/item/spawning configurations into a single location (serverVars) and reduces time and complexity of adding or removing new/old/buggy content across the board. Each weapon and item has a single definition with multiple cargo groups - making it quick and easy to see what is spawning where.

b) Creates a foundation to move other parts of the code across to this format, e.g. a new cargo group could be created called "vehicle_weapons" - which the random vehicle spawning script could use to determine which weapons can be spawned in vehicles. We could also create another new server var called randomVehicles along with a function called `createRandomVehicle' which can use the same type of free form group system, e.g. 'mission_heavy', 'mission_light' that people can expand on easily without digging into code.

c) Utilizes several existing functions to expand on existing functionality that works well, such as the updated processItems function (the addRandomCargo{Weapons,Items} functions both generate an array to be passed to processItems internally), the changes I made to this function are completely backwards compatible (e.g. the interface hasn't changed, only additional parameters added which default to zero when not passed).

Your thoughts?

(edit: a link to the current branch with differences to current master: https://github.com/TOPARMA/ArmA3_Wasteland.Chernarus/compare/master...shizweak:dynamic-box-spawning?expand=1)

Motavar commented 9 years ago

I love the idea! I think this is a great addition to the code base but it will be up to Lodac to see if he wants to accept the changes to his master.

l0dac commented 9 years ago

I'm all for it. I'd even like to see it taken further where it is pulled from the database :)

shizweak commented 9 years ago

Great to hear guys - I'll finish off the current work and replace all instances where random weapons/items are generated inside functions and then do a bit of clean up to get rid of any superfluous code (there seems to be a lot).

@l0dac I'll look at moving it to the database after I've finished this round of changes and finished off a few other things for our server. Otherwise it should be dead simple to move into the database, as I can just populate the arrays with the returned data from extDB. I'll have to dig into extending extDB "best practices" but I assume adding additional tables won't be an issue!

You can close this issue for now and once I'm down I'll pop a pull request through with a full change log covering new, modified and removed functions!

AgentRev commented 9 years ago

I'd even like to see it taken further where it is pulled from the database

lol you and your DB addiction

shizweak commented 9 years ago

@AgentRev Better than a crack addition I suppose :stuck_out_tongue:

l0dac commented 9 years ago

I've been trying to figure out how to pull admin from the database for two days now. I give up. haha

AgentRev commented 9 years ago

two days

*two months

shizweak commented 9 years ago

@l0dac what are you trying to achieve exactly? is this for the admin skin stuff I saw in a prior commit?