|
On January 25 2017 08:01 Freakling wrote:Show nested quote +On January 25 2017 05:35 imp42 wrote:On January 25 2017 04:34 Freakling wrote:On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Calling this a map-specific bug is all fine and dandy, unless you are actually a map maker who needs to manually test all critical spots on a map to avoid this and sometimes change terrain in ways that are not beneficial to the overall concept ot map balance to change these kinds of bugs. Another of these, and far more frequent, ones are workers just not mining properly (and in a much broader sense units just taking weird and unpredictable paths around a map sometimes, with all kinds of unwanted implications for how the map actually plays out). Calling these things "map specific bugs" is really missing the point. It is literally impossible to fix all of these in any given map, and doing so adds hours of (very monotonous and frustrating) work to making a map and usually requires making significant changes to the map, which may end up causing new issues of their own. So it would be best to fix the underlying reason, being that BW the path-finding algorithm is a giant mess that barely works most of the time and completely fails some of the time (there is a blog post by one of the original developers of the game linked somewhere here on TL.net, just search the forum). So basically the pathfinding algorithm would need to be fixed. And this is where some people will probably cry out, because, of course, how unit pathing works is a huge part of what actually makes BW the game it is (and replacing its bumper car mechanics with something like SC2's fluid simulation yields very undesirable results for balance and gameplay). So what would be a good change? Having a terrain editor that could calculate unit paths in real time without having to enter a game would be good, of course. It also seems like BW actually compiles a kind of general pathing map of a map from the terrain parameters at game start, which is what actually determines the parts units take on every part of the map (on a macroscopic scale at least) and is the cause for the the above mentioned issues. My analysis may not be 100% spot on, I may interpret the evidence wrong, but there are certain facts that can be observed consistently and lead me to this conclusion: - any change of relevant terrain parameters (such as terrain level, walkability or whether a tile is normal terrain or belongs to a doodad of one kind or another) at any part of a map can cause the path units take at any other point of the map.
- most significantly, both the unit stack stuck (aka black hole) bug as well as miner pathing bugs are known to regularly (and practically randomly) appear this way, and they can be fixed by "random" terain changes as well (obviously this can be a tedious process of trial and error...).
- I also made a map once which was basically a giant labyrinth of paths. This map used to crash the game upon game-start, giving me an error message that said something along the lines of "could not compute pathing". Unfortunately I do not have that map any more. I have another, similar one, but all that one does is crash without any error readout (might also have something to do with running the newer English BW distribution that runs without game CD by default on a Linux system as opposed to the classic German version on an old windows PC, which gave me that error message...), so I cannot tell any more what exactly it said.
Anyway, making that pre-computed pathfinding information part of the map file instead of generating it dynamically at game start would potentially allow it to be accessed and edited via a map editor, allowing a map maker to smooth out at least the worst kinks manually (as a by-effect it would probably also reduce map loading time, although on modern machine the difference would probably be negligible anyways). When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp. regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually. Whoever tscmoo is made claims without any knowledge of the matter. All map protection (i.e. corruption) does is to remove or change (to varying degrees) those data parts of the map file that are needed by the editor, but not by the game (like doodad information [the game only knows tiles and sprites] and most importantly isometric terrain information [the game only uses the resulting tile matrix]). As long as the tile data if the map is not changed (which would actually crash or at least visibly corrupt the map), nothing changes path-finding-wise, as that is solely dependent on tile properties. Show nested quote +On January 25 2017 06:02 ProMeTheus112 wrote:oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say A 5% single-saturation difference in, for example, a ZvZ can easily amount to a pair of lings or two less produced per minute (or even more). That is not negligible. In fact, that is significantly imbalanced. If you need an example for this in practice, just look at (4)Neo Jade 2.0. Show nested quote +The black hole thing is crazy bad if it happens but it is so rare!
I can't remember having it in one of my games, or not too bad. I can't remember seeing it in a tourney game or smtg. Must have happened though?^^ Not as rare as you may think. It may not always be apparent, as the right preconditions (units overlapping on tiles with specific properties) need to be met first, which may not occur in a game. However, if a main ramp is affected, like on (4)Dante's Peak, which is notorious for having multiple instances of this bug, that means big trouble (things like Lurkers morphing on the ramp can easily trigger the bug). Units spawning inside or outside of walls can be a pretty huge imbalance in some case. For example when Terran players need to compromise their natural wallin by lifting their racks to let marines in (an then not being able to land it fast enough to block the following stream of Lings. Games have actually been lost that way. At the very least it makes maps very positionally imbalanced for Terran. On the other hand we have nice little plays as the Pylon Dragoon trap, for example, that rely on the predictable spawning position. However, this is so rarely used that it would not fundamentally change the game to not have it...
I don't think spawn imbalance is necessarily a bad thing. It's forced diversity. How will the player cope with the situation? For example on top right on Hunters as Terran I go 2 rax bio into mech while at 6 o clock I'll go straight mech. I think your desire to force homogenous spawns will only serve to limit that diversity that allows for smart plays and situational decision making.
|
I believe the magic box behavior was put in to allow differenciating behavior for units between keeping formation or effectively all moving to a location instead if they are spread out (and it seems for casting spells with few units @same time), but I really doubt it was foreseen people would use it to make attacks with stacked air units on top of each other like this by using another slow/stuck far away unit. If it was intended I think some blizzard guys would have been using this trick on bnet and it would have been known since the start.
I agree a lot of bw is not a happy accident at all like some people say sometimes. The game is just rly smartly designed down to pretty much all its details. But it has a few rough corners and some unintended things and I think the air stack attacks is unintended. The way to use it is quite anti-ergonomic. And then it's so strong it becomes kind of the one best way to attack with air units, feels weird the relationship between muta and archon, turrets&canons next to workers (ease of killing workers while avoiding damage), and to lesser extent marines and goons (I'm not gonna say marines are too weak vs mutas lol but goons don't get that much opportunity to shoot at them since the mutas can all move & attack together, sustained dmg is what goons need to fight mutas goons which don't have that much mobility mutas being small 50% damage received..), and ofc hydras but I guess that was never rly played vs mutas even before?..
its not rly trivial removing this exploit I guess (?) so I think mutas => medium ^^^^ hydras deal more dmg, goliath&turrets, and goons&scouts ;; but thats not bug fix and unfair for ZvT by itself so disregard^^
PS: this doesn't make me want to play Z in 1v1
|
On January 25 2017 08:01 Freakling wrote:Show nested quote +On January 25 2017 05:35 imp42 wrote:
When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp.
regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually.
Whoever tscmoo is made claims without any knowledge of the matter.
tscmoo is probably the person that knows most about how Brood War works on this planet 
He (re)wrote the entire game engine after all (see the OpenBW thread). But there is a slight chance I misunderstood him.
Show nested quote +On January 25 2017 06:02 ProMeTheus112 wrote:oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say A 5% single-saturation difference in, for example, a ZvZ can easily amount to a pair of lings or two less produced per minute (or even more). That is not negligible. In fact, that is significantly imbalanced. If you need an example for this in practice, just look at (4)Neo Jade 2.0.
Yupp, I happen to have pretty exact numbers on this. On a standard map a 5% difference yields an additional worker after around 126 seconds (around the 3000 frame mark), assuming you build workers constantly. After that the difference grows faster obviously, until max saturation is reached.
|
On January 25 2017 09:34 Jealous wrote:+ Show Spoiler +On January 25 2017 08:01 Freakling wrote:Show nested quote +On January 25 2017 05:35 imp42 wrote:On January 25 2017 04:34 Freakling wrote:On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Calling this a map-specific bug is all fine and dandy, unless you are actually a map maker who needs to manually test all critical spots on a map to avoid this and sometimes change terrain in ways that are not beneficial to the overall concept ot map balance to change these kinds of bugs. Another of these, and far more frequent, ones are workers just not mining properly (and in a much broader sense units just taking weird and unpredictable paths around a map sometimes, with all kinds of unwanted implications for how the map actually plays out). Calling these things "map specific bugs" is really missing the point. It is literally impossible to fix all of these in any given map, and doing so adds hours of (very monotonous and frustrating) work to making a map and usually requires making significant changes to the map, which may end up causing new issues of their own. So it would be best to fix the underlying reason, being that BW the path-finding algorithm is a giant mess that barely works most of the time and completely fails some of the time (there is a blog post by one of the original developers of the game linked somewhere here on TL.net, just search the forum). So basically the pathfinding algorithm would need to be fixed. And this is where some people will probably cry out, because, of course, how unit pathing works is a huge part of what actually makes BW the game it is (and replacing its bumper car mechanics with something like SC2's fluid simulation yields very undesirable results for balance and gameplay). So what would be a good change? Having a terrain editor that could calculate unit paths in real time without having to enter a game would be good, of course. It also seems like BW actually compiles a kind of general pathing map of a map from the terrain parameters at game start, which is what actually determines the parts units take on every part of the map (on a macroscopic scale at least) and is the cause for the the above mentioned issues. My analysis may not be 100% spot on, I may interpret the evidence wrong, but there are certain facts that can be observed consistently and lead me to this conclusion: - any change of relevant terrain parameters (such as terrain level, walkability or whether a tile is normal terrain or belongs to a doodad of one kind or another) at any part of a map can cause the path units take at any other point of the map.
- most significantly, both the unit stack stuck (aka black hole) bug as well as miner pathing bugs are known to regularly (and practically randomly) appear this way, and they can be fixed by "random" terain changes as well (obviously this can be a tedious process of trial and error...).
- I also made a map once which was basically a giant labyrinth of paths. This map used to crash the game upon game-start, giving me an error message that said something along the lines of "could not compute pathing". Unfortunately I do not have that map any more. I have another, similar one, but all that one does is crash without any error readout (might also have something to do with running the newer English BW distribution that runs without game CD by default on a Linux system as opposed to the classic German version on an old windows PC, which gave me that error message...), so I cannot tell any more what exactly it said.
Anyway, making that pre-computed pathfinding information part of the map file instead of generating it dynamically at game start would potentially allow it to be accessed and edited via a map editor, allowing a map maker to smooth out at least the worst kinks manually (as a by-effect it would probably also reduce map loading time, although on modern machine the difference would probably be negligible anyways). When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp. regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually. Whoever tscmoo is made claims without any knowledge of the matter. All map protection (i.e. corruption) does is to remove or change (to varying degrees) those data parts of the map file that are needed by the editor, but not by the game (like doodad information [the game only knows tiles and sprites] and most importantly isometric terrain information [the game only uses the resulting tile matrix]). As long as the tile data if the map is not changed (which would actually crash or at least visibly corrupt the map), nothing changes path-finding-wise, as that is solely dependent on tile properties. Show nested quote +On January 25 2017 06:02 ProMeTheus112 wrote:oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say A 5% single-saturation difference in, for example, a ZvZ can easily amount to a pair of lings or two less produced per minute (or even more). That is not negligible. In fact, that is significantly imbalanced. If you need an example for this in practice, just look at (4)Neo Jade 2.0. Show nested quote +The black hole thing is crazy bad if it happens but it is so rare!
I can't remember having it in one of my games, or not too bad. I can't remember seeing it in a tourney game or smtg. Must have happened though?^^ Not as rare as you may think. It may not always be apparent, as the right preconditions (units overlapping on tiles with specific properties) need to be met first, which may not occur in a game. However, if a main ramp is affected, like on (4)Dante's Peak, which is notorious for having multiple instances of this bug, that means big trouble (things like Lurkers morphing on the ramp can easily trigger the bug). Units spawning inside or outside of walls can be a pretty huge imbalance in some case. For example when Terran players need to compromise their natural wallin by lifting their racks to let marines in (an then not being able to land it fast enough to block the following stream of Lings. Games have actually been lost that way. At the very least it makes maps very positionally imbalanced for Terran. On the other hand we have nice little plays as the Pylon Dragoon trap, for example, that rely on the predictable spawning position. However, this is so rarely used that it would not fundamentally change the game to not have it... I don't think spawn imbalance is necessarily a bad thing. It's forced diversity. How will the player cope with the situation? For example on top right on Hunters as Terran I go 2 rax bio into mech while at 6 o clock I'll go straight mech. I think your desire to force homogenous spawns will only serve to limit that diversity that allows for smart plays and situational decision making.
agree completely,quirks like units spawning outside of a wall adds to the depth of the game
|
So in conclusion of the discussion so far, we have found that everything is a feature, as it adds to the depth and diversity of the game, except for the black-whole-ramp, which in turn is nigh unfixable because map makers would need to invest unreasonable amounts of time to do so (and rewriting unit-pathing would fundamentally change / break the game).
|
On the other hand, if you remove dargoons getting stuck/correct their pathing, will it affect replays? Imagine that you have a game were your dragoon yet again decided to have a break, stopped and got killed. But in replay it will successfully retreat as it was ordered.
|
On January 25 2017 19:25 shall_burn wrote:
On the other hand, if you remove dargoons getting stuck/correct their pathing, will it affect replays? Imagine that you have a game were your dragoon yet again decided to have a break, stopped and got killed. But in replay it will successfully retreat as it was ordered.
I imagine that replays from older versions would work if the game just reloaded some logic&values from the correct version when a replay is launched. But it would require that the game code is organized in a way that makes it easy.
|
On January 25 2017 19:13 fazek42 wrote:
So in conclusion of the discussion so far, we have found that everything is a feature, as it adds to the depth and diversity of the game, except for the black-whole-ramp, which in turn is nigh unfixable because map makers would need to invest unreasonable amounts of time to do so (and rewriting unit-pathing would fundamentally change / break the game).
haha 
I did update the OP, categorizing some issues that have been mentioned so far. There is no way everyone will ever agree on every issue. But if most people people agree on most issues we have something to work with.
Also, one of the inputs was to give map makers real-time pathing predictions. A very good idea. I'm getting a lot out of this thread and it has been a exceptionally civilized discussion for far
On January 25 2017 19:25 shall_burn wrote:
On the other hand, if you remove dargoons getting stuck/correct their pathing, will it affect replays? Imagine that you have a game were your dragoon yet again decided to have a break, stopped and got killed. But in replay it will successfully retreat as it was ordered.
yes it will completely desync. This is way a well-thought out versioning system will be required. And only clients with the exact same bug fixes enabled will be able to play against each other.
|
On January 25 2017 11:29 fearthequeen wrote:Show nested quote +On January 25 2017 09:34 Jealous wrote:+ Show Spoiler +On January 25 2017 08:01 Freakling wrote:Show nested quote +On January 25 2017 05:35 imp42 wrote:On January 25 2017 04:34 Freakling wrote:On January 23 2017 03:10 imp42 wrote:On January 23 2017 02:29 Jealous wrote:
My vote is on not changing anything. why keep the "unit stuck on ramp, but only for one player on one side of the map" bug? or a bug where the lurker isn't able to burrow anymore? I realize there is a thin line and there might be border cases. This thread is to explore them. Calling this a map-specific bug is all fine and dandy, unless you are actually a map maker who needs to manually test all critical spots on a map to avoid this and sometimes change terrain in ways that are not beneficial to the overall concept ot map balance to change these kinds of bugs. Another of these, and far more frequent, ones are workers just not mining properly (and in a much broader sense units just taking weird and unpredictable paths around a map sometimes, with all kinds of unwanted implications for how the map actually plays out). Calling these things "map specific bugs" is really missing the point. It is literally impossible to fix all of these in any given map, and doing so adds hours of (very monotonous and frustrating) work to making a map and usually requires making significant changes to the map, which may end up causing new issues of their own. So it would be best to fix the underlying reason, being that BW the path-finding algorithm is a giant mess that barely works most of the time and completely fails some of the time (there is a blog post by one of the original developers of the game linked somewhere here on TL.net, just search the forum). So basically the pathfinding algorithm would need to be fixed. And this is where some people will probably cry out, because, of course, how unit pathing works is a huge part of what actually makes BW the game it is (and replacing its bumper car mechanics with something like SC2's fluid simulation yields very undesirable results for balance and gameplay). So what would be a good change? Having a terrain editor that could calculate unit paths in real time without having to enter a game would be good, of course. It also seems like BW actually compiles a kind of general pathing map of a map from the terrain parameters at game start, which is what actually determines the parts units take on every part of the map (on a macroscopic scale at least) and is the cause for the the above mentioned issues. My analysis may not be 100% spot on, I may interpret the evidence wrong, but there are certain facts that can be observed consistently and lead me to this conclusion: - any change of relevant terrain parameters (such as terrain level, walkability or whether a tile is normal terrain or belongs to a doodad of one kind or another) at any part of a map can cause the path units take at any other point of the map.
- most significantly, both the unit stack stuck (aka black hole) bug as well as miner pathing bugs are known to regularly (and practically randomly) appear this way, and they can be fixed by "random" terain changes as well (obviously this can be a tedious process of trial and error...).
- I also made a map once which was basically a giant labyrinth of paths. This map used to crash the game upon game-start, giving me an error message that said something along the lines of "could not compute pathing". Unfortunately I do not have that map any more. I have another, similar one, but all that one does is crash without any error readout (might also have something to do with running the newer English BW distribution that runs without game CD by default on a Linux system as opposed to the classic German version on an old windows PC, which gave me that error message...), so I cannot tell any more what exactly it said.
Anyway, making that pre-computed pathfinding information part of the map file instead of generating it dynamically at game start would potentially allow it to be accessed and edited via a map editor, allowing a map maker to smooth out at least the worst kinks manually (as a by-effect it would probably also reduce map loading time, although on modern machine the difference would probably be negligible anyways). When I wrote "map specific bug" I meant a bug most likely introduced due to willingly corrupting the map in order to "protect" it. At least tscmoo is fairly certain that was the reason of the units getting stuck at a specific ramp. regarding the unpredictability of the consequences terrain changes has on path finding, I'm confident this can be solved soon. Or at least fully understood. Also the idea to have a tool calculating paths in real-time during editing is great. This is something bot developers would want anyways, so here too, I'm pretty confident we will get this eventually. Whoever tscmoo is made claims without any knowledge of the matter. All map protection (i.e. corruption) does is to remove or change (to varying degrees) those data parts of the map file that are needed by the editor, but not by the game (like doodad information [the game only knows tiles and sprites] and most importantly isometric terrain information [the game only uses the resulting tile matrix]). As long as the tile data if the map is not changed (which would actually crash or at least visibly corrupt the map), nothing changes path-finding-wise, as that is solely dependent on tile properties. Show nested quote +On January 25 2017 06:02 ProMeTheus112 wrote:oh but the worker thing yeah that's a bit weird and annoying for mapmakers i'm sure I remember for a long time we played on maps with different speed of mining depending on pos like luna. Not sure it's so hard to fix in a map though, just juggle a little with the minerals? when it's like 5% or less difference of speed, kinda no big deal I would say A 5% single-saturation difference in, for example, a ZvZ can easily amount to a pair of lings or two less produced per minute (or even more). That is not negligible. In fact, that is significantly imbalanced. If you need an example for this in practice, just look at (4)Neo Jade 2.0. Show nested quote +The black hole thing is crazy bad if it happens but it is so rare!
I can't remember having it in one of my games, or not too bad. I can't remember seeing it in a tourney game or smtg. Must have happened though?^^ Not as rare as you may think. It may not always be apparent, as the right preconditions (units overlapping on tiles with specific properties) need to be met first, which may not occur in a game. However, if a main ramp is affected, like on (4)Dante's Peak, which is notorious for having multiple instances of this bug, that means big trouble (things like Lurkers morphing on the ramp can easily trigger the bug). Units spawning inside or outside of walls can be a pretty huge imbalance in some case. For example when Terran players need to compromise their natural wallin by lifting their racks to let marines in (an then not being able to land it fast enough to block the following stream of Lings. Games have actually been lost that way. At the very least it makes maps very positionally imbalanced for Terran. On the other hand we have nice little plays as the Pylon Dragoon trap, for example, that rely on the predictable spawning position. However, this is so rarely used that it would not fundamentally change the game to not have it... I don't think spawn imbalance is necessarily a bad thing. It's forced diversity. How will the player cope with the situation? For example on top right on Hunters as Terran I go 2 rax bio into mech while at 6 o clock I'll go straight mech. I think your desire to force homogenous spawns will only serve to limit that diversity that allows for smart plays and situational decision making. agree completely,quirks like units spawning outside of a wall adds to the depth of the game
Oh, I dunno... some ppl definitely might see it that way, but others probably think, "Geez, why can't I just make my units just spawn INSIDE OF my wall-in? That should be a given, I have other things to worry about than something that basic."
A poll on something like that would be interesting.
|
Nobody mentioned the following bug: mouse clicks are sometimes not registered while pressing buttons on the keyboard.
|
On January 28 2017 18:18 Biolunar wrote:
Nobody mentioned the following bug: mouse clicks are sometimes not registered while pressing buttons on the keyboard.
ROFLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
i f*cking bought 3 keyboards cuz i thought they were bugging
|
On January 28 2017 18:18 Biolunar wrote:
Nobody mentioned the following bug: mouse clicks are sometimes not registered while pressing buttons on the keyboard.
ok this one is potentially hard to track down, because you can't just reproduce it in a replay.
On the other hand there's a chance it will just be solved automatically ^^
Anyways, I added it to the bug list in the OP.
|
Dark Archon's 50 starting energy, is it intended or not? I mean, when the energy upgrade is reseached, it's still 50 at start. Other casters get like... 67? or something, after the upgrade is researched.
|
|
|
|
|
|
EPT
