pathing bit messed up but the reclaim I would say is alot more major

in the old days of 0.82, we had a different versioning scheme. the difference between 0.81->0.82 and 0.82.1->0.82.2 does not exist anymore (we had 3 different version parts for releases back then, now we have only two). 87.1 would have to be a non-sync breaking release. short: a release that would fix these bugs would be called 88.0 (or something higher then 88 even, as it is allwoed to skip numbers, at least in theory).

Could be, got another 'not saved settings' occurence on third pc with XP. The other two are with Win 7.

btw the bug with stuck units could be fixable ... easily.
just make a check for current position and queue of the unit in a given check acumulator size. 5 checks are enough to see that queue is still active but the position x,y is changed with some rly small percent instead of that for the queue. After that stop the unit, move it backwards again with small percent and then send it again with the same queue.

I still think the old versioning scheme was better... Now every sync breaking release is basically equal, whether it fixes 1 bug, or includes year of coding new features...
So we can't have a quick bugfix release for the area reclaim bug, because it breaks sync, so it would require a big release, which means people will keep including stuff in it, and we will all wait, and then the version will be released but not live on the server and we will have to wait even longer...

/rant

I am glad GoogleFrog implemented a workaround gadget in ZK for the area reclaim bug. It was becoming very annoying after several games.

what? that makes no sense. fixing the area reclaim bug is sync-breaking, with the old versioning scheme a "full" release would be also required to fix it.

feel free to create a regression-test-suite + add a test-case for area-reclaim to let it not break in the future again instead of ranting.

In a gadget:
The second line cause an error in Spring 87.
(It had worked fine for five years.)

The error being:
Error: Lua LoadCode pcall error = 0, LuaRules/main.lua, error = 2, LuaGadgets/gadgets.lua, ERROR_TYPE in WeaponDefs __index

We are obviously taking about different mod, I am talking about balanced annihilation where reclaim is 75% + of your eco. You might talk about 64v64 dsd where reclaim does not matter.

There is a reason why there are only 10 people (included spec) playing BA right now.

So is possible to make server go back to 0.85 or shall we see number of player drop till 0.88 and hope they will come back ?


I know you all done lot of work on that version (and congrats) but imo majors bug issue are more important to the players than huge engine impovment.

I think we are talking about the same game here. As you might have noticed I am one of the most unlikely people to play BADSD1000V1000. Maybe we differ in our estimation of the prioritisation of this issue by the devs. I assumed that this would be on the very top of their list and that a fix would be made ASAP. In the meanwhile the bug forces the player to do a lot more microing of cons and rezzers. Aircons are usefull too :)

So I would agree on reverting to 85 if a fix takes longer than two weeks or so.

Fixes for constructors were ready even before 87 release was set online. So devs please make release ASAP

Yea, sorry I meant the time needed for the fix to be released :)

IMHO spending resources for reclaim-units are waaaay too inefficient than simply building groups of 3 generators and metal maker. Loosing focus with reclaiming will eat your frontline in early game, and later this could lead to your fall in spam mini battles.

As a quick work-around you can set rez/con to patrol. They will then walk near enough to wrecks to reclaim them. Does not help to rez ofc, but well... it's a work-around :)

Also: I hear that someone (g_f?) made a widget to counter the problem for 0-K... maybe that works for BA too, or can be made to work?

Actually a rez/con set to patrol will still stop once the next reclaim target is a bit out of its range.

@100Gbps; lets keep focus on fixing 87 instead of discussing tactics :)

hmm... right... I guess it worked yesterday bc I used air-cons and their range is bigger (and they circle), so they always got to the next target - just luck :)

+1

BA reclaim range thing: viewtopic.php?f=44&t=27816&p=516931
imo first try to fix the game and only if it is unfixable scream for server revert

And here rises need of support multiple spring engine versions in the lobby. Personally I would love two releases of spring, stable with backported fixes and current where things might go wrong.

Of course such thing would be bad for packagers, but maybe spring as engine should disapear from packages completely and there would exist only lobbies. Good example would be playonlinux it autodownloads whatever needed version of WINE you need for whatever game from buildbot and no problems.

Please revert these so I don't have to explain why:
-isCommander tag
-infolog.txt buffering
-removing ArchiveMover
-GL smoothing ON by default
-wdef[id].areaOfEffect, wdef[id].maxVelocity
-network bandwidth limits
-falling damage(or document workaround)
+similarly braindead changes


"--safemode" is not that safe, it crashes always with my ATI which used to work fine for years, works ok after running springsettings. http://www.opengl.org/wiki/Common_Mistakes#GL_POINTS_and_GL_LINES


Related to WeaponDef.maxVelocity etc. rename, maybe a leftover from testing what the change affects or highly braindead idea to protect game devs of using the tag.

why?

Yeah isComander was good and simple. At least for guy who want to create nothing more but simple lua script which creates some sound after com death by mapmod now WWF_RAW is broken and Trololo works for zk only, because that noob dont know and didint detect comander in each mod :)