Page 2 of 3
Re: Unit Movement Pt. II
Posted: 18 Apr 2012, 20:26
by knorke
why does work need to go into current path finder, why cant it just be put like it was before? O.0
because:

Re: Unit Movement Pt. II
Posted: 18 Apr 2012, 22:34
by Kazori
knorke wrote:why does work need to go into current path finder, why cant it just be put like it was before? O.0
because:

why not develop it separate from spring then, its been shit for almost a year? I dunno exactly but it seems quite long now and I don't see any signs of it getting better
I just don't get why it needs to be released with Spring when its far from complete, its annoying for players like me especially when I dont even believe its going to become better than it was
Re: Unit Movement Pt. II
Posted: 18 Apr 2012, 23:47
by SanadaUjiosan
Kazori wrote:knorke wrote:why does work need to go into current path finder, why cant it just be put like it was before? O.0
because:

why not develop it separate from spring then, its been shit for almost a year? I dunno exactly but it seems quite long now and I don't see any signs of it getting better
I just don't get why it needs to be released with Spring when its far from complete, its annoying for players like me especially when I dont even believe its going to become better than it was
Testing is my guess. No one gets everything right the first time. This is a fact of life.
Re: Unit Movement Pt. II
Posted: 20 Apr 2012, 03:33
by PicassoCT
The journey is the reward
Re: Unit Movement Pt. II
Posted: 20 Apr 2012, 06:55
by Jazcash
PicassoCT wrote:The journey is the reward
I see what you did thar. Or something.
Re: Unit Movement Pt. II
Posted: 20 Apr 2012, 09:13
by Johannes
smoth wrote:Johannes wrote:(you'd expect programmers to care about their userbase to some extent even if they're working for free)
So tell me, great sage, if software is flawed does that mean the programmer didn't care?
Not really. But whether they improve on it, and how fast, is obviously determined a lot by how much they care - how high do they prioritize that compared to other things they could do.
Re: Unit Movement Pt. II
Posted: 20 Apr 2012, 09:59
by Beherith
Johannes, your tone suggest extreme ignorance about how and why anyone would contribute to an open source project.
You are almost accusing the engine developers of negligence, which not only saps developer motivation, but inokes extreme bitterness.
Re: Unit Movement Pt. II
Posted: 20 Apr 2012, 09:59
by smoth
Johannes
That is entirely untrue. Whether they improve on it and how fast is determined by the complexity of the problem before them.
Programmers are not wizards
Programming is not magic.
Re: Unit Movement Pt. II
Posted: 20 Apr 2012, 14:45
by Johannes
Beherith wrote:Johannes, your tone suggest extreme ignorance about how and why anyone would contribute to an open source project.
There are almost as many reasons as there are contributors. I can openly say that I'd wish those hows and why's would directly contribute to what I or other endusers desire, but yes I understand that's not always the case.
You are almost accusing the engine developers of negligence, which not only saps developer motivation, but inokes extreme bitterness.
Nobody expects the engine devs to quit their jobs or social lives in order to work on Spring code, but if they would care about the project to such extreme measures, then obviously things would proceed faster... That's a fact regardless of what tone it's stated in.
Basically, there's a limit to what you can expect anyone to dedicate to a hobby project.
Of course I could learn to do these myself too if I took enough interest in it but no, ultimately other things are more important for me. Respect to those who actually are doing more, even if I don't always like the changes made, nobody's obliged to do anything here.
smoth wrote:Johannes
That is entirely untrue. Whether they improve on it and how fast is determined by the complexity of the problem before them.
Progress = Complexity of issue / time used to work on it. (*existing skill)
Re: Unit Movement Pt. II
Posted: 20 Apr 2012, 16:17
by smoth
Johannes wrote:Progress = Complexity of issue / time used to work on it. (*existing skill)
Not even.
Re: Unit Movement Pt. II
Posted: 20 Apr 2012, 17:10
by Godde
I'm gonna list some of the challanges that the spring engine pathing require:
- Speedbonuses. Units can get speedbonues on different parts of the map.
- Slope tolerance. Different units can traverse different stepness.
- Changing elevation as craters fill the battlefield requiring the available paths to change as the game is running.
- Units with slow acceleration and slow turn rate. (Compare that to starcraft units which turn immedietly.) This makes it much harder to avoid obstacles and control a clumped up group of units.
- Feature rich maps. Some maps have forests and when wrecks fill the battlefield and then units need to find a path through the forests and fields of features.
These problems might be able to be solved so that units will always use the optimal path but at what cost?
All this has to be simulated at each computer connected to the game.
Re: Unit Movement Pt. II
Posted: 03 May 2012, 13:02
by Forboding Angel
Kazori wrote:
why not develop it separate from spring then, its been shit for almost a year? I dunno exactly but it seems quite long now and I don't see any signs of it getting better
I just don't get why it needs to be released with Spring when its far from complete, its annoying for players like me especially when I dont even believe its going to become better than it was
The current pathfinder performs extremely well. Test in Evo 2.9, and shut up. While you are shutting up, start asking yourself why it's so good in Evo and not in BA. Once you figure it out, post in this forum with proposed changes.
BA fights the pathfinder at every possible juncture. Accelerations and max velocities that take 30 seconds to reach (LOLFLASH? At one point the flash tank had an acceleration of 0.001 and a max velocity of 7), brakerates that are so low they take a year to properly manage. Not to mention turninplace false and super low turnrates. Add all the above values into one giant ball of fail, and
suprende! You get fail!
It is BA's fault that the pathing in BA is shit.
Edit:
armflash unitdef wrote:
armflash = {
acceleration = 0.05,
brakerate = 0.06,
maxvelocity = 3.5,
turnrate = 592,
}
And you have the
gall to
bitch about pathing sucking???
Why don't you do some math and figure out how long it takes 0 to turn into 3.5 by adding 0.05 a bunch of times.
Suck it.
Re: Unit Movement Pt. II
Posted: 03 May 2012, 13:50
by Forboding Angel
Oh snap, forb just fixed BA *GASPED*, now we have to find somethign else meaningless and even more full of bullshit to BAWWW about.
SHIIIIIIIT!!!!!!
http://springfiles.com/spring/games/bal ... ilation-32
Re: Unit Movement Pt. II
Posted: 03 May 2012, 16:07
by Google_Frog
Do you realise that you've mess up balance in dozens of barely measurable ways? Would you really throw away decades of fine tuning to make the game less frustrating to play?
Re: Unit Movement Pt. II
Posted: 03 May 2012, 16:14
by smoth
Decade (s)
Ha ha
Re: Unit Movement Pt. II
Posted: 03 May 2012, 16:42
by Ares
smoth wrote:Decade (s)
Ha ha
Is there something funny about corvette pathing?
Re: Unit Movement Pt. II
Posted: 03 May 2012, 16:49
by smoth
Total Annihilation was released in '98. Spring AA which BA is based on is from maybe 2005/2006. So not even a decade, let alone more than one.
Re: Unit Movement Pt. II
Posted: 03 May 2012, 22:12
by klapmongool
Even if it is not about any presumed delicate balance... Don't Forbs suggestions simply change the game into something else? That is not a fix.
Re: Unit Movement Pt. II
Posted: 03 May 2012, 22:16
by Beherith
Only way to decide is by trying it.
Re: Unit Movement Pt. II
Posted: 03 May 2012, 22:28
by smoth
klapmongool wrote:Even if it is not about any presumed delicate balance... Don't Forbs suggestions simply change the game into something else? That is not a fix.
Wait, wait, so changing stats makes the game into something else!
STOP THE PRESSES! BA DIED YEARS AGO WHEN AA CHANGED!
MUST
FEAR
CHANGE