IG HWT Bug (and any others)

Generic non-balance topics.
Gorbles
Level 3
Posts: 326
Joined: Mon 29 Sep, 2014 10:28 am

IG HWT Bug (and any others)

Postby Gorbles » Fri 06 Nov, 2015 9:15 am

So as I generally avoid HWT on principle, it's been a long time since I encountered this bug. The most I got out of the recent Blood Pack thread was that it was something to do with lasguns not appearing, which doesn't strike me as the actual issue at all.

From what I remember the HWT squad was neutered wrt. heavy weapons upgrades as an unintended consequence of fixing the all-weapons glitch. I need to know the following:

1. The state of HWT in vanilla and what they can / can't do.
2. The fix applied to them in ELITE - spare no technical details. Paste the XML if you want (or text-dumped RBF, your choice).

Also any other popular bugs affecting Multiplayer at this time would be appreciated. I know of the Steam Invite functionality and can replicate it. I was told about a bug whereby sometimes a player can't right-click for the whole of the match. Any more as bad as these ones? Any replays to show where they happened?

I would seriously appreciate help in this.
User avatar
Nurland
Moderator
Posts: 1343
Joined: Mon 04 Feb, 2013 5:25 pm
Location: Eye of Error
Contact:

Re: IG HWT Bug (and any others)

Postby Nurland » Fri 06 Nov, 2015 10:27 am

Tyrant Guard melee special does 0 damage. Iirc it is due its area of effect set to a point or something. Can't say much of the technical side. Lulgrim, Hakon and/or Windu should be able to help with that though.
#noobcodex
Myrdal
Admin
Posts: 347
Joined: Mon 15 Apr, 2013 1:47 pm

Re: IG HWT Bug (and any others)

Postby Myrdal » Fri 06 Nov, 2015 11:25 am

  1. ig hwt retinue models lack ranged weapons wargear and resort to melee when given an attack order
  2. ig hwt retinue models are given a ranged weapon wargear
    diff
    rbf2json used in diff
Gorbles
Level 3
Posts: 326
Joined: Mon 29 Sep, 2014 10:28 am

Re: IG HWT Bug (and any others)

Postby Gorbles » Fri 06 Nov, 2015 11:27 am

Thanks for the clarification, the melee-attack order is the big thing I was missing. Really appreciate the code, too.
User avatar
Indrid
Moderator
Posts: 898
Joined: Mon 04 Feb, 2013 5:06 pm
Location: London
Contact:

Re: IG HWT Bug (and any others)

Postby Indrid » Fri 06 Nov, 2015 12:36 pm

Tyrant Guard special attack 0 damage bug as mentioned.

Sound bug - user loses sound effects (not music) and game crashes shortly after. Some people never get it and others get it daily. Lots of possible causes have been thrown up and none seem to be concrete fixes. Personally I got it on Win10 and never on WIn7, same system. Can't seem to consistently reproduce.

Unable to give orders bug - sometimes accompanied by being unable to edge-scroll the view also. Usually goes away by itself. Can be worked around by zooming in very close to click on things. Can't seem to consistently reproduce.

Zoanthrope cannot snare transports with units inside (Focused Warp Blast), because it targets the units inside instead. Can't remember how the modders fixed it. This issue also affects various other weapons I think, such as the Falcon's AV weapon.

Commissar Lord has re-breather sound effects on his voice (Death Korps of Krieg DLC) no matter what scheme you are using. I don't know if you have to own the DKoK DLC for it to happen or it happens for everyone. Was a simple sound code fix I think, hakon can give details.

Private lobbies only work the first time you run the game. Otherwise all invites will fail. This is true for invites in general, but affects private lobbies the most.

Not sure if Catachan damage values are considered a data bug in retail, as it's theorised that the models who didn't have weapons were not taken into account when re-calculating after squad size was lowered.

Turrets deal 0 damage to power nodes. No idea what causes it, could be intended.
User avatar
Wise Windu
Moderator
Posts: 1190
Joined: Sat 14 Sep, 2013 2:22 am

Re: IG HWT Bug (and any others)

Postby Wise Windu » Fri 06 Nov, 2015 2:18 pm

Indrid wrote:Zoanthrope cannot snare transports with units inside (Focused Warp Blast), because it targets the units inside instead. Can't remember how the modders fixed it. This issue also affects various other weapons I think, such as the Falcon's AV weapon.
This was fixed by changing the weapon scatter values from:

Code: Select all

scatter: {
| angle: {
| | angle_scatter: 9.0f;
| | fow_angle_multiplier: 1.0f;
| };
| distance: {
| | distance_scatter_max: 10.0f;
| | distance_scatter_offset: 0f;
| | distance_scatter_ratio: 0.2f;
| | fow_distance_multiplier: 1.0f;
| };
| pattern: {
| | burst_pattern_enable: false;
| | delay_bracket_change_chance: 0f;
| | distance_bracket_count_air: 0;
| | distance_bracket_count_ground: 1;
| | pattern_direction_forward: true;
| | randomize_starting_pattern_bracket: true;
| };
| tilt: {
| | max_tilt_angle: 0f;
| | min_tilt_angle: 0f;
| | tilt_max_distance: 0f;
| | tilt_scatter_chance: 0f;
| };
};


to:

Code: Select all

scatter: {
| angle: {
| | angle_scatter: 0f;
| | fow_angle_multiplier: 0f;
| };
| distance: {
| | distance_scatter_max: 0f;
| | distance_scatter_offset: 0f;
| | distance_scatter_ratio: 0f;
| | fow_distance_multiplier: 0f;
| };
| pattern: {
| | burst_pattern_enable: false;
| | delay_bracket_change_chance: 0f;
| | distance_bracket_count_air: 0;
| | distance_bracket_count_ground: 1;
| | pattern_direction_forward: true;
| | randomize_starting_pattern_bracket: true;
| };
| tilt: {
| | max_tilt_angle: 0f;
| | min_tilt_angle: 0f;
| | tilt_max_distance: 0f;
| | tilt_scatter_chance: 0f;
| };
};


It also happens on a lot of other anti vehicle weapons. Probably a lot of other weapons in general, but they aren't significant or noticeable when hitting vehicles.

