Jump to content

Recommended Posts

Alright then :)

Will you be making any chances to the AI capabilities regarding transporting? Its just so sad to see the transport chopper/Truck/IFV following the AI squadleader walking from one end of the map to the other. SOMETIMES the leader enters the transport he has built, but it seems like he only does that when he is close to the base when the transport vehicle is finished building.

There will be dedicated transport roles for AI.

Share this post


Link to post
Share on other sites

hi,

i run into some problems with 073.

First of all i can´t get the upgrades_xx.sqf to do what i want it to. So a little closer explanation what exactly is needed to get it to work would be nice. Also, i think it was allready mentioned in this thread, ai commanders do stop doing upgrades with the original upgrades_xx.sqf after a while.

another problem is a error message spamming the rpt files. i can´t see why this error comes up, doesnt make much sense to me, since as far i can say the code is correct.

rpt error message

Error in expression <%1_PATROL_%2", _side, _type];

if (count _available > 0) then {_group = _availabl>

Error position: <_available > 0) then {_group = _availabl>

Error Undefined variable in expression: _available

File mpmissions\__cur_mp.Chernarus\Server\Functions\Server_GetTownPatrol.sqf, line 23

To be honest i dont really know wich patrols this refer to, so far i think its the city to city patrol wich i always thought to be done by resistance only. and the resistance patrols work as far i can say.

Another question i have is how resistance made playable actually effect the functionality of the resistance as it used to be. Does resistance in a not threeway game does use the upgrade table f.e.

thx for your time and work benny, highly appreciated

regards

scars09

Share this post


Link to post
Share on other sites
hi,

i run into some problems with 073.

First of all i can´t get the upgrades_xx.sqf to do what i want it to. So a little closer explanation what exactly is needed to get it to work would be nice. Also, i think it was allready mentioned in this thread, ai commanders do stop doing upgrades with the original upgrades_xx.sqf after a while.

another problem is a error message spamming the rpt files. i can´t see why this error comes up, doesnt make much sense to me, since as far i can say the code is correct.

rpt error message

Error in expression <%1_PATROL_%2", _side, _type];

if (count _available > 0) then {_group = _availabl>

Error position: <_available > 0) then {_group = _availabl>

Error Undefined variable in expression: _available

File mpmissions\__cur_mp.Chernarus\Server\Functions\Server_GetTownPatrol.sqf, line 23

To be honest i dont really know wich patrols this refer to, so far i think its the city to city patrol wich i always thought to be done by resistance only. and the resistance patrols work as far i can say.

Another question i have is how resistance made playable actually effect the functionality of the resistance as it used to be. Does resistance in a not threeway game does use the upgrade table f.e.

thx for your time and work benny, highly appreciated

regards

scars09

I'll have a look about AI commander & his upgrades.

For the RPT error it's my bad in Server_GetTownPatrol.sqf:

_type = switch (true) do {
case (_sv <= 30): {"LIGHT"};
case (_sv > 30 && _sv < 60): {"MEDIUM"};
case (_sv > 60): {"HEAVY"};
};

Replaced with:

_type = switch (true) do {
case (_sv <= 30): {"LIGHT"};
case (_sv > 30 && _sv <= 60): {"MEDIUM"};
case (_sv > 60): {"HEAVY"};
};

In a threeway, WFBE_DEFENDER = xxx define who is behaving as "resistance".

Share this post


Link to post
Share on other sites

Thx alot Benny, i should have spotted that missing '=' myself, i am getting old obviously.

Seems that this was a major performance killer since i just finished a game with 073 (original not the updated one) without any problems, before it went to a slideshow after a little more then one hour, wich prolly was the time to take a town and get sv up to 60.

Another thing that you might want to look into is that there seems nothing to prevent east and west to start at same position, nice instant action but certainly not intended.

Regarding the ai commander upgrades i played around a little more, but as a matter of fact he doesnt start upgrading at all with the config i edited. I took commander position and started the upgrades myself and switched back to ai commander right after that. AI did start ambulance range 1 and supply 1, but nothing else. With the unedited config he stops after supply 1 as i tried it.

The upgrades seem to work fine for human players, all links show up correct and upgrades can only be done if the needed stuff got researched before. It also shows correctly if an upgrade is at max level and u cant upgrade it anymore then, how it should be. The stuff i set to false is permanently set to 0, in both, parameters.hpp and init_CommonConstants.sqf.

I post the config i edited, maybe u see right away what my problem is.

Private ["_side"];

_side = _this;

missionNamespace setVariable [Format["WFBE_C_UPGRADES_%1_ENABLED", _side], [

true, //--- Barracks

true, //--- Light

true, //--- Heavy

true, //--- Air

true, //--- Paratroopers

false, //--- UAV

true, //--- Supply

true, //--- Respawn Range

false, //--- Airlift

false, //--- Custom Flares

true, //--- Artillery Time

false, //--- ICBM

if ((missionNamespace getVariable "WFBE_C_GAMEPLAY_FAST_TRAVEL") > 0) then {true} else {false}, //--- Fast Travel

true, //--- Gear

false, //--- Build Ammo

false, //--- EASA

false, //--- Supply Paradrop

false, //--- Artillery Ammo

false //--- IR Smoke

]];

missionNamespace setVariable [Format["WFBE_C_UPGRADES_%1_COSTS", _side], [

[[1300,4500]], //--- Barracks

[[3500,8000]], //--- Light

[[2500,5000],[11000,20000]], //--- Heavy

[[6000,10000],[25000,50000]], //--- Air

[[1500,7000],[2500,10000],[3500,22000]], //--- Paratroopers

[[2000,5600]], //--- UAV

[[2500,12500],[5000,27500],[15000,50000],[30000,100000]], //--- Supply

[[500,2000],[1500,4000],[2500,7500]], //--- Respawn Range

[[1000,4000]], //--- Airlift

[[4500,14000]], //--- Custom Flares

[[1200,3500],[1800,4400],[3500,9000]], //--- Artillery Time

[[50000,250000]], //--- ICBM

[[1500,5000]], //--- Fast Travel

[[500,2500]], //--- Gear

[[750,2250]], //--- Build Ammo

[[4500,35000]], //--- EASA

[[2000,10000]], //--- Supply Paradrop

[[2500,5000],[3500,10000],[4500,15000]], //--- Artillery Ammo

[[5000,25000]] //--- IR Smoke

]];

missionNamespace setVariable [Format["WFBE_C_UPGRADES_%1_LEVELS", _side], [

1, //--- Barracks

1, //--- Light

2, //--- Heavy

2, //--- Air

3, //--- Paratroopers

1, //--- UAV

4, //--- Supply

3, //--- Respawn Range

1, //--- Airlift

1, //--- Custom Flares

3, //--- Artillery Time

1, //--- ICBM

1, //--- Fast Travel

1, //--- Gear

1, //--- Build Ammo

1, //--- EASA

1, //--- Supply Paradrop

3, //--- Artillery Ammo

1 //--- IR Smoke

]];

missionNamespace setVariable [Format["WFBE_C_UPGRADES_%1_LINKS", _side], [

[[]], //--- Barracks

[[WFBE_UP_BARRACKS,1]], //--- Light

[[WFBE_UP_LIGHT,1],[WFBE_UP_LIGHT,1]], //--- Heavy

[[WFBE_UP_HEAVY,1],[WFBE_UP_HEAVY,1]], //--- Air

[

[[WFBE_UP_BARRACKS,1],[WFBE_UP_AIR,1],[WFBE_UP_GEAR,1]],

[[WFBE_UP_BARRACKS,1],[WFBE_UP_AIR,1],[WFBE_UP_GEAR,1]],

[[WFBE_UP_BARRACKS,1],[WFBE_UP_AIR,1],[WFBE_UP_GEAR,1]]

], //--- Paratroopers

[[WFBE_UP_AIR,2]], //--- UAV

[[WFBE_UP_LIGHT,1],[WFBE_UP_LIGHT,1],[WFBE_UP_LIGHT,1],[WFBE_UP_LIGHT,1]], //--- Supply

[[WFBE_UP_LIGHT,1],[WFBE_UP_LIGHT,1],[WFBE_UP_LIGHT,1]], //--- Respawn Range

[[]], //--- Airlift

[[]], //--- Custom Flares

[

[[WFBE_UP_BARRACKS,1]],

[[WFBE_UP_LIGHT,1]],

[[WFBE_UP_LIGHT,1]]

], //--- Artillery Time

[[]], //--- ICBM

[

[[WFBE_UP_LIGHT,1],[WFBE_UP_SUPPLYRATE,1]]

], //--- Fast Travel

[[WFBE_UP_BARRACKS,1]], //--- Gear

[[]], //--- Build Ammo

[[]], //--- EASA

[[]], //--- Supply Paradrop

[

[[WFBE_UP_GEAR,1],[WFBE_UP_HEAVY,1]],

[[WFBE_UP_GEAR,1],[WFBE_UP_HEAVY,1]],

[[WFBE_UP_GEAR,1],[WFBE_UP_HEAVY,1]]

], //--- Artillery Ammo

[[]] //--- IR Smoke

]];

missionNamespace setVariable [Format["WFBE_C_UPGRADES_%1_TIMES", _side], [

[60], //--- Barracks

[70], //--- Light

[450,900], //--- Heavy

[600,900], //--- Air

[35,55,75], //--- Paratroopers

[60], //--- UAV

[60,120,180,240], //--- Supply

[30,60,90], //--- Respawn Range

[45], //--- Airlift

[100], //--- Custom Flares

[40,80,120], //--- Artillery Time

[300], //--- ICBM

[60], //--- Fast Travel

[25,50,75], //--- Gear

[40], //--- Build Ammo

[90], //--- EASA

[50], //--- Supply Paradrop

[60,120,180], //--- Artillery Ammo

[120] //--- IR Smoke

]];

//todo, on commander missing link checkup, skip disabled upgrades.

missionNamespace setVariable [Format["WFBE_C_UPGRADES_%1_AI_ORDER", _side], [

[WFBE_UP_BARRACKS,1],

[WFBE_UP_GEAR,1],

[WFBE_UP_LIGHT,1],

[WFBE_UP_SUPPLYRATE,1],

[WFBE_UP_HEAVY,1],

[WFBE_UP_RESPAWNRANGE,1],

[WFBE_UP_SUPPLYRATE,2],

[WFBE_UP_HEAVY,2],

[WFBE_UP_ARTYTIMEOUT,1],

[WFBE_UP_SUPPLYRATE,3],

[WFBE_UP_ARTYTIMEOUT,2],

[WFBE_UP_ARTYTIMEOUT,3],

[WFBE_UP_RESPAWNRANGE,2],

[WFBE_UP_AIR,1],

[WFBE_UP_RESPAWNRANGE,3],

[WFBE_UP_PARATROOPERS,1],

[WFBE_UP_AIR,2],

[WFBE_UP_PARATROOPERS,2],

[WFBE_UP_PARATROOPERS,3]

]];

//--- Check potential missing definition.

(_side) Call Compile preprocessFileLineNumbers "Common\Config\Core_Upgrades\Check_Upgrades.sqf";

Thx again man!

i edited my stringtable.xml with some missing german translations, maybe you have use for them.

<Key ID="STR_WF_Repair_Camp_IsAlive">

<English>Information:\n\n The camp is already repaired.</English>

<French>Information:\n\n Le camp est déjà réparé.</French>

<German>Information:\n\n Das camp ist bereits repariert.</German>

<Russian>Information:\n\n The camp is already repaired.</Russian>

<Italian>Information:\n\n The camp is already repaired.</Italian>

</Key>

<Key ID="STR_WF_Repair_Camp_IsBeingRepaired">

<English>Information:\n\n The camp is being repaired.</English>

<French>Information:\n\n Le camp est en cours de réparation.</French>

<German>Information:\n\n Das camp wird momentan repariert.</German>

<Russian>Information:\n\n The camp is being repaired.</Russian>

<Italian>Information:\n\n The camp is being repaired.</Italian>

</Key>

<Key ID="STR_WF_Repair_Camp_IsRepaired">

<English>Information:\n\n The camp is repaired.</English>

<French>Information:\n\n Le camp est réparé.</French>

<German>Information:\n\n Das camp ist nun repariert.</German>

<Russian>Information:\n\n The camp is repaired.</Russian>

<Italian>Information:\n\n The camp is repaired.</Italian>

</Key>

<Key ID="STR_WF_Repair_Camp_None">

<English>Information:\n\n There is no nearby camps which can be repaired.</English>

<French>Information:\n\n Aucun camp à proximité ne peut être réparé.</French>

<German>Information:\n\n Es befinden sich keine camps zum reparieren in direkter Umgebung.</German>

<Russian>Information:\n\n There is no nearby camps which can be repaired.</Russian>

<Italian>Information:\n\n There is no nearby camps which can be repaired.</Italian>

</Key>

<Key ID="STR_WF_Repair_Camp_NoFunds">

<English>Information:\n\n You are currently missing $%1. in order to repair a camp.</English>

<French>Information:\n\n Il vous manque actuellement $%1. afin de réparer le camp.</French>

<German>Information:\n\n Momentan fehlen noch $%1. um das camp reparieren zu können.</German>

<Russian>Information:\n\n You are currently missing $%1. in order to repair a camp.</Russian>

<Italian>Information:\n\n You are currently missing $%1. in order to repair a camp.</Italian>

</Key>

<Key ID="STR_WF_Repair_Camp_None_Dead">

<English>Information:\n\n None of the nearby camps are destroyed.</English>

<French>Information:\n\n Aucun camp à proximité n'est détruit.</French>

<German>Information:\n\n Keines der camps in direkter Umgebung ist zerstört.</German>

<Russian>Information:\n\n None of the nearby camps are destroyed.</Russian>

<Italian>Information:\n\n None of the nearby camps are destroyed.</Italian>

</Key>

<Key ID="STR_WF_Repair_MHQ">

<English>Repair (MHQ)</English>

<French>Réparation (PC)</French>

<German>Reparatur (MHQ)</German>

<Russian>ВоÑÑтановить (КШМ)</Russian>

<Italian>Riparazione (MHQ)</Italian>

</Key>

<Key ID="STR_WF_Repair_TruckIsDeadOrTooFar">

<English>Information:\n\n The repair truck is either too far or destroyed.</English>

<French>Information:\n\n Le camion de réparation est trop loin de la cible ou à été détruit.</French>

<German>Information:\n\n Der Reparatur LKW ist entweder zu weit entfernt oder zerstört.</German>

<Russian>Information:\n\n The repair truck is either too far or destroyed.</Russian>

<Italian>Information:\n\n The repair truck is either too far or destroyed.</Italian>

</Key>

regards

scars09

Share this post


Link to post
Share on other sites

v2_073

with modACE = true; in init

gave an error in :-

common\config\core\Core_ACE_RU.sqf

line 67 was [_c select _z,_i select _z] Call SetNamespace;

should it not be [_c select _z,_i select _z] Call GetNamespace; ?

If so hope this helps

Never mind when its changed it gives a new error on line 54 :)

This worked though :-

copied this from the Core_ACE_US.sqf into the Core_ACE_RU.sqf

for '_z' from 0 to (count _c)-1 do {

if (isClass (configFile >> 'CfgVehicles' >> (_c select _z))) then {

_get = missionNamespace getVariable (_c select _z);

if (isNil '_get') then {

if ((_i select _z) select 0 == '') then {(_i select _z) set [0, [_c select _z,'displayName'] Call GetConfigInfo]};

if (typeName ((_i select _z) select 4) == 'SCALAR') then {

if (((_i select _z) select 4) == -2) then {

_ret = (_c select _z) Call Compile preprocessFile "Common\Functions\Common_GetConfigVehicleCrewSlot.sqf";

(_i select _z) set [4, _ret select 0];

(_i select _z) set [9, _ret select 1];

};

};

if (WF_Debug) then {(_i select _z) set [3,1]};

_p = if ((_c select _z) isKindOf 'Man') then {'portrait'} else {'picture'};

(_i select _z) set [1, [_c select _z,_p] Call GetConfigInfo];

missionNamespace setVariable [_c select _z, _i select _z];

---------- Post added at 06:56 AM ---------- Previous post was at 06:33 AM ----------

Still isnt showing the ACE weapons though trying to figure out why :(

Edited by BL1P

Share this post


Link to post
Share on other sites

Benny just wanted to pop in and say thanks for your hard work! I've been closely following all the changes you've got coming and I'm most excited about seeing HC work in your next version! I think HC is going to increase the pure awesomeness of Warfare even more than now. Thanks Benny!

Share this post


Link to post
Share on other sites

Hello Benny.

I have been trying to get ACRE radios to work with the Buy Gear section of the menus but this problem keeps coming up :-

=========================

Taken from this page :-

http://tracker.idi-systems.com/projects/acre/wiki/Class_Names_and_API#Radio-Type-vs-Radio-ID

=========================

Radio Type vs. Radio ID

Inside of the ACRE engine, there is one major thing that occurs. Due to the need to have multiple radio's of the same type in the inventory, as well as being able to save radio states when they are dropped by any person, or on their body, these states need to be tracked uniquely somehow. This is done by ACRE continuously scanning your inventory and replacing "base radios" with "unique radio IDs". Additionally, these unique IDs are managed by the server only in order to maintain their uniqueness and avoid conflicts. Therefore, the following happens:

1. You spawn into game, and your player has "ACRE_PRC148" in its inventory

2. ACRE detects the "Base radio" in the inventory, deletes it, and requests a new ID for that type from the server

3. Your client receives this new unique ID, and adds a new radio to its inventory - ACRE_PRC148_ID_X, e.g. ACRE_PRC148_ID_4

This means that when performing API operations on a specific radio ID, it is best to make sure that it actually exists, has been propagated to the player, and is currently registered as a radio. The best way to do this, from an API perspective, is to monitor acre_api_fnc_getCurrentRadioList result until you see the desired radios in the list.

Also - this means that any given player wont ever have the item "ACRE_PRC148" during gameplay, they will have a derivative of the radio type with the ID. This is why "isKindOf" and "hasKindOf" have been provided; they search for base radio types against ID types for you, saving you the time of writing the comparison code.

=========================

I can add the Items to the list of buyable things but the Buy Dialog menu its self does not recognize that we already have a radio.

Meaning that if you buy one then go back into the buy menu at any time you always need to re_buy a radio again as the system doesn't recognize you already have a radio.

Do you think you could tell me where to place the isKindOf or the hasKindOf in the Buy gear Menus creation so that they realise that We have an Acre radio in our gear ?

Yours en espérant

BL1P

Edited by BL1P

Share this post


Link to post
Share on other sites
Thx alot Benny, i should have spotted that missing '=' myself, i am getting old obviously.

Seems that this was a major performance killer since i just finished a game with 073 (original not the updated one) without any problems, before it went to a slideshow after a little more then one hour, wich prolly was the time to take a town and get sv up to 60.

Another thing that you might want to look into is that there seems nothing to prevent east and west to start at same position, nice instant action but certainly not intended.

Regarding the ai commander upgrades i played around a little more, but as a matter of fact he doesnt start upgrading at all with the config i edited. I took commander position and started the upgrades myself and switched back to ai commander right after that. AI did start ambulance range 1 and supply 1, but nothing else. With the unedited config he stops after supply 1 as i tried it.

The upgrades seem to work fine for human players, all links show up correct and upgrades can only be done if the needed stuff got researched before. It also shows correctly if an upgrade is at max level and u cant upgrade it anymore then, how it should be. The stuff i set to false is permanently set to 0, in both, parameters.hpp and init_CommonConstants.sqf.

I post the config i edited, maybe u see right away what my problem is.

Thx again man!

i edited my stringtable.xml with some missing german translations, maybe you have use for them.

regards

scars09

I suspect the AI Commander upgrade process to be faulty, The issue that I see is that he'll skip to the next upgrade if the current one cannot be upgraded.

I will correct that behavior.

Thanks for the stringtable btw :)

Hello Benny.

I have been trying to get ACRE radios to work with the Buy Gear section of the menus but this problem keeps coming up :-

=========================

Taken from this page :-

http://tracker.idi-systems.com/projects/acre/wiki/Class_Names_and_API#Radio-Type-vs-Radio-ID

=========================

Radio Type vs. Radio ID

Inside of the ACRE engine, there is one major thing that occurs. Due to the need to have multiple radio's of the same type in the inventory, as well as being able to save radio states when they are dropped by any person, or on their body, these states need to be tracked uniquely somehow. This is done by ACRE continuously scanning your inventory and replacing "base radios" with "unique radio IDs". Additionally, these unique IDs are managed by the server only in order to maintain their uniqueness and avoid conflicts. Therefore, the following happens:

1. You spawn into game, and your player has "ACRE_PRC148" in its inventory

2. ACRE detects the "Base radio" in the inventory, deletes it, and requests a new ID for that type from the server

3. Your client receives this new unique ID, and adds a new radio to its inventory - ACRE_PRC148_ID_X, e.g. ACRE_PRC148_ID_4

This means that when performing API operations on a specific radio ID, it is best to make sure that it actually exists, has been propagated to the player, and is currently registered as a radio. The best way to do this, from an API perspective, is to monitor acre_api_fnc_getCurrentRadioList result until you see the desired radios in the list.

Also - this means that any given player wont ever have the item "ACRE_PRC148" during gameplay, they will have a derivative of the radio type with the ID. This is why "isKindOf" and "hasKindOf" have been provided; they search for base radio types against ID types for you, saving you the time of writing the comparison code.

=========================

I can add the Items to the list of buyable things but the Buy Dialog menu its self does not recognize that we already have a radio.

Meaning that if you buy one then go back into the buy menu at any time you always need to re_buy a radio again as the system doesn't recognize you already have a radio.

Do you think you could tell me where to place the isKindOf or the hasKindOf in the Buy gear Menus creation so that they realise that We have an Acre radio in our gear ?

Yours en espérant

BL1P

Hey,

This is a bit tricky as I have never tried ACRE before.

I'll give some headlight in the Buy Menu still (073).

The target is updated in the buy menu at start and when the target is changed:

//--- Update the available target list.
if (_update_target) then {

The weapons and magazines are returned in that condition.

		_target_weapons = [weapons _target, "weapons"] Call WFBE_CL_FNC_UI_Gear_Sanitize;
		_target_magazines = [magazines _target, "magazines"] Call WFBE_CL_FNC_UI_Gear_Sanitize;

Depending if the ACRE radio is considered as a weapon or as a magazine you will have to browse one or the other.

Note that "WFBE_CL_FNC_UI_Gear_Sanitize" will remove undefined items (weapons/magazines). So you may have to tweak it before with "weapons _target" or "magazines _target".

Share this post


Link to post
Share on other sites

Thanks Benny

The radios are classed the same as an ingame radio or a map etc.

Ie a weapon \ item

Ill need to read how the isKindOf or hasKindOf works as I am not sure where it is placed :)

_target_weapons = [ iskindof weapons _target, "weapons"] Call WFBE_CL_FNC_UI_Gear_Sanitize;

??

Edited by BL1P

Share this post


Link to post
Share on other sites
Thanks Benny

The radios are classed the same as an ingame radio or a map etc.

Ie a weapon \ item

Ill need to read how the isKindOf or hasKindOf works as I am not sure where it is placed :)

_target_weapons = [ iskindof weapons _target, "weapons"] Call WFBE_CL_FNC_UI_Gear_Sanitize;

??

If the classname you wish to check is defined in the gear files then you can do it after the "_target_weapons" else you have to do it before.

Share this post


Link to post
Share on other sites
If the classname you wish to check is defined in the gear files then you can do it after the "_target_weapons" else you have to do it before.

Thanks again Benny Ill keep trying but I think this is beyond my copy \ paste skills :)

Share this post


Link to post
Share on other sites

for '_i' from 0 to count(_template)-1 do {
_current = _template s>
 Error position: <_template)-1 do {
_current = _template s>
 Error Undefined variable in expression: _template
Error in expression <ce = objNull;

Hi Benny any update on this post i posted a few days ago as it comes up on my RPT quite a lot. ;)

Share this post


Link to post
Share on other sites

Hi Benny,

I currently have a problem regarding saving & loading a game. Me and 3 of my friends like to play Warfare BE coop, but since even a small scale warfare session takes a long time to complete we almost never get the chance to complete one unless we save the game and reload later. The problem is that once I do that AI respawn in the middle of nowhere once they die (in the case of chernarus they respawn at Skalisty Island) and then they have to run (or swim!) back to HQ or the action. I know that skalisty Island is where you go temporarily when you die, but for some reason after loading a game you don't get transported to base once the respawn timer is done. Is there something that could be done to fix this issue?

Thanks,

kyfohatl

Edited by kyfohatl

Share this post


Link to post
Share on other sites

I have an idea regarding teamstacking issue in warfare

how about the team that have more people stacking will get less supply and money for it, that will discourage stacking and balance the game in term a of money/supply and manpower.

If the bounty can be adjusted accordingly too, then the team with fewer player can get more money and buy more vehicle to balance the game and still keep the game interesting and challenging for both teams.

Share this post


Link to post
Share on other sites

This is how I believe an autobalance script should work:

Here's how I'm thinking the autobalance script should work, it can't be as simple as evening teams. The learning curve is so difficult on Arma that 1 good player can equate to many more new players, because of this, the formula needs to be a little complex, here's what I'm thinking.

It should consider 2 things, how many players are on each team and what the team score is on both sides (if possible). This is basically what I consider when I'm admin and direct people to join as they enter the game.

For example lets consider this scenario, OPFOR has 10 players and BLUFOR 8. However, the score is OPFOR 200 and BLUFOR 450, clearly BLUFOR has fewer but better players. How can we balance this out?

Lets say for every 80PTS a team has over another team, we can consider it an extra player slot for the loosing team.

So, lets figure out the score imbalance followed by the player score difference

450pts-200pts = 250 point spread

250/80 = 3.125 ~ 3 player score difference (loosing team should have 3 more players then the winning team)

Now the player imbalance

OPFOR 10 players - BLUFOR 8 players = 2 player imbalance

We subtract player difference from player imbalance to determine how many more players the loosing team gets

3player score difference - 2player imbalance = 1 player forced to join OPFOR

With this formula 1 player would be forced to join OPFOR making the teams OPFOR 11 and BLUFOR 8. The next player would be pushed to BLUFOR under the same formula. BLUFOR would essentially be outmanned until the score difference between the teams began to stabilize. If BLUFOR continues to push farther away in score difference OPFOR would continue to get more players.

This formula ensures that a game stays balanced and that one team isn't completely dominating the other. With Arma matches being hours long, most people tend to quit when their team is completely being dominated by the other, this should help in keeping matches balanced and battles epic.

If the point spread is under 80pts the formula can ignore the score and just force the player onto the team with the least players. If the teams are even the formula can force the player onto the team with the lower score.

Having this as a parameter to enable/disable would also be a must for things like League matches

This formula only applies to players who join the server, not players who have already joined and selected a team (no team switching).

Let me know what you think.

Share this post


Link to post
Share on other sites

I like what gunso proposed and I do not like what SpanishSurfer proposed. I think we have to encourage people to make even teams but we do not have to try manually balance the game score. The score difference does not really mean in Warfare mode. A team with the high score can loose the round anytime by loosing MHQ or base structures.

Share this post


Link to post
Share on other sites
Hi Benny any update on this post i posted a few days ago as it comes up on my RPT quite a lot. ;)

Hey (sorry for the delay i was skiing :p),

Do you know when/how it happen?

By any chance, did you touch something in Init_Defenses.sqf ?

Hi Benny,

I currently have a problem regarding saving & loading a game. Me and 3 of my friends like to play Warfare BE coop, but since even a small scale warfare session takes a long time to complete we almost never get the chance to complete one unless we save the game and reload later. The problem is that once I do that AI respawn in the middle of nowhere once they die (in the case of chernarus they respawn at Skalisty Island) and then they have to run (or swim!) back to HQ or the action. I know that skalisty Island is where you go temporarily when you die, but for some reason after loading a game you don't get transported to base once the respawn timer is done. Is there something that could be done to fix this issue?

Thanks,

kyfohatl

Hey,

With the new profileNamespace command there is a new world of opportunities regarding persistent saving/loading, Maybe you will see something soon... :)

