Cruzz, what is the time needed for relic to disable the usf cavalry commander while they fix the bug ?
Fixing the issue requires 4 lines of script.
Banning a commander would probably require atleast several dozen lines of coding.
Posts: 1221 | Subs: 41
Cruzz, what is the time needed for relic to disable the usf cavalry commander while they fix the bug ?
Posts: 742 | Subs: 1
Fixing the issue requires 4 lines of script.
Banning a commander would probably require atleast several dozen lines of coding.
Posts: 444
Fixing the issue requires 4 lines of script.
Banning a commander would probably require atleast several dozen lines of coding.
Posts: 1221 | Subs: 41
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"
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
Posts: 17914 | Subs: 8
If they need dozen of lines to disable a commander, its that there code is quite ugly
Posts: 742 | Subs: 1
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.
Posts: 742 | Subs: 1
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.
Posts: 2635 | Subs: 4
Permanently BannedPosts: 4928
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.
Posts: 935
Posts: 1221 | Subs: 41
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.
Posts: 2635 | Subs: 4
Permanently BannedPosts: 1221 | Subs: 41
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
Posts: 1221 | Subs: 41
Posts: 2636 | Subs: 17
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.
Posts: 1221 | Subs: 41
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.
Posts: 1221 | Subs: 41
Posts: 2636 | Subs: 17
aim_time (ready & fire): 0.46875
burst: 0.064453125
rof: 10
cooldown: 0.5
time_reload: pi
accuracy: 0.36
Posts: 1221 | Subs: 41
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
61 | |||||
13 | |||||
106 | |||||
66 | |||||
31 | |||||
12 | |||||
6 | |||||
3 | |||||
3 | |||||
2 |