Indrid wrote:sometimes accompanied by being unable to edge-scroll the view also
Yeah, I've gotten this plenty of times, usually fixed after cycling through units a couple times.
KanKrusha
Level 3
Posts: 201
Joined: Tue 09 Apr, 2013 9:10 am

Re: IG HWT Bug (and any others)

Postby KanKrusha » Fri 06 Nov, 2015 7:07 pm

Hi

The shuriken cannon set up team is lost to player control when exiting a webway gate

There are some AI bugs for skirmish. I think the following are bugs rather than just limited AI:

1. Chaos lord uses kill the weak when in ranged combat, wasting it uselessly. Fix: in attrib\ai_tuning\ai_tuning_info.rbf change tactic_filter to
TacticFilter_UnderMeleeAttack

change this

Code: Select all

ability_tactic_info: {
| $REF: "types\ai\ability_tactic_info";
| ability: "ability\pvp\race_chaos\chaos_lord\csm_damage_aoe_attack";
| tactic_info: {
| | $REF: "types\ai\tactic_info";
| | priority: 75f;
| | tactic_filter: "TacticFilter_InCombatOrHealthLow";
| | tactic_demand: "AITacticDemand_Default";
| | squad_target_filter: "SquadTargetFilter_FirstFriendly_LowHealth";
| | entity_target_filter: "EntityTargetFilter_FirstFriendly_LowHealth";
| | position_target_filter: "";
| | tactic_class_types: {
| | | tactic_Combat: true;
| | | tactic_OnTask: true;
| | | tactic_Moving: true;
| | | tactic_CombatAtTarget: true;
| | | tactic_SniperFast: false;
| | | tactic_SniperStealthy: false;
| | };
| };
| tactic_info_toggle_off: {
| | $REF: "types\ai\tactic_info";
| | priority: -1f;
| | tactic_filter: "";
| | tactic_demand: "";
| | squad_target_filter: "";
| | entity_target_filter: "";
| | position_target_filter: "";
| | tactic_class_types: {
| | | tactic_Combat: true;
| | | tactic_OnTask: true;
| | | tactic_Moving: true;
| | | tactic_CombatAtTarget: true;
| | | tactic_SniperFast: false;
| | | tactic_SniperStealthy: false;
| | };
| };
};


to this

Code: Select all

ability_tactic_info: {
| $REF: "types\ai\ability_tactic_info";
| ability: "ability\pvp\race_chaos\chaos_lord\csm_damage_aoe_attack";
| tactic_info: {
| | $REF: "types\ai\tactic_info";
| | priority: 30f;
| | tactic_filter: "TacticFilter_UnderMeleeAttack";
| | tactic_demand: "AITacticDemand_Artillery";
| | squad_target_filter: "SquadTargetFilter_FirstEnemyNonVehicle";
| | entity_target_filter: "EntityTargetFilter_FirstEnemy";
| | position_target_filter: "PositionTargetFilter_EnemyClumpPosition";
| | tactic_class_types: {
| | | tactic_Combat: true;
| | | tactic_OnTask: false;
| | | tactic_Moving: false;
| | | tactic_CombatAtTarget: true;
| | | tactic_SniperFast: false;
| | | tactic_SniperStealthy: false;
| | };
| };
| tactic_info_toggle_off: {
| | $REF: "types\ai\tactic_info";
| | priority: -1f;
| | tactic_filter: "";
| | tactic_demand: "";
| | squad_target_filter: "";
| | entity_target_filter: "";
| | position_target_filter: "";
| | tactic_class_types: {
| | | tactic_Combat: true;
| | | tactic_OnTask: true;
| | | tactic_Moving: true;
| | | tactic_CombatAtTarget: true;
| | | tactic_SniperFast: false;
| | | tactic_SniperStealthy: false;
| | };
| };
};


2. Likewise Sentinel uses stomp when in ranged combat, wasting it uselessly. I am trying to use some Lua code with a range limit to stop this because the fix for Kill the Weak! doesnt work but not having much success

3. Teleporting heroes teleport on the spot when in melee combat make them very vulnerable. Fix: give the teleport a small minimum range. A better fix would be to add AI Lua code to choose a position with a minumum range

4. AI can't use spore mines because spore mines have no weapons so sit uselessly in base. Fix: set a spore limit of 0 to stop AI building them.

The file is data\simulations\ai\strategy_unit_purchase.ai . Here is code (with Elite units removed). I have limited the otyher units because these are the ones that AI tends to lose too easily.

Code: Select all

function strategy_unit_purchase.init()
   
   print("strategy_unit_purchase.init")
   
   s_unit_purchase_limit = {} -- example {[PBG_GetID(SBP.SM_MARINE)] = 2,...}

   SBP.TYR_SPORE_MINE = PBG_Get("sbps/pvp/race_tyranid/troops/tyr_spore_mines")
   s_unit_purchase_limit[PBG_GetID(SBP.TYR_SPORE_MINE)]=0

   SBP.IG_SENTINEL = PBG_Get("sbps/pvp/race_imperial_guard/vehicles/ig_sentinel")
   s_unit_purchase_limit[PBG_GetID(SBP.IG_SENTINEL)]=1
   
   SBP.IG_GUARDSMEN = PBG_Get("sbps/pvp/race_imperial_guard/troops/ig_guardsmen_squad")
   s_unit_purchase_limit[PBG_GetID(SBP.IG_GUARDSMEN)]=2

   SBP.IG_HWT = PBG_Get("sbps/pvp/race_imperial_guard/troops/ig_heavy_weapon_squad")
   s_unit_purchase_limit[PBG_GetID(SBP.IG_HWT)]=1

   SBP.SM_RHINO = PBG_Get("sbps/pvp/race_marine/vehicles/sm_rhino")
   s_unit_purchase_limit[PBG_GetID(SBP.SM_RHINO)]=1
   
   SBP.CSM_HERETIC = PBG_Get("sbps/pvp/race_chaos/troops/csm_cultist")
   s_unit_purchase_limit[PBG_GetID(SBP.CSM_HERETIC)]=2

   -- stored off so this can be overriden by scar
   s_demand_variance = s_personality.demand_variance
   s_eta_unit_wait_time = s_personality.eta_unit_wait_time
   