This is how I believe an autobalance script should work:

Here's how I'm thinking the autobalance script should work, it can't be as simple as evening teams. The learning curve is so difficult on Arma that 1 good player can equate to many more new players, because of this, the formula needs to be a little complex, here's what I'm thinking.

It should consider 2 things, how many players are on each team and what the team score is on both sides (if possible). This is basically what I consider when I'm admin and direct people to join as they enter the game.

For example lets consider this scenario, OPFOR has 10 players and BLUFOR 8. However, the score is OPFOR 200 and BLUFOR 450, clearly BLUFOR has fewer but better players. How can we balance this out?

Lets say for every 80PTS a team has over another team, we can consider it an extra player slot for the loosing team.

So, lets figure out the score imbalance followed by the player score difference

450pts-200pts = 250 point spread

250/80 = 3.125 ~ 3 player score difference (loosing team should have 3 more players then the winning team)

Now the player imbalance

OPFOR 10 players - BLUFOR 8 players = 2 player imbalance

We subtract player difference from player imbalance to determine how many more players the loosing team gets

3player score difference - 2player imbalance = 1 player forced to join OPFOR

With this formula 1 player would be forced to join OPFOR making the teams OPFOR 11 and BLUFOR 8. The next player would be pushed to BLUFOR under the same formula. BLUFOR would essentially be outmanned until the score difference between the teams began to stabilize. If BLUFOR continues to push farther away in score difference OPFOR would continue to get more players.

