Flying Drone after Flying SCV is fixed. -_-
Flying Drone after Flying SCV
Forum Index > BW General |
LaStScan
Korea (South)1289 Posts
Flying Drone after Flying SCV is fixed. -_- | ||
Cele
Germany4016 Posts
Flying probes obviously. | ||
[sc1f]eonzerg
Belgium6505 Posts
| ||
tec27
United States3696 Posts
![]() | ||
axtQttv
56 Posts
On August 02 2021 08:30 tec27 wrote: Flying drone is fixed on ShieldBattery already ![]() Good job! | ||
TT1
Canada9990 Posts
but ya regardless, blizz sux | ||
BlueStar
Bulgaria1162 Posts
| ||
fLyiNgDroNe
Belgium3996 Posts
| ||
Crimson)S(hadow
Philippines525 Posts
but my understanding is that it’s super hard to do, (requires near frame perfect timing?) and it only a very tedious one drone at a time. i’d say its useless, unless for scouting in island maps. any race can fend it off with zero difficulty with stack attack or probably even just regular attacking | ||
MeSaber
Sweden1235 Posts
| ||
tec27
United States3696 Posts
On August 03 2021 04:42 MeSaber wrote: I guess this is a different glitch than the old one. That glitch you didnt need to click a mineral as queue, oh and you couldnt control the drone either but it went to where you shift-clicked. It is the same basic underlying cause, the mineral thing is unrelated/unnecessary. The sequence of events between this and the SCV one is the same: 1) Make unit do something that results in the game removing it's collision detection (building a terran building, building on a geyser, etc.) 2) Fill the unit's order buffer 3) Cancel the first action The game then tries to restore the unit's collision detection (which is *also* an order), but sees that the order buffer is full, so that order cannot be queued. The unit is therefore left in that state forever. Blizzard's fix for flying SCV's was very targeted at the specific SCV case, so it doesn't fix the general issue. (But yes, the drone timing is much tighter than the SCV one) | ||
iamke55
United States2806 Posts
| ||
M3t4PhYzX
Poland4165 Posts
On August 02 2021 20:00 fLyiNgDroNe wrote: What? lmao | ||
MeSaber
Sweden1235 Posts
On August 03 2021 06:34 tec27 wrote: It is the same basic underlying cause, the mineral thing is unrelated/unnecessary. The sequence of events between this and the SCV one is the same: 1) Make unit do something that results in the game removing it's collision detection (building a terran building, building on a geyser, etc.) 2) Fill the unit's order buffer 3) Cancel the first action The game then tries to restore the unit's collision detection (which is *also* an order), but sees that the order buffer is full, so that order cannot be queued. The unit is therefore left in that state forever. Blizzard's fix for flying SCV's was very targeted at the specific SCV case, so it doesn't fix the general issue. (But yes, the drone timing is much tighter than the SCV one) Yes but this is another bug than the 1.09 fly drone. Then you didnt need to fill queue-buffer. Just a single queue and a cancel. Same with Templar merge, but the precision on cancel there was actually a thing, not on the extractor though, you could cancel as soon as it started going over gas, i.e you lost control of the drone. Oh and as i said you even lost control of the unit until it reached your queue destination, these bugs remain in bugged state while still having control. Having control of your drone is far superior ![]() Which is why these bugs where you have control and can manipulate the game with it has to be fixed. | ||
Purressure
106 Posts
| ||
shakigami
219 Posts
![]() | ||
oxKnu
1143 Posts
On August 04 2021 04:31 shakigami wrote: btw, is there any other bug/ glitch like this? I think I watched a video on FBH's youtube demonstrate like 10 others glitchs around a year ago ![]() All of them revolve around the same buffer overflow problem, so one programmer that also understands the game and the SC codebase could probably come up with 10 other bugs in one week of testing various scenarios in the game. | ||
tec27
United States3696 Posts
On August 03 2021 21:01 MeSaber wrote: Yes but this is another bug than the 1.09 fly drone. Then you didnt need to fill queue-buffer. Just a single queue and a cancel. Same with Templar merge, but the precision on cancel there was actually a thing, not on the extractor though, you could cancel as soon as it started going over gas, i.e you lost control of the drone. Oh and as i said you even lost control of the unit until it reached your queue destination, these bugs remain in bugged state while still having control. Having control of your drone is far superior ![]() Which is why these bugs where you have control and can manipulate the game with it has to be fixed. Right, I wasn't saying it was the same as the 1.09 bug, I was saying that this bug and the flying SCV one had the same underlying cause. I misunderstood what exactly you meant by "old one", sorry ![]() This particular issue was caused by other fixes Blizzard made during the SC:R timeframe, they weren't possible in 1.16. On August 04 2021 04:52 oxKnu wrote: All of them revolve around the same buffer overflow problem, so one programmer that also understands the game and the SC codebase could probably come up with 10 other bugs in one week of testing various scenarios in the game. The fix on ShieldBattery is quite general and attempts to solve the entire class of bugs, so it likely fixes those other things as well. | ||
MeSaber
Sweden1235 Posts
As i guess you fixed it at the core mechanics of queue buffer class which is why you say you fixed it for everything while blizzard did not, but im intrigued to know how blizz did it as it must be a hacky fix for scv only? | ||
tec27
United States3696 Posts
On August 04 2021 08:20 MeSaber wrote: Out of curiosity do you know how blizz fixed flyingscv without fixing flyingdrone? As i guess you fixed it at the core mechanics of queue buffer class which is why you say you fixed it for everything while blizzard did not, but im intrigued to know how blizz did it as it must be a hacky fix for scv only? It is a very targeted fix for that case, yeah. In pseudocode their fix looks like: if ( So it is basically saying "if the order queue is full and this is a RESET_COLLISION order for an SCV that is currently building, append it anyway". Whereas SB's fix doesn't look at any particular unit state or order, it just reserves space at the end of the order queue for any automatically-queued orders (collision reset, die, etc.) | ||
| ||