end


5. AI is no good at increasing Tier levels. I think this is partly programming as AI uses red as a resource to calculate the demand but I found one error in the code. My fix is annotated with "kk" so can search through the code to look for my change

Code: Select all

File is data\simulations\ai\strategy_tech_purchase.ai

function TechTierUpgradeDemand()

   local ucount = table.getn(s_tech_tier_upgrades)
   aitrace("TechTierUpgradeDemand: Considering "..ucount.." upgrades!" )

   -- is upgrading disabled?
   if (s_components[COMPONENT_BuildResearch] == false) then
      aitrace("BuildResearch Component Disabled!")
      return
   end

   if (cache.tech_tier_level > table.getn(s_tech_tier_upgrades)) then
      aitrace("MaxTechTierRule: Hit the maximum tech level: "..cache.tech_tier_level)
      return
   end
   
   local upgradeRequests = Util_CountTechTierUpgradeRequests()
   aitrace("TechTierUpgradeReq:"..upgradeRequests)
   if (upgradeRequests >= 1) then
      aitrace("Reached tech tier upgrade request limit of: 1")
      return
   end
   
   local res_tasks = Task_CountInGroup( s_selfplayer, TGROUP_ResourceAddOns )
   if (res_tasks > 0) then   
      aitrace("ResourceBuildRule:Only one CapturePointConstruction build task at a time: "..res_tasks)
      return
   end

   dbAssert(cache.tech_tier_level > 0 and cache.tech_tier_level <= table.getn(s_tech_tier_upgrades))
   
   -- determine if we can build these upgrades
   local upgrade = s_tech_tier_upgrades[cache.tech_tier_level]

   if (upgrade and upgrade.pbg) then
      local upgradePBG = upgrade.pbg
         
      local hit_limit_cap = false
      if (UtilPBG_CountTotal( upgradePBG ) > 1) then
         aitrace("HitLimitCap:"..PBG_GetName( upgradePBG ).." Limit: 1, Count:"..counttotal)
         hit_limit_cap = true
      end
         
      if (not hit_limit_cap) then
            
         local numRequested = Task_CountActivePBG( s_selfplayer, upgradePBG, false )
      
         -- extract info about this upgrade, does it match our demands/ strategies
         if (numRequested == 0 and AIProduction_CanNonSquadProduce( s_selfplayer, PITEM_Upgrade, upgradePBG )) then
            local productionETA = GetProductionETA( PITEM_Upgrade, upgradePBG )
            aitrace("UpgradeList:"..tostring(cache.tech_tier_level)..":"..PBG_GetName( upgradePBG ).." ETA:"..productionETA)
         
            if (productionETA < s_eta_production_wait_time) then
               if (upgrade.condition_func==nil or upgrade.condition_func()) then
                  local demandoffset = 0
                  if (SpecialTechBuildingRules) then         -- kk corrected as had wrong function name
                     demandoffset = SpecialTechBuildingRules( upgradePBG )
                     aitrace("DemandOffset:"..demandoffset)
                  end

                  local demandval = AI_RandRange(3,5) + demandoffset
                  aitrace("UpgDemand:"..demandval )
                  
                  -- currently random, will definitely need rules for each upgrade
                  s_techDemand[ upgradePBG ] = {demand=demandval, buildstyle = nil, demand_type = DEMAND_Upgrade }
               else
                  aitrace("--Skipping because 'condition_func()' failed.")
               end
            else
               aitrace("--Skipping because ETA is too long")
            end
         end
      else
         aitrace("CANNOT BUILD TECH-TIER UPGRADE:"..PBG_GetName( structure.pbg ) )
      end
   end   
end


6. AI does not buy upgrades for units due to inadequate demand. Fix: increase initial budget for add ons in default.ai

Here are my values

Code: Select all

   ai_budget:init()
   ai_budget:add( "BUDGET_Units", strategy_unit_purchase.do_purchase, 100, true )
   ai_budget:add( "BUDGET_Tech", strategy_tech_purchase.do_purchase, 55, true, 1 )
   ai_budget:add( "BUDGET_AddOn", strategy_addon_purchase.do_purchase, 75, false,1 )      
   ai_budget:add( "BUDGET_Secure", strategy_defence_purchase.do_purchase, 35, false, 1 )
   ai_budget:add( "BUDGET_ResourceAddOn", strategy_resourcing.do_purchase, 25, false, 1 )         
   ai_budget:add( "BUDGET_PlayerAbility", player_abilities.do_purchase, 5, true )
   ai_budget:add( "BUDGET_SquadAbility", ability_money_cache, 5, true, 1 )
   


Also increase final returned demand in function UpgradeDemandFromRating( upgradePBG ) from file data\simulations\ai\strategy_addon_purchase.ai
My code is a bit complicated for this but simply multiplying the demand by 2 or 3 when returning it would work