This formula ensures that a game stays balanced and that one team isn't completely dominating the other. With Arma matches being hours long, most people tend to quit when their team is completely being dominated by the other, this should help in keeping matches balanced and battles epic.

If the point spread is under 80pts the formula can ignore the score and just force the player onto the team with the least players. If the teams are even the formula can force the player onto the team with the lower score.

Having this as a parameter to enable/disable would also be a must for things like League matches

This formula only applies to players who join the server, not players who have already joined and selected a team (no team switching).

Let me know what you think.

That's not a bad idea, i'll try to work something out.

Autobalancing is probably going to be in... in ArmA III. :cc: Bennnnnnny! See you there. o/

:cool:

Share this post


Link to post
Share on other sites

hey benny, im going to be purchasing the arma 3 alpha package, just wondering if we can expect a arma 3 benny warfare edition anytime soon, it would be awsome!. awsome map and great work btw i apreciate all the hard work that is being put in the map, keep it up!

Share this post


Link to post
Share on other sites
hey benny, im going to be purchasing the arma 3 alpha package, just wondering if we can expect a arma 3 benny warfare edition anytime soon, it would be awsome!. awsome map and great work btw i apreciate all the hard work that is being put in the map, keep it up!

Yep :cool:

I still got to rework the AI tho

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×