Members in Shoutbox
None.

Shoutbox Search
Search for:


Shoutbox Commands
/w [name] > Whisper
/r > Reply to last whisper
/me > Marks as action

Shoutbox Information
Moderators may delete any and all shouts at will.
Global Shoutbox
Please log in to shout.
Pages: < 1 « 442 443 444 445 4463567 >

[2017-12-24. : 4:05 pm]
Moose -- u'all
[2017-12-24. : 3:56 pm]
Excalibur -- u
[2017-12-24. : 3:11 pm]
lil-Inferno -- u
[2017-12-24. : 2:51 pm]
Dem0n -- u
[2017-12-24. : 2:40 pm]
Moose -- God damn y'all made some gold in the shiutbox last night
[2017-12-24. : 2:38 pm]
Moose -- Freakling
Freakling shouted: Somehow this feels like discussing with some religious fanatic by now…
Ya, I see you brought out Occam's razor LMAO
[2017-12-24. : 2:37 pm]
Moose -- Freakling
Freakling shouted: Exactly the fact that its made by humans and not suffers from any complications of real-world physics is the reason why it is completely irrational to assume a complicated solution to a simple problem, especially if no evidence from within the game or the game code suggests otherwise and the complicated solution would explain nothing the simple one couldn't and would be, to be true, virtually indistinguishable form the simple solution.
fucking rekt
[2017-12-24. : 8:33 am]
O)FaRTy1billion[MM] -- Suicidal Insanity
Suicidal Insanity shouted: lil-Inferno According to a dev the pathiong is a bunch of hacks on top of hacks on top of hacks to get something working
ya, that should have already been common knowledge by now XD
[2017-12-24. : 2:57 am]
Freakling -- Lanthanide
Lanthanide shouted: right, so passing between two pillars should be quite possible, although moving to stand between them may not be
Example: https://i.imgur.com/oRIiEy9.jpg . Note the disjoined regions above and below the gap.
[2017-12-24. : 2:43 am]
Freakling -- Exactly the fact that its made by humans and not suffers from any complications of real-world physics is the reason why it is completely irrational to assume a complicated solution to a simple problem, especially if no evidence from within the game or the game code suggests otherwise and the complicated solution would explain nothing the simple one couldn't and would be, to be true, virtually indistinguishable form the simple solution.
[2017-12-24. : 2:40 am]
Freakling -- Somehow this feels like discussing with some religious fanatic by now…
[2017-12-24. : 2:40 am]
Lanthanide -- we're dealing with a game made by humans, who can make it do whatever they want in case Z, not physics
[2017-12-24. : 2:40 am]
Lanthanide -- saying "X happens in case Y, therefore in case Z, X must also happen" is not convincing
[2017-12-24. : 2:39 am]
Lanthanide -- for the record: I entirely believe you, I'm just saying your argument is not convincing
[2017-12-24. : 2:39 am]
Lanthanide -- anyway, I have to go to the beach now
[2017-12-24. : 2:39 am]
Lanthanide -- sorry, I did
[2017-12-24. : 2:39 am]
Freakling -- No, not really.
[2017-12-24. : 2:39 am]
Lanthanide -- I already explained that
[2017-12-24. : 2:38 am]
Freakling -- So what then would that 'destack while moving' algorithm look like? Maybe you should think that part through first before continuing the discussion with hypotheticals.
[2017-12-24. : 2:37 am]
Lanthanide -- so the chancse of you stopping them while stacked are very low, hence you never see it
[2017-12-24. : 2:37 am]
Lanthanide -- because the dragoons have already applied the 'destack while moving' algorithm so they are hardly ever stacked
[2017-12-24. : 2:36 am]
Freakling -- Lanthanide
Lanthanide shouted: Freakling if you hit stop when the stacking is not fully resolved, then you would you get standard de-stacking algorithm applied
Exactly. But this does not happen with Dragoons just moving around.
[2017-12-24. : 2:35 am]
Lanthanide -- Freakling
Freakling shouted: Lanthanide And then you hit stop… And what?
if you hit stop when the stacking is not fully resolved, then you would you get standard de-stacking algorithm applied
[2017-12-24. : 2:34 am]
Lanthanide -- 1. a bunch of stacked units is not already moving, so that doesn't invalidate my argument. 2. once units are stacked and have begun to employ their "detack algorithm", again what I am proposing no longer applies
[2017-12-24. : 2:34 am]
Freakling -- Lanthanide
Lanthanide shouted: I'm saying it resolves the collision using a less disruptive algorithm
And then you hit stop… And what?
[2017-12-24. : 2:33 am]
Freakling -- Lanthanide
Lanthanide shouted: Freakling another explanation is that units within the same magic box ignore the changing collision size while undergoing movement, but units from different magic boxes are affected by it
Simple counter-argument: You cannot just walk a stack of stacked units, even though they are most definitely withing the same magic box. You have to wait till they are unstacked. Furthermore, that is not how magic-boxing works. Magic boxing just means that the actual target point for a movement command depends on their relative position within the selected group..
[2017-12-24. : 2:32 am]
Lanthanide -- I'm saying it resolves the collision using a less disruptive algorithm
[2017-12-24. : 2:30 am]
Freakling -- Lanthanide
Lanthanide shouted: I'm not saying you're wrong, I'm just saying that argument isn't convincing
What other thing could it do? Either it detects collision and tries ot resolve them (which requires a fixed-size collision box to avoid spontaneous stack) or it does not (in which case they could just walk through other units).
[2017-12-24. : 2:29 am]
Lanthanide -- Freakling
Freakling shouted: Lanthanide The Zealot would still have to go somewhere else, space that's potentially occupied by some other unit at that point. Again, you cannot observe these kinds of spontaneous collisions in-game, and you could hardly avoid or overlook them, given how disruptive to gameplay they would be.
another explanation is that units within the same magic box ignore the changing collision size while undergoing movement, but units from different magic boxes are affected by it
[2017-12-24. : 2:27 am]
Lanthanide -- I'm not saying you're wrong, I'm just saying that argument isn't convincing
[2017-12-24. : 2:27 am]
Freakling -- Lanthanide
Lanthanide shouted: Freakling yes. So a dragoon and a zealot walking in the same direction, when both are at rest the dragoon is at its maximum size. They both start walking in the same direction, the zealot stays a fixed distance from the dragoon and there are no issues. If during the path of the journey, the zealot walks closer to the dragoon for an instant when it can because the box is smaller, then when the box gets larger the zealot is bumped (not involving the previously talked about 'unstack algorithm', but a different 'I'm already moving' one) and steers clear of the dragoon
The Zealot would still have to go somewhere else, space that's potentially occupied by some other unit at that point. Again, you cannot observe these kinds of spontaneous collisions in-game, and you could hardly avoid or overlook them, given how disruptive to gameplay they would be.
[2017-12-24. : 2:26 am]
Lanthanide -- your argument essentially seems to be "if dragoons have changing boxes, then the crappy "unstack algorithm" will be employed during movement of troops and it would be terrible", but that's simply an assertion - it doesn't have to play the same algorithm, it could do other things
[2017-12-24. : 2:25 am]
Freakling -- You can also look through the openBW code and see if you can find any part where unit collision size (or bounding box, I think it's called their) is not treated as a fixed value.
[2017-12-24. : 2:24 am]
Lanthanide -- Freakling
Freakling shouted: Lanthanide But it is not. That's the point. You can, in fact, have ScmDraft have display both for you very conveniently and find that they are not the same.
the original algorithm to generate the sizes most likely relied on the sprite size, and then at some point in time the boxes were divorced from the sprite size and began using fixed values / offsets
[2017-12-24. : 2:23 am]
Lanthanide -- Freakling
Freakling shouted: Lanthanide Other units can also walk next to walking Dragoons.
yes. So a dragoon and a zealot walking in the same direction, when both are at rest the dragoon is at its maximum size. They both start walking in the same direction, the zealot stays a fixed distance from the dragoon and there are no issues. If during the path of the journey, the zealot walks closer to the dragoon for an instant when it can because the box is smaller, then when the box gets larger the zealot is bumped (not involving the previously talked about 'unstack algorithm', but a different 'I'm already moving' one) and steers clear of the dragoon
[2017-12-24. : 2:23 am]
Freakling -- Lanthanide
Lanthanide shouted: that's very convenient for creating collision boxes for units, hence why they choose that design, but it fails in the cases of units that have sprites that have large changes in size
Cosmetically, maybe. You can find a lot of unnatural looking sprite overlap in BW. But that's defintely an issue of lesser concern
[2017-12-24. : 2:22 am]
Freakling -- Lanthanide
Lanthanide shouted: if collision box size is based on the size of the sprite, when the sprite increases in apparent size, the collision box likewise increases
But it is not. That's the point. You can, in fact, have ScmDraft have display both for you very conveniently and find that they are not the same.
[2017-12-24. : 2:21 am]
Lanthanide -- that's very convenient for creating collision boxes for units, hence why they choose that design, but it fails in the cases of units that have sprites that have large changes in size
[2017-12-24. : 2:21 am]
Lanthanide -- if collision box size is based on the size of the sprite, when the sprite increases in apparent size, the collision box likewise increases
[2017-12-24. : 2:21 am]
Freakling -- Lanthanide
Lanthanide shouted: Freakling no, it's not reciprocal, we're saying that dragoons change size while moving, but do not change size when stationary. therefore if another unit walks pass a dragoon, there's no issue, because its size doesn't change
Other units can also walk next to walking Dragoons.
[2017-12-24. : 2:20 am]
Freakling -- 3. Simple Occams razor: I don't know why the idea of changing collision box sizes would appeal to any one at the first place. Especially not to a team of developers who are already struggling with the implementation of their pathfinding algorithm. There is absolutely no reason for them to make life unnecessarily hareder for themselves.
[2017-12-24. : 2:18 am]
Freakling -- 2. You can also see how overlap can travel in waves through a tightly packed group of goons, forcing henceforth stationary (hold position or stop commanded) goons to also move out of the way, as would be expected with normal collision box overlap.
[2017-12-24. : 2:15 am]
Lanthanide -- Freakling
Freakling shouted: Lanthanide 1. And another one for units walking by such a unit. Yes. In which case collision would either have to be completely disabled (not the case, or Dragoons could just walk through other units) or minimal distances, i.e collision size, would, again, have to be fixed.
no, it's not reciprocal, we're saying that dragoons change size while moving, but do not change size when stationary. therefore if another unit walks pass a dragoon, there's no issue, because its size doesn't change
[2017-12-24. : 2:15 am]
Freakling -- Lanthanide
Lanthanide shouted: unless there's a special case exception for "this unit is standing still, and another unit passes it by with expanding and contracting collision box -> stationary unit does nothing"
1. And another one for units walking by such a unit. Yes. In which case collision would either have to be completely disabled (not the case, or Dragoons could just walk through other units) or minimal distances, i.e collision size, would, again, have to be fixed.
[2017-12-24. : 2:12 am]
Freakling -- Lanthanide
Lanthanide shouted: it's obviously true that collision boxes are to some extent ignored when units are in motion, since you can pack dragoons into a small space, then add another one, and have them walking over the top of each other etc, and they don't "get stuck on each other"
The "walking over the top of each other" is exactly what a stack looks like. However, the salient point is that you cannot create this just by moving Dragoons (or any other units) but that some initial stack needs to be created somewherefirst, be it through workers, mines, Archon warps, burrow or Egg morphs.
[2017-12-24. : 2:11 am]
Lanthanide -- unless there's a special case exception for "this unit is standing still, and another unit passes it by with expanding and contracting collision box -> stationary unit does nothing"
[2017-12-24. : 2:09 am]
Freakling -- Have you ever burrow stacked units and the unburrowed them? Or used any of at least half a dozen tricks to glitch units across a mineral line or other unit obstackle? Or hit stop on a worker line? Just two examples to easily demonstrate how units behave when they get stacked, i.e. have overlapping collision boxes (while collision is enabled). It will disrupt previous unit commands and instead force the units into an "get unstacked" routine, which involves their erratically moving around until the overlap is resolved.
[2017-12-24. : 2:05 am]
Lanthanide -- it's obviously true that collision boxes are to some extent ignored when units are in motion, since you can pack dragoons into a small space, then add another one, and have them walking over the top of each other etc, and they don't "get stuck on each other"
[2017-12-24. : 2:04 am]
Lanthanide -- my assumption is - if units are moving and allied, we ignore collision box overlap, if units halt then they will act to disentangle themselves
[2017-12-24. : 2:04 am]
Lanthanide -- you haven't actually defined what you mean by "regularly get stuck on each other just from moving"
[2017-12-24. : 2:02 am]
Freakling -- Lanthanide
Lanthanide shouted: that claim doesn't follow, the collision box can expand and contract at will, so long as there is some other mechanism to prevent units getting stuck on each other as you say
The other mechanic would have to take into consideration the vertical and horizontal distances to unwalkable terrain and other units, in other words: collision boxes.
[2017-12-24. : 2:00 am]
Freakling -- Lanthanide
Lanthanide shouted: Freakling that article is not written by Day9
One of Day9's videos making that claim and (generally explaining Bw pathfinding very badly) is linked as the main source in the first paragraph…
[2017-12-24. : 1:59 am]
Lanthanide -- that claim doesn't follow, the collision box can expand and contract at will, so long as there is some other mechanism to prevent units getting stuck on each other as you say
[2017-12-24. : 1:58 am]
Lanthanide -- Freakling
Freakling shouted: And day9 has no clue. The "Dragoon's collision boxes extend and contract claim" is basically informational cancer that keeps spreading despite being obvious nonsese (if collision boxes changed in size, units would regularly get stuck on each other just from moving and glitch out as a result, which is not happening).
that article is not written by Day9
[2017-12-24. : 1:58 am]
Lanthanide -- Freakling
Freakling shouted: Lanthanide It does in BW, too. For some reasons people mistake animations (i.e changing sprites) for something real on a mechanical level.
it feels like with a hydra moving from point A to B, that if you order it to Stop, there are points along the path where it is much more likely to halt, than other points
[2017-12-24. : 1:50 am]
Freakling -- Suicidal Insanity
Suicidal Insanity shouted: lil-Inferno According to a dev the pathiong is a bunch of hacks on top of hacks on top of hacks to get something working
Look at that map with "mostly walkable" tile overlays and pathfinding regions activated, and you'll probably find that the relevant tiles are considered mostly unwalkable and the regions disjoint (i.e. not directly connected to each other). I that case not even perfect micro will allow you to maneuvre a unit through a gap.
[2017-12-24. : 1:45 am]
Freakling -- And day9 has no clue. The "Dragoon's collision boxes extend and contract claim" is basically informational cancer that keeps spreading despite being obvious nonsese (if collision boxes changed in size, units would regularly get stuck on each other just from moving and glitch out as a result, which is not happening).
[2017-12-24. : 1:43 am]
Freakling -- Lanthanide
Lanthanide shouted: they could have retained their fluid pathing, while giving a few units quirky movement styles for variety, but instead everything moves in constant speed from point A to B
It does in BW, too. For some reasons people mistake animations (i.e changing sprites) for something real on a mechanical level.
[2017-12-24. : 1:40 am]
Freakling -- You have to differentiate between the actual pathfinding, magic box behaviour and collision handling.
[2017-12-24. : 1:39 am]
Freakling -- NudeRaider
NudeRaider shouted: Excalibur sounds like he's coming from a gameplay perspective, whereas when talk about a bug when code works differently from what is expected or intended
I just find calling pathfinding in BW as a whole a "bug" is way to general. There are definitely very serious bugs associated with pathfinding (like the inability to find actual shortest paths in many many cases, or vortex bugs, just to name the most serious ones). But you have to be more specific and I find that most people, even top players or map makers, in this discussion or elsewhere generally have rather hazy or outright wrong notions of what is actually going on.
[2017-12-24. : 1:34 am]
Lanthanide -- according to the article, the clunky pathfinding was definitely not intentional
[2017-12-24. : 1:32 am]
Freakling -- All I am saying is that the clunky pathfinding in BroodWar is the inevitable result of the design decisions made, for whatever reasons, not that all the resulting idiosyncrasies were a design goal to begin with, which seems to be the point you believe I am arguing for.
[2017-12-24. : 1:30 am]
Freakling -- NudeRaider
NudeRaider shouted: Excalibur then it shouldn't be a problem for him to show proof that the pathing algorithm was designed to act weirdly.
The problem is not any claim I supposedly make but that you mistake it for something different.
[2017-12-24. : 1:24 am]
Freakling -- NudeRaider
NudeRaider shouted: Freakling gotta have to ask for proof for your claim that the pathing algorithm is supposed to all these crazy things.
What? trying to walk around obstacles and keeping formations of units in close proximity (aka. magic boxing)? You have actually played Brood War at some point, right? Or what kind of proof are you looking for? You could look for the relevant function in the OpenBW code for technical details.
[2017-12-24. : 1:17 am]
Lanthanide -- right, so passing between two pillars should be quite possible, although moving to stand between them may not be
[2017-12-24. : 1:09 am]
Suicidal Insanity -- I think allowed movement from tile to tile requires at least 2 microtiles pathable on each side
[2017-12-24. : 12:43 am]
Lanthanide -- probably not enough space on the sub-tiles for the dragoons?
[2017-12-24. : 12:43 am]
Suicidal Insanity -- lil-Inferno
lil-Inferno shouted: NudeRaider I'm pretty sure the pathing is a product of its time (because hardware succed or whatever) but unintentionally created deep, balanced gameplay
According to a dev the pathiong is a bunch of hacks on top of hacks on top of hacks to get something working
[2017-12-24. : 12:43 am]
lil-Inferno -- I remember Psionic_Storm showing me a map with two pillars on Twilight, and though it was clear there's a ton of space in between the pillars, a dragoon would walk around them instead of walking between them
[2017-12-24. : 12:42 am]
Suicidal Insanity -- FaRTy1billion
FaRTy1billion shouted: did you get color cycling fixed?
I haven't worked on that yet, last 1.5 weeks has been redoing sprite / image rendering / dirty rect logic

Pages: < 1 « 442 443 444 445 4463567 >


Members Online: NudeRaider, Zincoshine