Getting into improvements here rather than bug fixes but I also changed in default.ai
k_maxBuildOrderTime = 1 -- changed from 5*60
also special unit priority reduced from 1500 to 150 (special unit priority is a hang over from COH code and doesn't really fit with DOW2)

EDIT - apologies as tis is definitely an improvement rather than bug. When calculating demand to tech up tiers the AI considers red resource, I think this is a hang over from the original beta and is wrong for current game

I have re-written the entire function - code free to use for yourself or whichever mystery person you are talking with.

Code: Select all


File simulation\ai\strategy_tech_purchase.ai

function CalcDemandTechPriorityLevel()
   local curResources = cache.resources
   local resRate = cache.resources_rate
   local tier_level = cache.tech_tier_level
   local min_units = 3 + math.ceil((tier_level+1))   

   -- if we can tech up, we would have started at level 1            -- kk this entire function shortened and simplified
   if (tier_level < 1) then
      return TECHPRIORITY_Low
      elseif (tier_level == 1 and curResources.power >= 125) then
         return TECHPRIORITY_Urgent
      elseif (tier_level == 1 and cache.military_count <= (min_units-1) ) then
         return TECHPRIORITY_Low
      elseif (tier_level == 1 and cache.military_count >= min_units) then
         return TECHPRIORITY_Urgent
      elseif ( cache.military_count  >=  min_units and curResources.power > 125) then
         return TECHPRIORITY_High   
      elseif ( cache.military_count <=4) then
         return TECHPRIORITY_Low
      else return TECHPRIORITY_Med
   end
end
Last edited by KanKrusha on Fri 06 Nov, 2015 10:47 pm, edited 5 times in total.
User avatar
egewithin
Level 5
Posts: 1144
Joined: Mon 26 Jan, 2015 7:08 pm

Re: IG HWT Bug (and any others)

Postby egewithin » Fri 06 Nov, 2015 7:58 pm

Btw, when Sorcerer is down, if you use warp global, warped unit summons to nowhere on the map.

- Once, teleported Avatar to somewhere close to our baseş

- Far before that, teleported our LR to enemy base! Ahahahhaha, can't forget that. :D
KanKrusha
Level 3
Posts: 201
Joined: Tue 09 Apr, 2013 9:10 am

Re: IG HWT Bug (and any others)

Postby KanKrusha » Fri 06 Nov, 2015 9:55 pm

Anyone got the details on the Apothecary weapon re-equip bug? That was a fairly big one.

Ah, found it. Replacing improved medical equipment removes more energy regen (-0.15) than was granted by the upgrade (+0.1)

Change this

Code: Select all

wargear: {
| race: "racebps\space_marines";
| name: 9049418;
| type: "commander_accessory";
| weapons: {
| };
| slot: 1;
| exclusive: true;
| owner_modifiers: {
| };
| on_equip_entity_actions: {
| };
| on_remove_entity_actions: {
| };
| speech: {
| | $REF: "speech\speech";
| | speech_code_3: {
| | | $REF: "types\speech\speech_codes";
| | | codes: {
| | | };
| | };
| };
| quality: "common";
| level: 0;
| unique: false;
| render_models: {
| };
| fx_actions: {
| };
| dropped_by: {
| };
| animation_template: "";
| basic_statistics_strings: {
| };
| bonus_statistics_strings: {
| };
| negative_statistics_strings: {
| };
| on_grant_entity_actions: {
| };
| apply_grant_action_to_all_squads: true;
| ui: {
| | icon_name: "sm_acc_medkit_pack_1";
| | decorator_name: "";
| | combination_decorator: false;
| | replacement_decorator: "";
| | traits: {
| | };
| };
| ignore_level_requirement_when_dropping: false;
| requirements: {
| };
| on_equip_squad_actions: {
| | apply_modifiers_action: {
| | | $REF: "actions\ability\apply_modifiers_action";
| | | duration: 0f;
| | | permanent: false;
| | | modifiers: {
| | | | energy_regen_rate_squad_modifier: {
| | | | | $REF: "modifiers\squad_modifiers\energy_regen_rate_squad_modifier";
| | | | | application_type: "apply_to_squad";
| | | | | exclusive: false;
| | | | | target_type_name: "";
| | | | | usage_type: "addition";
| | | | | value: 0.1f;
| | | | | exclusive_type: "tp_modifier";
| | | | | show_modifier_decorator: true;
| | | | };
| | | | energy_maximum_squad_modifier: {
| | | | | $REF: "modifiers\squad_modifiers\energy_maximum_squad_modifier";
| | | | | application_type: "apply_to_squad";
| | | | | exclusive: false;
| | | | | target_type_name: "";
| | | | | usage_type: "addition";
| | | | | value: 100f;
| | | | | exclusive_type: "tp_modifier";
| | | | | show_modifier_decorator: true;
| | | | };
| | | };
| | };
| };
| on_remove_squad_actions: {
| | apply_modifiers_action: {
| | | $REF: "actions\ability\apply_modifiers_action";
| | | duration: 0f;
| | | permanent: false;
| | | modifiers: {
| | | | energy_maximum_squad_modifier: {
| | | | | $REF: "modifiers\squad_modifiers\energy_maximum_squad_modifier";
| | | | | application_type: "apply_to_squad";
| | | | | exclusive: false;
| | | | | target_type_name: "";
| | | | | usage_type: "addition";
| | | | | value: -100f;
| | | | | exclusive_type: "tp_modifier";
| | | | | show_modifier_decorator: true;
| | | | };
| | | | energy_regen_rate_squad_modifier: {
| | | | | $REF: "modifiers\squad_modifiers\energy_regen_rate_squad_modifier";
| | | | | application_type: "apply_to_squad";
| | | | | exclusive: false;
| | | | | target_type_name: "";
| | | | | usage_type: "addition";
| | | | | value: -0.15f;
| | | | | exclusive_type: "tp_modifier";
| | | | | show_modifier_decorator: true;
| | | | };
| | | };
| | };
| };
| override_drop_entity_model: "";
| squad_wargear_count: 0;
| leader_equip_type: "leader_preferred";
| defence: 0;
| type_consumable: "none";
| slot_item_on_equip_squad_actions: {
| };
| slot_item_on_remove_squad_actions: {
| };
| terminator_armor: false;
| on_equip_buffs: {
| };
| on_take_hit_range: {
| };
| on_take_hit_melee: {
| };
| on_take_hit_melee_buffs: {
| };
| on_take_hit_range_buffs: {
| };
| online_level_render_models: {
| };
| description_strings: {
| };
| force_stance: "dont_care";
| on_grant_player_actions: {
| };
| apply_grant_action_to_all_teammates: false;
| wargear_tag: "untagged";
| can_destroy: true;
| on_take_hit_range_attacker: {
| };
| on_take_hit_melee_attacker: {
| };
| expendable_actions: {
| };
| valid_campaigns: {
| };
| multi_squads: {
| };
| chapter_render_models: {
| };
};



to this

Code: Select all

wargear: {
| race: "racebps\space_marines";
| name: 9049418;
| type: "commander_accessory";
| weapons: {
| };
| slot: 1;
| exclusive: true;
| owner_modifiers: {
| };
| on_equip_entity_actions: {
| };
| on_remove_entity_actions: {
| };
| speech: {
| | $REF: "speech\speech";
| | speech_code_3: {
| | | $REF: "types\speech\speech_codes";
| | | codes: {
| | | };
| | };
| };
| quality: "common";
| level: 0;
| unique: false;
| render_models: {
| };
| fx_actions: {
| };
| dropped_by: {
| };
| animation_template: "";
| basic_statistics_strings: {
| };
| bonus_statistics_strings: {
| };
| negative_statistics_strings: {
| };
| on_grant_entity_actions: {
| };
| apply_grant_action_to_all_squads: true;
| ui: {
| | icon_name: "sm_acc_medkit_pack_1";
| | decorator_name: "";
| | combination_decorator: false;
| | replacement_decorator: "";
| | traits: {
| | };
| };
| ignore_level_requirement_when_dropping: false;
| requirements: {
| };
| on_equip_squad_actions: {
| | apply_modifiers_action: {
| | | $REF: "actions\ability\apply_modifiers_action";
| | | duration: 0f;
| | | permanent: false;
| | | modifiers: {
| | | | energy_regen_rate_squad_modifier: {
| | | | | $REF: "modifiers\squad_modifiers\energy_regen_rate_squad_modifier";
| | | | | application_type: "apply_to_squad";
| | | | | exclusive: false;
| | | | | target_type_name: "";
| | | | | usage_type: "addition";
| | | | | value: 0.1f;
| | | | | exclusive_type: "tp_modifier";
| | | | | show_modifier_decorator: true;
| | | | };
| | | | energy_maximum_squad_modifier: {
| | | | | $REF: "modifiers\squad_modifiers\energy_maximum_squad_modifier";
| | | | | application_type: "apply_to_squad";
| | | | | exclusive: false;
| | | | | target_type_name: "";
| | | | | usage_type: "addition";
| | | | | value: 100f;
| | | | | exclusive_type: "tp_modifier";
| | | | | show_modifier_decorator: true;
| | | | };
| | | };
| | };
| };
| on_remove_squad_actions: {
| | apply_modifiers_action: {
| | | $REF: "actions\ability\apply_modifiers_action";
| | | duration: 0f;
| | | permanent: false;
| | | modifiers: {
| | | | energy_maximum_squad_modifier: {
| | | | | $REF: "modifiers\squad_modifiers\energy_maximum_squad_modifier";
| | | | | application_type: "apply_to_squad";
| | | | | exclusive: false;
| | | | | target_type_name: "";
| | | | | usage_type: "addition";
| | | | | value: -100f;
| | | | | exclusive_type: "tp_modifier";
| | | | | show_modifier_decorator: true;
| | | | };
| | | | energy_regen_rate_squad_modifier: {
| | | | | $REF: "modifiers\squad_modifiers\energy_regen_rate_squad_modifier";
| | | | | application_type: "apply_to_squad";
| | | | | exclusive: false;
| | | | | target_type_name: "";
| | | | | usage_type: "addition";
| | | | | value: -0.1f;
| | | | | exclusive_type: "tp_modifier";
| | | | | show_modifier_decorator: true;
| | | | };
| | | };
| | };
| };
| override_drop_entity_model: "";
| squad_wargear_count: 0;
| leader_equip_type: "leader_preferred";
| defence: 0;
| type_consumable: "none";
| slot_item_on_equip_squad_actions: {
| };
| slot_item_on_remove_squad_actions: {
| };
| terminator_armor: false;
| on_equip_buffs: {
| };
| on_take_hit_range: {
| };
| on_take_hit_melee: {
| };
| on_take_hit_melee_buffs: {
| };
| on_take_hit_range_buffs: {
| };
| online_level_render_models: {
| };
| description_strings: {
| };
| force_stance: "dont_care";
| on_grant_player_actions: {
| };
| apply_grant_action_to_all_teammates: false;
| wargear_tag: "untagged";
| can_destroy: true;
| on_take_hit_range_attacker: {
| };
| on_take_hit_melee_attacker: {
| };
| expendable_actions: {
| };
| valid_campaigns: {
| };
| multi_squads: {
| };
| chapter_render_models: {
| };
};



Ork slugga burna upgrade is supposed to grant 15% increased health but is bugged and only grants 10%

change this

Code: Select all

apply_modifiers_action: {
| $REF: "actions\ability\apply_modifiers_action";
| duration: 0f;
| permanent: false;
| modifiers: {
| | health_maximum_modifier: {
| | | $REF: "modifiers\entity_modifiers\health_maximum_modifier";
| | | application_type: "apply_to_squad";
| | | exclusive: false;
| | | target_type_name: "";
| | | usage_type: "multiplication";
| | | value: 1.1f;
| | | exclusive_type: "tp_modifier";
| | | show_modifier_decorator: true;
| | };
| };
};


to this

Code: Select all

apply_modifiers_action: {
| $REF: "actions\ability\apply_modifiers_action";
| duration: 0f;
| permanent: false;
| modifiers: {
| | health_maximum_modifier: {
| | | $REF: "modifiers\entity_modifiers\health_maximum_modifier";
| | | application_type: "apply_to_squad";
| | | exclusive: false;
| | | target_type_name: "";
| | | usage_type: "multiplication";
| | | value: 1.15f;
| | | exclusive_type: "tp_modifier";
| | | show_modifier_decorator: true;
| | };
| };
};


Minor one: Also I think terminators had the wrong icon when equipping a heavy melee weapon
Gorbles
Level 3
Posts: 326
Joined: Mon 29 Sep, 2014 10:28 am

Re: IG HWT Bug (and any others)

Postby Gorbles » Sat 07 Nov, 2015 12:11 am

Appreciate all the feedback, folks. Very glad to have code detail as well.
User avatar
Black Relic
Level 4
Posts: 846
Joined: Mon 29 Jul, 2013 3:05 am
Location: United States
Contact:

Re: IG HWT Bug (and any others)

Postby Black Relic » Sat 07 Nov, 2015 7:08 am

I dont see it mentioned here.

It's the obs bug. I have no idea how it happens but when you start a match the countdown will reach zero and after a few seconds say the countdown has stopped. A work around iis the observers leaving the lobby and rejoining.

Double clicking on the inquisitors portrait in the hero selection sometimes crashes my game. Idk if anyone else has experienced this.
"...With every strike of his sword, with every word of his speech, does he reaffirm the ideals of our honored master..." -From the Teachings of Roboute Guilliman as laid down in the Apocrypha of Skaros. Space Marines Codex pg. 54
User avatar
Adeptus Noobus
Level 4
Posts: 991
Joined: Sat 15 Feb, 2014 12:47 pm
Contact:

Re: IG HWT Bug (and any others)

Postby Adeptus Noobus » Mon 09 Nov, 2015 1:47 am

I can confirm the right-click bug. Sadly I did not save the replay.
It was on Calderis Refineries bottom lane. The entire lane was off limits for me as I couldn't command my units to either attack or cap or anything else that requires the right mouse button. Moving my army to the center of the map improved the situation a bit, considering I could attack or cap from time to time.

I do not know whether this has to do with the battleservers but the Continue button is not available anymore in multi-player lobbies of any kind.

Sudden synch errors for no apparent reason i.e. nobody disconnected. It forces everybody to Alt-F4 out of the game and restart it.

Hammer of the witches bugs out quite a lot. The animation starts and nothing happens. Sometimes you can immediately cast it again sometimes you can't.
Atlas

Re: IG HWT Bug (and any others)

Postby Atlas » Mon 09 Nov, 2015 5:54 pm

To add to the HotW talk, sometimes you're able to chain them if you cancel the ability at just the right time. I haven't reliably reproduced it yet but I did manage to get 3 in a row once.
User avatar
Adeptus Noobus
Level 4
Posts: 991
Joined: Sat 15 Feb, 2014 12:47 pm
Contact:

Re: IG HWT Bug (and any others)

Postby Adeptus Noobus » Tue 10 Nov, 2015 2:43 am

The Lord General can die but his retinue stays alive (!!!)

Edit: Again, I forgot to save the replay...
Attachments

[The extension jpg has been deactivated and can no longer be displayed.]

KanKrusha
Level 3
Posts: 201
Joined: Tue 09 Apr, 2013 9:10 am

Re: IG HWT Bug (and any others)

Postby KanKrusha » Fri 20 Nov, 2015 5:44 pm

Hi Gorb, probably too late here but there is another important one

When a squad that has been increased in size from max squad size by an upgrade (ie imperial guardsmen) goes through a tyrannid tunnel the squad will lose the non-leader entities back down to original max squad size. This does not happen with eldar webway gates
User avatar
Nurland
Moderator
Posts: 1343
Joined: Mon 04 Feb, 2013 5:25 pm
Location: Eye of Error
Contact:

Re: IG HWT Bug (and any others)

Postby Nurland » Sat 21 Nov, 2015 1:50 pm

It does happen with webway gates as well.
#noobcodex
User avatar
Toilailee
Champion
Posts: 918
Joined: Tue 12 Mar, 2013 8:26 pm

Re: IG HWT Bug (and any others)

Postby Toilailee » Sat 21 Nov, 2015 1:55 pm

Adeptus Noobus wrote:The Lord General can die but his retinue stays alive (!!!)


That's not a bug, only the storm trooper models die before LG. It is a bit silly tho since if you have other retinue members alive when LG dies they can't do anything but stand there and get slaughtered. Altho if you revive LG while they're still alive they will teleport to base with him.
Swift I: You're not a nerd, you're just a very gifted social spastic
KanKrusha
Level 3
Posts: 201
Joined: Tue 09 Apr, 2013 9:10 am

Re: IG HWT Bug (and any others)

Postby KanKrusha » Wed 02 Mar, 2016 8:09 pm

OKay, I have left this way too late because the patch is announced and from looking at the notes it looks like AI changes were out of scope anyway. However, for the record the AI code is actually broken in two places and these minor fixes make a big difference.

These error are major problems for the AI and make it too easily exploitable

First:
File - in the AI files in tactics\tactics.ai
Function - function TacticFilter_ShouldRetaliate(squad)
Bug - Line 19 of the function (line 270 of the file)is supposed to calculate a percent but the denominator is forgotten

Here is the bugged function with a note at the error

Code: Select all

function TacticFilter_ShouldRetaliate(squad)

   if (not TacticFilter_IsBeingAttacked(squad)) then
      return false
   end
   
   local in_capture_task = AISquad_InCaptureTask(squad)
   
   if (not in_capture_task) then
      return true
   end
   
   local sim_squad = AISquad_ConvertToSimSquad(squad)
   if ( sim_squad == nil ) then
      return false
   end

   local capture_progress_remaining = 1 - AISquad_GetCaptureTask_CaptureProgress(squad)
   local squad_health_percentage = Squad_GetHealth(sim_squad)            -- kk this line is incorrect and needs denominator
   
   return capture_progress_remaining > squad_health_percentage
end


Here is the function corrected. I have gone further and made the function better with more parameters

Code: Select all

function TacticFilter_ShouldRetaliate(squad)

   if (not TacticFilter_IsBeingAttacked(squad)) then
      return false
   end
   
   local in_capture_task = AISquad_InCaptureTask(squad)
   
   if (not in_capture_task) then
      return true
   end
   
   local sim_squad = AISquad_ConvertToSimSquad(squad)
   if ( sim_squad == nil ) then
      return false
   end

   local capture_progress_remaining = (1 - AISquad_GetCaptureTask_CaptureProgress(squad))

   local squad_health_percentage = Squad_GetHealth(sim_squad)/Squad_GetHealthMax(sim_squad)   -- kk fixed error here, denominator was not percent
   
   -- kk added lines to stop capping if under melee attack
   if AISquad_IsUnderMeleeAttack(squad) then
      if capture_progress_remaining > 0.15 or squad_health_percentage < 0.85
         then return true
      end
   end

   return capture_progress_remaining > squad_health_percentage      
end


Second
File - in the scar files scar\designerlib.scar
Function - function AutoRetreat_Manager()
Bug - this whole function is a problem. First the function causes retreat of a group rather than a single squad which can result in weird behaviour. Second there is no reference to health so the squad only retreats when it loses squad members. Also the code only counts original members and leaders and not additional squad members in the same way that the Ravener tunnel bug works.

here is the original function. With some annotations. My annotations are marked with kk so they can be found easily

Code: Select all

function AutoRetreat_Manager()
   
   for n = table.getn(_AutoRetreatTable), 1, -1 do
      
      if (SGroup_Count(_AutoRetreatTable[n].group) == 0) then
         table.remove(_AutoRetreatTable, n)
      else
         
         -- see if the squad is pinned...
         if (SGroup_GetCourage(_AutoRetreatTable[n].group) > 0.4) then       -- kk this line is bizarre and seems backwards but does seem to work. Better to use SGroup_IsSuppressed()
            if (_AutoRetreatTable[n].pinnedtime == nil) then
               -- just become pinned
               _AutoRetreatTable[n].pinnedtime = World_GetGameTime()
            elseif ((World_GetGameTime() - _AutoRetreatTable[n].pinnedtime) > _AutoRetreatTable[n].duration) then
               -- been pinned for more than 10 seconds
               AutoRetreat_Retreat(_AutoRetreatTable[n])
               table.remove(_AutoRetreatTable, n)
            else
               -- not 10 seconds yet: do nothing (but still check for dropping to the threshold)
               if (SGroup_TotalMembersCount(_AutoRetreatTable[n].group) <= _AutoRetreatTable[n].threshold) then
                  AutoRetreat_Retreat(_AutoRetreatTable[n])
                  table.remove(_AutoRetreatTable, n)               
               end
            end
         else
            -- not pinned, so ensure the pinned time is blank
            _AutoRetreatTable[n].pinnedtime = nil
            
            -- see if the squad has dropped to the threshold
            if (SGroup_TotalMembersCount(_AutoRetreatTable[n].group) <= _AutoRetreatTable[n].threshold) then
               AutoRetreat_Retreat(_AutoRetreatTable[n])
               table.remove(_AutoRetreatTable, n)               
            end
            
         end
         
      end
      
   end
   
   -- if we removed the last items from the table, remove the manager rule
   if (table.getn(_AutoRetreatTable) == 0) then
      Rule_Remove(AutoRetreat_Manager)
   end
   
end


Now here is what I have done for elite. The changes in these functions result in
i) retreat is done by individual squads
ii) the time for a suppressed squad to retreat is slightly shorter
iii) the retreat function accounts for health as well as squad numbers'
iv) there is a separate threshold for squad leaders

