Cruzz's The More You Know

Jump back to quoted post28 Jun 2016, 09:18 AMBlalord

Cruzz, what is the time needed for relic to disable the usf cavalry commander while they fix the bug ?

Jump back to quoted post28 Jun 2016, 09:49 AMCruzz

Fixing the issue requires 4 lines of script.

Banning a commander would probably require atleast several dozen lines of coding.

Jump back to quoted post28 Jun 2016, 09:49 AMCruzz

Fixing the issue requires 4 lines of script.

Banning a commander would probably require atleast several dozen lines of coding.

If they need dozen of lines to disable a commander, its that there code is quite ugly

                                    "$REF": "action\\change_target_action.lua",
                                    "actions": [ (CURRENT ABILITY BUFFS HERE)],
				    "change_target_type": "entities"

Jump back to quoted post28 Jun 2016, 09:57 AMImSkemo

dont have to disable commander just replace the ability with some thing else till they fix it, ( like M1919) or some recon calling or something, till its fixed.. that would be even simpler and would stop this BS

Jump back to quoted post28 Jun 2016, 09:53 AMBlalord

If they need dozen of lines to disable a commander, its that there code is quite ugly

Jump back to quoted post28 Jun 2016, 10:41 AMKatitof

As someone who experiences this kind of issues first hand, removing an item from the shop offer is easy, removing it from the drop tables MAY be easy.
Removing/hiding it from players inventory, keeping track who had it and who didn't and then reimbursing the item is a crapload of effort from developers, sys admins AND QA as it requires separate test build, separate patch, server restarts, testing everything etc.

Long story short: If its not a blocker issue, it can be let there until much easier to prepare hotfix arrives.

Jump back to quoted post28 Jun 2016, 10:14 AMCruzz

That makes no sense. They'd have to code in disabling commanders, as well as UI elements for telling players that commanders are banned. It'll definitely be more complex than the amazing fix to Combined Arms which will be more or less:

Code

                                    "$REF": "action\\change_target_action.lua",
                                    "actions": [ (CURRENT ABILITY BUFFS HERE)],
				    "change_target_type": "entities"

It takes more scripting to change abilities than it takes to fix the problem with combined arms.

I don't see why people think this is some amazingly difficult issue, Relic just forgot to apply the same changes they've made to all the other USF timed buffs so far, to Combined Arms.

Jump back to quoted post28 Jun 2016, 07:06 AMCruzz

If you start a game on south Semois (just chosen for the mostly flat area), spawn a unit and command it to attack ground like 30 meters in front of one of the stone walls, rounds will occasionally hit the stone wall even though it's clearly outside of the scatter area. Either the physics system is bugging out, or there's some minor height variation added to rounds for cinematic effect or whatever. Either way it clearly happens, most of the lucky shot from across the map videos prove that as well.

Jump back to quoted post29 Jun 2016, 08:14 AMsome one

Q to Cruzz .
Relic says that they change something in vet of flame halftrack.
So what is actual veterancy of flame ostheer halftrack.

I know what part you're talking about and I believe that's related to territory height differences.

SQUAD: assault_engineer_squad_mp
assault_engineer_mp                   Target Size: 1   Sight: 35
   UPGRADE: assault_engineer_flamethrower
     1: assault_engineer_flamethrower  5.07    5.07    5.07
        DMG: 16 Range: 0-20 Pen: 2.5 Delay: 2s Burst shots: 1
        2.0: 16    2.0: 16    2.0: 16                  
        range 10.0: x: 0.5, y: 6.2, range 20.0: x: 1, y: 6.2
   DEFAULT
     1: engineer_m3_grease_gun_mp   14.66    1.32    0.29     10.16    0.93    0.32 x4
        DMG: 4 Range: 0-35 Pen: 1.0 Delay: 0.5-3.6s Burst shots: 12-3
SQUAD: assault_engineer_squad_mp VET 3
assault_engineer_mp                Target Size: 0.71   Sight: 35
   UPGRADE: assault_engineer_flamethrower
     1: assault_engineer_flamethrower    5.64    5.64    5.64
        DMG: 16 Range: 0-20 Pen: 2.5 Delay: 1.6s Burst shots: 1
        2.0: 16    2.0: 16    2.0: 16                  
        range 10.0: x: 0.5, y: 6.2, range 20.0: x: 1, y: 6.2
   DEFAULT
     1: engineer_m3_grease_gun_mp   21.65    2.09    0.49     14.58    1.38     0.5 x4
        DMG: 4 Range: 0-35 Pen: 1.0 Delay: 0.4-2.8s Burst shots: 12-3

Jump back to quoted post2 Jul 2016, 10:57 AMCruzz

http://pastebin.com/1RMUDU3q

Finally got around to testing how burst values work, and as usual I had gotten it wrong. Rounds to next integer for the rof*duration calculation. And it's not a 1+rof*duration, just rof*duration.

Jump back to quoted post2 Jul 2016, 11:15 AMMr.Smith

You mean number_of_bullets = ceiling(rof*duration) ?

That should be almost equivalent to 1 + floor(rof*duration), except for the cases where rof and duration are perfectly aligned.

aim_time (ready & fire): 0.46875
burst: 0.064453125
rof: 10
cooldown: 0.5
time_reload: pi
accuracy: 0.36

Jump back to quoted post6 Jul 2016, 16:39 PMMr.Smith

I was running my parser/calculator thing for Panzergrenadiers. If I am not mistaken, at max-range (35) the moving DPS of PGrens should be 2.28, which means it overtakes the stationary DPS of PGrens (since cooldown is massively decreased).

To help us debug, I get the following values for range/moving dependent parameters at range 35 and moving:

Code

aim_time (ready & fire): 0.46875
burst: 0.064453125
rof: 10
cooldown: 0.5
time_reload: pi
accuracy: 0.36