because:why does work need to go into current path finder, why cant it just be put like it was before? O.0
Unit Movement Pt. II
Moderator: Content Developer
Re: Unit Movement Pt. II
Re: Unit Movement Pt. II
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 betterknorke wrote:because:why does work need to go into current path finder, why cant it just be put like it was before? O.0
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
- SanadaUjiosan
- Conflict Terra Developer
- Posts: 907
- Joined: 21 Jan 2010, 06:21
Re: Unit Movement Pt. II
Testing is my guess. No one gets everything right the first time. This is a fact of life.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 betterknorke wrote:because:why does work need to go into current path finder, why cant it just be put like it was before? O.0
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
The journey is the reward
Re: Unit Movement Pt. II
I see what you did thar. Or something.PicassoCT wrote:The journey is the reward
Re: Unit Movement Pt. II
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.smoth wrote:So tell me, great sage, if software is flawed does that mean the programmer didn't care?Johannes wrote:(you'd expect programmers to care about their userbase to some extent even if they're working for free)
Re: Unit Movement Pt. II
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.
You are almost accusing the engine developers of negligence, which not only saps developer motivation, but inokes extreme bitterness.
Re: Unit Movement Pt. II
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.
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
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.Beherith wrote:Johannes, your tone suggest extreme ignorance about how and why anyone would contribute to an open source project.
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.You are almost accusing the engine developers of negligence, which not only saps developer motivation, but inokes extreme bitterness.
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.
Progress = Complexity of issue / time used to work on it. (*existing skill)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.
Re: Unit Movement Pt. II
Not even.Johannes wrote:Progress = Complexity of issue / time used to work on it. (*existing skill)
Re: Unit Movement Pt. II
I'm gonna list some of the challanges that the spring engine pathing require:
All this has to be simulated at each computer connected to the game.
- 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.
All this has to be simulated at each computer connected to the game.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Unit Movement Pt. II
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.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
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:
And you have the gall to bitch about pathing sucking???armflash unitdef wrote: armflash = {
acceleration = 0.05,
brakerate = 0.06,
maxvelocity = 3.5,
turnrate = 592,
}
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.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Unit Movement Pt. II
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
http://springfiles.com/spring/games/bal ... ilation-32
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Unit Movement Pt. II
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
Is there something funny about corvette pathing?smoth wrote:Decade (s)
Ha ha
Re: Unit Movement Pt. II
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.
-
- Posts: 843
- Joined: 13 Aug 2007, 13:19
Re: Unit Movement Pt. II
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
Only way to decide is by trying it.
Re: Unit Movement Pt. II
Wait, wait, so changing stats makes the game into something else!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.
STOP THE PRESSES! BA DIED YEARS AGO WHEN AA CHANGED!
MUST
FEAR
CHANGE