The elite AI also takes in account how many surrounding allies and enemies there are but that was several new functions so i have not included that here.


Code: Select all

function DesignerLib_Init()

   _AutoReinforceTable = {}      -- Auto Reinforce
   _lastknownposcheckticker = 1

   _AutoRetreatTable = {}         -- Auto Retreat

   _AutoChargeTable = {}         -- Auto Charge
   _lastautochargeindex = 1

   _CeasefireTable = {}         -- Ceasefire

   _MarchTable = {}            -- March Territory Forwards

   _AutoTerritoryTable = {}      -- Auto Territory
   _lastautoterritoryindex = 1

   _kk_lastencounterindex = 1            -- kk created a new line here so we can have preserve individual sgroups

   _MobRule_Definitions()

end

-- whole lot of lines between here

function AutoRetreat_AddSGroup(sgroup, dest, threshold)

   if (scartype(dest) == ST_MARKER) then
      dest = Marker_GetPosition(dest)
   end

   if threshold == nil then
      threshold = 0.6         -- kk increased from 0.5 to 0.6
   end


   -- do some type checking
   if (scartype(sgroup) ~= ST_SGROUP) then fatal("AutoRetreat_AddSGroup: SGroupID is invalid") end

   if (SGroup_Count(sgroup) >= 1) then

      -- remove any old references to the SGroup from the table
      for n = table.getn(_AutoRetreatTable), 1, -1 do
         if (_AutoRetreatTable[n].group == sgroup) then
            table.remove(_AutoRetreatTable, n)
         end
      end

   -- add the new group     -- kk changed to make this one squad per group
   for counta = 1, SGroup_Count(sgroup) do
         local size_of_table_plus = table.getn(_AutoRetreatTable) +1
         local sgroup2 = SGroup_Create("new_sgroup"..counta..size_of_table_plus )
         SGroup_Add(sgroup2, SGroup_GetSpawnedSquadAt(sgroup, counta))

         -- kk add a health retreat threshold as well
      local this_squad = SGroup_GetSpawnedSquadAt(sgroup2,1)
      local squad_sbp = Squad_GetBlueprintName( this_squad )


      -- kk take advantage here to set the call for help distance
      Squad_SetCallForHelpDistance(this_squad, 60)

         if healththreshold == nil then
            healththreshold = 0.5

            if (Skirmish_IsHeroSBP( squad_sbp )) then
               healththreshold = 0.33
            end
         end

   table.insert(_AutoRetreatTable, {group = sgroup2, destination = dest, pinnedtime = nil, duration = World_GetRand(5, 8), threshold = (SGroup_TotalMembersCount(sgroup2) * threshold), healththreshold = healththreshold})            -- kk note changed form 6 to 10 secs to 5 to 8
      
   end
      
      -- start up the manager rule if it isn't running already
      if (Rule_Exists(AutoRetreat_Manager) == false) and (table.getn(_AutoRetreatTable) >= 1) then
         Rule_AddInterval(AutoRetreat_Manager, 0.25)            -- kk incr to check each quarter sec
      end
               
            
   end

end

function AutoRetreat_Manager()
   local randfraction = (World_GetRand(-5,5))/100

   for n = table.getn(_AutoRetreatTable), 1, -1 do

      if (SGroup_Count(_AutoRetreatTable[n].group) == 0) then
         table.remove(_AutoRetreatTable, n)
      else
            --kk some more lines to modify by conditions
            local this_squad = SGroup_GetSpawnedSquadAt(_AutoRetreatTable[n].group,1)      
               -- kk note this works because i changed AutoRetreat_AddSGroup(sgroup, dest, threshold) to use only single squad sgroups      
            
            local retreatmodifier = 1
            
            local last_attackers = Squad_GetLastAttackers(this_squad, 5)
            local nearest_attacker = SGroup_GetSpawnedSquadAt(last_attackers, 1)
         
            if Squad_IsDoingAbility(nearest_attacker,abil_pvp_sm_melee_resistance_aura ) and      -- kk i am not sure this function works but it causes not bugs   
               not ( Squad_IsDoingAbility(this_squad, abil_pvp_sm_melee_resistance_aura))  then
                  retreatmodifier = retreatmodifier *2
            elseif Squad_IsDoingAbility(this_squad, abil_pvp_sm_melee_resistance_aura) and
                not (Squad_IsDoingAbility(nearest_attacker, abil_pvp_sm_melee_resistance_aura )) then
                  retreatmodifier = retreatmodifier*0.75
            end
            
            if Squad_GetActiveCommand(this_squad) == SQUADSTATEID_Melee then
               retreatmodifier = retreatmodifier *1.5
            end

            
         -- see if the squad is pinned...
         if (Squad_IsSuppressed(this_squad)) then      -- kk fixed error here originally was wrong with courage

            if (_AutoRetreatTable[n].pinnedtime == nil) then
               -- just become pinned
               _AutoRetreatTable[n].pinnedtime = World_GetGameTime()
            elseif ((World_GetGameTime() - _AutoRetreatTable[n].pinnedtime) > _AutoRetreatTable[n].duration) then
               -- been pinned for more than 10 seconds
               AutoRetreat_Retreat(_AutoRetreatTable[n])
               table.remove(_AutoRetreatTable, n)
            else
               -- not 10 seconds yet: do nothing (but still check for dropping to the threshold)
               if (SGroup_TotalMembersCount(_AutoRetreatTable[n].group) <= math.floor(math.max(0.6*Squad_GetMax(this_squad), AutoRetreatTable[n].threshold)*retreatmodifier*1.3))
               or (Squad_GetHealth(this_squad)/Squad_GetHealthMax(this_squad) <= math.max(0.55,  (_AutoRetreatTable[n].healththreshold*retreatmodifier + 0.15 + randfraction)))
               then
                  AutoRetreat_Retreat(_AutoRetreatTable[n])
                  table.remove(_AutoRetreatTable, n)
               end

            end
         else
            -- not pinned, so ensure the pinned time is blank
            _AutoRetreatTable[n].pinnedtime = nil

            -- see if the squad has dropped to the threshold
            if (SGroup_TotalMembersCount(_AutoRetreatTable[n].group) <= math.floor(math.max(0.3*Squad_GetMax(this_squad), _AutoRetreatTable[n].threshold*retreatmodifier)))
               or (Squad_GetHealth(this_squad)/Squad_GetHealthMax(this_squad) <= math.max(0.3,(_AutoRetreatTable[n].healththreshold*retreatmodifier + randfraction)))
             then
               AutoRetreat_Retreat(_AutoRetreatTable[n])
               table.remove(_AutoRetreatTable, n)
            end


         end

      end

   end

   -- if we removed the last items from the table, remove the manager rule
   if (table.getn(_AutoRetreatTable) == 0) then
      Rule_Remove(AutoRetreat_Manager)

   end

end
User avatar
HARRYY
Level 2
Posts: 141
Joined: Sat 25 Jan, 2014 3:17 pm

Re: IG HWT Bug (and any others)

Postby HARRYY » Wed 02 Mar, 2016 8:13 pm

dude,thats wonderful!!!

can u compile all your fixes and POST it over there at their Forums, so they feel more pressure to implement this? Ist obvious, they have ressource - which is different from what we thought: THERE WILL BE NOTHING AT FKUCKING ALL....
put some pressure on them, posting possible fixes!!!! They and only react.
Gorbles
Level 3
Posts: 326
Joined: Mon 29 Sep, 2014 10:28 am

Re: IG HWT Bug (and any others)

Postby Gorbles » Thu 03 Mar, 2016 9:18 am

harrysonn wrote:dude,thats wonderful!!!

can u compile all your fixes and POST it over there at their Forums, so they feel more pressure to implement this? Ist obvious, they have ressource - which is different from what we thought: THERE WILL BE NOTHING AT FKUCKING ALL....
put some pressure on them, posting possible fixes!!!! They and only react.

Just because they made some fixes, doesn't mean they have further resources.

Based on the amount of bugs people have reported, vs. the amount that have managed to be fixed, shows that they evidently have limited resources (which makes sense given the age of the game).
User avatar
Adeptus Noobus
Level 4
Posts: 991
Joined: Sat 15 Feb, 2014 12:47 pm
Contact:

Re: IG HWT Bug (and any others)

Postby Adeptus Noobus » Thu 03 Mar, 2016 10:01 am

Gorb wrote:
harrysonn wrote:dude,thats wonderful!!!

can u compile all your fixes and POST it over there at their Forums, so they feel more pressure to implement this? Ist obvious, they have ressource - which is different from what we thought: THERE WILL BE NOTHING AT FKUCKING ALL....
put some pressure on them, posting possible fixes!!!! They and only react.

Just because they made some fixes, doesn't mean they have further resources.

Based on the amount of bugs people have reported, vs. the amount that have managed to be fixed, shows that they evidently have limited resources (which makes sense given the age of the game).

Since quite a few things have been fixed/improved (not talking balance here) in the ELITE Mod, would it be too much to ask to just copy+paste it into the vanilla version, click "compile best game 2016" and then upload to intarwebz? Apparently there is at least one person sitting at his desk, programming stuff to give us the Necron Lord after all. He probably wouldn't mind to make the documented changes, posted here.

P.S: Don't mind the sarcasm.
Gorbles
Level 3
Posts: 326
Joined: Mon 29 Sep, 2014 10:28 am

Re: IG HWT Bug (and any others)

Postby Gorbles » Thu 03 Mar, 2016 10:21 am

Hey, no, sorry, your suggestion makes sense, but spamming it all over the official forums when their team already read all available DoW fansites isn't going to help much of anything.

I've already passed this thread onto them directly, you see (way back when).

As for the programming required for the Necron Overlord, that at least guarantees fiscal return for man-hours spent. As much as we'd like it to be, post-release support for an expansion released half a decade ago isn't a charity.

Return to “Community General Discussion”



Who is online

Users browsing this forum: No registered users and 74 guests